Enriching a file log by branches, tags and bookmarks

Simon King simon at simonking.org.uk
Wed Apr 8 11:40:17 CDT 2015


On Wed, Apr 8, 2015 at 3:04 PM, Marc Strapetz <marc.strapetz at syntevo.com> wrote:
> On 08.04.2015 02:01, Simon King wrote:
>>>
>>> On 8 Apr 2015, at 00:25, Simon King <simon at simonking.org.uk> wrote:
>>>
>>>
>>>> On 7 Apr 2015, at 14:55, Marc Strapetz <marc.strapetz at syntevo.com>
>>>> wrote:
>>>>
>>>> I'm taking this thread from the main list to the developers list:
>>>>
>>>> I'm looking for a way to enrich a file log (or sub-tree log) by
>>>> branches, tags and bookmarks: every such "tag" should be displayed at the
>>>> "closest" commit of the file log, i.e. at that commit which contains the
>>>> file in identical state (content).
>>>>
>>>> Here is an example of how this should look like for setup.py of the
>>>> Mercurial repository (note that this repository is quite outdated, so most
>>>> recent tags do not show up):
>>>>
>>>> http://i.imgur.com/AYt885I.png
>>>>
>>>> Using a loop of revset queries gives me the information I'm looking for,
>>>> but is too inefficient (pseudo-code):
>>>>
>>>> $ for all $X in tags(): hg log -r "max(ancestors(tagged(X)) and
>>>> file(setup.py))" -T "$X {rev}\n"
>>>>
>>>> For this approach, e.g. ancestors() as well as file(setup.py) is run for
>>>> every tag (N times), while I'm having in mind a solution which would
>>>> traverse the commit hierarchy only once or twice, possibly increasing memory
>>>> usage by O(N) for the sake of constant running time. (Is that reasonable for
>>>> large repositories, like for the CPython repository?)
>>>>
>>>> Unfortunately my Python and Mercurial knowledge are quite limited and
>>>> hence I'm looking here for someone who is able to write an extension to
>>>> solve this problem on a work-for-hire basis.
>>>>
>>>> -Marc
>>>>
>>>>
>>>
>>>
>>> Below is an extension that horribly abuses revsets to do something like
>>> what you are asking for. I’ve only tested it with hg 3.2.3. I hope that with
>>> the lazy revset functions in recent versions of mercurial it is fairly
>>> efficient. In particular, that iterating over "sort(::n, -rev)” is an
>>> efficient way to travel down the ancestry for a revision.
>
>
> Many thanks, Simon! This is basically what I'm looking for and running time
> with Mercurial 3.3 on the CPython repository is really good.
>
>> Actually, on further testing I see this is buggy. I was trying to
>> reproduce your screenshot but it is putting the 2.5-related tags on the same
>> revision as the 2.4 ones.
>>
>> o    18900
>> |\
>> | \
>> | |\
>> | | \
>> | | |\
>> | | | \
>> | | | |\
>> +-+-+---o  18866 2.5.4
>> | | | |/
>> | | | o  18755 2.5.3
>> | | | |
>> +-+---o  18754
>> | | |/
>> +---o  17926
>> | |/
>> | o    17732 2.4-rc 2.4 2.4.1 2.4.2 2.5-rc 2.5 2.5.1 2.5.2
>
>
> I can reproduce that. I think the core problem is that the caching assumes a
> total order between all revisions. I've changed code now to replace
> 'sort(::%d, -rev)' by 'sort(ancestors(%d), -rev)', however still 2.5-rc is
> mapped to r17732 instead of r18754 due to the merge at r18543.
>

These are equivalent:

    "x::y"
      A DAG range, meaning all changesets that are descendants of x and
      ancestors of y, including x and y themselves. If the first endpoint is
      left out, this is equivalent to "ancestors(y)", if the second is left
      out it is equivalent to "descendants(x)".

      An alternative syntax is "x..y".

I'm sure this should be fixable - if I have time this evening I'll
have another look.

Simon

> I currently have no idea how to fix the algorithm to work correctly here,
> though that would be desirable because it's fast and memory-efficient.
>
> A less memory-efficient approach which I'll try to implement will be
> traversing the entire commit network and shifting tags from a revision to
> all of its ancestors. Once a commit of the file's log is encountered tags
> will be reported and shifting will be stopped for these tags. This might
> result in large sets of tags being applied to many nodes, possibly requiring
> large amounts of memory (though I'm not yet sure on that).
>
> Either way, I'll come back with a modified version of your extension once
> it's working.
>
> -Marc
>


More information about the Mercurial-devel mailing list