A truly linear file history

[Simon King]

On Tue, Oct 22, 2013 at 3:37 PM, Bob Hood <bhood2 at comcast.net> wrote:
> This is a log mining question.
>
> I'm amusing myself by writing a utility that does a Subversion-like "blame"
> mechanism for a Mercurial repository.  I have it working, but I'm running
> into a problem with the "hg log" command.  I cannot seem to find the right
> combination of command-line options to produce a fully linear file history,
> running from the point of introduction (initial check-in) up to the
> last/latest change.  This is required in order to faithfully reconstruct the
> current state of the file.

Just to check: you do know about "hg blame", don't you?

How will you cope with files where the history *isn't* linear? The log
command that you suggest below may interleave versions from different
(topological) branches, which is probably not what you want.

>
> The command line I'm using is:
>
>    hg log -r "0:tip" -v -p -b default -b trunk <file>
>
> (Note that, since we migrated from a Subversion repository to Mercurial,
> some files in our repository have their complete history dating back to that
> SCM, so I need to include the Subversion branch where a file might have
> originated ("trunk") in order to get back to the point of introduction.)
>
> I'm running into what appear to be "gaps" in the file history.  For example,
> in one revision I have the introduction of a block of code in its diff:
>
>     +    for plist_filename in [ 'proj1/Info.plist',
>     +                            'proj2/Info.plist',
>     +                            'proj3/Info.plist',
>     +                            'proj4/Info.plist',
>     +                            'proj5/Info.plist',
>     +                            'proj6/Info.plist'
>     +                          ]:
>
> but then in the next delta, I have the "undocumented" introduction of new
> lines to this same block:
>
>          for plist_filename in [ 'proj1/Info.plist',
>                                  'proj2/Info.plist',
>                                  'proj3/Info.plist',
>     +                            'proj8/Info.plist',
>                                  'proj10/Info.plist',
>                                  'proj11/Info.plist',
>     -                            'proj4/Info.plist',
>                                  'proj5/Info.plist',
>                                  'proj6/Info.plist'
>                                ]:
>
> Note the two middle lines (in bold in HTML viewers).  These just "magically"
> appeared between revisions.  I'm assuming there was some kind of merge that
> added them in, but that isn't being listed in this linear log.  I noticed
> that this particular delta has a "parent:" tag:
>
>     changeset:   23426:17fc48a06ae4
>     parent:      23424:5183dd4183d3
>
> but when I try to bring up a log for it ("hg log -r 23424"), it is empty, so
> it doesn't seem like something I can pursue to fill in these gaps.
>

When you say "it is empty", do you mean that "hg log -r 23424" returns
no output, or "hg log -r 23424 <filename>" returns no output?

Mercurial revision numbers apply to the repository as a whole. The
parent revision of 23426 is 23424 (suggesting that revision 23425 is
on a different branch), but if the file you are looking at wasn't
modified in 23424, then "hg log -r 23424 <filename>" won't return any
output.

I suspect the issue is that the history for this file *isn't* linear,
and your deltas are being produced against inappropriate parent
revisions.

hg log -G <filename> might make the problem more obvious.

> I know I'm missing something here, because there can't just be this kind of
> disconnected fragmentation of a file's lineage.  Is it possible to produce
> an end-to-end linear history of a Mercurial file using a single command line
> as I'm attempting, or do I need to "scoop in" these diversions using
> additional processing?
>
> Thanks for your insights, or any URL links that can properly edumacate me.
> ;)
>

Regards,

Simon