On Thursday 29 September 2005 11:02, Sean Dague wrote:
> On Thu, Sep 29, 2005 at 10:45:32AM -0500, Hollis Blanchard wrote:
> > On Sep 28, 2005, at 5:35 PM, Dan Smith wrote:
> > >This patch causes the short changeset id or sequence number to be
> > >included on the 'xen_changeset' line in the 'xm info' output.
> > >
> > >We plan to use this sequence number as a very fuzzy way of sorting
> > >test reports so that we can start looking for trends. While we know
> > >it won't result in a perfect ordering of changesets for reporting, it
> > >will help us get close.
> >
> > So if the new format is
> > xen_changeset : Wed Sep 28 13:06:49 2005 +0100
> > 7120:5e5ae8340956
> > This is a bad idea. If you want to compare two changesets, you already
> > have the full date right in front of you!
> >
> > The revision number is a convenience for *local* operations, for
> > example 'hg export 7033:7035'. It obviously should never be compared
> > across different repositories "and just hope things work out ok."
>
> Yes, single repository, like xen-unstable (upstream). For the xm test work
> having a sequence number from a single repo makes a number of things much
> easier. If it was so harmful to have the sequence number then I would
> think it would be eliminated from hg entirely.
The revision number is useful, as you can see in my export example above --
there would be no easy way to specify a range of changesets without it.
> Most people using hg for xen-unstable aren't doing so to write code, they
> are doing so to make it easy to test latest pull (akin to anon cvs). For
> that class of people and applications, having sequence number available is
> a very good thing.
I haven't seen Dan's intended use case described, but there are better sources
of information, such as the changeset hash or the changeset date.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home