RE: Future CVS Development

[Kostur, Andre]

> -----Original Message-----
> From: Noel L Yap [mailto:address@hidden
> Sent: Monday, June 18, 2001 8:49 AM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: Future CVS Development
> 
> 
> 
> >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.
> 
> Or how 'bout using the edit and commit patches that more or 
> less give you
> advisory locks.  I'm thinking you may also want to add (if 
> it's possible without
> breaking something like client/server) a server-side config 
> that would make
> these flags a default.

(I'm still pondering a coherent response to 1-3)

Now there's the rub... it requires patches to get advisory locks.  I'm
talking about baseline CVS, as shipped out-of-the-box.   And, the patches
aren't necessarily kept up-to-date with the latest CVS.