yuja added a comment.

  >   > >   >  extras field. Almost all extras data are texts, and IIRC we 
regret that
  >   > >   >  transplant sources are stored in binary form.
  >   > >   
  >   > >   Why not? I picked \0 and \n because they won't appear in filenames, 
so it's convenient in that way.
  >   >
  >   > I don't remember, but we do store even boolean value as text, not in 
binary
  >   >  `\0`/`\1` form. `transplant_source` is the solo exception.
  >   
  >   
  >   Perhaps it's just so `{extras}` doesn't print ANSI escape codes and such? 
(I assume that can still happen if put escape characters in your filenames, for 
example.)
  
  Ok. That might be the reason, and I'm fine with the `\0` separator.
  
  >   > https://www.mercurial-scm.org/wiki/ChangesetExtra
  >   > 
  >   > And if we pick \0/\n separators, _string_escape() wouldn't be needed
  >   >  at the encodecopies() layer.
  >   
  >   Oh, now I see what you're saying! That's embarrassing. So maybe we should 
`_string_escape()` the whole thing? I'll do that.
  
  Not really. I meant `_string_escape()` could be removed entirely if we store
  copies in binary (valid_filename + invalid_filename_separator) form. The extra
  dict will be encoded later.

REPOSITORY
  rHG Mercurial

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

To: martinvonz, #hg-reviewers
Cc: yuja, pulkit, gracinet, marmoute, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to