A simple implementation of the patches' XOR discussed on darcs-users
( http://lists.osuosl.org/pipermail/darcs-users/2015-December/027153.html ).
I'm not sure of the placement of the repoXor function. In this patch
it is in Darcs.Repository.State which, from the outside, makes sense
but that module only had functions related to the pristine state up
to now.
To try it run "darcs show repo".
1 patch for repository http://darcs.net:
patch 4ffc811884bedc6f08860d58ecd41ada4f4ff2e9
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date: Wed Dec 16 14:25:53 ART 2015
* implement repoXor and show it in "show repo" output
Modified the patch so that when --no-files is passed
to `darcs show repo` the XOR is not shown (otherwise
we break the assumption that `darcs show files --no-files`
is O(1)). Also change a comment.
1 patch for repository http://darcs.net:
patch 44d1170cca665bdd3ec891a8c7747992d12beca1
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date: Tue Dec 22 11:39:00 ART 2015
* implement repoXor and show it in "show repo" output
I'm happy with this, should we apply it?
I think we should come up with a less operational external name for
the hash - how about "weak repo hash"? "repoXor" is fine in the
code.
> zero = SHA1 z z z z z where z = minBound -- 0 for Word32
Why not just `0 0 0 0 0`?
By "external name" you mean what is shown in "darcs show repo"? I'm not
super happy with the "XOR" word but at least it's short. "Weak hash" is
not too long anyway and is indeed better.
About the use of minBound vs 0 , I remember using plainly 0 threw a
warning with GHC 7.8, but now that I'm trying again with 7.10 I no
longer have it. I'm sending an amended patch.
The new version, that I'm screening now.
1 patch for repository http://darcs.net:
patch 4d8a2ff4b094acc4ace791852d46749141979ba3
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date: Wed Jan 13 12:57:49 ART 2016
* implement repoXor and show it in "show repo" output as "Weak Hash"
Accepted after we talked about it during the sprint (with Florent and
Ganesh). Also going into 2.10 branch.
We thought maybe we need to prefix this hash with some letter, or make
it an URL so that users don't confuse it with a patch hash or some other
hash. But we ended up saying we will wait for the problems to appear
before fixing them preventively :)