RE: Resoving tree conflicts results in inconsistent state between two working copies of same branch

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.

Dave Wallace

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Thursday, August 18, 2011 3:43 PM
To: David Wallace
Cc: dev_at_subversion.apache.org
Subject: Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

On Thu, Aug 18, 2011 at 10:02:45PM +0000, David Wallace wrote:
> Ok, I've attached a filtered typescript in which I was able to
> reproduce the problem, using a subtree in our repository as if it was
> the full repository.

Thanks!

> I don't have a full reproduction script, because that would require me
> to (1) set up a new repository

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)
> parse the output from svn log to get the proper range of revision
> numbers to attach to subsequent commands. But this typescript should
> be pretty easy to follow manually.

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.
Received on 2011-08-19 18:52:38 CEST