On Fri, Sep 9, 2011 at 12:38 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Sep 09, 2011 at 12:17:15PM -0400, David Carson wrote:
> > To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so
> I
> > could experiment and see for myself. I did a simple merge from one
> branch
> > to another. I was disappointed to see that the same miscellaneous group
> of
> > files and directories below the top-level are having their snv:mergeinfo
> > modified, even though they do not participate in the change. I guess I
> am
> > not reading the documentation for 1.7 correctly, because I thought that
> this
> > was one of the major changes; namely, that any object which is not
> affected
> > by the merged changes would not have its svn:mergeinfo property changed.
>
> Did the change you were merging contain svn:mergeinfo property changes?
> If so, those will be applied to the working copy.
>
> If the revision rN you are merging from 1.2 into 1.3 was itself the
> result of a merge, and this merge was done with a 1.6 client,
> this would explain the problem.
>
Bingo -- that makes sense. In my test, I updated a child branch with new
parent content and that range of revisions contained one that was itself a
merge which was performed using svn 1.6 (i.e., before taking the snapshot of
the repository).
OK, so let's try again. I've merged a change from another branch, which is
a commit with a single file changed. The result is much better, but let me
verify that I understand my results:
- file a/b/c/foo.c shows the file changes -- OK
- file a/b/c/foo.c also contains svn:mergeinfo changes -- I assume this is
because it happens to be one of the many files that got contaminated with
the property prior to this test. So, since it is part of the changeset for
my merge, the prop has to be updated too.
- <top-level> directory (call it TLD/) contains svn:mergeinfo changes -- OK
- TLD/a also contains svn:mergeinfo changes -- Same as above. Directory
TLD/a is one of the directories which was previously contaminated, and since
this path is 'involved' in the change, the prop has to be updated. I
wouldn't say the path really involved, except that it is the path on wich
foo.c sits. After all, TLD/a/ is not itself changed. Nonetheless, I can
live with this.
Now, are there any tools to aid in cleanup of the mess? Besides the large
number of files/dirs with the prop attached, the prop itself has a large
number of paths to contend with.
Received on 2011-09-09 21:01:28 CEST