[darcs-devel] [issue1484] I wish there were a --count and --range that counted from the beginning instead of the end.

Zooko bugs at darcs.net
Tue Jun 23 17:17:45 UTC 2009


New submission from Zooko <zooko at zooko.com>:

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 at 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.

----------
messages: 7926
nosy: dmitry.kurochkin, kowey, simon, thorkilnaur, zooko
status: unread
title: I wish there were a --count and --range that counted from the beginning instead of the end.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue1484>
__________________________________


More information about the darcs-devel mailing list