On 6/22/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> Hi Charles, great to see you on the list. Here are my first thoughts.
Hey Ben!
> Your spec talks about the 'svn diff' command being able to produce
> 'default', 'unidiff', and 'svnpatch' output. My question is: why do
> we need both 'default' and 'unidiff' modes? Seems like the only
> difference is whether or not property diffs are displayed. The
> current output of 'svn diff' seems to be a combination of the two
> modes at the moment (unidiff, but also shows property diffs)... is
> there a compelling reason to change this? It would be a lot simpler
> to just have 'svn diff' continue producing what it does now, and then
> add one extra mode to produce our new 'svnpatch' format containing
> editor commands.
It has been discussed previously that we couldn't address all needs
with only 2 modes (default and svnpatch). I seem to recall:
- we don't want 'svn diff' default behaviour (designed more for
patch review than for patch(1) use) to be changed -- 'default'
- because of 'default' design, we need another format that really
fits with a patch(1) use -- 'unidiff'
The proposal at http://spicybox.net/svn-prop.txt tells about the 'why'.
I do think though that having three formats might be likely confusing
for everybody. And it would be hard to guess which format between
'default and 'unidiff' was used when looking at a patch. Should I
entirely focus on the 'svnpatch' format for now?
> My only other thought is that hey, yeah, I guess that using a chunk of
> svn-protocol is definitely a nice way of representing an
> editor-drive.... but is it optimal for us? Does it have too much
> baggage specific to client/server stuff? I'm just wondering if some
> other serialization format might be simpler.
Yes, hence I suggested to solely stick with the Editor Command Set.
What's nice with the svn-protocol is that people know it and there's
some code in the codebase to use it. After all, it's been designed to
drive an editor and that's what we want here. So this keeps from
re-inventing the wheel and having people to get to know yet another
serialization format (and write the implementation for it). The
Editor Command Set looks just perfect here as it is not client/server
-specific.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 23 18:30:10 2007