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.
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?
Jim
---------------------------------------------------------------------
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:10:19 2004