[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Locking] Terminology and extending output

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-12-22 00:50:35 CET

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
Received on Wed Dec 22 00:50:31 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.