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
|
Home