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.
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