> > You are assuming I want to know what files are safe to work
> > on. I want to know what files are POTENTIALLY unsafe to work
> > on. I will check the repo if I want the true status. People
> > work in different ways.
>
>
> > You said the information "is useless", but then gave an
> > example where it was useful...
>
>
> Relying on cached lock information implies that you do not care about
> locks in the first place.
There is a definite disconnect here somewhere. I'll agree that you
have no need for the usage case I (and others) have described multiple
times.
People can care about a lock without wanting to get the lock at that
exact moment. Your scenarios below are only a piece of the possible usage
cases.
I agree that the usage case you describe is valid. The intent of
lock caching is not to solve this scenario. (It also doesn't hurt this
scenario since it is no worse or better without lock caching)
> I) If I run status/update 5 minutes after someone placed a lock, then
> the Locker and I win.
>
> II) If I run status/update 5 minutes _before_ someone places the lock,
> then
> a) an (exciting?) merge will need to be performed and either
>
> b1) the Locker gets chastised for not notifying people
> (via email) that a major change was being done and that anyone else
> already working on the file needed to coordinate with the Locker.
> (Locked for a reason.)
>
> b2) or, if there is no need to chastise the Locker then
> everyone is following or accepts SVN's standard copy-modify-merge
> paradigm, in which case, there was no need to lock the file in the first
> place. (Locked for no reason.)
>
>
> In short, relying on cached lock information implies that you do not
> care about locks in the first place.
>
> This problem also applies to 'svn lock'. So the only "rational" way to
> use locking in SVN is to a) communicate locks outside of SVN (email,
> etc.,) or b) use 'needs-lock'.
Email communication is just a different form of "lock status caching"
implemented
outside of SVN. Why make it harder for users to get/propagate this
information
by forcing them to use another tool? Why make every team that wants/needs
this information invent a custom way to propagate it?
Yes, it doesn't make any sense to put all functionality into Subversion,
but
in this case, Subversion has the information, can show it to you, but
doesn't
save it so you can look at it later without having to ask the whole
question
again.
In this case I am fully aware the status may not be the current status,
but I'm
fine with that. I'll ask the question again if I truly want to take
the time to ask the whole question and contact the server.
> To go back to Mr. Bicking's roof analogy. People aren't saying that a
> meteor-proof roof is the only viable solution worth pursuing (perfect
> roof or nothing.) Instead, we're trying to say that cached lock info is
> similar to building a small section of roof on rails, and then sliding
> that section of roof over you as you move from room to room. Your head
> may stay dry, but you will still end up sitting on wet furniture.
> Sliding roofs (and cached lock info and 'svn lock') do not solve the
> problem of why you need a roof in the first place.
It is more like creating a small section of meteor proof roof on rails
above your existing roof. That way when your house is hit by a meteor
you will live, even if your belongings are all destroyed.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 19:21:59 2007