Re: more editor v2

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.

I understand
'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.

~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395295