Jim Correia <jim.correia@pobox.com> wrote on 10/13/2004 02:09:42 PM:
> On Oct 13, 2004, at 1:40 PM, Mark Phippard wrote:
>
> >> Because it couples unrelated operations and may have unexpected
> >> results
> >> for the user.
> >
> > I haven't seen a good explanation as to what those unexpected results
> > would be. If the file were locally modified, I do not think anyone is
> > suggesting that svn lock should do an update, this is actually the so
> > called "hijack" scenario. So other than that, given that you have to
> > be
> > up to date to acquire the lock, what would be unexpected about doing
it
> > automatically.
>
> Possible unexpected side effects:
>
> 1) Person gets a lock to edit something in the file, but as a side
> effect of the update that thing has changed. I suppose this could be
> mitigated by telling the user the file has been updated.
I am not sure how "unexpected" this is, but you are correct that it would
at least need to tell the user that the item was updated.
> 2) I want to get a lock on FOO to make an edit. svn lock FOO updates it
> to a newer revision. The newer revision also has other files in it,
> some that changes in FOO depend on, but svn lock has put my WC in an
> inconsistent state that breaks the build. If I was told I was out of
> date, and did the single file update myself, I got what I deserved. I
> could also decide if now was a good time to do an svn up and deal with
> the consequences.
I think that is a pretty good reason. However, it probably applies less
to people using this feature for binary files, like Photoshop, then for
people that are using this for "normal" development because their company
is afraid of Copy-Merge-Update. For these people, while this feature
would work no worse than the same feature in VSS et. al., it does still
make some sense to encourage the use of svn up.
> It could be that these are not situations that people will run into
> often. I don't know for sure. But it strikes me as a bad idea to couple
> acquiring a lock with updating the file. If it were a good idea, why
> doesn't svn commit do silent updates on delete instead of telling you
> that you can't commit a delete on a file that isn't up to date?
Thank you, I think these are all pretty good explanations.
I do think an option on svn lock to do an update would still be a good
idea, but you are all probably right that it might not be the best
default.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 20:29:49 2004