[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: Reedick, Andrew <jr9445_at_ATT.COM>
Date: 2007-11-30 23:08:10 CET

> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Friday, November 30, 2007 2:32 PM
> To: Les Mikesell
> Cc: kmradke@rockwellcollins.com; Reedick, Andrew;
> users@subversion.tigris.org
> Subject: RE: Communication of LOCKS and CHANGES
>

> Sure, review this message again:
>
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=7218
> 2
>
> Add to that the user id, and you know both who is radically altering
> the
> file, and why. Given this information, if you've not yet started work
> on that class, you might decide to:

        This thread has broken into two steams as far as Outlook is
concerned, so this may appear redundant.

        David is talking about 'courtesy' or soft locks (for lack of a
better term.) If you absolutely must avoid a merge, you need to use
'svn lock' and announce the lock to your teammates (email, IM, etc.)
That would be a hard lock. All sides agree on this. (Lock and
broadcast.)

        A soft lock is when you want to tell others to "please avoid
working on this file unless you have to." It's soft because cached lock
info isn't a reliable way to transmit lock info. You lock the file. If
Bob runs update after you lock, then Bob sees the lock and knows to work
on other files. If Bob hasn't updated since you placed the lock, then
Bob doesn't see the lock and you and Bob will have to merge. It's not
"important" enough to completely lock the file down (hard lock) so it
acts as a soft or courtesy lock. (Lock but no broadcast message.)
        It's interesting to note that 'svn lock' is also a soft lock
unless paired with 'needs-lock'.

> Regardless of the choice I make, I have to wait for the lock release
> before I can commit. Knowing the file is locked should clue me in to
> the probability that major merge is in my future. Maybe I want to
> mitigate that.

        Currently SVN lets you find out about locks at commit time,
which is a tad late. Ideally, you see the lock as it is placed, or
better, the Locker-To-Be can see who is already working on a file.
However, since the SVN client pulls data, there's no reliable way to
keep lock info current w/o constantly pinging the server.
        Therefore, if you're working in a 'soft lock' environment then
cached lock info can sometimes, if you're lucky (or if you run
update/status often,) identify locks before you work on a locked file,
which should be better than nothing.

*****

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 30 23:08: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.