Paul Burba wrote:
> "svn co --force URL WC_PATH" behaves exactly as "svn co URL WC_PATH" does
> now except when the co attempts to add some path PATH where URL/PATH ==
> WC_PATH/PATH. In these cases there is an obstruction and these are
> handled as follows:
[8 cases described (not exactly "use cases" in the normal sense -
> I'm uncertain what the ideal behavior is in use cases E and G.
What is the overall description of the new behaviour, the concise summary of
its intent, from which the reader can mostly deduce or at least find it easier
to understand and remember the behaviour in each case? Writing this would help
you to answer your own questions about how it should behave in certain cases.
Please add this concise summary to the "svn checkout --help" output as part of
> A few people have mentioned that perhaps missing paths should be scheduled
> for deletion and non-obstructing paths scheduled for addition. This patch
> does neither as it wasn't in my original proposal and I wanted to keep
> this first patch as simple as possible.
To my mind, that would be an operation with a different and incompatible
purpose, not an optional extension to the behaviour. Your goal is along the
lines of adding stuff from the repository to what is already present,
> + _("Failed to takeover directory '%s': "
One of my language bug-bears:
If you must use the term "takeover" at all, when used as a verb as it is here,
it should be two separate words: "I take over, you take over, he/she/it takes
over, to take over, ...". (Not "It takeovers" or "It takesover".)
Finally, I believe one of the goals should be that the sequence:
svn import local-dir
svn checkout URL local-dir --force
should accomplish a conversion in place of the local dir to a WC, whatever
properties (from auto-props) and file types are present, and with no errors and
no slew of warnings (maybe one warning at most). I'd like to see that
explicitly listed as a goal (if you agree) and perhaps tested (if it isn't
already; I haven't read your tests).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri May 5 14:08:15 2006