[Gnu-arch-users] Re: advanced usage advice: the prism technique

[Pau Aliagas]

On Sun, 28 Sep 2003, Andrea Arcangeli wrote:

> > This way you can have your 300 revisions sharing inodes; it would be nicer 
> > to have tla get -hardlinks, but nevrtheless this would work.
> 
> sounds a good start. That will do the branch creation pretty fast, but
> when I have to fix the bug in one of the pure branches, the checkout
> will still be slow right? This however would just solve the checkin
> issue, which is the first problem I've to deal with ;).

If you want to get (co) a branch and dont' have a working tree, that'd be 
slow now. It's slear tht you need an express get via hardlinks as 
discussed.

The commit (ci) will always involve the calculus of patches and its write 
out to the archive (repository). It will be fast because of the recent 
inode optimization.

> btw, I already though I need a for loop, I sure can't type those
> commands by hand 300 times ;). The main issue seems the naming of the
> branch, the "i" will be quite weird, but at least there should be no --
> in the middle of the names so I can probably preserve the current names
> without problems.

You can't avoid the "--" to separate the cat--branch--version.
I'd choose linux-kernel for the category and the branch names are up to 
you, but something in the line of what we talked seems convenient.

> I will start to experiment with it soon, now I've some more kernel work
> to do before trying this. (I will ignore the explicit tagging internal
> details for the first experiments, now that I learnt how to implement
> strict commits I don't see any blocker anymore ;)

I'd go for taglines as it's a superset of explicit and you have the same 
level of control (strict commit as you like to call it).
It has nothing to do with regexps as you seem to think reading your 
emails, it has to do with identifying a file without file forks, xattrs or 
.arch-ids.
You just ignore that taglines will be possible and use add/del as you do 
in cvs. This way you leave the door open.

> From the last email: the main issue I had is the fact I would need to
> tag each branch on top of the other

I suggested tagging all branches from marcelo's branch, in parallel, so
that merges are direct. If you need branches that include patches from 
other branches, just star-merge them in, no need to create more 
dependencies. There are cases where you clearly want to build a tree ov 
branchs, but you should think about it thoroughly. There's no magic 
recipe, it depends entirely on your needs. Anyway, I'd start without many 
complications and go on from there.

> and when I want to insert a new branches in the middle (to keep it near
> the marcelo original branch, I'd need something like a re-tag. But there
> maybe solutions already for this that I'm not aware of (one solution
> could be to recreate a new set of branches by hand with a script and to
> leave the old ones unchanged, however that will bost the version for
> every branch so it will waste quite lots of space, I'd like to share the
> patchsets in the old branches that still patch cleanly, but maybe this
> is not a reasonable request dunno for sure yet, after some more practice
> everything will be more clear).

You don't neeed to insert branches in the middle. Tag from Marcelo's and, 
if you need patches from other branches, just get them via star-merge. You 
don't need a branch to be an ancestor to get patches from it :), that's 
the real power.


Pau