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

RE: svn commit: r1434913 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 18 Jan 2013 15:18:23 +0100

> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 18 januari 2013 11:20
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1434913 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
> "Bert Huijben" <bert_at_qqmail.nl> writes:
> > I think
> > $ svn mv A B
> > $ svn mv B A
> >
> > Will now store moved_from and moved_to in the same record, at the
> > op-depth of A. (Or copy_tests.py move_file_back_and_forth wouldn't
> > show moved_from and moved_to on a single node using status using the
> > code snippet here)
> >
> > How will this store a future move
> > $ svn mv A C
> I think:
> svn mv A B
> svn mv B A
> is shorthand for:
> svn mv A X
> svn mv B A
> svn mv X B
> If so then a subsequent:
> svn mv A C
> should result in A->B and B->C but it appears there is a bug in the
> implementation. The result is B->C but the A->B move gets lost.

I'm still not sure if the current scheme scales under the move of multiple

svn mv A Z
svn mv Z/B B
svn mv Z/C C
svn rm Z

svn up

So after this A/B is still moved to B and A/C to C, but keeping track of all
of this will take a lot of work.

I would guess it is much simpler to store in op_depth A/B that it is
currently in B, and in op_depth A/C that it is in C. (and while doing the
above that A was at Z)

The status walker currently just checks what is stored in the latest read
op-depth, so that code is certainly broken over multiple layered moves where
subtrees are involved.

svn mkdir --parents A/A/A/A/A/A
svn ci -m ""
svn mv A/A/A/A/A/A C
svn mv A/A/A/A D
svn mv A/A E
svn mv B/A/ A/A
and more things like this..

It is certainly possible to get multiple moved-froms at different depths the
same path if you try a bit with a scheme like this.

There is no way status or a single path can pinpoint a single moved-to this
way, yet this is what the current apis offer.

This problem will never occur with a storing moved-from in BASE (op-depth
(Moved-from is always stored in the op-root of the addition, so this can
never have this problem... The problem is in the moved-to scheme)

The current scheme appears to be designed to allow only tracking the root of
deletes, which is just the easy case, compared to generic move tracking.

Received on 2013-01-18 15:19:03 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.