[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 17:17:31 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: vrijdag 18 januari 2013 16:53
> To: Bert Huijben
> Cc: 'Philip Martin'; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1434913 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
> On Fri, Jan 18, 2013 at 03:18:23PM +0100, Bert Huijben wrote:
> > I'm still not sure if the current scheme scales under the move of
> > subtrees
> >
> > svn mv A Z
> > svn mv Z/B B
> > svn mv Z/C C
> > svn rm Z
> You need --force here for 'svn rm Z' to work, and this results in
> the moves being lost:
> $ svn st
> D A
> D A/B
> D A/C
> A + B
> A + C
> $
> Huh.
> Well, I'm sure you're pointing out real problems.
> However, you keep providing incomplete or non-obvious examples in
> your problem descriptions (like 'svn mv A B; svn mv B A' earlier, which
> also doesn't make sense).
> Please be more precise in explaining the problems you see. Otherwise it
> is difficult to have a productive discussion. I'd like to be able to
> properly reason about the issues you are raising but you aren't clearly
> enough communicating these problems for me to be able to digest them.

This is the worst case scenario of:
* You have a folder with N files, and R directories.
* You move all of them to a different location
* And you delete that folder

Which is a common operation in e.g. Java if you rename a namespace, moving
all the classes to different locations.

Our move and update-move-tree-conflict-handling must support this to make
any sense to users.

Just allowing that parent folder to be renamed via move tracking is a much
to simple view. Moves of subtrees must be handled independent of their

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