Loosing revision history after rename and compress/rebase

[Becker, Mischa J]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Weichelt David J
> Sent: Tuesday, January 07, 2014 9:09 AM
> To: Matt Mackall
> Cc: Albright Steve; Bogh Jason; mercurial at selenic.com; Faber Ross
> Subject: RE: Loosing revision history after rename and compress/rebase
>
> Response below.
> -----Original Message-----
> From: Matt Mackall [mailto:mpm at selenic.com]
> Sent: Friday, January 03, 2014 6:13 PM
> To: Weichelt David J
> Cc: mercurial at selenic.com; Albright Steve; Bogh Jason; Faber Ross
> Subject: Re: Loosing revision history after rename and compress/rebase
>
> On Fri, 2014-01-03 at 22:53 +0000, Weichelt David J wrote:
> > I'm looking for support on this problem we have seen.  The scenario
> was confirmed with other developers and it perhaps needs to be fixed by
> the Mercurial community...  we don't know how to work around this.  Not
> cool to loose revision history from code that we are moving around and
> changing.
> >
> > Steps to reproduce:
> >
> > 1.       Have a committed file with a revision history
> >
> > 2.       Hg rename the file from one directory to a new one (with
> renaming the file in my testing)
> >
> > 3.       Commit the changes
> >
> > 4.       Compress the changes (also can see same problem with rebase)
>
> This is not a term in our jargon. Perhaps you mean rebase --collapse? Or
> perhaps the THG project has taken to introducing their own jargon.
> <David> THG has compress and rebase as two different options.

THG has a Compress History right-click option if you've selected two changesets.  Is that the one you mean?

> > 5.       (optional) Strip the original changset that was compressed
> >
> > 6.       Notice that the revision history is missing on the new
> changeset
>
> Are you saying that the renamed file does not have any evidence of
> linkage to the original file? How are you determining this?
>
> <David> Yes, the renamed file doesn't have evidence of linkage to the
> original file (and thus the history of the original file).  It appears
> that the renamed file is a new file with only 1 changeset.

Assuming you are using Compress History, all it does is:

% hg update --clean --rev [ancestor]
% hg revert --all --rev [descendant]

It then opens the commit screen and prepopulates the commit message with all messages from the revisions you are compressing. You can make any changes you want before hitting the commit button.

I've been playing around with a test repo but the only way I can make the compressed changeset not know about the rename is if it was never marked as a rename in the first place.  Can you recreate the problem?

Mischa


________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.