[Top][All Lists]

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

Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es f

From: Zenaan Harkness
Subject: Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files
Date: Mon, 27 Sep 2004 09:24:14 +1000

On Mon, 2004-09-27 at 09:09, Jason McCarty wrote:
> Zenaan Harkness wrote:
> > Isn't --link kind of mutually exclusive with "desired shared revlib
> > perms"?
> > 
> > To my newbie mind it only really makes sense to disable --link on shared
> > revlibs. Don't know how one could determine that though... revlib
> > meta-data?
> My thought is that to make shared revlibs work, all files in the revlib
> would be chmod 444 (555 for dirs and executables), and tla would set the
> permissions from recorded meta-data when it built a tree.
> But if you want to use --link on such a revlib, a link-breaking editor
> is no longer sufficient. You need a new "tla edit" command or similar,
> which would break the link and set the permissions of the new file to
> those recorded in the meta-data.

This is the way (no comment on goodness) bitkeeper does it, as most
probably know by now.

Then it/you'd have an option to check out a tree where all files are by
default editable (not linked, and all writable), as alternative to
"tla edit".

And then you export EDITOR and alias vi="tla edit".

Which option you use depends on your tree size and needs.

> The way to go on this depends on how much shared revlibs are valued
> versus ease of working with a hard-linked tree (the current problem of
> permission changes not being detected is just a fixable bug, and
> shouldn't enter into consideration on this issue, IMO). Certainly a
> per-revlib flag could be added to let the user decide, but that also
> ramps up the learning curve ;-)

reply via email to

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