>--- Forwarded mail from [EMAIL PROTECTED]
>On Friday, February 18, Frode Nilsen wrote:
>> This whole discussion started because we have lots of files in our source
>> tree that are non merge able -> we have to assure serialized work on these
>> files. Hard locking is the only solution that guarantees that.
>I disagree, it is *one* solution that could guarantee that. There are others.
The ones you've mentioned in the past rely on out-of-band communications.
Can you suggest one that can be enforced by the VC system?
>>>Sure it is. Is your software freely available for me to browse, and see what
>>>sort of coding practices, code organization, and other structure there is
>>>within it?
>>
>>Nope. I think you would find it on the average, but we have lot of non
>>merge able files (LabView) that sometimes creates great problems when
>>someone have tried to edit them concurrently.
>Yes, merge conflicts.
...which cannot be resolved without a LOT of pain... How nice it would have
been to have been discouraged from making changes when a conflict could
have been predicted and avoided.
>> And I don't think locking can be caracterized as a whim, it is something
>> that is used in a lot of VS systems and this thread IMO has showed that it
>> also has a place in CVS that is mainly a concurrent system.
>No, I believe that a lot of these people have demonstrated that they wish
>to use CVS (however appropriate in their case) in a sub-optimal way, either
>due to software/coding practices, or their own preconceived notions of what
>CVS should be able to do.
It's being used in a suboptimal way because it doesn't provide an optimal
solution.
>> (Every problem is not a nail).
>True, however, not every problem is to be solved by CVS. You in some sense
>must be from the "mainframe/wintel" side of things, where they advocate tools
>that can do everything. Most of the original CVS people are from the unix side
>of things, where we advocate 1 tool == 1 job.
And if that one job == version control? With all of the various details
contained therein? Even in those cases where concurrent changes are clearly
undesirable? When concurrency remains the preferred method where it's
appropriate?
Bigger jobs beget bigger tools.
>> Even thoose resisting locks have showed the need of locks
>> in some cases, where you already in the cvs add command could have tould
>> that concurrency is not applicable for this file. And by doing so they
>> whould have saved them self a lot of work later on, without any extra work
>> caused by the locks on these files.
>Personally, I've yet to use *any* of the locking type features currently
>available within CVS. I've not had a use for 'cvs edit', nor for 'cvs admin'
>type "locks".
You've never worked in my environment. Our requirements obviously differ.
>> If someone writes a patch that clean up the use of locks as of today in CVS
>> it should be accepted as a part of CVS, not rejected because of the C in
>> CVS.
>Maybe. I don't speak for people who have commit access to CVS. If it is
>sufficiently clean (and there I have my doubts), and far enough out of my
>way, in such a way that it would not impact me in any way, I would not have
>much trouble with CVS having locks.
>However, if CVS changes, and I have to change my current concurrent use of
>CVS, a tool which I *specifically* picked for its concurrent features, I will
>be a very unhappy man...
Fair enough. I believe there's a user model for locks in CVS that will meet
your acceptance criteria.
>--- End of forwarded message from [EMAIL PROTECTED]
