On Mon, Aug 29, 2011 at 08:04:09PM +0400, Danil Shopyrin wrote: > Hi Stefan! > > On Mon, Aug 29, 2011 at 6:54 PM, Stefan Sperling <s...@elego.de> wrote: > > Any ideas about how to solve this without using successors? > > > > [[[ > > deleted_nodes = nodes which appear in LEFT_PATH@LEFT_REV but not in > > RIGHT_PATH@RIGHT_REV > > added_nodes = nodes which appear in RIGHT_PATH@RIGHT_REV but not in > > LEFT_PATH@LEFT_REV > > moved_nodes = [] > > # A 'node' in this context is a repos_relpath > > for each node in deleted_nodes { > > node_rev_id = get_node_node_rev_id(node@LEFT_REV) > > Just a question, why wouldn't you like to iterate over added_nodes > (instead of deleted_nodes)? It seems that the whole algorithm can be > reverted and work without successors. Or do I misunderstand something?
Sorry, I'm a real scatterbrain today and didn't recall the real reason we need copy-to. You're right, this algorithm can work quite well using existing copyfrom information. Note that it calculates moves which happened in the delta requested by the client, e.g. the incoming change during a merge. The use case we need copy-to for is a different one. It is about nodes which have moved in the merge target's history. For instance, when the server tells the client to edit some file in the merge target branch, the client may find the file missing from its working copy. The client must now figure out what why this file is missing. It could ask the server "I don't know about this file, can you tell me if it has been deleted or if it was moved in my own history?" To answer this question, the server must first track history of the file in the merge source branch backwards, until it hits the branch point (the common ancestor of this file in both branches). From the branch point, it has to trace history on the merge target *forward* to see if it can find a file in the merge target branch at HEAD which corresponds to the file the merge must edit. This forward tracing is what the successor-id and server-side log caching proposals perform when they populate their caches. It is still possible to use copyfrom for this lookup. However, without a cache it is not likely to scale well because every file which appears in the branch's HEAD revision is now in the added_nodes list.