On Nov 14, 2007 8:03 PM, Bicking, David (HHoldings, IT)
<David.Bicking@thehartford.com> wrote:
> > -----Original Message-----
> > From: Erik Huelsmann [mailto:ehuels@gmail.com]
> >
>
> > > Oh, and to deal with the user's statement that "Subversion must be
> > > broken.." If svn status -u or svn get-lock return a statement or
> > > value that lets user know that "File X was locked since
> > working copy
> > > was last updated" then the user can't say that subversion
> > was broken.
> > > Then you prevent your error case *AND* provide the maximum
> > data value.
> >
> > But locks are transient - unversioned - data. There's no way
> > to know the lock existed before the update: they're not
> > related to revisions in any way.
> >
> > bye,
> >
> > Erik.
> >
>
> Erik, I don't understand why that is relevant. The idea is to show the
> state of the server, isn't it? Perhaps you're thinking about the
> concept of "revert to revision", where you're "updating" to a non-head
> revision. Is it a problem? Why does it matter that locks are
> transient?
Tom argued that the information should be retrieved with update, but
update isn't related to locking: it may even be undesirable to run
update in the middle of the preparation of a commit, yet it may be
desirable to take out a lock. He also said "file X was locked since
the working copy got updated": there's no way to tell when a file got
locked (before or after update) because locks aren't attached to a
specific revision but to a path in the repository.
Does that explain it?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 14 20:47:09 2007