> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Thursday, November 29, 2007 3:35 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: RE: Communication of LOCKS and CHANGES
>
>
>
> > So aside from 'courtesy locking' or being as lucky as B,
> > where's the benefit?
>
> First, those are worthy benefits.
I agree that it is a benefit. However, it's a very unreliable and
random benefit.
> Knowing what's going on as of the last update is beneficial, whether
> you
> believe it or not. If I want a lock because I don't want to deal with
> a
> complex merge, doesn't it make sense to give the other developer(s) a
> heads up so they might avoid it too? Am I going to spam them when
this
> happens? I know two of my teammates who don't even see my email for
> hours after I send it (read receipt is useful that way).
Well, that's just it. You may or may not have avoided a complex merge.
If you really, really, really want to avoid a complex merge, you must
phone/IM/email/sneaker-net that fact to the relevant parties. So yes,
spamming is the 'correct' answer.
Caching is the UDP of locking. The lock notice may or may not have been
reached the recipient. You just don't know, which implies that the lock
isn't that important to begin with.
OTOH, as I stated previously, cached locking would prevent a complex
merge if you have a policy in place to ensure that locks must be placed
24 hours in advance and people must run status/update at 9am daily.
Then I would definitely want to see cached lock information, since it
would be reliable and thus quite useful.
> If I'm assigned to one feature, and two other people are assigned to
> other features that happen to use the class I'm updating, it is very
> possible they might need to make minor changes to it for their tasks.
> Further, I submit that it should not be necessary for individuals to
> send out team-wide emails every time they want to lock a file "just in
> case" someone else decides to modify it. Frankly, it isn't worth my
> time. Why not let them discover it through SVN?
>
> I'm neither talking about an earth-shattering, world-changing benefit,
> nor a massively complicated and interface-breaking enhancement. I
just
> want to see what's already there.
Understood. I agree that cached info provides some benefit. However,
its unreliability in communicating lock information makes it an
extremely limited benefit, and it's not worth the development effort to
make this a standard svn feature, nor worth the headache of telling
everyone about one more thing in svn that you have to be wary of (in
addition to lack of merge tracking, svnmerge.py, lack of true renames,
bi-direction merging issues, etc.)
I could see TortoiseSVN implementing this due to file icons and the
relative ease of coding such a feature in a *-windows environment.
Especially if they made Tortoise more chatty by running 'status -u' in
the background.
Even then, I'd much rather see a more reliable and complete
implementation of courtesy/soft locks in which the client would tell the
server what files are being worked on, which would make it easy to
communicate both hard and soft lock information. (Yes, I'm aware that's
a paradigm shift and would only benefit folks on a closed, corporate
style LAN/environment.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 30 18:42:51 2007