[PATCH 2 of 2] convert: keep converted parents that are outside convert.hg.revs (BC)

Mads Kiilerich mads at kiilerich.com
Sun Mar 27 16:23:46 EDT 2016


On 03/27/2016 09:07 AM, Yuya Nishihara wrote:
> On Fri, 25 Mar 2016 01:14:03 -0700, Mads Kiilerich wrote:
>> # HG changeset patch
>> # User Mads Kiilerich <madski at unity3d.com>
>> # Date 1458860864 25200
>> #      Thu Mar 24 16:07:44 2016 -0700
>> # Node ID ede9dd4902ae4a5cd464811532acdcd2fd02728f
>> # Parent  0dd592daa18caead5b26cfc1f438b5d885d8b8ce
>> convert: keep converted parents that are outside convert.hg.revs (BC)
>>
>> Before, when converting revisions without also converting their parents,
>> parents that already had been converted would no longer be parents.
>>
>> That seems unfortunate and we dare to assume that nobody ever wants that.
>>
>> Instead, preserve parents that are outside the current convert range but
>> already has been converted.
> I think the direction is good.
>
>> --- a/hgext/convert/filemap.py
>> +++ b/hgext/convert/filemap.py
>> @@ -259,7 +259,7 @@ class filemap_source(common.converter_so
>>       def getheads(self):
>>           return self.base.getheads()
>>   
>> -    def getcommit(self, rev):
>> +    def getcommit(self, rev, revmap=None):
>>           # We want to save a reference to the commit objects to be able
>>           # to rewrite their parents later on.
>>           c = self.commits[rev] = self.base.getcommit(rev)
> Perhaps filemap_source should forward revmap to base source, but I got
> IndexError if I changed it in that way.
>
> Can we pass a copy of the known revmap by constructor? I think it will be
> simpler because revmap isn't necessary to be updated dynamically.

I don't see a good way to do that with the current convert architecture. 
The source and destination are created independently before both are 
passed to convert().

The same result could also be achieved with other more or less intrusive 
changes to how parents generally are handled or to the conversion 
framework in general. I am not sure which one would be better.

/Mads



More information about the Mercurial-devel mailing list