[Bf-committers] developer.blender.org status

Mon Nov 11 12:52:35 CET 2013

Notes about git submodules.

Intention is to use git submodules as a replacement for svn:externals which
we used for "integrating" translations and addons into main tree.

Tricky part about submodules is that submodules in git are poiting to a
specific SHA revision of external repository. So if you want to use latest
addons you'll need to update blender's repository to use latest SHA
revision from from adons repository.

This is what we'll want for release tags. Basically, we'll create tag in
addons/translations repositories and make release tag in blender repository
track submodules with given tag name.

This is done by adding/modifying "branch" setting in .submodules file.

Now, how to deal with regular development. It is possible to update
submodules to their latest SHA:

git submodule update --remote

--remote means submodules will be updated to latest HEAD of an external
repo instead of hash stored in parent repository.

Bad thing about this is that this marks parent repository as changed with
uncommited changes (because submodule update modifies SHA of submodule
stored in parent repository). We don't want such changes to be commited by
an accident, and seems there's a workaround for this.

If you add ignore=all to .gitmodules, then parent repository will ignore
all the changes made to submodule, ingcluding modifying/adding files there
or updating HEAD of submodule. This way doing `git submodule update
--remote` will pull all the changes from submodule's repository but
wouldn't mark parent repository as changes. Roughly speaking, `git commit
-a` invoked from parent repo will say "no changes to commit" which is nice.

Fortunately, if you make changes to submodule itself (like, fix bug in an
addon) you still able to commit changes to addons repository directly from
submodule. To do this you just cd to addons submodule and do regular git
commit followed by push.

As a sideeffect of such approach, you owuldn't be able to commit changes
made to submodule together with changes made to parent repository. But in
fact, this is also rather good. Generally speaking, you would NOT want to
commit chnages to submodule and parent repo with the same commit and will
want to commit changes to submodule first and then update parent
repository. Otherwise you'll run into all sorts of possible issues.

So, the proposal is:
- Attach blender-addons, blender-addons-contrib and blender-translations to
main git's tree as a submodule (`git submodule add git://
git.blender.org/blender-addons/ ./release/scripts/addons` and so on)
- Add ignore=all to .gitsubmodules. This will be stored in blender's
repository, so you only need to do this once. No need for all the
develoeprs to modify their .gitsubmodules.
- To checkout checkout the repository: `git clone --recursive git://
git.blender.org/blender`. This will also download all the submodules. You
would need to `run git submodule update --remote` after this manually, coz
submodule's SHA might not be updated in blender repo yet.
- To update the checkout: `git pull && git submodules update --remote`.
This will pull all the changes made to blender itself and changes made to
all the external repos. This will NOT add changes from submodules to parent
repository,
- Commits from blender repo would NOT include changes made to addons
- To commit changes made to addons you simply cd to
./release/scripts/addons and do git commit and push from there

There's one weak aspect still, which is it's not clear which SHA submodules
should point to. This doesn't affect workflow proposed above, but would be
nice to have some trict policy about when and how to update submodule's
SHA. Couple of ways:
- Submodule's SHA will point to previous release's tag during current
development cycle. All the changes made to those repos will be pulled with
`git remote update --remote`, so not a bit isue wor dveelopers/regular
users.
- Update submodules's SHA with commit hook of external repositories. This
will clutter our main repo's history with bunch of "update submodule SHA"
commits.
- Manually update submodule's SHA regularly, like once a week.

And one last note about changes made to git 1.8.2 about tracking tip of a
branch. Those change only makes ti so `git remore add --branch` will add
branch=xxx to .gitsubmodules, which would make git remote --update follow
the branch specified to git submodule add command. You might do the same
change manually and there's no need to use brand-new git. And this is only
needed when one initialized submodules to blender repo, after this it
doesn't matter whether you use git 1.8.2 r older one.

On Sat, Nov 9, 2013 at 12:06 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Latest Update:
>
> * Contrib Addons will be in a separate repository from Release Addons
> * Translations repository will contain only .po files, with binary .mo
> files generated as part of build
>
> * Documentation is being written:
>
> http://wiki.blender.org/index.php/Dev:Ref/Proposals/Migration_to_Git_Phabricator#Documentation
> http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator
> http://wiki.blender.org/index.php/Dev:Doc/Tools/Git
> http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review
> http://wiki.blender.org/index.php/Dev:Doc/Process/Addons
>
> * We aim for migration somewhere next week, perhaps wednesday
>
>
> On Thu, Nov 7, 2013 at 7:33 PM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
> > The bf-extensions trackers have been migrated for testing as well now.
> >
> >
> http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration#Addons
> > http://developer.blender.org/project/view/3/
> >
> >
> > On projects.blender.org there is an bf-extensions project with various
> > trackers that not only store bug reports, but also an entry for each
> > addon. This is confusing however, and there is already a wiki page for
> > each addon with this information duplicated. We will simplify the
> > process as follows:
> >
> > * There is an Addons project
> > * The authoritative list of addons and their information is on the
> > wiki (a page here was already required)
> > * We will have Submit an Addon and Report a Bug forms for the Addons
> > project, similar to regular Blender bug reporting and patch submission
> > * Based on the wiki page information, bug reports can be assigned to
> > the relevant addon maintainer when they are triaged
> >
> > The only remaining open reports are:
> >
> > * Bugs reported to the tracker
> > * Patches in Py Scripts Upload (so, not committed to svn)
> > * Everything else is closed as archived
> >
> > The addon/extensions workflow documentation will be updated in the wiki
> later.
> >
> >
> > Feedback on this is welcome.
> >
> > Thanks,
> > Brecht.
> >
> >
> >
> > On Wed, Nov 6, 2013 at 6:46 PM, Brecht Van Lommel
> > <brechtvanlommel at pandora.be> wrote:
> >> Hi all,
> >>
> >> As you may have noticed, we now have a test version of phabricator and
> >> git running:
> >> http://developer.blender.org/
> >> http://developer.blender.org/diffusion/B/
> >>
> >> These are both test versions and work is ongoing, so don't base any
> >> actual work on them yet. You will have to redownload the git repo and
> >> recreate any data on developer.blender.org when the final thing goes
> >> live. As we are planning to switch to them next week, now seems a good
> >> time to get some feedback from other developers.
> >>
> >> Migration status:
> >> http://wiki.blender.org/index.php/Dev:Ref/Migration_to_Git_Phabricator
> >> Phabricator docs:
> http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator
> >>
> >> You can basically go to developer.blender.org and check things out,
> >> your username and password from projects.blender.org will still work.
> >>
> >> There's still a bunch of incomplete things that we are working on,
> mainly:
> >> * Addon and translation repositories
> >> * Patch / code review submission clarity
> >> * Migrating bf-extensions trackers
> >> * Documentation for git, arc, building, ..
> >>
> >> Feedback is welcome!
> >>
> >> Thanks,
> >> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
With best regards, Sergey Sharybin