Re: renaming under CVS

[Noel Yap]

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

>  It's hard to say how much of
> a problem this
> would be in practice, though.

What I suggest could wait until the second phase.

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

OTOH, it might be nice if such a command were
introduced 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.

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

> >There's another problem I'm thinking of:  What
> happens
> >if developer A modifies a file, developer B checks
> in
> >a move of that file, then developer A updates just
> the
> >directory of that file (rather than the entire
> >sandbox)?  My first inclination would be to say,
> "This
> >is exactly the same situation as when developer B
> >checks in a removal of that file".  But then, what
> if
> >developer A updates the entire sandbox?  In order
> for
> >this to behave properly, something in CVS must know
> >what directory the update starts.
> 
> Yeah, that's an interesting problem.  But CVS knows
> where
> the update started.  It's either the present working
> directory
> or given on the command line when the main()
> function is
> invoked.  I would hope that a new implementation
> would not
> chdir around, so it would be easy to carry that info
> around.
> (I have found that it's rarely a good idea to use
> the chdir
> call within a program for the specific reason that
> it obsoletes
> relative paths passed into the program, unless
> there's a very
> good reason to do so or it's isolated in a child
> process.)

IIRC, CVS does chdir around.  This may not be so
difficult to get around, though.  I'll have to see
when it's time to look at the code again.

> >Let's add one more mapping in the above.  The
> >directory repo will need to remap the archive name
> >back to the actual filename.  This would take care
> of
> >renames within the same directory.
> 
> Suppose you keep an RCS file in the repository whose
> versions
> represent the contents of a sandbox directory.  It
> maps the RCS
> files to the names of the sandbox copies of each
> file, plus
> whatever child directories are attached (and perhaps
> a reference
> to the parent directory).  That RCS file is tagged
> and branched
> just like any source file, but manifests itself as
> the contents
> of the Entries file rather than a source file.

This is exactly what I had in mind.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/