Re: [Monotone-devel] Re: removal of packet functions

[John Bailey]

On 08/11/2010 04:50 AM, Thomas Keller wrote:
> I think this should be doable - we planned to let monotone eat its own
> dog food long ago (i.e. some kind of "mtn patch" command), its just that
> nobody has started on that yet. The problem might be divided into
> several sub tasks / issues:
> 
> 1) implement a way to represent binary patches in some 7bit-clean
>    manner. we could probably just steal the fdelta format we
>    currently output for automate packet_for_fdelta and wrap it nicely.
>    if we want to include this into plain mtn diff, we should probably
>    leave the current "# XY is binary" stanza and pad each following
>    line with a "#" for the fdelta data, so we still have a vague
>    chance to generate valid diffs which patch(1) accepts. I played
>    around with it and crafted an artificial diff and it seems as if
>    patch ignores the binary part here completely
<snip>
>    and only processes the text parts it finds

I hadn't considered binary files.  That seems like it could be a workable
solution, so long as the binary files involved aren't large enough to create a
ridiculously large patch.

> 2) create a "pack" command which "packages" together a single
>    revision or multiple revisions just like mtn di does (i.e. raw
>    revision format in the header) plus the accompanying certs of that
>    revision.
>    Multiple revisions would just lead to multiple sets of
>    information, i.e. we do not allow collapsing multiple revisions
>    into one changeset for now, as we'd have to work out f.e. what
>    to do with all these multiple certificate values (concatenation
>    might be an option for changelog and comment, but what to do
>    with date, author and branch?)

In the event of an acceptable set of revisions, I'd prefer to be able to retain
the history, so treating each of the submitter's revisions as a new revision in
my database is what I'd want to see.  So my opinion is definitely don't collapse
revisions.

> 3) create an "unpack" command which reads such a packaged revision
>    apply that to a workspace. this is actually the hard part, since
>    we have no diff-applying code in mtn yet, and we need to handle
>    things like updating the workspace to the parent_revision of a
>    single packaged revision and then apply the diff. and we need
>    to handle conflicts gracefully somehow.
> 
>    applying the raw revision data and patch is not enough though,
>    just as we allow the caching of a log message in _MTN/log now, we
>    need to find a way to cache other certificate values from the
>    package in _MTN as well, since we should not commit the patch
>    directly without review of committer and would otherwise loose
>    this information from the package after we applied it.

Perhaps a way to step through the revisions in the "package" would be in order
here.  I'm not quite sure how to envision a sane way to handle it, though.

> A "package" in a whole could probably then look like this:
<snip>
> Opinions?

The package format looks fine to me.

John

signature.asc
Description: OpenPGP digital signature