[Bf-committers] developer.blender.org status

Dalai Felinto dfelinto at gmail.com
Mon Nov 11 14:32:42 CET 2013


> - Manually update submodule's SHA regularly, like once a week.
I think this is reasonable, and how we do for translations already.

Apart from that I think it's a nice workflow.

Cheers,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com


2013/11/11 Sergey Sharybin <sergey.vfx at gmail.com>

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list