indygreg added a comment.

  This is more of an RFC patch. My actual goal is support for ingesting CBOR 
patches via `hg import`. I figured it would be easier to test that if we had 
support for CBOR with `hg export`. And the reason I want CBOR support for patch 
ingestion is because it is safer: it reduces the surface area for injecting 
badness via patch parsing. See e.g. 
http://rachelbythebay.com/w/2018/04/05/bangpatch/. This implementation is still 
only partially there: I think a better approach would be to have structured 
data for the diffs so we don't need to parse those either. That would allow us 
to use binary data without escaping, not have to use inline text metadata for 
copy/renames, not have to worry about encoding of filenames, etc. All the 
problems with "parse a patch" go away and you are left with commit metadata and 
a series of splicing instructions, which should be pretty generic.
  
  The I/O in the export code is pretty wonky. I'm kinda sad that `cbor2` 
insists on binding an encoder/decoder to a file object. I *really* wish you 
could get straight bytes out of it without having to use `io.BytesIO()`.
  
  I suspect someone is going to tell me that `hg export` should use the 
templating layer. If someone does, I would appreciate help implementing that. 
Of course, for us to get CBOR with the templating layer, we'd have to teach the 
templating layer to emit CBOR. Since we can emit JSON, CBOR seems reasonable. 
I'm just not too familiar with that code though.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D3175

To: indygreg, #hg-reviewers
Cc: mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to