http://mail.gnu.org/pipermail/info-cvs/2001-March/013565.html
I've read the information I could find in the archives, but there's one question left unanswered in my tiny little brain…:
http://www.laine.org/cvs/vss2cvs/ gives much information and scripts, but doesn't answer the one question I could really do with before making the final push to switch to CVS.
Are there any patches or techniques for CVS similar to the sharing functionality in VSS?
> Are there any patches or techniques for CVS similar to the sharing > functionality in VSS?
You can do something similar to sharing *entire directories*, via specifying lines in the file CVSROOT/modules (look up the "modules" file under "CVS Administrative files" in the documentation).
There is no CVS equivalent to VSS' sharing of individual repository files into multiple places in the work directory, though. Many people will tell you that sharing files from the repository is bad anyway, since it often makes it nearly impossible to fully test changes before doing a commit ("checkin", for a VSS person). The unfortunate reality is that it seems to get used by VSS people *a lot*. (As a matter of fact, a reorganization to eliminate shares of single files is the one thing that's still holding us back from converting :-( ).
The only suggestion I can give is to reorganize your source so that any shares are done as entire directories (and try to make as few as possible, since your modules file could otherwise get quite messy). Look at this as an oppurtunity to give your source code that well-deserved organizational overhaul you've been wanting to do for so long! ;-)
> There is no CVS equivalent to VSS' sharing of individual repository > files into multiple places in the work directory, though.
Well, not natively in CVS, but if you're running it on a server that supports _symlinks_, you can approxmate that behavior, somewhat.. Just symlink the actual repository files to multiple places, works rather well.
The political issues that you raise are correct, though, testing becomes much more complex, I generally use it for simple header files and junk that doesn't change much..
Symlinks in the repository are not for the faint-of-heart (actually, just about anything where you're mucking about in the repository isn't for the faint-of-heart), and things do occasionally get a bit goofy (usually only after I've been mucking about), but I generally find things easy to fix.
Please, backup and _test_ your backups before you go doing anything that involves hopping in to the repository directly..
jon
> > There is no CVS equivalent to VSS' sharing of individual repository > > files into multiple places in the work directory, though. > > Well, not natively in CVS, but if you're running it on a server that > supports _symlinks_, you can approxmate that behavior, somewhat.. Just > symlink the actual repository files to multiple places, works rather > well.
..until one day when the symlinked file magically becomes corrupted. CVS sets locks on a per-directory basis when it is modifying the repository (eg for a tag or commit). If a ,v file is symlinked into multiple directories, two different CVS processes might believe that they have "the lock" that allows them free reign over that file, and one will end up clobbering the other.
A symlink of a directory, on the other hand, likely won't cause any problems. but of course, you can do that via a modules file entry…
> The political issues that you raise are correct, though, testing becomes > much more complex, I generally use it for simple header files and junk > that doesn't change much..
That would lower the likelyhood of a corrupted file, but not completely eliminate the possibility.
> Please, backup and _test_ your backups before you go doing anything that > involves hopping in to the repository directly..
I'll go along with that. Heck, I even do a backup before every import, just in case I do something fumble-fingered.