Re: renaming under CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>--- Paul Sander <address@hidden> wrote:
>> Hmmm...  I have two problems with this.  First,
>> renaming a file
>> should not break the ability to check out prior
>> releases by tag
>> or branch/datestamp pair.  Second, renaming a file
>> on one branch
>> should not break another user's ability to work on
>> the same file
>> on a different branch.

>I agree.  I'm thinking branches can be broken off into
>their own directories.  Doing so would also introduce
>branch ACL's through the file system (but would
>partially break RCS compatibility).

I'll have to think about this.  There are compelling reasons to
move access control into the application, but I could go either way.

>> On the other hand, since once an RCS file is
>> created, it need never
>> move around the repository; only the mapping between
>> RCS files and
>> sandbox copies needs to change.  This opens up
>> another avenue for
>> access control, which is to dedicate directories
>> within the repository
>> to each group (in the access control sense). 
>> Changing group ownership
>> of a file could then equate to moving the RCS file
>> to a new directory
>> with different access controls.

>This is true.  It would also have to introduce new CVS
>commands to manage permissions since doing so directly
>through the file system would become extremely
>tedious.

Agreed.

>OTOH, it might be nice if such a command were
>introduced anyway.

It's already needed; how many times have the execute bits been
set incorrectly for various files?  I was figuring on adding
at least this capability anyway.

>> I think that RCS files can indeed live in one
>> directory, though
>> we could consider using different directories
>> strictly as an
>> access control mechanism.  The type of sharing in
>> this example
>> can easily be done if directories are described by
>> text files
>> that map RCS file names to sandbox files.

>I'm thinking a bit more about keeping all
>like-permission archive files in one place.  It may
>not be feasible when trying to deal with ACL's.  Each
>time one creates a new combination of permissions, CVS
>will need to create and keep track of a new directory.
> I'm more worried about the keeping track part rather
>than the creating part.

I still need to be educated on how filesystem-supplied ACLs
work on various Unix systems, but I'm under the impression
that their implementations are proprietary and non-portable.
This makes for a compelling reason not to support them.

On the other hand, assuming that ACL implementations can be
abstracted out reasonably well, perhaps we can cut back on the
bookkeeping by ignoring certain aspects of ACLs.  We could, for
example, require that owners have write permission, and store
execute permissions as attributes on the RCS files.  We could
also treat world read access as an attribute and world write
access would negate the need for any ACL tracking at all.
So, we narrow down to just three cases:  Owner-only access
(an easy special case), world write access (another easy special
case), and tracking group read/write access using your method.
For source control, I think that the execute bits can match read
bits for those cases where execute access is needed (hence the
attribute).

>Do you mean mapping from RCS file names to sandbox
>file names (rather than sandbox files)?

I've been using the two terms interchangeably because,
unless we're considering supporting hard links in the
sandbox, there's a one-to-one mapping between the
sandbox files and their identities.

>--- End of forwarded message from address@hidden