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 <stsp_at_elego.de> wrote:
> > Any ideas about how to solve this without using successors?
> >
> > [[[
> > deleted_nodes = nodes which appear in LEFT_PATH_at_LEFT_REV but not in
> > RIGHT_PATH_at_RIGHT_REV
> > added_nodes = nodes which appear in RIGHT_PATH_at_RIGHT_REV but not in
> > LEFT_PATH_at_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_at_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.
Received on 2011-08-29 20:01:51 CEST