Re: renaming under CVS

[Noel Yap]

--- Paul Sander <address@hidden> wrote:
> Keep in mind that "permissions" include not only the
> file's mode,
> but also its user and group ownerships, plus
> whatever additional
> mechanism (e.g. ACLs) are provided by the operating
> system.  As
> files propagate around the repository then the
> permissions will
> have to behave in ways that the user expects that
> are not necessarily
> easy to implement.

Permissions need to work correctly in order to satisfy
there primary goal, security.

I'll have to check whether mv'ing the archive file
into the new location will follow the SGID bit setting
of the new directory.  If not, ln'ing or cp'ing the
archive file to its new location, then rm'ing the old
one will have to do.

> >Assuming that a file is moved from one directory to
> >another with a different group, and the SGID bit is
> >set on the repo directory, the archive file will be
> >moved adopting the new group.  An update to the
> >repo-wide archive location mapping will also be
> >necessary.
> 
> How do you expect this to affect retrieval by tag or
> datestamp?
> The person performing that task may not be a member
> of the new
> group.

Then they shouldn't be allowed to access the file
(unless other permissions are set).  If this isn't the
desired behaviour, the cvs admin will need to change
permissions within the repo.

> What about this case?
> 
> mod-a a
> mod-b a/b
> 
> Anyway, disallowing this type of sharing and that in
> the example
> above is not acceptable to me.  Code reuse by
> sharing source code
> isn't going away any time soon (no matter that the
> buildmeisters
> want it to), and the version control system can't
> get in the way
> of that.

At first, I was thinking that all the archive files
will reside within one directory in the repo.  This is
not viable if we want to have permission
responsibility owned by repo directories.  I'll have
to rethink this (and other "complex" module
definitions) in light of the fact that the archive
files will need to reside within their repo
directories.

> Also note that retrieval by tag or datestamp is
> required to retain
> the old shape of the tree.  Making that work means
> that a single
> RCS file maps to multiple locations in workspaces
> anyway, so the
> kind of sharing that I demand should come for free.

The new scheme I'm thinking of should take care of
this.

> My thought had been that if a project reaches the
> end of its life,
> should a user be permitted to delete its definition
> from the top level?
> Re-thinking this, I don't think it matters.  It's
> still retrievable by
> tag or datestamp, and the effect is no different
> from moving the project
> into a new directory and removing it from there.
> 
> The question remaining is how to query the system
> for existing modules,
> because the ones contained at the top level of the
> repository are really
> just a subset of the total possible.  There's also
> the issue of ambiguity
> of names, because a project might be removed and a
> new one created with
> the same name.

It sounds like a job for "cvs ls".  I'll leave this
for another time.

> Let's say a user does a "cvs add f; cvs commit f". 
> Obviously, this
> commits the initial contents of f to the repository.
>  But does it
> also commit the addition of f to the parent
> directory, or is a separate
> "cvs commit ." needed?  If the latter, what happens
> to the RCS file
> if the sandbox is released before the directory is
> committed?
>
> Now suppose that the "cvs add f" is really
> resurrecting a file, or linking
> (sharing) a file from another part of the
> repository.  This introduces a
> condition where the contents of the file are already
> up to date, but
> contents of the directory have been modified.  What
> should "cvs commit f"
> do, and is a separate "cvs commit ." required?
> 

These are good points.  I'll have to mull them over.

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.

> >I was thinking that the users' sandboxes would have
> >the filename mapping within its CVS/Entries files.
> 
> >For example, let's say file asdf.cc is mapped to
> >01ef,v (I'll use four nibble archive names to save
> on
> >bandwidth).  CVS/Entries will store this
> information.
> 
> >The client will look up the archive name from
> >CVS/Entries and will use only that name when
> >communicating with the server.
> 
> >The server will then lookup the location of that
> >archive within the repo using the repo-wide archive
> >location mapping.  Everything else should work as
> it
> >does now, more or less.
> 
> That will probably work, and it would seem to solve
> the evil
> twin problem well enough.

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.

> On a single-user basis, this is true.  But by
> granting exclusive
> locks on the entire repository to a single user at
> any given time
> will reduce throughput a lot.  Some kind of
> concurrent locking
> is necessary, but for demonstration purposes (i.e.
> the first hack)
> a repository-level lock should be sufficient.

I wasn't going to abandon reader-writer locks.  But
doing this introduces the problem of having a writer
block forever.  I suppose we could add better
heuristics to the locking mechanism (eg if the writer
has let three readers cut in already, let him
through).  Like you said, though, a normal
reader-writer lock mechanism is good enough for now.

> Yeah, that's why I propose a system in which
> checkouts are done
> after the versions are identified (either by tag,
> version number,
> or branch/timestamp pair).  That precludes the need
> for read locks
> altogether.

I'll have to think about this a bit more.

> >> Fair enough.  The hard link thing is a workaround
> >> for RCS' lack
> >> of a two-phase commit hook.  They can be
> eliminated
> >> by adding
> >> to RCS the ability to leave the ,*, file and
> >> renaming it back to
> >> the *,v file at a later time using the existing
> RCS
> >> mechanism.
> >> Would that be satisfactory?
> 
> >I'm not sure if "mv" is supposed to be atomic, but
> we
> >can discuss this on another thread.
> 
> I'm inclined to think that "mv" should be (it just
> updates a sandbox,
> after all), but that the commits that follow make
> the entire rename
> process not be atomic.

I think my statement was taken out of context.  We
were talking about using the OS "mv" command to create
locks.

Noel

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/