gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pau Aliagas
Subject: [Gnu-arch-users] Re: advanced usage advice: the prism technique
Date: Sun, 28 Sep 2003 17:39:48 +0200 (CEST)

On Sun, 28 Sep 2003, Andrea Arcangeli wrote:

> > If you change permissions in a tree, that is part of teh revision control, 
> > so I don't see it feasible.
> 
> Oh good point Pau, I didn't think arch was preserving the attributes in
> the patchsets. So if we mark the tree readonly the first commit would
> notice all the changes in permissions that we don't want to.

That's it. owner and group cannot be preserved by obvious reasons (the
repository can be behind an sftp, ftp, webdav or in the filesystem), but
file permissions are preserved.

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

> > What I see feasible is to, somehowm add an option to tla get to use 
> > hardlinks to library revisions or cached revisions, instead of massive 
> > copying. The library option sound easier as its exactly this.
> 
> yes, the library option sounds easier, and we should start easy by
> leaving the permissions as they're supposed to be.
> 
> > I have even thought of creating library revisions as working dirs, then
> > copying the {arch} dir inside. If your editor and patch copy-on-write, 
> > immediate support for this special "tla get --hardlinks" would be almost 
> > done :)
> 
> sounds very good ;)

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.

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.


Pau





reply via email to

[Prev in Thread] Current Thread [Next in Thread]