[Top][All Lists]

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

RE: Future CVS Development

From: Kostur, Andre
Subject: RE: Future CVS Development
Date: Mon, 18 Jun 2001 14:39:53 -0700

> -----Original Message-----
> From: Pascal Bourguignon [mailto:address@hidden
> Sent: Monday, June 18, 2001 2:17 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: Future CVS Development
> > 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.

Granted, if the user chooses to circumvent the source code control system,
you're in trouble, and that's where merge becomes useful as a safety net.
But if CVS could enforce that a user declares their edits before allowing
them to commit to the repository (OK, for files declared as COPY, and -kb
files.  Ones where CVS cannot automatically handle conflicts), this would
allow people to checkout a copy of the repository without blocking anybody,
but not allowing them to edit the binary files without notifying the
repository.  Even if they take away the read-only status of the file and
edit the file that way, when they attempt to commit, CVS will refuse citing
that they are not an editor of the file.  When they then declare their edit,
CVS will complain that the local copy doesn't match the repository copy.  If
the user then does some handwaving and copies their file out of the way,
updates from the repo, then copies their file back and then commits, well...
you're pretty much out of luck.  There's not much that you can do if the
editor is willing to go that far to work around CVS.  However this does help
prevent inadvertent conflicts with binary files (at least), where CVS cannot
deal with the conflicts automatically.   And, to be quite honest, this sort
of locking doesn't necessarily have to be strict locking, it could be
advisory.  But give the user a chance to realize that the changes they're
about to make to a binary file may need to get reapplied to the binary file
since someone else is currently editing the file.

Currently CVS does have the capability of locking a file (cvs admin -l), but
this only stops the user at commit time which is after the user has expended
the effort of modifying the file which will have to be duplicated to now
modify the new file in the repository (once the lock is removed).

However, I do see one drawback to this, and that is if a user is working
without being connected to the repository, they would either be denied edit
access to binary files, or risk the conflict when they finally connect to
the repository.  That's where an advisory instead of strict lock would
probably be better since CVS could warn the user that the edit hasn't been
verified with the repository, but let the user do the edit anyway.

reply via email to

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