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

Re: [PATCH]: Was [PROPOSAL] Takeover Take 2

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-05-08 21:56:19 CEST

Philip Martin <philip@codematters.co.uk> wrote on 05/08/2006 02:00:35 PM:

> Paul Burba <paulb@softlanding.com> writes:
>
> > Currently checkout reports paths only as 'A Added'. Update uses that

> > too, as well as 'D Deleted', 'U Updated', 'C Conflict', and 'G
Merged'.
> > I can understand not wanting to reuse a letter/symbol from the first
two
> > columns of status (i.e. ' ', 'A', 'C', 'D', 'I', 'M', 'R', 'X', '?',
'!',
> > '~'). But must we really avoid using the letters from the other
columns
> > of status?
>
> That was the consensus when we added 'K' for 'lock toKen' instead of
> reusing 'L'.

Ok, I wasn't aware of that.
 
> > Maybe something completely new like "obstructed" or "blocked" is
better?
> > Though there isn't a good single letter for those if we avoid reusing
any
> > letters currently employed by status...'E' is the only choice.
>
> 'E' for 'already Exists'
> 'P' for 'adoPted'

I like 'E' (and wish I had thought of it). I'm glad to avoid any
"takeover" language in this patch as it has different meanings for
different people. "Exists" is much less ambiguous.

Thanks Philip,

Paul B.

(Honestly, what I really wish I'd thought of was Michael Sweet's off-list
suggestion of "assimilate". That still makes me laugh.)

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 8 21:56:53 2006

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.