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.
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.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgp4539AnTrs9.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home