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

[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: Matthew Dempsky
Subject: Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files
Date: Sun, 26 Sep 2004 00:40:19 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Zenaan Harkness <address@hidden> writes:

> On Sun, 2004-09-26 at 08:04, Matthew Dempsky wrote:
>> I wonder if permissions aren't just outside the scope that arch should
>> be trying to address anyways.  It would seem ugly trying to
>> interroperate between two companies where one requires a umask of 077
>> while the other might have no requirements and everyone just defaults
>> to 002 or 022.
>> 
>> Yeah, they could do some arch magic like one company tags off a
>> branch, changes permissions and commits, then has the other company
>> tree-sync with the revision, but they'll have to repeat that each time
>> a new file gets added to the source tree.
>
> Actually, I'd think that, surely, this decides it - due to issues
> including revlib sharing, providing public access to archives, etc,
> the only sane way to handle perms is for them to be file meta-data.

Sure, but all of those matters are site-specific.  I don't need to
share revlibs on my laptop, your site might want to share revlibs
between everyone, other groups might want to only share revlibs
between small knit groups to minimize the risk and damage of
corruption.

If tla manages this (as part of the archive meta-data at least) rather
than umask, every site has to share this data or at least go through a
bunch of work so their personal revisions are just the way they like
it.

> Files must be able to be publicly readable when in an arch archive.

In an arch archive, sure, but the working directories just need to be
in whatever shape the user wants to edit them in.

> Permissions must be version controlled.

Not by arch (other than maybe +x).




reply via email to

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