The second semester is not over yet and several assessments are yet to
come until the end of June (read "I'm considering sleepless night to
work on Subversion" :-) . Still, I'd like to share some thoughts with
all about the design of the serialisation format.
(In case you can't recall details the proposal suggested, here's a
shortcut: http://spicybox.net/svn-prop.txt)
First off, about the nature of the serialisation format. I think it
should use the svn protocol terminology, that is, the Editor Command
Set as in libsvn_ra_svn/protocol. It would look much like what
crosses the network when performing operations against svnserve: a
stream of functions driving the editor. This way we can reuse some
existing editor-driving code from other places, which would ease the
implementation and avoid reinventing the wheel. Now, I've seen
functions within libsvn_ra_svn API (svn_ra_svn_{read|parse}_tuple()
and such) to read and interpret tuples, but that doesn't look like an
option to use this code to read out from a file (the patch). In
libsvn_ra_svn/marshal.c there are some facilities to read and parse
tuples but here too I'm afraid this won't work as a verbatim use, and
using libsvn_ra_svn not to use ra_svn sounds weird. How about
duplicate and tweak? Otherwise I'll make the gap with APR file stream
functions and implement the parsing myself to drive the editor.
Second, when generating the patch ('svn diff --svnpatch'), we'll have
the following change as opposed to 'svn diff' default behavior:
* Delete: remove '---' lines; become delete-entry in the chunk
* Add: remove '+++' lines; become add-file + apply-textdelta
* Move: add-file with copy-path + delete-entry
* Copy: add-file with copy-path
Note: I'm not sure that's what we want with the Add operation. Do we
really want to "hide" this new file and its content into the chunk?
We also need to consider Move and Copy operations plus modifications.
I'd lean toward leaving contextual modifications within the
human-readable part. Application (patch application) would have to
deal with both the human and the computer -readable parts.
As many things will be hidden into the chunk, I'm planning to
implement a 'reveal' feature that would come along with the 'svn
patch' command so that it would be easy for the end-user to read
through the chunk and see what's inside before any use. I'm sure this
would prevent lots of surprises. Or, implement a --dry-run mode?
Either sounds nice.
I don't have code yet, but is it planned to create SoC feature branches?
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 11 23:44:19 2007