> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> > I have to disagree with the assertion that it would be
> useless in the
> > working copy. True, it could become invalid between updates,
>
> Well, I'd not use the word /could/, I'd say *will*, because
> there's no saying how long either the lock owner will keep
> the lock or how often the user will update the working copy.
>
> > but at
> > least the user has some idea that a file she wants to use
> is locked by
> > someone else as of the last update.
>
> If you want to update the file, obviously, you'd need to
> acquire the lock first. At that time, the client needs to
> contact the server to acquire it. If a lock is already held,
> the user will be notified of that fact...
>
> > Then, a quick update will verify if
> > that is still the case, and if it is the same person.
> Armed with this
> > information, she can then contact that person and
> coordinate their work.
>
> ... and with that information she can go through the steps
> you describe above.
>
> > Without any lock identification on the client side, it becomes a
> > manual process that requires the user to remember to check
> for locks,
>
> Not really, but it would require the user to lock the file,
> which, obviously you want the user to do anyway...
>
> > examine
> > the list of files, and be sure the one that has her
> interest is not in
> > the list.
>
> > Can you see the value in this? Is there a chance you might change
> > your mind?
>
> Not yet, sorry.
>
> bye,
>
>
> Erik.
Interesting. What happens when a person gets a lock on a file while
another person begins working on his own local copy? Am I correct in
believing that the user who doesn't have the lock will do his work
oblivious to the new lock until he attempts to commit? What happens if
the person who has the lock made changes that make the second person's
work totally useless?
It seems to me that it would be useful to know this with a quick
"update" operation. Keep in mind that I'm looking at this through the
eyes of joe (microsoft) developer who is using an IDE integration. Many
of them are a bit more "lazy" when it comes to SCM. They don't want to
execute a "list all changes on the server" operation. They want to see
a visual notification that something interesting changed ("oh, gee, with
this update, the file I'm editing suddenly has a padlock on it! I
wonder who did that?").
Granted, the individuals who may or may not be giving me a hard time for
the lack of this notification, might not want to do even the work I'm
suggesting. There are some people who expect the server to be pushing
out information all the time. I'm merely putting this out there as an
issue that I agree has some merit for the above reasons.
A few bytes of information in the working copy can't hurt that much, and
the fact that it will almost certainly be out of date quickly is true
for every other aspect of the working copy, too, so why bother keeping
one?
> From: Andy Levy [mailto:andy.levy@gmail.com]
>
> How would this be any different (or better, from a user's
> perspective) from just enforcing the svn:needs-lock property?
> Before the user edits the file, they'll need to obtain the
> lock, and if someone else has it, they'll be informed at that time.
True, except when user "B" doesn't want a lock, but does want to edit
without worrying about being invalidated later.
I was interrupted from writing this just now by someone arguing
vigorously for the importance of the user being notified when someone
else has any file "checked out" (I'm not even talking about locks here).
Perhaps it is just a philosophical difference that cannot be bridged
with some people.
He feels it is critical for coordination between developers, rather than
finding out "at the end" that there is some conflict, and doing it any
other way imposes an "external manual process" of coordination. The
model is completely different from Subversion. Users need to tell the
server they intend to edit "this file". I'm afraid it is VSS legacy.
However many other commercial products work in the same way.
Have you encountered this kind of attitude? Would you say it is
"wrong"? How would you convince someone of a different way?
--
David
*************************************************************************
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 Mon Sep 17 17:16:18 2007