You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com> on 2007/09/14 20:08:45 UTC
Finding Locks
Hello,
I'm just a font of annoying questions lately, aren't I? I just played
with the lock feature and I see that in Ankh and Tortoise there is a
visual cue on files locked by "me" in the workspace. However, I see no
such cue on a secondary duplicate workspace even after I "update".
I suspect that this is because the workspaces that do _not_ have the
lock have no indication from the repository that locks exist. Is this a
correct guess? If so, I have a feature request. It would be nice for
the workspace to know which files have locks on them (upon "update", of
course), and better yet, to know who has those locks. Similar to my
earlier feature request, the information could be used by clients like
Ankh to offer this information in a mouse-over or on a properties
dialog. If the information is already available to the workspace, then
I'll take my feature request directly to Ankh and tortoise ;)
--
David Bicking
*************************************************************************
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
RE: Re: Finding Locks
Posted by "Thompson, Graeme (AELE)" <Gr...@smiths-aerospace.com>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: 17 September 2007 14:52
> To: Bicking, David (HHoldings, IT)
> Cc: Larry Martell; listman; Erik Huelsmann; Miller, Eric;
> users@subversion.tigris.org
> Subject: Re: Finding Locks
>
<snip>
> > > > what command should we be using to get the list of
> locks from the
> > > > server?
> > >
> > > svnadmin lslocks
> > >
<snip>
If you want to get the list of locks from the client you can use (from
within your working copy):
svn status -u -v | grep "^.....[^ ]"
You can alter this command to find the list of locks for a user by
adding the username to the grep command:
svn status -u -v | grep "^.....[^ ].*uname"
(I know that this is not perfect but we do not get many false positivs
where the username is in the filename...)
Hope this helps,
Graeme
************************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Finding Locks
Posted by Andy Levy <an...@gmail.com>.
On 9/17/07, Bicking, David (HHoldings, IT)
<Da...@thehartford.com> wrote:
>
>
> > -----Original Message-----
> > From: Larry Martell [mailto:larry.martell@gmail.com]
> > Sent: Friday, September 14, 2007 5:57 PM
> > On 9/14/07, listman <li...@burble.net> wrote:
> > >
> > >
> > > On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
> > >
> > > >>> I suspect that this is because the workspaces that do
> > _not_ have
> > > >>> the lock have no indication from the repository that
> > locks exist.
> > > >>> Is this
> > > >> a
> > > >>> correct guess?
> > > >>
> > > >> Yep.
> > > >>
> > > >>> It would be nice for
> > > >>> the workspace to know which files have locks on them (upon
> > > >>> "update",
> > > >> of
> > > >>> course), and better yet, to know who has those locks.
> > > >>
> > > >> I agree, this would be quite useful. Locking has always seemed
> > > >> like such an afterthought and really doesn't get a lot
> > of attention.
> > > >
> > > > I can't help it, but this is by design, not because locking is or
> > > > was an afterthought: it would be really useless to have this
> > > > information in a working copy, because the minute it's stored in
> > > > the working copy, that information may be outdated.
> > > >
> > > > If you want to have up-to-date information on locks, you need to
> > > > contact the server. That's what this 'non-availability' of
> > > > information is about...
> > >
> > > what command should we be using to get the list of locks from the
> > > server?
> >
> > svnadmin lslocks
> >
>
> I have to disagree with the assertion that it would be useless in the
> working copy. True, it could become invalid between updates, 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. 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.
>
> Without any lock identification on the client side, it becomes a manual
> process that requires the user to remember to check for locks, examine
> the list of files, and be sure the one that has her interest is not in
> the list.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Notification of checkouts (was: Re: Finding Locks)
Posted by Lorenz <lo...@yahoo.com>.
>On Sep 17, 2007, at 10:19, Bicking, David (HHoldings, IT) wrote:
>> 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.
I see that as a "I want to know when someone is messing with MY files"
attitude, that is not satisfied by being notified (by commit email or
log) after it has happend.
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Notification of checkouts (was: Re: Finding Locks)
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
>
> On Sep 17, 2007, at 10:19, Bicking, David (HHoldings, IT) wrote:
>
> > 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.
>
> Note that the Subversion operation "checkout" does not really
> correspond with a dictionary definition of "check out". If
Yes, that was the point I made. This particular individual doesn't like
that, for reasons I cannot quite understand. I think it is a knee-jerk
reaction to "difference", because even with the system he's currently
using, you only see the most recent person who "checked out" the file.
>
> If you still want to be notified when someone "gets a copy",
> Subversion does not provide hooks for this, but you can fake
> them, as long as you are serving your repository using Apache
> 2. I provide a script that helps you with this:
>
> http://www.ryandesign.com/svnhookdispatcher/
>
>
This may come in handy, though in our case everybody on the team and
several who aren't will pull down the files, so it doesn't serve the
purpose this guy wants.
--
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
Re: Notification of checkouts (was: Re: Finding Locks)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 17, 2007, at 10:19, Bicking, David (HHoldings, IT) wrote:
> 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.
Note that the Subversion operation "checkout" does not really
correspond with a dictionary definition of "check out". If you think
of "check out" as in a public library, when you check out a book, you
physically take the book away, and nobody else can have it until you
check it back in. But in Subversion, "checkout" really means "get a
copy". It would be like going to the library and photocopying
whatever material you want and taking the photocopies home. Anybody
else can still go to the library and do the same. And just because
you took home some photocopies, that doesn't mean you'll ever bring
them back with notes in the margins expecting them to be incorporated
into the original book. You might do that (svn commit workingcopy),
or you might just as easily throw the photocopies away after you've
looked at them (rm -rf workingcopy). Given this, it's not necessarily
useful to know when someone checks out the code.
If you still want to be notified when someone "gets a copy",
Subversion does not provide hooks for this, but you can fake them, as
long as you are serving your repository using Apache 2. I provide a
script that helps you with this:
http://www.ryandesign.com/svnhookdispatcher/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Finding Locks
Posted by Rainer Sokoll <R....@intershop.de>.
On Mon, Sep 17, 2007 at 11:19:45AM -0400, Bicking, David (HHoldings, IT) wrote:
> 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 the file has the property svn:needs-lock, the file is r/o in the wc's
filesystem. That means, without having a lock, it is (not so easy) to
edit the file.
> 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?").
TSVN has its own overlay icons, it is easy to see which files are r/o
and for wich files the user has a lock.
The same for Subclipse, others I do not know.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Finding Locks
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
>
> > 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.
I'm refering to the case where normally, operations are not locked down,
but a user locks the file with the expectation that they will make major
changes.
>
> > 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.
Your point is the one I make, but that doesn't mean it will be accepted.
>
> > 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.
Yes. Remember, though, I am evaluating different packages for adoption,
so it will come down to "reset the expectations" or "this isn't for us".
This is the reason for my probing questions.
> -----Original Message-----
> From: Rainer Sokoll [mailto:R.Sokoll@intershop.de]
> > 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?").
>
> TSVN has its own overlay icons, it is easy to see which files
> are r/o and for wich files the user has a lock.
> The same for Subclipse, others I do not know.
>
> Rainer
Well, yes and no. I verified that TSVN (and Ankh) only shows an overlay
for items locked by the workspace that initiated the lock, which lead to
my initial post. There is no information available by standard "update"
that would let TSVN choose an icon to identify the state as defined by
OTHER users. This is why I suggested the information be included in the
workspace update info.
--
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
Re: Finding Locks
Posted by Andy Levy <an...@gmail.com>.
On 9/17/07, Bicking, David (HHoldings, IT)
<Da...@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
RE: Finding Locks
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----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
Re: Finding Locks
Posted by Erik Huelsmann <eh...@gmail.com>.
On 9/17/07, Bicking, David (HHoldings, IT)
<Da...@thehartford.com> wrote:
>
>
> > -----Original Message-----
> > From: Larry Martell [mailto:larry.martell@gmail.com]
> > Sent: Friday, September 14, 2007 5:57 PM
> > On 9/14/07, listman <li...@burble.net> wrote:
> > >
> > >
> > > On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
> > >
> > > >>> I suspect that this is because the workspaces that do
> > _not_ have
> > > >>> the lock have no indication from the repository that
> > locks exist.
> > > >>> Is this
> > > >> a
> > > >>> correct guess?
> > > >>
> > > >> Yep.
> > > >>
> > > >>> It would be nice for
> > > >>> the workspace to know which files have locks on them (upon
> > > >>> "update",
> > > >> of
> > > >>> course), and better yet, to know who has those locks.
> > > >>
> > > >> I agree, this would be quite useful. Locking has always seemed
> > > >> like such an afterthought and really doesn't get a lot
> > of attention.
> > > >
> > > > I can't help it, but this is by design, not because locking is or
> > > > was an afterthought: it would be really useless to have this
> > > > information in a working copy, because the minute it's stored in
> > > > the working copy, that information may be outdated.
> > > >
> > > > If you want to have up-to-date information on locks, you need to
> > > > contact the server. That's what this 'non-availability' of
> > > > information is about...
> > >
> > > what command should we be using to get the list of locks from the
> > > server?
> >
> > svnadmin lslocks
> >
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Finding Locks
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Larry Martell [mailto:larry.martell@gmail.com]
> Sent: Friday, September 14, 2007 5:57 PM
> On 9/14/07, listman <li...@burble.net> wrote:
> >
> >
> > On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
> >
> > >>> I suspect that this is because the workspaces that do
> _not_ have
> > >>> the lock have no indication from the repository that
> locks exist.
> > >>> Is this
> > >> a
> > >>> correct guess?
> > >>
> > >> Yep.
> > >>
> > >>> It would be nice for
> > >>> the workspace to know which files have locks on them (upon
> > >>> "update",
> > >> of
> > >>> course), and better yet, to know who has those locks.
> > >>
> > >> I agree, this would be quite useful. Locking has always seemed
> > >> like such an afterthought and really doesn't get a lot
> of attention.
> > >
> > > I can't help it, but this is by design, not because locking is or
> > > was an afterthought: it would be really useless to have this
> > > information in a working copy, because the minute it's stored in
> > > the working copy, that information may be outdated.
> > >
> > > If you want to have up-to-date information on locks, you need to
> > > contact the server. That's what this 'non-availability' of
> > > information is about...
> >
> > what command should we be using to get the list of locks from the
> > server?
>
> svnadmin lslocks
>
I have to disagree with the assertion that it would be useless in the
working copy. True, it could become invalid between updates, 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. 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.
Without any lock identification on the client side, it becomes a manual
process that requires the user to remember to check for locks, 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?
Thanks
--
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
Re: Finding Locks
Posted by Larry Martell <la...@gmail.com>.
On 9/14/07, listman <li...@burble.net> wrote:
>
>
> On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
>
> >>> I suspect that this is because the workspaces that do _not_ have the
> >>> lock have no indication from the repository that locks exist. Is
> >>> this
> >> a
> >>> correct guess?
> >>
> >> Yep.
> >>
> >>> It would be nice for
> >>> the workspace to know which files have locks on them (upon "update",
> >> of
> >>> course), and better yet, to know who has those locks.
> >>
> >> I agree, this would be quite useful. Locking has always seemed like
> >> such an afterthought and really doesn't get a lot of attention.
> >
> > I can't help it, but this is by design, not because locking is or was
> > an afterthought: it would be really useless to have this information
> > in a working copy, because the minute it's stored in the working
> > copy, that information may be outdated.
> >
> > If you want to have up-to-date information on locks, you need to
> > contact the server. That's what this 'non-availability' of information
> > is about...
>
> what command should we be using to get the list of locks from the
> server?
svnadmin lslocks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Finding Locks
Posted by listman <li...@burble.net>.
On Sep 14, 2007, at 2:04 PM, Erik Huelsmann wrote:
>>> I suspect that this is because the workspaces that do _not_ have the
>>> lock have no indication from the repository that locks exist. Is
>>> this
>> a
>>> correct guess?
>>
>> Yep.
>>
>>> It would be nice for
>>> the workspace to know which files have locks on them (upon "update",
>> of
>>> course), and better yet, to know who has those locks.
>>
>> I agree, this would be quite useful. Locking has always seemed like
>> such an afterthought and really doesn't get a lot of attention.
>
> I can't help it, but this is by design, not because locking is or was
> an afterthought: it would be really useless to have this information
> in a working copy, because the minute it's stored in the working
> copy, that information may be outdated.
>
> If you want to have up-to-date information on locks, you need to
> contact the server. That's what this 'non-availability' of information
> is about...
what command should we be using to get the list of locks from the
server?
thx
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Finding Locks
Posted by Erik Huelsmann <eh...@gmail.com>.
> > I suspect that this is because the workspaces that do _not_ have the
> > lock have no indication from the repository that locks exist. Is this
> a
> > correct guess?
>
> Yep.
>
> > It would be nice for
> > the workspace to know which files have locks on them (upon "update",
> of
> > course), and better yet, to know who has those locks.
>
> I agree, this would be quite useful. Locking has always seemed like
> such an afterthought and really doesn't get a lot of attention.
I can't help it, but this is by design, not because locking is or was
an afterthought: it would be really useless to have this information
in a working copy, because the minute it's stored in the working
copy, that information may be outdated.
If you want to have up-to-date information on locks, you need to
contact the server. That's what this 'non-availability' of information
is about...
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Finding Locks
Posted by "Miller, Eric" <Er...@amd.com>.
> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Friday, September 14, 2007 2:09 PM
> I suspect that this is because the workspaces that do _not_ have the
> lock have no indication from the repository that locks exist. Is this
a
> correct guess?
Yep.
> It would be nice for
> the workspace to know which files have locks on them (upon "update",
of
> course), and better yet, to know who has those locks.
I agree, this would be quite useful. Locking has always seemed like
such an afterthought and really doesn't get a lot of attention.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org