Greg Stein wrote:
> Re: review: I already reviewed and edited some of the overview text.
> Haven't done an exhaustive review yet.
oh? thanks, I'll check it out.
> Re: update and copy: the resulting WC state should be the same, whether
> you use checkout or update.
I do see a profound difference between update and checkout:
1. An update may cause tree- and other conflicts against WORKING. "WC state
should be the same" debunked.
2. An update can/must build upon the presence of a previous state.
'update' as "download the delta between BASE and HEAD, and merge",
'checkout' as just an ftp makeover.
'update' may also send a 'replace', checkout never will. I'd much more
associate 'update', 'switch' and 'merge', and I find 'checkout' quite unrelated.
>So if checkout does not use copy(), then why
> should update? I assume you're trying to optimize, rather than a
> correctness issue...
It's actually correctness ... ok, maybe rather precision:
We are introducing the ability of communicating moves and copies in an
atomic way. IMHO, we should absolutely not miss that chance by ripping moves
/ copies apart during update. Clients should receive the information that
"this is a move"/"...copy" during an update (and switch and merge). That's
crucial information for improving tree-conflicts so that they may one day,
who'd think they might, be intuitive. (I hope stsp joins in here)
With copy(), what I seem to not be getting: The new copy() callback is the
only way of "adding with history". Is "A+" actually not needed during
'update'? And if it isn't, why omit this info on purpose? The client should
be able to print sth like
$ svn up
A + file (copied from ^/otherfile)
If 'merge' does it, 'update' should too.
Received on 2009-09-16 01:39:50 CEST