On Wed, 2004-10-13 at 13:09, Jim Correia wrote:
> 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.
>
> 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.
Exactly.
We could always have a 'svn lock --update' switch.
-Fitz
---------------------------------------------------------------------
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:24:12 2004