Re: svn diff output

Ben Collins-Sussman <sussman@collab.net>:
> In defining an extended patch format, it seems like there are a lot of
> different goals to choose from here. And they all seem to be mutually
> exclusive. What's most important to us?
>
> * arch compatibility?

I don't think this will work. Someone else pointed out that (a) the format
is binary, and (b) it involves an arch-specific notion of file IDs.
I think we want something purely textual that we can mail around.
 
> * svk compatibility?

I'm mildly against this, as I think svk is a kluge. A kluge with some
interesting ideas in it and an energetic and clever project leader, mind
you, but still a kluge.

> * 'patch' compatibility? (i.e. defining a format whereby
> tree-structure changes are just ignored by Larry Wall's 'patch'?)
>
> * trying to use what we have? (tweaking our dumpfile format)
>
> I think we can choose only one of these goals. :-)

Oh? I'm not sure why. The dumpfile format is not written in stone,
after all. I can readily imagine moving the surface syntax to being
patch-compatible. However, I don't think it would be wise to try
doing that at the same time we're working out the semantic issues in
dump/patch unification. There would be too much risk of allowing the
classic patch format to contrain our thinking.

I suggest the following plan:

1. Implement the action diff and repo sync primitives using whatever
enhanced version of the editor_t object we turn out to need. Stick
with marshalling/unmarshalling editor_t objects to the dump format or
a close enhancement.

2. After step 1 is done, try to change the dumper/parser so that it handles
a format Larry Wall's patch(1) understands in simple cases.

By doing it in two steps, we make sure Subversion's functional objectives
are satisfied *first*. I think being patch(1)-compatible is a laudable
goal but a secondary one.

-- 
		Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org