info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future CVS Development


From: Pascal Bourguignon
Subject: Re: Future CVS Development
Date: Mon, 18 Jun 2001 23:17:05 +0200 (CEST)


> From: "Kostur, Andre" <address@hidden>

> 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------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]