__group__ ticket summary component version type owner status created _changetime _description _reporter Milestone 6 "make ""python ./setup.py --version"" and ""python ./setup.py --fullname"" work" component1 defect somebody new 2009-08-15T23:01:50Z 2009-08-15T23:01:50Z "{{{ hm, question about darcsver if I have a tree that has no _darcs directory but does have an updated src/allmydata/_version.py file [17:12] should ""setup.py --version"" work? I'm getting 0.0.0 That's not right. setup.py --version ? [17:13] You mean ./setup.py darcsver ? (this is in a git tree, in which I've copied the _version.py from a freshly 'setup.py build'-ed darcs tree) * zooko thinks. Do you have darcsver installed? no, I'm using ""setup.py --version"" to ask it what the tahoe version is, so I can guess the name of the tarball created by a subsequent ""setup.py sdist"" setup.py --version ? I've never heard of that. You could try ""python ./setup.py darcsver --loud"" ... [17:14] I'm expecting ""setup.py darcsver"" (via 'make make-version') to populate something which setup.py --version can see later I've gotta go. ok, see ya warner: um, I'll keep playing with this sorry, the way it currently works.. Let's see. I'm also using 'setup.py --package' to find out what the package name is btw, I only noticed these options a few minutes ago [17:15] they may not have ever worked but they'd be awfully handy for what I'm trying to write right now Well, they definitely don't work now. Information display options (just display information, ignore any commands) --help-commands list all available commands --name print package name --version (-V) print package version The way I had been doing it was to use ""python ./setup.py darcsver --count-all-patches"" to generate the version --fullname print - and something to do with ./src/allmydata/_appname.py for the app name. [17:16] ah, maybe I have to copy _appname.py too zooko: afaict my buildbot is on ... I remember having to do two things to make any given git tree work right, but I couldn't remember the other one ERC> }}}" zooko Milestone 2 "use ""darcs query"" to get count of patches faster" component1 enhancement somebody new 2009-02-12T21:58:13Z 2009-02-12T22:03:19Z "darcsver currently uses {{{darcs changes --xml}}} to get a count of patches, which takes 8 seconds on draco for the Tahoe trunk repository. Darcs also offers {{{darcs query repo}}} which emits the relevant value (the count of patches) in 0.4 seconds. This is important because it is probably the single largest component of slowdown in http://allmydata.org/trac/tahoe/ticket/591 (""make quicktest"" could be quicker and less noisy) (although it would probably be better to change ""make quicktest"" so that it didn't invoke darcsver at all, if possible.)" zooko Milestone 3 "store the hash of ""darcs changes --context"" and make it available as ""--hashed-version""" component1 enhancement somebody new 2009-06-21T17:59:13Z 2009-06-23T17:46:58Z "Suppose someone has a darcs repository of your project which is not merely a prefix of your repository (by ""prefix"" I mean here that one repository has all of the patches of the other, in order, from the first patch up until some patch, and then stops). Then the darcsver feature of showing a count of patches isn't sufficient to let you know how their version relates to your version -- indeed it could even be misleading. We would like for the version number generated (by darcsver) from the other person's repository to convey as much information as possible about how that repository relates to yours. In general (regardless of whether you are using darcs, git, hg, bzr, or something else), the version string can't communicate to you exactly what is in their repository unless the version string contains the full set of patches in their repository or, equivalently, if it includes an identifier of what is in their repository and also an address that you can use to get read-access to their repository in order to download the full set of patches. However, without going that far, the version string ''can'' reliably tell you whether their repository is ''different'' from yours, simply by including the hash of (some description of) their repository. It isn't so easy for the version string to reliably tell you whether their repository is the ''same'' as yours, because revision control tools (darcs and git, at least) tend to emit hashes of the history by which you got here rather than of the current state, and because small differences such as timestamps or automatically updated file contents might cause the hash to be different even when everything that you actually care about is the same. Fortunately, most of the time, the same history was used to get to the same place, and no minor change perturbed the state, so if the tree states match, the hashes usually match. And finally, if you sometimes have the same tree state showing different hashes (because of different histories or minor perturbations), that's not a big problem. What you really care about is if you have different states then you get different hashes, and that always works. To close this ticket, add a feature to {{{darcsver}}} in which it takes {{{darcs changes --xml|sha256sum}}} and stores the resulting hash, so that when you invoke {{{$YOUR_EXECUTABLE --hashed-version}}} it emits that hash. Then you can use that resulting hashed version to tell whether two repositories differ." zooko Milestone 4 "store the output of ""changes --context"" and make it available as ""--exact-version""" component1 enhancement somebody new 2009-06-21T18:51:06Z 2009-06-23T17:11:51Z "Suppose someone has a darcs repository of your project which is not merely a prefix of your repository (by ""prefix"" I mean here that one repository has all of the patches of the other, in order, from the first patch up until some patch, and then stops). Then the darcsver feature of showing a count of patches isn't sufficient to let you know how their version relates to your version -- indeed it could even be misleading. We would like for the version number generated (by darcsver) from the other person's repository to convey as much information as possible about how that repository relates to yours. In general (regardless of whether you are using darcs, git, hg, bzr, or something else), the version string can't communicate to you exactly what is in their repository unless the version string contains the full set of patches in their repository or, equivalently, if it includes an identifier of what is in their repository and also an address that you can use to get read-access to their repository in order to download the full set of patches. However, without going that far, the version string ''could'' contain the full metadata about all the patches (excluding patches which are covered by a tag). This would not only let you know (by visual inspection of the string) whether it was equivalent to a version that you produced, but it would also let you know exactly what was different -- if certain of your patches were left out, or if patches of their own device were added (patches which you might not actually be able to acquire, but the metadata of which you can read). This one is pretty easy to implement -- darcs uses this technique itself (if you run {{{darcs --exact-version}}} it prints out the full metadata about which patches went into that build of darcs." zooko Milestone 5 "store a read-address to the repository and make the latter available as ""--source-repo""" component1 enhancement somebody new 2009-06-23T17:11:03Z 2009-06-23T17:11:20Z "If you have ticket #3 (store the hash of ""darcs changes --context"" and make it available as ""--hashed-version"") or #4 (store the output of ""changes --context"" and make it available as ""--exact-version""), then you also want a way to read from the repository from which this version was produced, so that you can get the actual patches. Maybe darcsver could grab the contents of `host` and `pwd`, as a start." zooko Milestone 8 "extract an ""appname"" from the most recent tag" component1 enhancement somebody new 2010-08-01T17:42:20Z 2010-08-01T17:42:20Z "In Tahoe-LAFS we make tags like {{{tahoe-lafs-1.9.0}}}. darcsver currently finds the most recent tag and extracts a version number, in that example ""1.9.0"" from it. This ticket is to extend darcsver to also extract an ""appname"", in this case ""tahoe-lafs"", from the tag. This was David-Sarah's suggestion, and I like it." zooko