info-cvs
[Top][All Lists]
Advanced

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

Re: Multilevel vendor branch import


From: Paul Sander
Subject: Re: Multilevel vendor branch import
Date: Mon, 27 Oct 2003 21:13:29 -0800

The rename problem has been discussed at length in this forum, and
several methods have been discussed.  I believe that the best way to
solve the problem is to add a layer of indirection in the translation
between working file and RCS file.  The pointer to the RCS file would
be stored in a versioned object; changing an identifier paired with a
pointer renames the file.

I can see two practical implementations of the versioned mapping:
One is to distribute it across the entire repository in the form of
versioned directories, the other is to replace the modules database
with named collections of mappings that define entire modules.
Either way, the number of special cases to handle in a concurrent
environment is quite large and it will take some effort to work out
all of the semantics.  (Examples:  When committing a rename, is it
required to commit both the source and target of the rename in the
same command?  If user A renames file X to Y, should an existing Y be
removed?  If yes, how does user B resolve a merge conflict if he
modifies his copy of Y and when A's new Y is introduced to his
workspace during a subsequent "cvs update"?)

Note that by divorcing the identities of working files from those of
the history containers (RCS files), the CVS directory-level locking
mechanism in the repository becomes impractical to manage access.
It becomes necessary to lock tags (branches and versions) whenever
they are processed, and then lock individual RCS files.  (RCS
already does this, but something would have to be done to defer the
final rename until after all of the ,*, files have been updated.
So a two-phase commit mechanism, in the database sense, is called for.)

There are some tricks that can be brought to bear to improve performance.
Intent-mode locking can be used on the tag locks to manage concurrent reads
and writes.  Identifying desired versions in advance of read operations (by
version number or by branch/timestamp pair) eliminates the need for RCS file
locks on read operations.

When an object is guarded by an intent-mode lock, the following semantics
apply:  Read locks can exist in the presence of other read locks, and a
single intent lock, and no write locks.  An intent lock can exist in the
presence of read locks and in the absence of other intent locks and write
locks.  A write lock can exist in the absence of read and intent locks.
Read locks may upgrade to intent locks after waiting for all other intent
and write locks to vanish, and intent locks may upgrade to write locks
after all read locks have vanished.  Typically what happens is that while
an object has an intent lock, it is copied and the copy is updated.  The
copy replaces the original object while the object is write locked.  The
end result of all this is that write locks need be held only during the
second phase of the two-phase commit procedure, which is nothing but a
series of renames of RCS files.  That means that "cvs update" can run
concurrently with "cvs commit" and will complete first, and "cvs commit"
will only block access to the modified files and tags for a short period
of time at the very end of its processing.

The two-phase commit also has the benefits of making changes to the
repository be truly atomic, and it opens up a better avenue for crash
recovery.

--- Forwarded mail from address@hidden

On Mon, Oct 27, 2003 at 11:52:19AM -0800, Mark D. Baushke wrote:
> CVS is a more mature product and needs to move a bit more conservatively
> oriented when considering large changes in how it works. I suspect there
> will be a place for cvs even after svn 1.0 is released.

I know, it's easy to turn a mature, useful and complicated project like 
cvs in a complete mess. Except for some exoteric uses, CVS fits the bill 
of 95% of our versioning needs, and I've been using it for 2 years know 
without major complains. Those 5% missing is due to the lack of 
copy/move/rename changes in a repository (at least in my opinion). Maybe 
some way of recording, alongside with the diffs, the file name of a 
revision, I don't know. RCS doesn't give us the flexibility needed :(

--- End of forwarded message from address@hidden





reply via email to

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