[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-29 20:46:05 CET

> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Wednesday, November 28, 2007 2:43 PM
> To: brucetwilson@toomuchblue.com
> Cc: Reedick, Andrew; users@subversion.tigris.org
> Subject: RE: Communication of LOCKS and CHANGES
>
>
> Yep. How does that invalidate the other scenarios when user
> B and C can see when the file they're about to edit is
> locked?

Argh! That's the part that is driving me nuts.

What if B sees the lock, but C doesn't see the lock? (The file was
locked by A after C's update.)

        B knows not to do any work on the file.
        C merrily hacks away on the file.

How is that useful? B is happy, but A & C are going to have a merging
problem. If you're B, then the process succeeded. The process has
'failed' for A, C and the team in general.

> How are they worse off than the current situation?

Depends on how you keep score.
        no caching:
                A, B, and C, have to work this weekend to resolve the
merge. The team loses. The project is late.

        caching:
                B is up. A & C are down. A & C have to work this
weekend to resolve the merge. B wins. The team loses. The project is
late.
                or
                B is up. B doesn't care if A & C have to work this
weekend to resolve the merge. B wins. The team loses. B can blame A &
C for making the project late.

The need to lock implies that coordination is needed by the team.
Letting luck determine who gets to be A, B, and C doesn't make for much
of team.

So when is caching useful?
        - If there are dozens of locked files, caching would make it
easier to avoid working on them. This assumes that people won't be
locking additional files, which means the files are agreed on in advance
to be locked (so everyone can run update at the same time.) But then
why not slap 'needs-lock' on the files instead?
        - Courtesy locking. You lock the file to encourage people to
work on other files until you're done. If they have no other work, then
you accept that they will merge. You accept that merging may still have
to be done if someone hasn't run update since you placed the lock.
                This implies two levels of locking. Hard locks: major
changes, binary files. Soft locks: I'm making signficant changes, so
please don't force a merge unless you have to or want to.

The case of locking when making major changes doesn't benefit from
cached info or even from 'svn lock.'
The case of non-mergable files is only solved by 'needs-lock'.

So aside from 'courtesy locking' or being as lucky as B, where's the
benefit?

*****

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 Thu Nov 29 20:46:49 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.