Interesting...I didn't know that it didn't use the output in any way.
Part of my hope was that I could write a single diff program that both
svn and the end user could use. SVN would use the output to store
semantic differences rather than literal differences, and the end user
would be able to see the output in a meaningful way, rather than huge
spews of binary differences. My real hope is that subversion will
eventually have some sort of mapping system similar in intent to the
following:
first-file second-file
path-to-diff
MIME::text/plain:ebcdic MIME::text/plain:utf-8
/usr/local/bin/SVNdiffStuff/EBCDICtoUTF8
MIME::text/plain:utf-8 MIME::text/plain:ebcdic
/usr/local/bin/SVNdiffStuff/UTF8toEBCDIC
FILENAME::*.txt FILENAME::*.txt
/usr/bin/diff
FILENAME::*.proprietary FILENAME::*.proprietary
https://www.bigIron.com/propDiff
And yes, the last line is unlikely, but I figured I'd toss it in just to
get a discussion going.
The reason for this method of mapping is that the diff programs in
question don't have to guess about the file types they are differencing
at all. I also assume that subversion can do a check to see if the
files can be opened for reading before calling the programs. I'm not
quite sure how to pass in switches (build it into the path? Means that
you have multiple lines using the same program, but with different
switches), but I'm sure something can be worked out.
Other unanswered questions:
1) Would these programs be done on a per-install, per-repository,
per-directory, or per-file basis?
2) The mapping I've got above would work great on an ASCII based system;
not so hot on multi-byte encodings. Would an XML based approach (where
you can specify the encoding of the mapping) be better?
3) Will subversion do a check on the mapping file to make sure that it
is sane? e.g. if you've got the same pair of file types but to two
different programs, will subversion check it at run time? Or would it
be better to make it a part of the admin tool (svnadmin check-mappings
<mapping file>) so that you save a little time later on?
4) What methods of communicating file-types and program locations should
be used? I've listed a few ideas above, but they may be incomplete or
excessive.
5) Most importantly, there needs to be an absolutely firm standard on
how these programs communicate the differences they've found back to
subversion. I can look through libsvn_diff to figure out how it is
currently done, but it would be better to have a solid standard in
place.
Thanks,
Cem Karan
> -----Original Message-----
> From: kfogel@newton.ch.collab.net
> [mailto:kfogel@newton.ch.collab.net] On Behalf Of kfogel@collab.net
> Sent: Wednesday, November 17, 2004 6:30 PM
> To: Karan, Cem (Civ, ARL/CISD)
> Cc: Matthew England; users@subversion.tigris.org
> Subject: Re: pluggable diff program requirements? (was: Re:
> Any problems w/ very large (10-100MB) binary files?)
>
>
> "Karan, Cem \(Civ, ARL/CISD\)" <CKaran@arl.army.mil> writes:
> > Nope, no confusion. I know what you mean below, I just
> meant format
> > as in 'how you pass in commands + files to diff' which is basically
> > 'diff [options ]file1 file2' and that the output is the
> unified output
> > format. I'm assuming that subversion understands the unified diff
> > format in terms of storing the data, right? I ask so that when I
> > write a diff program, it outputs the correct format. Also,
> is there
> > anything in the way subversion works that prevents me from
> popping up
> > a seperate bitmapped window? I would like to have my diff program
> > usable by subversion AND by the end user, such that when
> invoked the
> > end user can see the differences, and when they close the window,
> > save, whatever, subversion gets the output from the command. Are
> > there any problems with this?
>
> Subversion does not use the output of 'svn diff'. The output
> is for the user only. This is why I am still confused at
> your question...
>
> -Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 18 18:01:12 2004