Opened 16 years ago
Last modified 16 years ago
#3 new enhancement
store the hash of "darcs changes --context" and make it available as "--hashed-version"
Reported by: | zooko | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | component1 | Version: | |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
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.
Change History (3)
comment:1 Changed 16 years ago by zooko
comment:2 Changed 16 years ago by zooko
See also #5 (store a read-address to the repository and make the latter available as "--source-repo").
comment:3 Changed 16 years ago by zooko
Ooh, it turns out that the darcs hackers are actually making some progress on http://bugs.darcs.net/issue992 ! That would be way better than this kludge in this ticket. http://lists.osuosl.org/pipermail/darcs-users/2009-June/020262.html and http://lists.osuosl.org/pipermail/darcs-users/2009-June/020263.html .
This method of generating a hash of the version might be less efficient and less secure than if darcs did it itself. That's the topic of http://bugs.darcs.net/issue992 (short, secure, fast version identifiers), which has a more complete explanation of the desired use case from Brian's point of view as well as a proposal by David Roundy of how darcs could implement it.