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: flux <flux AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] wondering about the grimoire branches...
  • Date: Wed, 31 Mar 2010 00:35:26 +0900

Thomas Orgis (thomas-forum AT orgis.org) wrote [10.03.30 23:56]:
> 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.

There's an easy solution to get what you want: multiple copies of the
repository. Each separate working tree could be a different checked out
version. You can have each separate working copy track it's own upstream
branch, or you can set up a single local repository as a shared
repository, and have that one pull from upstream to get the updates.
Then you can check your local shared repository out as many times as you
want, and you also get everything nicely separated.

Once again, the problem is not the branches themselves. The problem is
in the way people use them (or don't use them). Git is an extremely
flexible and powerful tool, but only when used properly. The same goes
for sorcery/scribe. Maybe what we need is just a doc on the wiki
explaining how to (properly) use branches. Or maybe we need some extra
features to sorcery to make it smarter about which
branches/repos/grimoires to pull what from. I don't know what would make
things easier for people to get around it, but the functionality is
already there even if it isn't polished. Of course, correct me if I'm
wrong on any of this. :)

> 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?

I do like the idea of implementing the "overlay grimoires", simply
because there's a lot for gnome and kde that I will never cast as a
minimalist (I barely use X ever on rare occasions, but definitely not
DEs). If I don't need it, I'd rather not have it contribute to what I
have to download in the first place. There's a tradeoff though: if we
split the grimoire into a core plus overlays, we increase the complexity
of the system for the end-user who does want the extra spells. The same
goes for developers who then have to use multiple repositories just to
do a couple commits. Are we really improving things *enough* to warrant
that tradeoff if we split off into overlays? That's something we should
discuss/test before actually going through with it I think.

--
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpznN4AZcIP4.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page