Re: renaming under CVS

[Mark]

If you want to version directories CVS, you will have to eliminate reliance on
actual filenames and directory names (real and meaningless filenames to be used
by CVS, not seen by user). Still use the RCSfile format for the backend.

Example repo:
/usr/local/myrepo/CVSROOT/
/usr/local/myrepo/src/
                      file1.java
                      file2.java
/usr/local/myrepo/lib/
                      jar1.jar
                      jar2.jar

1) you would need a CVS repository structure file that is versioned, that lays
out the directory structure for the repository, say add .struct to the repo
name.

/usr/local/myrepo/myrepo.struct,v
---- the contents for revision 1.2 of myrepo.struct might be:

./src:1.2:d2523
./lib:1.5:d6343

This is where directory names would be stored, to facilitate moves and renames.
example, version 1.2 of directory file d2523, which is located at ./src from
repository root.

2) you would need a versioned directory file for each directory

d2523,v
---- the contents of d2523 version 1.3 might be:

file1.java:1.8:f2344,v
file2.java:1.12:f2345,v

This is where filenames are stored to facilitate moves and renames. Same as for
directories, version 1.8 of file f2344, is in directory d2523 version 1.3 and
called file1.java

Of course this would require much work in CVS, and haven't thought much about
how the f####,v's and d####,v's would be stored in the repository since it is
very unlikely something like this will be done. In any case, it may be helpful
if the RCSfile format is extended to record each versions filename and
location.

CVS wasn't designed to version directories nor support renames and moves in the
same manor as other tools. It makes sense the CVS would have to be redesigned
to do so.

Just some thoughts after reading you post.

Mark

--- "Mark D. Baushke" <address@hidden> wrote:
> Noel wrote:
> 
> >Let me explain so even you can understand: Developer A should be able
> >to modify a file while developer B renames it.  The merge should go
> >gracefully and seemlessly regardless of who checked in first since
> >there is no conflict.  But this isn't true when using CVS.
> 
> Well, even in other systems that do version control of directories,
> the above is not usually that peaceful (cf, ClearCase).
> 
> Once long ago in a dim memory I recall on some mailing list we talked
> about the possibility of adding version control to directories.
> 
> It is possible to extend cvs to deal with renames of directories and
> files, it just requires a lot of work.
> 
> Right now cvs gets very confused if you create a subdirectory foo and
> also manage to have a foo,v in the same directory. Clean up that
> glitch by making a ,v file with the same name as a directory be a
> special version controlled entity that controls the names of files in
> that directory and you have the basis of a solution to version
> controlling names...
> 
> Of course, this means an extra few checks for files with the same
> names as directories and it also means coming up with a reasonable
> format to describe versioned elements for the directory and what it
> means to move a file to a different directory.
> 
> The biggest downside here is the performance hit of needing to look
> for a ,v file to shadow every directory. However, it may also mean
> that support for something like a symbolic link might also be possible
> and I know of a number of people that would like to see those added to
> what cvs is able to track.
> 
>       Enjoy!
>       -- Mark
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com