On Tue, Sep 15, 2009 at 19:35, Neels J Hofmeyr <neels_at_elego.de> wrote:
> Greg Stein wrote:
>...
>> 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.
Ah. True. I wasn't thinking about local mods, just that these two
would be the same:
$ svn co $URL
versus
$ svn co -r 1 $URL
$ svn up
> 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.
Checkout, update, and switch all change BASE. At the same time WORKING
may have assumptions about the intended changes against BASE, which
has (now) been altered, thus raising a tree conflict. But these three
operations are primarily intended to alter BASE, not WORKING. They
will tweak localmods that reside in WORKING, but very much as a side
effect.
Merge and patch are both directed at WORKING/ACTUAL and will *never* alter BASE.
>>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)
Well... what if the source of the copy/move is not on the client? ie.
the working copy is branches/1.6.x/, but the source is trunk. What
then?
And remember: the working copy state does *not* record history. This
is what I meant by checkout and update being the same. The working
copy does not record "and this directory is here because of a copy 170
revisions ago." It just has the directory.
copy/move are transient operations, not persisted state.
I do see that you may want to record tree conflicts a bit differently,
or resolve problems better/differently, depending upon the source and
operation. But the underlying BASE tree will be precisely the same. If
there were local mods, then the WORKING tree may have some specific
data.
> With copy(), what I seem to not be getting: The new copy() callback is the
> only way of "adding with history".
Correct.
We have adds. And we have copies, and moves. "Add with history" is a
copy or a move. Nothing else that I can think of.
> Is "A+" actually not needed during 'update'?
I don't think that status ever occurs during an 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)
That might be nice, but it isn't omitted "on purpose". The editor
drive in libsvn_repos ("dir delta" or somesuch) does not use/consider
copy information when generating instructions to edit a tree to a
target revision. It is a series of adds, deletes, and changes. That's
it.
> If 'merge' does it, 'update' should too.
Merge is recording changes in the WORKING tree, which includes "copy A
to B", which is then sent to the server to say "copy A to B". The
WORKING tree has the capability to record copies like that, and it
*should* so that it can properly describe the change to the server at
commit time.
The BASE tree has no historical information. Thus, an update does not
carry that information with it. I think it would be very difficult to
determine what that information should be. Consider a crazy case like:
$ svn copy A/B A/B2
$ svn rm A/B2/C
$ touch A/B2/C/file1
$ svn add A/B2/C A/B2/C/file1
$ svn commit
$ echo "changes" >> A/B2/C/file1
$ svn commit
$ cd elsewhere
$ svn co -r 1 $URL
$ svn up
What should the status be? Add with history? Add? Modified? I'll note
that A/B2 would appear as "add with history", yet where would the
delete of A/B2/C be shown? Maybe that is supposed to show as a
replacement?
It's all a big black hole. It could be theoretically possible to
define the status reporting, and to do some major rewrites in
libsvn_repos to start issuing more edits than simply "add" and
"delete". But I think that is *way* past the scope of Ev2. I think Ev2
provides a framework for that, and will definitely help, but its a
problem space well beyond what the repos library can do today.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395329
Received on 2009-09-16 05:31:22 CEST