It is possible that there are two ranges. It is not my intent to have these
two ranges, it would just be from the mechanics of svn copy. I have
recently switched from CVS where I did merges with tags. I am attempting to
use svn copy to do the same thing.
I make a new tag (svn copy) in my production version source every time I
merge changes forward into my development version. Then I do an svn merge
between the prior tag I created this way
(svn://192.168.0..../tags/one-month-ago) and the current tag
(svn://192.168.0..../tags/just-created).
In the example that I had given 461 would be the last commit before the svn
copy and 462 is the svn copy itself.
--------------------------------------------------
From: "Bob Archer" <Bob.Archer_at_amsi.com>
Sent: Thursday, April 14, 2011 1:38 PM
To: "Daniel Walter" <d2walter_at_hotmail.com>; <users_at_subversion.apache.org>
Subject: RE: duplicate merge conflict
>> --------------------------------------------------
>> From: "Bob Archer" <Bob.Archer_at_amsi.com>
>> Sent: Thursday, April 14, 2011 9:33 AM
>> To: "Daniel Walter" <d2walter_at_hotmail.com>;
>> <users_at_subversion.apache.org>
>> Subject: RE: duplicate merge conflict
>>
>> >> When I merge changes in SVN, the merges work well except for the
>> >> conflicts. For some reason, the merges are frequently (but not
>> >> always done twice). As an example:
>> >> <<<<<<< .working
>> >> <<<<<<< .working
>> >> const int SERIALIZE_FIELDS_DATA_LENGTH = 83;
>> >> =======
>> >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91;
>> >> >>>>>>> .merge-right.r462
>> >> =======
>> >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91;
>> >> >>>>>>> .merge-right.r461
>> >> It appears that I am merging the changes between versions 442
>> and
>> >> 462 into the current working copy so I don't understand where
>> 461
>> >> is coming from.
>> >>
>> >> This is happening both with Tortoise SVN (using Merge two
>> different
>> >> trees) or from the command line with:
>> >>
>> >> svn merge tree1 tree2 --non-interactive
>> >
>> > Can you revert your merge and verify that your working copy
>> didn't already
>> > have those r461 merge indicators in it. I know here people have
>> checked in
>> > files that had unresolved conflict markers in them.
>> >
>> I reverted to the original source and verified it. It had no
>> conflicts.
>> Then I did the merge again. The same thing happened and I ended up
>> with
>> duplicate conflicts again.
>>
>
> Is it possible you are merging in a range of non-contiguous revision? I
> believe that does a merge of each range separately.
>
> BOb
>
>
Received on 2011-04-14 19:57:37 CEST