Problem with locks in cvs11-1p1 (with possible fix attached).

[Andrea Gazzaniga]

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