[PATCH 2 of 2] identify: add the --locate flag to display nearest surrounding tags

Gilles Moris gilles.moris at free.fr
Mon Aug 31 02:48:21 CDT 2009


On Sun August 30 2009 01:59:17 Mads Kiilerich wrote:
> Gilles Moris wrote, On 08/28/2009 09:38 AM:
> > # HG changeset patch
> > # User Gilles Moris<gilles.moris at free.fr>
> > # Date 1234603377 -3600
> > # Node ID 1583cb23bd884b0bcdc473054b1076f7a20f0a43
> > # Parent  6fed19d04b0d859931837172ad974edb1e7b6b80
> > identify: add the --locate flag to display nearest surrounding tags
> >
> > The goal is to give an idea of the position of the revision in the history
> > topology (where are the nearest tags? on which named branch?).
> >    
> 
> What are the use-cases for this? Which question does it answer? How does 
> the answer look like - and how should it be interpreted?
> 
> Which algorithm is used - and what are the thoughts behind it?
> 
> /Mads
> 

May be it's good to state back I am working in the medical domain.

When we find a problem, even more if it can impact patient safety, we want
to know:
- at what stage of which project it was introduced ?
- why did that happen ?
- who are the customer impacted on the field so that they can be fixed ?
I should not be alone in that case otherwise 'git describe' would not exist.
We are tagging a lot for our traceability. Tags provide valuable landmarks
about where we were in the development history for a particular cset.

So when a problem is identified on version V, we first want to know from
which branch of development it can come, for possibly do a hg bisect with
a previously working release.

When we have identified the cset that introduced the problem, we want to know
all the impacted version, so that by traceability we can fix our customers.
For that, we need to all the next tags impacted by that cset.

So I have added a locate option to identify:
% hg identify --locate -r cset
0123456789abcdef 
based on 1.0.2(-96 stable1.x) 1.5(-223 exp)
went in 2.0(+392 stable2.x) 2.1(+489)

Which means cset 0123456789abcdef 
- has for latest tags 1.0.2 (96 rev ago on the stable1.x named branch) and 1.5
  (223 rev ago of the exp named branch)
- is embedded in version 2.0 (branch stable2.x) and on the default branch (489
  rev further)

I used a pretty dumb algorithm: create a topological distance map from the
given rev, take all the tags and invalidate all ancestors (when below rev) or
descendants (above given rev) of the tag so that only nearest tags remain.

Anyway, this is rather obsoleted by what you've done, though perfs were not so
bad even on 100k+ repo.

Regards.
Gilles.


More information about the Mercurial-devel mailing list