[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