On 10/14/2014 05:03 AM, Philip Martin wrote:
Alexey Neyman <sti...@att.net> writes:
On 10/13/2014 04:08 PM, Andreas Stieger wrote:
Hello,
On 09/10/14 23:48, Alexey Neyman wrote:
What I was doing:
- checked out a project from /trunk
- did some local changes
- copied WC to a branch
- attempted to switch to the branch
What exactly does "copied WC to a branch" mean in terms of svn or file
system operations?
It means exactly that, copying from a WC to a new directory in the repository:
$ svn cp . ^/engr/aneyman/mybranch
That's a commit. Did it succeed? If so then the commit should contain
a lot of information about the state of the working copy. What does the
commit look like? What does 'svn log -v' show for the commit? Adds,
modifications, copies, deletes, property changes, etc.?
Yes, it is a commit and it has succeeded. If I check out a separate
working copy from that new path, it is fine and contains all the
modifications from the working copy thus checked in.
Actually, looking at the commit I came up with a reproduction scenario:
[[[
#!/bin/bash
cd /tmp
svnadmin create repo
svn co file://`pwd`/repo wc
svn mkdir wc/trunk wc/trunk/d1 wc/trunk/d2
echo hi > wc/trunk/d1/f1
svn add wc/trunk/d1/f1
svn ci -mm wc
rm -rf wc
svn co file://`pwd`/repo/trunk wc
svn mv wc/d1/f1 wc/d2
svn rm wc/d1
svn cp -mm wc file://`pwd`/repo/newbranch
svn switch file://`pwd`/repo/newbranch wc
]]]
Running this script under SVN 1.8.10 gives the same "missing row" error.
So, the problem operation is "copy a file from a directory, then delete
that directory".
Checked the issue using SVN trunk. It does not abort like 1.8.10, but it
does report tree conflicts for d1/f1 and d1. I would say such conflicts
should be resolved automatically, given that the working copy contains
exactly the same changes as in the incoming edit. Figuring that out may
not be trivial, though, as the copied directory may be arbitrarily deep.
Regards,
Alexey.
