> From: "Kostur, Andre" <[EMAIL PROTECTED]>
> I see many suggesting floating around on what should be added to CVS (where
> everybody seems to have a different idea of what "should" is). However, I
> don't recall seeing a roadmap to what is _going to be_ added to CVS. There
> are a few design decisions that I'd like to know more about, personally.
[...]
> 4) And I know this is going to be a contentious point: the _option_ of
> exclusive locking. Now I'm not saying that everyone should use this, or
> changing the default of do not strict lock files, but having the option
> _available_ would make CVS much more attractive to people who want that
> safety net, particularly in the case of binary files which cannot be merged.
> It would be really irritating to start modifying a file, work on it for 3
> days, try to commit it only to find that someone else changed a spelling
> error 5 minutes before you committed, with the end result that you have to
> do a manual merge on your own. An argument that I can see offhand is that
> in a widely distributed development environment, you don't want to lock down
> files for editing since the guy over in Europe (I'm North American), may
> lock a file and accidentally leave it locked. One possible solution (I
> haven't thought it through completely...) is that exclusive locks are
> "leased" for a certain period of time, and must be renewed to continue past
> that.
When we used RCS, I tried to implement exclusive locking, but most
often than not developers would just chmod u+w the file and go on
editing it. The more so when they worked on MS-Windows.
Therefore I would say that there is no way to prevent editing a file,
you can always at least edit a copy. All you can do is to check if it
has changed at check-in (commit) time, and refuse it (ask for a
merge).
Well, yes, there is: just make the developer edit the files from
within the CVS system, provide a specific CVS editor and never give
access to the files outside of this environment.
> Now do be gentle... I am looking for calm, reasoned debate, and not a
> flamefest... (although I am pulling on the flame-retardant longjohns as we
> speak....), particularly on what direction is CVS going.
I hope so too.
--
__Pascal_Bourguignon__ (o_ Software patents are endangering
() ASCII ribbon against html email //\ the computer industry all around
/\ and Microsoft attachments. V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100 2001:my($f)=`fortune`; http://petition.eurolinux.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++ UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs