>>> less work to attain. Why is that such a terrible thing? I am
>>> becoming quite frustrated. Can someone at least acknowledge the
>>> points I'm making, rather than set up a straw man and set
>>>
>> fire to it?
>>
>> Because it won't solve the use case you're giving us here: if
>> the file is locked, but it's not usually locked, why should
>> the developer at all decide to update it and see if it's
>> locked? For normal day-to-day operations it would be valid
>> for him to start working on the file even before updating it,
>> because any server side changes will be merged in anyway.
>>
>
> So you see no value, as a developer, in refreshing your workspace with
> any updates currently on the server before beginning work, or continuing
> work from a prior day? You'd rather be blissfully ignorant of anybody
> else's changes, wait as long as possible to merge, and then deal with
> conflicts that probably would not have existed if you updated 8 hours
> ago? Really? I have to tell you, I think that is a fabulous way to
> make more work for yourself. Have fun. I respectfully suggest that at
> least some of us would rather not work that way. Are you suggesting we
> are incorrect, and should get with the plan?
>
>
This is an interesting thread.
I work on a multi-threaded application. A while ago a co-working was
looking at some code and decided that there was a potential race
condition in some initialization code. The initialization occurred the
first time the module was used via a static if(initialize) test
throughout the module entry points. He decided that fixing the problem
right was too much work so he instead added some code that narrowed the
window in which the race condition could occur. Of course this was very
helpful because if the race condition could occur it would happen less
often and be even harder to reproduce and debug. I hope that most
everyone would agree that this was not the correct solution.
The solution being discussed here is the same type of issue. It does not
solve the problem it just makes it less likely to happen. Since it less
likely to happen people won't be thinking about it. This increases the
likelihood that when the problem does occur it will be more difficult to
deal with.
If you cache the information people will see it and believe it. And
because it's right most of the time this will re-enforce the idea that
the information is correct. Users will come to rely on the information
to make important decisions. Sometimes the results will be catastrophic.
It has been my experience that the likelihood of such a problem will
occur is inversely related to the amount of time available to do a
project and directly proportional to the importance of finishing on time.
Subversion uses a pull model to convey information from the server to
the client/working copy. This problem cannot be solved correctly with
the pull model unless you use needs lock and require files to be locked
before editing them. It is not clear to me that caching the the
information when running the status command necessarily reduces the size
of the window of occurrence. What is clear to me is that if the
information is cached and displayed a large majority of people will
assume that the information is correct.
If you work in a culture where communicating this information via
version control is important, would using a server side hook to _push_
this lock information out to the users be a much better solution? I am
not sure that you can run a script when a file is locked but I would
imagine that the post commit event occurs when the lock property is
committed. There are already scripts available that send out an email
notification during post commit. Email probably not the best solution,
there would be an random delay between the time of the event and when
people received the notification, but would guarantee everyone would be
notified automatically. It would also be possible to use some other
mechanism to reduce the delay.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 19:00:59 2007