On Fri, 05 May 2006, Philip Martin wrote:
> Paul Burba <paulb@softlanding.com> writes:
>
> > The original proposal was for svn co to tolerate obstructions by default,
> > but eventually I decided to require the --force option.
>
> I think "checkout --force" is acceptable but I think the behaviour
> should be extended to "update --force" as well, after all, checkout
> and update share a lot of code.
>
> > Note: When a file or dir exists prior to a forced checkout and obstructs
> > during the co, it is reported as
> >
> > "T WC_PATH/PATH"
> >
> > rather than
> >
> > "A WC_PATH/PATH"
> >
> > "T" of course stands for takenover. This applies to use cases C, D, E,
> > and H.
>
> We already use 'T' for a "sTolen" lock during update. If update can
> also takeover then we really need to use some other letter, how about
> 'V' for "takenoVer"? Even if we don't change update I think it would
> be a good idea to avoid reusing 'T'.
It looks like Garrett used 'V' on the fs-atomic-renames branch to
represent a 'moVe' operation:
------------------------------------------------------------------------
r19010 | rooneg | 2006-03-23 17:05:06 -0800 (Thu, 23 Mar 2006) | 10 lines
On the fs-atomic-renames branch:
I can't resist, add basic support for renames to the log code so that
we can for the first time actually see the results of a rename in the
command line client.
* subversion/libsvn_repos/log.c
(detect_changed): Set action to 'V' for svn_fs_path_change_move, and
treat 'V' as an action that has a copyfrom path/rev.
------------------------------------------------------------------------
I assume he's intending the same for status output. While
fs-atomic-renames hasn't been merged into the mainline yet, how about
'K' instead? 'K' is not currently used in the first column of status
output (though is in the 6th, for 'locked in repository, lock toKen
present').
- application/pgp-signature attachment: stored
Received on Sat May 6 02:51:15 2006