"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.
> > -----Original Message-----
> > From: firstname.lastname@example.org
> > [mailto:email@example.com] On Behalf Of firstname.lastname@example.org
> > Sent: Monday, November 15, 2004 5:14 PM
> > To: Karan, Cem (Civ, ARL/CISD)
> > Cc: Matthew England; email@example.com
> > 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: firstname.lastname@example.org
> > > > [mailto:email@example.com] On Behalf Of
> > firstname.lastname@example.org
> > > > Sent: Monday, November 15, 2004 11:24 AM
> > > > To: Karan, Cem (Civ, ARL/CISD)
> > > > Cc: Matthew England; email@example.com
> > > > 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 16 01:55:47 2004