I use trac to browse darcs history, like this:

http://allmydata.org/trac/tahoe/timeline?from=2009-06-21&daysback=30&changeset=on&update=Update

and

http://allmydata.org/trac/darcs-2/timeline

Trac assigns incrementing integers to darcs patches, as you can see if you
follow those links.

My build system for Tahoe generates version numbers for Tahoe based on the most
recent darcs tag and the count of patches.  We use the count-of-patches so that
(provided someone is using the same linear history as the official repo that the
trac is showing), the Tahoe version number shows you exactly which point in the
history that version was built from.

I just observed the following exchange on IRC:

<warner> kpreid: I think I introduced the #732 problem fairly recently. From
	 your Incident file I see you were running 1.4.1-r3882, and zooko was
	 running 1.4.1-r3906						[10:45]
<warner> it is a continuing frustration to me that it takes a lot of work to
	 figure out what rNNN I introduced that change into.. I have to go to
	 Trac and do a bunch of searching. But I suspect that both r3882 and
	 r3906 were after I committed that patch.			[10:46]
<warner> it looks like 3893 is where I started to do that work, which explains
	 zooko's problem but not yours					[10:47]
<warner> actually, what frustrates me is that tags are not shown on the trac
	 per-source-file revision log. if someone tells me that they had a bug
	 in 1.4.1-release, then comparing that to a specific change is
	 difficult							[10:49]
<warner> oh, I think I don't trust these numbers.			[10:51]
<warner> kpreid: have you updated your source tree since producing that
	 incident file? does src/allmydata/_version.py still say r3882? If so,
	 could you do a "darcs changes -i src/allmydata/client.py" and see if
	 there's a patch there from me dated 2009-06-01 named "start to factor
	 server-connection-management into a distinct StorageServerFarmBroker
	 object" ?							[10:53]
<warner> I suspect that your tree, despite calling itself r3882, actually has
	 my bug-inducing change						[10:54]
<kpreid> yes, I have updated since
<warner> ah, oh well
<kpreid> still produces the problem
*** ioerror (n=ioerror@mail.lostinthenoise.net) has joined channel #tahoe
<warner> yeah, everything since r3893 should probably have the problem	[10:55]
<kpreid> er, is darcs changes -i expected to be slow?
<warner> much of darcs is expected to be slow :(
<warner> but not horribly so
<kpreid> I mean, with no cpu utilization				[10:56]
<warner> ah, don't pipe it into less
<kpreid> er, >0 ~0
<kpreid> I didn't
<warner> hm
<warner> the -i means it will show you each patch, one at a time, and wait for
	 you to say what you want to do next, so it's probably doing that now
									[10:57]
<warner> when it shows a large patch, it'll run a pager automatically (and grr
	 not consistently, and 'q' to quit the pager when it decided to not
	 use a pager will quit darcs)					[10:58]
<kpreid> it is continuing to not do anything				[11:01]
<kpreid> if I ^C it ^CwithSignalsHandled: Interrupted! and exits	[11:02]
<warner> sigh
<warner> try it without a filename, i.e. 'darcs changes -i' ?
<kpreid> worked								[11:03]
<kpreid> yes I have the 'start to factor' patch
<warner> can you tell if you had that patch when you experienced the repair
	 failure?							[11:04]
<warner> (the date of the incident report is after I pushed those patches to
	 trunk, but it's hard to tell if you happened to pull them by then or
	 not)
<kpreid> what was the date of the incident?				[11:07]
<warner> 2009-06-19
<warner> (incidentally [no pun intended], "flogtool dump incident-..." will
	 show you the various versions in the header)			[11:08]
<kpreid> yes I had that patch then
<warner> darcsver depends upon the patches in your repo to be in the same
	 order as those on allmydata.org, which I know is affected by
	 recording patches locally and then pushing them (or submitting them
	 to a ticket and having them pushed later), but I'd expect that to
	 inflate the version number rather than deflate it		[11:09]
<warner> ok, good, that explains the failure you saw then
<zooko> Hi folks!
<kpreid> warner: so, all set? no mysteries, will be fixed?		[11:10]
<warner> I wish I knew why your system's r3882 contained my patch that landed
	 on allmydata.org as r3893.
<warner> fortunately zooko already knows about this particular gripe of mine :)

So the problem is: given a version number emitted by Tahoe when you run "Tahoe
--version", how do you recreate the source code that was used to build this
version of Tahoe, or at least tell which patches went into it, or at least which
of the official versions from your official repository it was, if it was one of
those?

