Hello. I experienced a problem with locks on files imported with 'cvs import'. I looked in some newsgroups and I found many with the same problem, but no solutions. I hope the patch I suggest can be acceptable for the moment.
Let's have this situation: a file has been imported, and never changed in the main trunk. It should have a head revision 1.1.1.x in the vendor branch, and only the initial 1.1 on the main trunk. When a user locks the file, the revision locked is the 1.1.1.x in the branch. Now, the user who previously locked the file is going to check it in on the main trunk: there is a lock set in 1.1.1.x at this point, and when lock_RCS() in commit.c change the active branch, it will set the lock for checkin (commit.c:2288) in rev 1.1. If we do so, RCS_checkin will find a multiple lock and fail. This is the only patch I am able to think: remove the lock on the branch (if the owner match), before changing to main trunk. It works, but it's not very nice. The question is: since RCS allow to use non-strict locking policy, why don't use this feature for CVS, instead of make dummy locks in commit.c? It could be a way to enforce locks use for few "critical" files only, leaving the usual unreserved behaviour for all the others. Obviously, for backward compatibility with existent repositories, this new approach should be triggered by a global option (maybe in CVSROOT/config). Please, let me know if this patch will be included in a future release, or if you find a better solution (as i hope). Andrea Gazzaniga (See attached file: commit.c) P.S.: If you plan to put this message in some public site, please hide my e-mail address. Thank you.
commit.c
Description: Binary data
