On 9/17/07, Bicking, David (HHoldings, IT)
<David.Bicking@thehartford.com> wrote:
> > -----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?
If you're using svn:needs-lock, the file will be read-only for that
user until either they manually unset the read-only bit (or their
software ignores it) or they claim a lock on the file for themself.
> 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?").
Sorry, but I think at some point, the developer has to take
responsibility for his own actions. You can only hold his hand so far.
It does not take that much effort to check for locks on the server
beyond checking the status of your working copy in the first place. If
you're properly using svn:needs-lock and your software properly obeys
the read-only attribute, this really isn't a problem.
> 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.
Then those expectations need to be reset. Subversion just plain
*doesn't* "push" information out all the time. It's a pull system.
---------------------------------------------------------------------
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:32:38 2007