The best solution to this would be for darcs to implement issue992 (short,
secure, fast version identifiers), but that isn't scheduled and I'm not sure
darcs will ever do that.  A slight less good but easier (for me) solution is for
me to implement a kludgy approximation of it in darcsver -- that's the topic of
http://allmydata.org/trac/darcsver/ticket/3 (store the hash of "darcs changes
--context" and make it available as "--hashed-version") and of
http://allmydata.org/trac/darcsver/ticket/4 (store the output of "changes
--context" and make it available as "--exact-version").  An even simpler and
more limited solution would be for "--index" and "--number" options to "darcs
changes" to count from the beginning instead of counting from the end.  That
way, numbers returned from calls to "darcs changes" would still be correct after
another patch was added to the repository.  For example, that would make the
darcs changes command-line generate the same numbers as the trac timeline and
the darcsver tool.

Marking issue992 as a superseder (in case we do manage to implement it first)

At the risk of saying something evil, one option may be just to reverse the
current --number and --index switches so that they count up instead of down. 
I suspect that this UI change would have few adverse effects as --number and
--index were introduced somewhat quietly and that not many people are using them

If issue992 is really the right solution and if there isn't much use for this
other than looking up versions, we should fix issue992.

Note that you could always do a little subtraction using --count to get the
total number of patches.  Since the scenario involves a tool that calls darcs,
that tool could do it.

Zooko mentioned this ticket in IRC, so for posterity I'm posting on it
the relevant kludges that I quickly concocted in response.

Zooko wrote:
> So the problem is: given a version number emitted by Tahoe when you
> run "Tahoe --version", how do you recreate the source code that was
> used to build this version of Tahoe, or at least tell which patches
> went into it, or at least which of the official versions from your
> official repository it was, if it was one of those?

Assuming you know what repository it was, you might say (where
Version: 0.6.0+3 and the repo is http://example.net/foo)

    darcs get http://example.net/foo --tag 0.6.0
    darcs pull --repo foo <<<yyyd

In readline (e.g. bash), you can enter 123 y's with M-1 M-2 M-3 y.

Zooko also wrote (in IRC):
> The issue that is irritating me right at the moment is that I can't
> say: DARCS! What was the 1000th patch added to this repo!

I can (ab)use XSLT for this, see the following transcript.

Considering the following test repository:

    $ darcs init
    $ for i in {1..8}; do date --rfc-3339=ns >x; darcs rec -lam$i x; ((i % 3)) || darcs tag 0.$i.0; sleep 1; done &>/dev/null
    $ darcs cha
    Fri Jun 11 13:09:07 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 8

    Fri Jun 11 13:09:06 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 7

    Fri Jun 11 13:09:04 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      tagged 0.6.0

    Fri Jun 11 13:09:04 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 6

    Fri Jun 11 13:09:03 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 5

    Fri Jun 11 13:09:02 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 4

    Fri Jun 11 13:09:01 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      tagged 0.3.0

    Fri Jun 11 13:09:01 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 3

    Fri Jun 11 13:09:00 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 2

    Fri Jun 11 13:08:59 EST 2010  Trent W. Buck <trentbuck@gmail.com>
      * 1

We have a end-user version string of:

    $ echo Version: $(darcs show tags | head -1)+$(darcs changes --count --from-tag .)
    Version: 0.6.0+3

The nth patch, counting from one in ascending commit chronology:

    $ darcs cha --xml --reverse | xmlstarlet sel -t -c //patch[2]
    <patch author="Trent W. Buck &lt;trentbuck@gmail.com&gt;" date="20100611030900" local_date="Fri Jun 11 13:09:00 EST 2010" inverted="False" hash="20100611030900-c31ef-c547fd0e979b3908eec60f7a8b46f283f2cc2a93.gz">
            <name>2</name>
            <comment>Ignore-this: c854c3f7ed4fa967d35183bbc82d985d</comment>
    </patch>

The nth patch, counting from the tag in question:

    $ darcs change --from-tag 0.6.0 --xml --reverse | xmlstarlet sel -t -c '//patch[3]'
    <patch author="Trent W. Buck &lt;trentbuck@gmail.com&gt;" date="20100611030907" local_date="Fri Jun 11 13:09:07 EST 2010" inverted="False" hash="20100611030907-c31ef-3d37f439d1067d5fb8e9973500ba925e9ce9e755.gz">
            <name>8</name>
            <comment>Ignore-this: a5944b55afbfb44b83ccff44bf7346a6</comment>
    </patch>

    $ darcs change --from-tag 0.6.0 --xml | xmlstarlet sel -t -c '//patch[last() - 2]'
    <patch author="Trent W. Buck &lt;trentbuck@gmail.com&gt;" date="20100611030907" local_date="Fri Jun 11 13:09:07 EST 2010" inverted="False" hash="20100611030907-c31ef-3d37f439d1067d5fb8e9973500ba925e9ce9e755.gz">
            <name>8</name>
            <comment>Ignore-this: a5944b55afbfb44b83ccff44bf7346a6</comment>
    </patch>