> > Many times before, people have had misconceptions about what
> > a lock is, and how it should be handled. I'm not going to
> > talk about what it is, because I'm assuming the interested
> > people already know this. Instead I'm talking about what can
> > be done to communicate this better, to the average unsuspecting user.
> >
> >
> > #1
> ----snip----
>
> I agree with these observations, and reiterate that it is very useful
> for peers to see when files are locked, and by whom. I don't really
> care how it is done.
Good.
> Since the feature is useful to all IDE plugins and
> integrations, it makes sense to consolidate the logic in the core
> system, rather than force all integration clients to implement their own
> technique (in this case by a combination of "update" and "status -u" and
> proprietary local cache files).
No. Locking is independent of update. There is no reason whatsoever to
run update on a locked target. It won't unlock it - ever.
> Personally, if I see a file I want is locked, the first thing I will do
> is "update" and see if it is still locked.
No need. Stronger: No reason. Locking is independent of updating;
there simply is no relation other than that they may concern the same
path in the same (virtual) filesystem.
> Then I can take action or postpone my work.
> Right now, I don't see that it is locked until I try
> to commit it or I _remember_ to explicitly check for locks.
If a file can't be merged, this is where your error is: your workflow
conflicts with the type of file you're chaning. You need to lock the
file before editing it. No need to check for locks: 'svn lock' will
tell you someone else has the file locked already, all this means
you're doing *more* work than required, not less. If you were to lock
the files before editing them, instead of "update", "status", "lock",
"update", you could do with "lock", "update". Clearly this is less
work.
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 20 16:26:08 2007