RE: Locking support

[Ellison, Martin [IT]]

Noel,

OK, I had a look at your patches on RCVS, thanks.

I suspect that we will need mandatory reservation. It's not coming from me,
but I work with a group of developers who are used to RCS and have developed
a process around rcs -l. Locking is not a problem for them as they are all
in the same room anyway.

I will probably rework some of the existing patches to upgrade edit to
locking. 

Regards,
Martin

> 
> Take a look under the project RCVS under SourceForge.
> 
> Please note that the "cvs edit -c" patch is for advisory 
> locks.  Nothing prevents a user from circumventing it.
> 
> The philosophy is that the advisory locking helps 
> inter-developer communication
> without preventing concurrent development.  If something has 
> a lock on it, the
> would-be editor should find out why it's there and proceed if 
> it's deemed that
> the two edits won't conflict (who knows, maybe one of the 
> edits is just for
> temporary debug printf's?).
> 
> Noel

> 
> Does anyone know the best way to put locking into CVS?
> 
> cvshome has an old patch relative to 1.9 -- is there anything 
> more recent?
> 
> If we create a cvsadmin group, this means that cvs admin -l 
> doesn't work.
> What should I do? Is there a patch to allow users to do cvs 
> admin -l and -u
> (and -k) but not any other cvs admin command? This doesn't 
> seem to difficult
> to code, so has anyone done this?
> 
> (I am not asking whether to implement locking, only how).
> 
> Regards,
> Martin
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> 
> 
> 
> This communication is for informational purposes only.  It is 
> not intended as
> an offer or solicitation for the purchase or sale of any 
> financial instrument
> or as an official confirmation of any transaction. All market 
> prices, data
> and other information are not warranted as to completeness or 
> accuracy and
> are subject to change without notice. Any comments or 
> statements made herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>