New extension: fixrenames

Martin Geisler mg at aragost.com
Thu Aug 18 07:27:08 UTC 2011


Stanimir Stamenkov <s7an10 at netscape.net> writes:

> Mon, 15 Aug 2011 01:01:47 +0300, /Stanimir Stamenkov/:
>> Tue, 28 Jun 2011 08:30:25 +0200, /Martin Geisler/:
>>> Stanimir Stamenkov writes:
>>>> Mon, 27 Jun 2011 15:38:05 +0200, /Martin Geisler/:
>>>>
>>>>> https://bitbucket.org/aragost/fixrenames
>>>>>
>>>>> The extension lets you replay old history in order to detect
>>>>> missing rename information. It basically does:
>>>>>
>>>>> $ hg update N
>>>>> $ hg revert --all --rev N+1
>>>>> $ hg addremove
>>>>> $ hg commit
>>>>>
>>>>> in a loop over a range of revisions you specify. The new
>>>>> changesets are identical to the old changesets, with the exception
>>>>> of the added rename information.
>>>>
>>>> That may prove really helpful for me when converting from SVN -
>>>> I'll give it a try.
>>>
>>> Let us know how it goes.
>>
>> Unfortunately it doesn't appear to have any effect for me. I've
>> previously mailed you a sample repo I'm trying with.

Please avoid private mails -- I do most of my Mercurial stuff at work
these days and a private mail goes in the back of the queue.

But I just tried with the repo you talk about and the extension no
longer crashes for me. So I think the crash bug is solved?

>> Its graph looks like:
>>
>> @ 10:a69ef8c0f8c9
>> |\
>> | o 9:73b8ec407320
>> | |
>> o | 8:1ccb1cb06a35
>> | |
>> o | 7:9d0d0e2e7936
>> | |
>> o | 6:1d4418cb59d0
>> |\|
>> | o 5:28e6d84bb104
>> | |
>> o | 4:f4f2830bce2f
>> | |
>> o | 3:16f303bc865c
>> | |
>> o | 2:8e1941400e0c
>> |/
>> o 1:4bd7b4fe69c0
>> |
>> o 0:880ee814d5a7
>>
>> Initially there's an README file in the root of the repository. In
>> rev 3 the file is (properly) renamed to doc/README. In rev 4 it gets
>> few lines added. In rev 5 the not yet renamed on that branch README
>> also gets few lines added. The merge rev 6 gets the lines added to
>> README in rev 5 to the renamed doc/README, but then the annotations
>> show those lines are made by rev 6, and not rev 5. Do you know what's
>> happening (or not happening) in this case?

I don't have time to look into this right now, but I've uploaded the
repositories in question to Bitbucket. Here is the one you sent me:

  https://bitbucket.org/mg/rename-test/

and there is the result of running "hg fixrenames -s 50 --strip 4":

  https://bitbucket.org/mg/rename-test-fixed-4/

> So my problem appears to be not with bad renames, but with bad merges
> (caused by deficiencies in the SVN->Hg conversion I've pointed
> previously) involving renamed files - the renames are not accounted
> for in the merged revision. Could the 'fixrenames' extension also
> handle re-merge with similarity detection of such merge revisions?

Yeah, it could do something more intelligent for merges. Right now it
always detects renames between ctx and ctx.p1().

I'll be happy to merge in changes if you can come up with something nice
here.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/



More information about the Mercurial mailing list