>>>>> "Jason" == Jason M Felice <[EMAIL PROTECTED]> writes:
Jason> Quoting "Stephen J. Turnbull" <[EMAIL PROTECTED]>:
Did you quote what you intended to? ;-) I see no relationship, so I'm
omitting it.
Jason> My understanding (which I've verified) is that the author,
Jason> the patch name, the patch log message, the date, and
Jason> whether the patch is inverted are all hashed to create the
Jason> unique filename. Therefore, you can't even edit the log
Jason> message or the name after recording (and look how many
Jason> typos there are in darcs' own "changes"!)
I don't have a problem with that, really. (Cf the errata policy for
IETF RFCs.)
Jason> It would seem to *me* to be more sane to hash the patch
Jason> file's contents plus whether it was inverted instead. This
Jason> way unpull/pull or unrecord/record will only corrupt the
Jason> repository (from the perspective of other pullers) in the
Jason> case where a previously pulled patch's _contents_ were
Jason> actually changed.
You're halfway to "git", there. :-)
I've been thinking about this, although I unfortunately can't read
Haskell yet.
I think that, like git (and as you suggest), the patch contents should
be hashed to get a name for the change itself. But I think that the
metadata is part of the patch, not just a human-readable name.[1] So
it should also be hashed, along with the "name" of the contents (the
content hash), to give the patch's unique name. (IIRC, this is like
"git tag".) Then if you want to replace the contents with something
different, you can keep the meta data, and add "Replaces:
old-patch-unique-name" to the hash. That gives a robust
implementation of amend-record. (I haven't thought about this part
carefully, so assume any apparent bugs are bugs!) Similarly, if you
want to replace the meta-data but keep the change, that's easy enough,
too. This would solve Clive's problem. It also should make clear why
Clive's problem is non-trivial.
The reason I want this facility is that I would like to be able to
decompose patches ex post into a set of patches that each contains a
clean changeset, or aggregate a bunch of patches into a changeset.
I'd also like to be able to merge identical patches into a single
patch with alternative names, that kind of thing.
Footnotes:
[1] This is not something I thought up for myself, and I'm not really
in a position to argue it right now. The gnu-arch-users mailing list
archives would be a good place to look for arguments why making
meta-data essentially read-only is a good idea.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
