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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
