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

[Thomas Keller]

Am 11.08.2010 07:55, schrieb John Bailey:
> On 08/10/2010 04:28 PM, Thomas Keller wrote:
>> Am 10.08.10 17:20, schrieb John Bailey:
>>> It would be nice to have a way to send (or possibly even generate for manual
>>> sending) a series of patches in a manner similar to what git and hg allow.
>>
>> Could you please be a bit more specific how you'd imagine this should
>> work out / look like? Personally I haven't dealt much with the patch
>> possibilities in neither hg nor git, so it would be interesting to know
>> what you actually need.
> 
> Ok, here's a scenario that I've seen recently, albeit not one that Pidgin was
> involved in.  I apologize for the length, but I want to make the use case 
> clear.
> 
> A user has no write access to any public netsync servers and is behind a
> firewall he does not control (thus can't run a netsync server).  This user has
> taken an interest in some section of the project and begins committing minor
> bugfixes and feature additions to his local database.  Now he'd like to send 
> the
> revisions he committed in some manner.
> 
> Let's presume for illustrative purposes that his beginning revision is 
> abcd1234
> and his ending revision is cdef3456.  Ideally we'd have some command where we
> could tell monotone to generate the series of patches for revisions starting 
> at
> abcd1234 and ending at cdef3456 (where each patch would look like the output 
> of
> 'mtn log --no-graph --diffs --last 1 --from $rev', for the purpose explained
> below).  From here I'm not sure what the best approach would be to actually
> transport the information via e-mail.  Mercurial, at least, allows use of raw
> SMTP, the sendmail command, or creation of an mbox file and can have the 
> patches
> be either inline or attachments.
> 
> On the other side, the receiving developer should be able to reassemble and
> "import" the patches.  The idea is that importing the patches would add them 
> to
> the importer's database as revisions, ideally making use of the data before 
> the
> actual patch (i.e. the parent, author, date, branch, and changelog fields).  
> In
> the case of Mercurial, there is an extension that allows importing patches 
> from
> an mbox file or an IMAP mailbox.
> 
> I know there are some challenges to this, such as how to handle merges.  I 
> don't
> expect this overnight, and truthfully, I count it only as a "would be nice"
> thing.  Also, I don't really expect monotone to grow SMTP or IMAP support.  I
> imagine some of monotone's developers would think those to be unreasonable
> things to support, as monotone is a VCS, not a Swiss Army Knife.  I'd be 
> willing
> to bet, however, that a lot of people would be happy with generating a simple
> mbox file, as there are a ton of tools that can read them for review prior to
> import.

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

#
# old_revision [6ff3990cfa24fe3223d0133c69efc37b4449f1a6]
#
# patch "binary-file"
#  from [617c3ae809ca290b34932c165822e2b57576db75]
#    to [db3f4d9546deed6864d3aa2c66575466d7e0ed47]
#
# patch "text-file"
#  from [55587ed635c15b26bdf7c17d80ee30e20f5fe971]
#    to [17c5fb5cd4e02443d30c372f43732ed1ac5312a3]
#
============================================================
--- binary-file   617c3ae809ca290b34932c165822e2b57576db75
+++ binary-file   db3f4d9546deed6864d3aa2c66575466d7e0ed47
#H4sIAAAAAAAA/5VU227aQBB991dMLaHYARNfuFPSh6iRIuUP2got9hovgV2
#0u4TSqv/emTVgSNpK9YMxs3M5c+bsPEAMw0Fv7D1B0h94d3dg9QGsgg2zeQ
#...
============================================================
--- text-file        55587ed635c15b26bdf7c17d80ee30e20f5fe971
+++ text-file        17c5fb5cd4e02443d30c372f43732ed1ac5312a3
@@ -1,3 +1,4 @@
+asd
 sdfasdf
 hsdfga
 sdgasg

   and only processes the text parts it finds

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?)

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.

A "package" in a whole could probably then look like this:

# ----------------------------------------------------------
#
#  cert_name "author"
# cert_value "Thomas Keller"
#
#  cert_name "date"
# cert_value "2010-08-11T10:54:22"
#
# ...
# ----------------------------------------------------------
#
# old_revision [6ff3990cfa24fe3223d0133c69efc37b4449f1a6]
#
# patch "binary-file"
#  from [617c3ae809ca290b34932c165822e2b57576db75]
#    to [db3f4d9546deed6864d3aa2c66575466d7e0ed47]
#
# patch "text-file"
#  from [55587ed635c15b26bdf7c17d80ee30e20f5fe971]
#    to [17c5fb5cd4e02443d30c372f43732ed1ac5312a3]
#
============================================================
--- binary-file   617c3ae809ca290b34932c165822e2b57576db75
+++ binary-file   db3f4d9546deed6864d3aa2c66575466d7e0ed47
#H4sIAAAAAAAA/5VU227aQBB991dMLaHYARNfuFPSh6iRIuUP2got9hovgV2
#0u4TSqv/emTVgSNpK9YMxs3M5c+bsPEAMw0Fv7D1B0h94d3dg9QGsgg2zeQ
#...
============================================================
--- text-file        55587ed635c15b26bdf7c17d80ee30e20f5fe971
+++ text-file        17c5fb5cd4e02443d30c372f43732ed1ac5312a3
@@ -1,3 +1,4 @@
+asd
 sdfasdf
 hsdfga
 sdgasg
# ----------------------------------------------------------
#
#  cert_name "author"
# ...


Opinions?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature