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