Re: [Xen-devel] [PATCH] Add sequence number to 'xm info'

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Thursday 29 September 2005 11:05, Dan Smith wrote:
> HB> +If you want to compare two changesets, you already have the full
> HB> +date right in front of you!
>
> That's true.
>
> HB> The revision number is a convenience for *local* operations, for
> HB> example 'hg export 7033:7035'. It obviously should never be
> HB> compared across different repositories "and just hope things work
> HB> out ok."
>
> I completely agree and understand.  Telling someone to try to resolve
> their problem by checking out changeset 7033 would be a bad idea.
> However, if we're talking about loosely grouping and sorting a month's
> worth of test reports to make a determination about failure trends, I
> think it's a valid way to do it.  It's quick and it doesn't require
> any parsing of the date string.

Look at the way you phrased that: you aren't saying "a hundred revisions"; 
you're saying "a month". Maybe you could describe this classification process 
a little better. Are you looking to make statements like "dom0 booting was 
broken every week"?

And let's be honest: I'm not a big math fan, but the arithmetic on time zone 
conversions is not very difficult. :) 

> Also, when I'm comparing two of my test machines to see which is
> running a newer pull, I have to parse the date string with my eyes and
> do timezone conversions to figure out the order.  Since my (and most,
> I imagine) test machines are always running clones of the main repo,
> the sequence numbers would always be valid.

Sure, although if someone forgets what tree they're currently working in 
(happens to me anyways :), or doesn't have a pristine tree handy, or 
whatever...

> Independent of how people choose to use the information, is there a
> strong argument for not even showing it?

Because if you show it then people might be tempted to use the information. :) 
Revision numbers are local numbers, and should only be used locally.

I don't think "in this one case it will usually be ok" is a good argument, 
especially since "will always work" methods are readily available.

-- 
Hollis Blanchard
IBM Linux Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel