On Jul 26, 2004, at 3:46 PM, Paul Libbrecht wrote:
> Well, even this would be interesting, I think... that would be a half
> solution... but only half (as it would need to know the exact byte
> position of an XPath coordinate thus shouldn't tolerate, e.g., a
> whitespace difference.
I'm not sure you are understanding (it's hard to tell), so just in case
you arent:
svndiff is the name of the format that is actually stored in the
database.
It is a set of encoded instructions for how to produce some data (in
our case, a revision), given some other data (in our case, a previous
revision).
The binary diff algorithm svn uses, vdelta, produces svndiff
instructions.
You have two options for changing the binary diff algorithm:
1. Either make yours produce svndiff instructions (which i don't see
the real benefit in, since it will still be just a set of svndiff
instructions on binary data)
or
2. change svndiff so it can accomodate what you want to do.
svndiff is actually versioned now with the current version number being
0 (i produced an svndiff version 1, with better encoding/compression,
and in the process, added a version number to svndiff), and the version
number is stored in the svndiff stream.
You could produce an "svndiff version 2" that was nothing like the
existing svndiff at all (you could make it an xml based diff that works
in a completely different way, whatever), and as long as you teach
libsvn_delta to produce/read it, everything should work.
I consider these easy, but then again, i've done this before (As i
said, i produced an svndiff version 1 whose encoding is completely
different than the current svndiff version 0). It took me roughly 3-4
weeks to produce working code that did this.
What you can't currently do without going outside libsvn_delta, is
tell it to use svndiff version 0 for some files (IE use the standard
binary diff algorithm for some files), and tell it to use "svndiff
version 2" (your xml diff format) for other files. That would require
passing that information down from somewhere on high.
Of course, none of this is "pluggable" diffs, in the sense that they
are all hard-coded diff algorithms.
You could theoretically plug in any program you want to do the
encoding/decoding (as long as it can handle arbitrary data, and produce
something that we can store in the database), but it needs to always be
available, and always work, or else you'd seriously be f*cked.
The long and short of it is that hardcoded *new* diff algorithms for
certain types of files isn't actually all that hard. It's probably a
month or two of subversion hacking for an experienced subversion
hacker.
You can do special xml diffing that way if you wanted.
Plugging in random diff and merge programs at diff and merge time is a
completely intractable idea.
If your program changed its format, or failed to work with some
arbitrary data, it would make your revision database worthless (unless
you encode the way to decode the data, into the encoding format, which
is actually what svndiff does).
> Is the application of such patch really scattered around the source
> code ?
Theoretically, it should only touch libsvn_delta.
>
> paul
>
>
> Le 26 juil. 04, à 19:59, Daniel Berlin a écrit :
>
>> In fact, you *could* plug in your xmldiff, though it would likely be
>> pointless, since you'd have to take the results and turn it into
>> byte-oriented insert + copy instructions, which svndiff uses.
>>
>> :)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 27 04:38:45 2004