> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445@att.com]
>
> > -----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.
You're not answering the question. Actually, you did, but not as you
intended. In this case B has less work than the current situation, and
A has the same work as the current situation. That is a somewhat better
outcome than not having lock communication.
>
>
> > 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.
So instead of 3 people working the weekend (and possibly being paid OT),
2 people are working the weekend, earning less OT.
> 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.
B can also be chastised by his boss for unprofessional behavior. If the
team loses, they lose no more than they would if nobody knew about the
lock.
>
> 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 lets have everybody lose? Not only is the scenario unlikely, but I
never even implied this feature could or should replace normal healthy
team dynamics.
> 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?
For large numbers of files, a branch should be used. That's a humongous
change. This scenario shouldn't happen.
> - 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.
That pretty much sums up the family scenarios I had in mind.
> 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.
Almost. The definition of "major change" in that statement would be a
restructure of an individual file, which would fall in the Soft lock
category for me. Truly major changes belong on a task branch anyway
because there will be considerable testing. At this point, the team is
accepting a future complicated merge.
>
> The case of locking when making major changes doesn't benefit
> from cached info or even from 'svn lock.'
If it is a "soft major change", I disagree. If it is a task-branch
candidate major change, I agree.
> The case of non-mergable files is only solved by 'needs-lock'.
Agreed, and not relevant to this debate.
> So aside from 'courtesy locking' or being as lucky as B,
> where's the benefit?
First, those are worthy benefits.
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).
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.
--
David Bicking
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 21:36:09 2007