"Bert Huijben" <b...@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 mean. > 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. -- Philip
