> -----Original Message-----
> From: Noel L Yap [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 8:49 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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.
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
