On Wed, Feb 14, 2024 at 11:00 PM Sands, Daniel N. via users <users@subversion.apache.org> wrote: > > > > Okay, I finally figured out how to trip up SVN: > > > > > > > I built my own experiment which I'll try to reconstruct here: > > > mkdir test > > > mkdir test/foo > > > mkdir test/foo/bar > > > mkdir test/baz > > > echo "a" > test/foo/bar/example.c > > > svn import test svn+ssh://theserver/var/svn/playground/test > > > rm -rf test > > > svn co svn+ssh://theserver/var/svn/playground/test > > > cd test > > Now I did something that SVN apparently doesn't like: > > svn mv foo/bar/example.c baz > svn cp . ^/playground/test2
Hm, that's quite an atypical set of operations. The first command makes a local move in the 'test' working copy (without committing that move), and then creates a branch-from-WC with a local modification in it. Creating a branch from a working copy is a bit special, precisely because it may carry along local mods that are not committed to the branch source. This is translated by SVN into copy of the branch source, with the local modifications injected "on top". If you 'svn log -v' the revision that created that branch I think you'll see something like this: A + /playground/test2 (from /playground/test:XXX) D /playground/test2/foo/bar/example.c A + /playground/test2/foo/baz/example.c (from /playground/test/foo/bar/example.c:XXX) As you can see, the Deleted file is different from the "copyfrom" of the Added file (which is copied from the original pre-branch location). So the simple logic in the tree conflict resolver cannot detect that D-A pair as a move (it is not smart enough to see that you created test2 from test in the exact same revision). In theory, this should be a supportable scenario, but it'll take some special handling I think. When I create branches, I usually do so purely in the repository, by copying URL's (either from TortoiseSVN's repo browser, or by 'svn cp URL1 URL2' -- keep in mind that the caret for SVN is a shortcut for the repo-root-URL). That way the branch is a "clean" copy from something else in the repository. I prefer to keep other changes separate from the branch-creation, so either I commit them before or after creating the branch. The only exception I make to this is when creating tags for release, where I commit a "version-number" change in some file together with creating the tag. That's how the Subversion project creates its release tags too, see for example http://svn.apache.org/viewvc?view=revision&revision=1914487 -- Johan