[cvsnt-dev] Re: Feature Request: warnings on edit

Christian Schmidt christian2.schmidtREMOVE_THIS at gmx.de
Thu Jul 1 09:13:41 BST 2004

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Tony Hoyle wrote:
>> But if everyone wants to work with reserved edits and someone
>> forgets to call update before edit you might end up in a conflict.
> .. which CVS is well equipped to handle, in most cases.

There are endless discussions whether reserved edits are necessary or not.
There are good arguments for both opinions. Our policy is using reserved
edits. So we try to avoid merging due to conflicting commits.

> Remember reserved edit is just a hack.  It's not really a true
> reserved edit and probably never will be.

We can live with this hack very good. Sure, one can work around reserved
edits, but we _want_ to work with reserved edits and if a user gets a
warning that an other user is editing the file he wants to edit, he picks up
the phone and calls the other guy to resolve the conflict.

>> BTW I think edit on tagged or not up-to-date files _is_ an error -
>> or at least it's an action that the user should be warned of.
> Not really - you can have multiple editors of the same file.  Edit
> doesn't change the state, it just states that you are interested in
> that file at the moment.  10 people could be editing the same file
> with no problems... a lot of the time they'll be using out of date
> copies.
> The -c hack just limits that to one at a time, it doesn't change the
> semantics.  You're just stating that you're interested in the file at
> the moment - nothing more.

... and the other guys respect that interest - at least in our organization.
So reserved edits support our process of software development.

>> Why? We use this feature sometimes to temporarily prevent users from
>> modifing certain directories.
> chacl would be quicker, or just set the permissions on the directories
> (trusting the users is even better...).  edit does not prevent users
> from doing anything if they really want to.  If they're using a client
> that doesn't support commit -c it'll just go ahead anyway.

As I said, we don't have problems with guys working around reserved edits.
chacl is no option, because our frontend does not (and needs not) support
it. Edits do exactly what we want: Warn the user and tell him to call the
editor of the file, to get to know whats going on.

>> But you can't edit a tagged version of the file. At least you can't
>> commit changes to a tagged file, so consequently you shouldn't be
>> allowed to edit it.
> You could do the edit, then update -A, then commit.  The edit is still
> valid after the update.

Actually you should do the update -A first, then edit and then commit. But
you can't edit and commit only. So that's why I think you should warn the
user, that he has to do something before he can commit his edits. And he
should be warned, before he starts to hack code and that is when he calls


More information about the cvsnt-dev mailing list