WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Add sequence number to 'xm info'
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Thu, 29 Sep 2005 12:41:01 -0500
Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 29 Sep 2005 17:39:40 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8764sjluzn.fsf@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <87r7b8x1kh.fsf@xxxxxxxxxx> <cc771642dd285c3e22b2771ac04530b9@xxxxxxxxxx> <8764sjluzn.fsf@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
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