[darcs-users] darcs patch: resolve issue27: add junk to patch identifiers.

[Eric Kow]

> Wed Sep 17 11:10:46 EDT 2008  David Roundy <droundy at darcs.net>
>   * resolve issue27: add junk to patch identifiers.

Looks fine to me.

I still would be happier with a deterministic approach.  To be clear,
what I have in mind is to keep things simple.  For example, I do not
particularly care about about self-authentication (sorry Zooko) nor do I
think we should bother to keep this deterministic across all versions of
darcs.  So for me, it's perfectly OK if tailorising with darcs 2.0.3
gets you different result from tailorising with darcs 2.1.  With this
relative paucity of desires, it seems like a 'simple' calculateHash
(show patchAndContext) would do the trick.  As an added bonus, this even
saves us from putting things into IO!

That said, I trust you if you say "considerably harder to produce".
Perhaps one issue is that when we want to create a patch info, we don't
always have the context handy in convienient form.  If so, too bad :-)

In any case, I'm taking this for stable, although I might postpone it
until darcs 2.1

resolve issue27: add junk to patch identifiers.
-----------------------------------------------
> +GHC_CHECK_MODULE(System.Random, random, randomRIO (0,10) :: IO Integer,,
> +                 AC_MSG_ERROR(Cannot find System.Random; try installing the Haskell package random?))
> +

If we were to keep this, I think we could remove Dmitry's
Windows-specific check

> hunk ./src/Darcs/Commands/AmendRecord.lhs 153
> hunk ./src/Darcs/Commands/Record.lhs 200
> hunk ./src/Darcs/Commands/Record.lhs 211
> hunk ./src/Darcs/Commands/Record.lhs 390
> hunk ./src/Darcs/Commands/Rollback.lhs 137
> hunk ./src/Darcs/Commands/Tag.lhs 83
> hunk ./src/Darcs/Commands/Unrevert.lhs 129
> hunk ./src/Darcs/Commands/Unrevert.lhs 131

The changes here are straightforward consequences of patchinfo being in
IO

> hunk ./src/Darcs/Patch/Core.lhs 111
> -anonymous :: Patchy p => p C(x y) -> Named p C(x y)
> +anonymous :: Patchy p => p C(x y) -> IO (Named p C(x y))

Hmm... do we really want this?  Would it be better to just use the
NamedP constructor here and stay out of IO?

> +add_junk :: PatchInfo -> IO PatchInfo
> +add_junk pinf =
> +    do x <- randomRIO (0,2^128 :: Integer)
> +       return $ pinf { _pi_log = packString (head ignored++showHex x ""):
> +                                 ignore_junk (_pi_log pinf) }

Add junk, clobbering any pre-existing junk.  For the interested, the key
is to remember that _pi_log is a list of lines, not just a single string.

> +ignored :: [String] -- this is a [String] so we can change the junk header.
> +ignored = ["Ignore-this: "]

I like your eye for future-proofing :-)

> +ignore_junk :: [PackedString] -> [PackedString]
> +ignore_junk = filter isnt_ignored
> +    where isnt_ignored x = doesnt_start_with (unpackPS x) ignored
> +          doesnt_start_with x ys = not $ any (`isPrefixOf` x) ys

Just a silly low-level comment.  In situations like this, I tend to find
myself pushing the negativity as far up to the suface as possible, so
filter (not . is_ignored).

> - $$ vcat (map ((text "  " <>) . packedString) (_pi_log pi))
> + $$ vcat (map ((text "  " <>) . packedString) (ignore_junk $ _pi_log pi))

This is just the human friendly output.
It may be worth making the XML output fancy by putting the junk into an
attribute.

> hunk ./src/Darcs/Repository/Internal.lhs 523

The changes here are a straightforward consquence of the anonymous
switch to IO.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080918/447ddb0f/attachment.pgp