[cvsnt] Re: forcing a text file at "non-mergable"

[Gerhard Fiedler]

Oliver Giesen wrote:

>>> P.S.: You should by all means try to forget again about the -kx
>>> option 

>> Could you please expand a little on this (reasons, motivation, pros
>> and cons)? 

> If you use -kc it is not possible anymore to accidentally forget to use
> cvs edit -c or cvs ci -c. Those options will be used implicitly on all
> files that carry that flag. IMO -kc is simply and beautifully this:
> Reserved Edits made fail-safe at last.

Thanks for getting back. If I understand that correctly, the difference
between -kc and -kx is that with -kc a missing or not allowed "edit" can be
overridden with "commit -f", whereas with -kx the only possibility of an
override is through an admin command, removing the current "edit". Is this
understanding correct?


> I also recommend reading Tony's and Jerzy's comments on the thread "Why
> edit -x?" started 2004-10-02 on this list
> (nntp://news.cvsnt.org/support.cvsnt/14940). 

Just read the thread. There's a bit of a confusion of arguments, it seems
(not that I want to re-open that discussion :)  The basis of the concurrent
model is, in a way, "developers are responsible and are able to talk to
each other and coordinate their efforts." The basis for Jerzy's argument
against "edit -x" is basically "developers are not responsible enough to be
able to withstand the attraction of an exclusive lock." Seems a bit
contradictory to me, as far as the argument goes.

Additionally, that discussion was about "edit -x". I think the file option
-kx is something quite different, in the sense that applying -kx to select
files does not lead to any other files marked unnecessarily as exclusively
edited (the main argument cited against "edit -x"). I don't see why it
shouldn't be used for files that have to be edited exclusively. I sure
would not like to notice after three days of hard work on (properly
"edited") rev 1.21 of such a file that some bozo has in the meantime forced
a commit of rev 1.22, just because he noticed after an hour of work that he
forgot to "edit" the file. If a developer can't be trusted to not use "edit
-x" when not necessary (the argument against "edit -x"), he sure can't be
trusted to not use "commit -f" when not appropriate (the argument for -kx).

Of course one could say that whoever uses a forced commit to override
somebody else's edit should be taken off the team if that was not done for
the proper reasons and with the necessary communication. But then the same
could be said of unnecessary exclusive edits. It always goes back to the
question "are people responsible to handle the feature?" And I think the
philosophy behind the concurrent model tends to say "yes, they are" -- no
matter what the feature. It's usually the "locking control freaks" who
don't trust the developers (and want to restrict the available options :)

Gerhard