RE: Resoving tree conflicts results in inconsistent state between two working copies of same branch
From: David Wallace <dave_at_bluepearlsoftware.com>
Date: Fri, 19 Aug 2011 16:49:54 +0000
Thanks, Stefan. In addition to the specific bug issues I mentioned below, there's also the design issue of whether this should properly be considered a tree conflict at all. After all, file2.txt was originally added in changeset 8036 back on davebr1, and every other branch or trunk that subsequently adds the file does so by merging in a changeset that either directly or indirectly traces back to changeset 8036. So at least in theory, it should be possible for subversion to realize "Oh, this is all the same file that was originally added back in 8036" and keep the histories straight. But I realize that it might require significant architectural changes to the tool to get this to happen.
On Thu, Aug 18, 2011 at 10:02:45PM +0000, David Wallace wrote:
> I don't have a full reproduction script, because that would require me
You can create a temporary repository for experiments on the local hard drive like this:
svnadmin create /tmp/repos
and then check out a working copy:
svn co file:///tmp/repos wc
There is no need to set it up a repository on your Subversion server or even use your production repository for such things.
> and (2)
It is quite long. At first glance it looks like a bug. I don't know if it is a known bug. I'll try to find some time to look at in detail next week.
This is an archived mail posted to the Subversion Dev mailing list.