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: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] wondering about the grimoire branches...
  • Date: Wed, 07 Apr 2010 22:05:05 +0200

Excerpts from Eric Sandall's message of Wed Apr 07 21:20:47 +0200 2010:
> 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.

Definitely yes. I've kept personal merged branches for a long time without
problems. Especially as you can easily pull from both master and a devel
branch
to the merged branch, since git handles repeated merges well. Pruning would
be
a lot of work that is imho wasted, since just creating a merge branch for
testing is essentially free with git.
Is our git repo accessible over http for non-developers? That's the only use I
see for devel tarballs. With git accessible, a page explaining how to create
such a merged branch would be enough.
--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page