[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 07 Mar 2011 12:50:06 +0000

"Bert Huijben" <bert_at_qqmail.nl> writes:

>> > Some scenarios:
>> >
>> > % svn cp A A2; svn up A2/
>> >
>> > % svn cp A A2; svn up A2/mu
>> >
>> > % svn rm A2; svn cp A A2; svn up A2/
>> >
>> > % svn rm A2; svn cp A A2; cd A2; svn up
>> >
>> > % svn rm A2; svn cp A A2; cd A2; svn up mu
>> At present the copyfrom revision of A2 is fixed at the time of the copy.
>> Updating a copy, or inside a copy, could be useful if the copy is
>> incomplete; it could be "resume an interrupted copy". It's debateable
>> whether this should be part of update or copy.
>> It's also possible that update could "see through" the copy and update
>> any deleted base nodes below, but that is of limited use to the user.
> Well, it is an essential feature of tree conflict detection.

Detection? Do you mean resolution? I don't really understand what you

> And you need it
> to allow revert to bring your working copy back to a pristine single
> revision working copy. I wouldn't call that limited use.

I don't understand that either.

>> A more interesting feature would be a dynamic HEAD copy, where the
>> copyfrom revision is not fixed at the time of the copy. Then update of
>> the copy would be a real operation that modified the WORKING layer.
> I think this should be handled as part of real moves, but in that case it
> (w/c)ould be handled via the tree conflict on the moved_away node.

I don't really understand this either. If I were to copy HEAD it might
not even be part of a move.

>> >> The update editor should not look at layers above op_depth 0. Nodes
>> >> can only be added below an existing op_depth 0 node.
>> >>
>> >> If the update editor would touch something in the higher layers just
>> >> a (tree) conflict should be raised. (And in some specific cases
>> >> things might be automatically handled for compatibility reasons)
>> One case where update affects the working layer is where the update adds
>> a new node to a deleted directory. The code doesn't raise a tree
>> conflict but extends the delete to cover the new node.
> We discussed this a few months ago, where we finally came to the conclusion
> that the update editor should raise a tree conflict here, but the default
> tree conflict handler should then detect this case and do the right thing,
> probably without asking the user. (That way advanced clients can use a
> different method.)

I don't understand this either. The tree conflict resolution is built
into the update editor. I wasn't aware that a client using the update
editor chose the tree conflict handler.

I feel that update should always update all the BASE nodes. The old
system where bits of the BASE tree got skipped in tree conflicts is no
longer needed.

Received on 2011-03-07 13:50:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.