Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] wondering about the grimoire branches...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] wondering about the grimoire branches...
  • Date: Wed, 07 Apr 2010 12:20:47 -0700

Quoting Thomas Orgis <thomas-forum AT orgis.org>:

I read the dev meeting log and there it was mentioned that people don't use/test grimoire branches. I must admit that I'm also not good at using branches, even for testing purposes.

What I wonder about is the workflow that is expected for a branch tester. I got the master branch configured as local grimoire... I can test all stuff happening there easily. Now suppose I want to test some branches, too. Like, devel-gcc and some fresh xorg.
I could switch my local git grimoire to the gcc branch, cast gcc.... then I want to test xorg stuff, so I switch to xorg devel branch and figure out what spells to cast from there (well, it will mostly be xorg sections... plus perhaps related spells that need fixing...).

Then, I switch back to master... well, that is not pretty. I'm hampering the workability of things like 'gaze versions' as the grimoire that I cast gcc and the xorg stuff from is not there anymore. I am mixing up things.

Now, I guess the proper way would be to create a local branch and merge all the branches one wants to test into one grimoire (plus merging with updates in master... but not those conflicting with the branch). But that needs some effort from the tester that might impact its willingness to actually test. You want things to be easy to testers. They're nearly like users -- you won't get them to do anything unless it's convenient;-)
And also, when the tester creates a local merged grimoir from several branches, it is technically testing some derived work, not the original branch -- there might have been conflicts to resolve, etc.

I see a big problem in the branches being for the whole grimoire. A branch usually wants to change a small set of spells... and makes a copy of the whole grimoire for that. Everything else than the spells worked on starts to age, while the master branch gets new changes. Because of that we see big update commits to everything but the spells a branch is concerned with to sync the rest with master, I presume. What really would ease testing and acceptance of branches for being useful is a method that gets away with the cruft:

There should be some generation of overlay grimoires that contain just the spells that a branch is concerned with. Most easy way would be publishing that as periodic tarballs just like the test grimoire. The crucial point here is that that way, a tester -- not only core smgl/git hackers! -- can just add a devel-gcc grimoire on top of its other grimoires and this will just contain the core build toolchain that needs to be updated to get a new gcc. This makes it possible to stack several branch grimoires on top of each other, avoiding conflicting and outdated versions of spells that the branches aren't actually dealing with.
It should be possible to generate a tarball of only the spells that had changes since the branch has been created from master (or if there have been merges, all spells touched by commits that are not also in master), or shouldn't it?

Branches are cheap in git (really, they are!). If you want to work on multiple projects at once you can easily swap between the branches to commit changes and then make a third branch that merges all the changes for testing. Just be sure to only push the branches that are tested and working into master and not the fully merged branch. :)

I think it'd be more work to prune the branches for only the changes you want than it is to create another for merging.

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285




Archive powered by MHonArc 2.6.24.

Top of Page