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" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs