[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Communication of LOCKS and CHANGES

From: <kmradke_at_rockwellcollins.com>
Date: 2007-11-29 19:21:24 CET

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

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

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"
outside of SVN. Why make it harder for users to get/propagate this
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,
in this case, Subversion has the information, can show it to you, but
save it so you can look at it later without having to ask the whole

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.