You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/12/21 23:50:35 UTC

[Locking] Terminology and extending output

Hi,

I am *soon* going to start implementing locking functionality for svn
update and svn status. We need to discuss how to extend the output of
these commands in a backwards compatible way. I am not sure what we are
allowed to do without breaking compatibility guarantees.

Also, we have a terminology clash that we need to resolve. The WC has a
concept of locking, for serializing write access to the WC in itself. This
is what svn st means with an L in its output. What should we call our new
locks to distinguish these concepts? Repository locks?

svn status:
"svn status" needs to show that the working copy has a lock on this file.
In the current spec, it is suggested that we add another column. Is this
OK regarding compatibility? Also, we need a new symbol to show that the
path is locked. "L" is used. Suggestions?

"svn st -u" will show files locked in the repository. I suppose we want
another column for that? Another way is to use one column and use
different symbols for "this WC has a lock", "this WC has a defunct lock"
and "the repository has a lock on this file". I am also considering adding
the lock owner to "svn up -uv". Do we want that or is svn info URL enough?

svn update:
svn up will remove defunct locks. This needs to be shown to the user. Are
we allowed to add another column here? Also, we need a symbol here. "U"
for "Unlocked" is obviously not a good choice. Maybe "B" for broken lock
in a third column?

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 24 Dec 2004, Walter Nicholls wrote:

>
> > I think that R, X, or K are all good.  I like Philips suggestion too
> > about a unique character, even if in a special column (turns out my
> > xterms have the same color scroll background as content background
> > making it sometimes hard to immediately ascertain where the left
> > column starts).
> >
> I like K too, but the simple reason of locK is good enough for me. And
> it's unique.
>
Thanks for the suggestions. I settled on K for locKed, "you have the Key"
or whatever:-) It's in r12534 if you want to have a look. Also I use S in
column nine for "Stolen", which is the same as Switched, but that will
only appear when column six contains K, so I think it is pretty clear in
that case.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
> I think that R, X, or K are all good.  I like Philips suggestion too 
> about a unique character, even if in a special column (turns out my 
> xterms have the same color scroll background as content background 
> making it sometimes hard to immediately ascertain where the left 
> column starts).
>
> One thing I like about K is that most locKs require Keys, so the 'K' 
> just feels like an easy association.
>
> Of course, that's not true in this case: the locKs require toKens. :-)
>
> -Travis
>

I like K too, but the simple reason of locK is good enough for me. And 
it's unique.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by Travis P <sv...@castle.fastmail.fm>.
On Dec 22, 2004, at 1:33 PM, Philip Martin wrote:

> Branko ÄŒibej <br...@xbc.nu> writes:
>
>> Walter Nicholls wrote:
>>>>
>>> 'R'eserved?
>>> I don't see how you can get away without adding a column since this
>>> property is independent of any of the others.
>>
>> Not bad. Or eXclusive.
>
> Even if the locked symbol appears in a different column I think it
> would be better if we didn't reuse an existing status symbol.
>
> How about 'B' for booked, 'K' for 'locKed, or 'H' for 'lock Held'.

I think that R, X, or K are all good.  I like Philips suggestion too 
about a unique character, even if in a special column (turns out my 
xterms have the same color scroll background as content background 
making it sometimes hard to immediately ascertain where the left column 
starts).

One thing I like about K is that most locKs require Keys, so the 'K' 
just feels like an easy association.

Of course, that's not true in this case: the locKs require toKens. :-)

-Travis


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@xbc.nu> writes:

> Walter Nicholls wrote:
>>>
>> 'R'eserved?
>> I don't see how you can get away without adding a column since this
>> property is independent of any of the others.
>
> Not bad. Or eXclusive.

Even if the locked symbol appears in a different column I think it
would be better if we didn't reuse an existing status symbol.

How about 'B' for booked, 'K' for 'locKed, or 'H' for 'lock Held'.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by Branko Čibej <br...@xbc.nu>.
Walter Nicholls wrote:

>
>> svn status:
>> "svn status" needs to show that the working copy has a lock on this 
>> file.
>> In the current spec, it is suggested that we add another column. Is this
>> OK regarding compatibility? Also, we need a new symbol to show that the
>> path is locked. "L" is used. Suggestions?
>>  
>>
> 'R'eserved?
> I don't see how you can get away without adding a column since this 
> property is independent of any of the others.

Not bad. Or eXclusive.

> Is now a bad time to suggest adding "svn status --xml " - so that 
> people wanting to parse output have a way that won't break if this 
> happens again?

It's not a bad time -- in fact, I'd suggest that /all/ SVN commands that 
produce output get an --xml switch -- but it's quite unrelated to the 
locking issue.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Locking] Terminology and extending output

Posted by Walter Nicholls <wa...@cornerstone.co.nz>.
>svn status:
>"svn status" needs to show that the working copy has a lock on this file.
>In the current spec, it is suggested that we add another column. Is this
>OK regarding compatibility? Also, we need a new symbol to show that the
>path is locked. "L" is used. Suggestions?
>  
>
'R'eserved? 

I don't see how you can get away without adding a column since this 
property is independent of any of the others.

Is now a bad time to suggest adding "svn status --xml " - so that people 
wanting to parse output have a way that won't break if this happens again?

- Walter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org