[Paul Sander - Mon at 07:15:45PM -0700] > >2. If so, is there a way to make CVS use exclusive file locks - a la RCS & > >SCCS? > > There is a patch that changes CVS in such a way that with selected files > users must declare their intent to modify a file before they can commit > changes. These have been described as advisory locks, but they are not > exclusive, and they are easily defeated using the CVS command line interface.
According to the ACL discussion, CVS is not a security tool, hence it would be very hard to make anything else than advisory locks. The idea behind CVS is that locks never should be needed. With a bare minimum of cooperation and communication (...and the watchers feature in CVS can be a smart way of discovering that communication is needed), the most obvious conflicts should be avoided, and it usually should be okay to merge the files anyway. Of course, merging is not trivial when it comes to binary files - but then again, if two editions of a file cannot be merged, you probably won't need advanced version control anyway, merely an archive of old versions and a changelog. I do see situations where putting _some_ binary files into a cvs repository would be convinient, but I think using CVS as a version control scheme for binary files only makes sense if the files easily can be wrapped into text files, and merged somehow. > CVS can work if you apply a bunch of patches and try to keep up. However, > the patches mentioned above do not have wide support in the CVS community, > and you can't count on them being compatible with future releases. If nothing else, it should be a simple task to make an external script that fixes some kind of advisory lock. PS: I'm currently unemployed :-) I'd say using external scripts are far better than applying hacks and patches to the cvs source. -- Unemployed hacker Will program for food! http://ccs.custompublish.com/ _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
