[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: pluggable diff program requirements? (was: Re: Any problems w/ very large (10-100MB) binary files?)

From: Karan, Cem \(Civ, ARL/CISD\) <CKaran_at_arl.army.mil>
Date: 2004-11-16 17:15:36 CET

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?

Thanks,
Cem Karan

> -----Original Message-----
> From: kfogel@newton.ch.collab.net
> [mailto:kfogel@newton.ch.collab.net] On Behalf Of kfogel@collab.net
> Sent: Monday, November 15, 2004 7:55 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:
> > OK. For now, I'll assume the basic format that diff uses as input.
> > Honestly though, has anyone started planning this out yet
> (anyone at
> > all)? If there IS someone who is thinking about all of
> this, I'd like
> > to start discussing things with them; the more planning
> now, the fewer
> > headaches later on.
>
> I'm worried there might be some confusion here.
>
> Diff doesn't have an input format -- its input is the files
> themselves, the 'before' file and the 'after' file. They can
> be in any format you want. If your diff tool only handles
> plain text files, then of course they should be some sort of
> texty format. But if your diff tool can handle, say, MS Word
> files, then they can be Word files.
>
> Have you used the --diff-cmd option to Subversion before?
> It's just a way to name a program that will take two
> arguments: the before file and the after file. It is
> completely agnostic regarding the formats of those files --
> that's up to your diff program to deal with.
>
> -Karl
>
> > > -----Original Message-----
> > > From: kfogel@newton.ch.collab.net
> > > [mailto:kfogel@newton.ch.collab.net] On Behalf Of
> kfogel@collab.net
> > > Sent: Monday, November 15, 2004 5:14 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:
> > > > Thats the ideal, but I'm thinking of the cases where the
> > > type of the
> > > > file affects what kind of diff program you want to use. E.g.
> > > > 'wordDiff' versus 'pdfDiff'. If there are plans to put
> together a
> > > > dictionary (MIME or file-type to program mappings) within the
> > > > repositories, then using a simple 'diff' compatible
> form is best.
> > > > However, if subversion is always going to be ignorant of
> > > the mappings
> > > > of file type->diff program, then it means I need to write a
> > > mapper of
> > > > my own. The mapper is easy; the problem is where to store
> > > the mapping
> > > > dictionary. Ideally, it would be stored within the repository
> > > > (probably as some sort of property), but I don't want this
> > > to conflict
> > > > with what people are already planning on doing. THAT
> is what I'm
> > > > REALLY worried about.
> > >
> > > I don't think there's been enough planning yet for you to be
> > > able to anticipate conflicts. Just go with the simplest,
> > > most obvious thing for now. Whatever mechanism Subversion
> > > eventually uses, it will surely be straightforward for you to
> > > make the appropriate tweaks to your wrapper/mapper.
> > >
> > > -Karl
> > >
> > > > > -----Original Message-----
> > > > > From: kfogel@newton.ch.collab.net
> > > > > [mailto:kfogel@newton.ch.collab.net] On Behalf Of
> > > kfogel@collab.net
> > > > > Sent: Monday, November 15, 2004 11:24 AM
> > > > > 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:
> > > > > > If you look on http://subversion.tigris.org/roadmap.html,
> > > > > you'll see
> > > > > > that pluggable client-side diff programs are part of the
> > > > > future plan;
> > > > > > that will solve problems when that comes about.
> Are there any
> > > > > > developers monitoring this right now? Where can we get
> > > in on the
> > > > > > requirements phase of this? (I'm scratching my own itch in
> > > > > developing
> > > > > > an OS X diff program right now, and I'd like to make it
> > > compatible
> > > > > > with subversion before I get too much further ahead)
> > > > >
> > > > > Well, I wouldn't think compatibility will be a huge problem.
> > > > > It's not like Subversion is completely without pluggable diff
> > > > > program support right now -- just make your program take
> > > > > arguments the way, say, GNU diff does, and you can
> use it with
> > > > > the --diff-cmd option with SVN.
> > > > >
> > > > > -Karl
> > > > >
> > > > >
> > >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 16 17:16:08 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.