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

[Andrea Arcangeli]

On Sun, Sep 28, 2003 at 05:39:48PM +0200, Pau Aliagas wrote:
> On Sun, 28 Sep 2003, Andrea Arcangeli wrote:
> > Theoretically however we could teach arch to ignore any file with link
> > count > 1. That's quite an hack but it may work just fine. the new files
> > likely are created with the same permissions as the old one but only
> > with the writeable bit set again. However this sounds quite like a
> > dirty hack.
> 
> It's not useful as you could have hard links inside your tree. It wouldn't 
> work.

we don't have hardlinks in most trees (sure not in the kernel), but
you're right it's not generic.

> Maybe this could be easyly hacked. Remember that meanwhile nothing 
> prevents you from doing things like:
> 
> You have a working dir which you want to branch your versions from
> $ cd working-tree-1
> $ tla tree-version
>   address@hidden/linux-kernel--aa--2.4
> 
> for i in list_all_the_version_you_need
> 
>   Create the new version, derived from the most convenient one
>   $ tla archive-setup linux-kernel--aa-o1-sched--2.4
>   $ tla tag linux-kernel--aa--2.4 linux-kernel--aa-o1-sched--2.4
> 
>   Now, whilst we don't have tla get --hardlinks, just emulate it
>   $ cp -al working-tree-1 working-tree-2
>   $ cd working-tree-2
>   $ patch_up_to_desired_branch_with_copy_on_write
> 
>   Now the trick: once you have the tree as you'd like to, assign ot to the 
>   appropriate version:
>   $ tla set-tree-version linux-kernel--aa-o1-sched--2.4
>   $ tla make-log
>   $ tla commit
> 
> done
> 
> 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 ;).

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.

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 ;)

>From the last email: the main issue I had is the fact I would need to
tag each branch on top of the other, 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).

> Forget by now the revision libraries as working dirs... it was just a 
> suggestion on how to start to hack the --hardlinks option, and maybe not 
> to fortunate, I have't even checked.

ok. thanks again for all the good hints!

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/