New extension: fixrenames
Stanimir Stamenkov
s7an10 at netscape.net
Thu Aug 18 20:28:05 UTC 2011
Thu, 18 Aug 2011 09:27:08 +0200, /Martin Geisler/:
> 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?
Yes, the crash bug is solved. Sorry for not making it clear.
> Stanimir Stamenkov writes:
>
>>> 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.
Thanks for responding and confirming merges could be handled in a
better way. Unfortunately I have never programmed in Python and I
have no knowledge of Mercurial code internals. I was mainly
providing a feedback and I was checking if my specific case could be
easily handled. I won't bother you further if you have no interest
in it. Sorry for the private email - I was not sure if the list
would accept a binary attachment (the zipped repo).
--
Stanimir
More information about the Mercurial
mailing list