On Thu, 6 Jan 2005, Philip Martin wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>
> > On Thu, 6 Jan 2005, Philip Martin wrote:
> >
> >> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> >>
> >> Why use two columns? Just use one column:
> >>
> > svn st -u uses different colummns for WC state and repo out-of-dateness
> > already. Consistency.
>
> I guess you mean the '*' field, unlike locks it's hard to see how to
> combine that with another column. I still prefer one column for
> locks.
>
OK. Seems reasonable after all.
> >> 'K' locked in wc and repository
> >> 'B' locked in wc but 'Broken' so not locked in repository
> >> 'T' locked in wc but 'sTolen' so some other token in repository
> > And for "don't locked in WC, but locked in repository"?
>
> Some other letter? 'H' for 'lock Held' perhaps, 'O' for 'Other lock',
> 'E' for 'someone Else', we have lots to choose from.
>
Nothing very intuitive. I think i dislike O for Other lock (or locked in
Other WC) the least. It isn't necessarily someone Else, and the lock is
Held even if it is in this WC. OTOH, the lock doesn't necessarily have to
exist in another WC either, but that's a corner case. The important thing
is to find a mnemonic that isn't lying too much:-)
> > but I used "S" instead of "T" on
> > the grounds that being that far away from the switched column would make
> > it clear anyway.
>
> I didn't see 'S' in your proposal, but I don't like letters being
> reused. If the letters are different I can scan the status output, or
> the help text, and quickly recognise the token, if a token is reused
> it's harder.
>
If we use one column, S is out of the question anyway because of its
position, and your point about not reusing symbols is valid. It just gets
hard to find letters that has some meaning.
> > > Now update can print 'B' when it removes a lock. It could even
> > print > 'T' if knows the lock has been stolen, does update have that info?
> >>
> > It doesn't know the difference. Then I odn't like "B" in this case,
> > because it might as well be stolen.
>
> A stolen lock is also broken, I don't see a problem.
>
Good point. I've been afraid this will confuse users, but that's maybe not
a problem as you suggest. I mean, a broken lock might be stolen a second
later anyway. You never know until you try to lock the path. I've been
thinking of what is happening to the lock token, since we're talking about
the state change of the WC. Maybe the user won't see it that way.
> Ah, I see now that you were refering to the locking-ui.txt
proposal > for 'S', 'T', etc.
>
Sorry, I wasn't clear enough about that. I was proposing changes to that
file.
Anyway, my head is starting to spin round now. I'll give this time over
the night and await others comments.
T summarieze this mail, it seems like we currently have the following as
an alternative to the current locking-ui.txt:
svn up
col 3:
' ' NO lock touched.
'B' Lock token removed from working copy (broken or stolen lock).
svn st
col 6:
' ' not locked in this WC
'K' LocKed in this WC
svn st -u
col 6:
' ' No lock.
'K' Locked in this WC, token valid.
'O' Locked in repository (lock token in Other WC)
'B' Lock token in this WC, but invalid in repository (lock Broken)
'T' Lock token in this WC, but other token in repository (lock sTolen)
Might this be acceptable?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 7 00:06:08 2005