[Buildbot-devel] Mercurial rev-ids 12 -> 40 char

[Axel Hecht]

Sounds reasonable to me, I've seen that mismatch in other places painfully,
too.

Wonder what the Mozillan relengs think

Axel

2010/1/12 Marcus Lindblom <macke at yar.nu>

> Hi,
>
> Would it upset anyone if I changed the getRev() step on Mercurial to get
> the full 40-char SHA-1 hex string, as opposed to the 'short' one that we
> get by default?
>
> The reasons are:
>
> 1. there's a mismatch between the full revision id in change the the one
> returned by the source step which is both confusing and wrong (long and
> short ids don't compare equal.)
>
> 2. When a build's source-step fails, the rev id from change is shown
> grid views. If the source-step succeeds, the short rev is shown. This
> looks ugly and the mergings of compiled revs doesn't work (see above).
>
> 3. The short-rev id is not guaranteedly unique (it probably is during a
> short period though.)
>
> 4. Git always uses long-revs, so Buildbot might as well be consistent.
>
> One could use short rev-ids, but that defeats the last two points.
>
> By avoiding showing the full id in the HTML, it'd be easier on the eye
> too. Onecan always get the full-id by looking at the build page. (And/or
> we add the recently discussed change-link or some javascript/tooltip
> magic.)
>
> Comments?
>
> Cheers,
> /Marcus
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20100112/f6b3b399/attachment.html>