On Fri, Jan 23, 2009 at 2:36 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Fri, Jan 23, 2009 at 1:33 PM, Gunter Woytowitz
> <Gunter.Woytowitz_at_jdsu.com> wrote:
>> Hi Paul,
>> I did not use the --naïve-mode, and I am positive the svnmerge-migrate-history.py script did this.
> That's good news in the sense that it keeps the problem in the
> migration scripts (which are small) rather than in the core code
> (which isn't).
>> I have just copied the one line of svn:mergeinfo that was corrupted.
>> I have many (40+) branches that are branched and merged between each other like crazy. If you think it would be helpful I can track down the exact path of branches and merges given some time,
> For now just two questions:
> Do you have any broken history in the path with the range-overlapping
> mergeinfo? By which I mean you deleted the path and later resurrected
> it with some variant of 'svn copy
> What was the value of the svnmerge-integrated property on the path
> prior to running the migration script?
>> but the short term need is to relax the error checking to allow unordered/overlapping versions on reads of svn:mergeinfo data.
> I will look into this today. It's not quite as straight forward as
> fixing the unordered rangelist problem (r35297). Not to bore you with
> the details, but I need to deal with the potential for overlapping
> ranges where one range is inheritable and the other is not...just want
> to be sure not to introduce new problems while fixing old.
I was wrong, this was simple and there doesn't appear to be any added
complications. Went ahead and fixed it in r35466. I will also
nominate it for backport to the 1.5.x branch for inclusion in 1.5.6.
Received on 2009-01-26 15:31:31 CET