Dave Pawson <firstname.lastname@example.org> wrote on 09/07/2005 08:52:01 AM:
> On 07/09/05, Mark Phippard <MarkP@softlanding.com> wrote:
> > > Which makes it unsuitable for handling XML files, if a diff is
> > Subversion may very well be unsuitable for handling certain types of
> > files, but it isn't for this reason. The internal storage format used
> > Subversion does nothing that will prevent you getting a proper diff
> > between revisions.
> Fair comment.
> I guess it is XML definitions that makes 'identical' different.... if
> you see what I mean :-)
> can be 'identical' to
> If you had a diff tool that gave the results you are
> > looking for and could be plugged into Subversion, then it would work
> > regardless of the Subversion internal formats.
> and svn accepted the output of that diff engine, yes.
> Ryan said
> No, Subversion always uses its internal differencing engine to store
> diffs. Specifying alternate diff tools is solely for your benefit
> when you're examining files.
> which implies that is not the case?
No. You are comparing two different things. How Subversion internally
stores its revisions is irrelevant (unless you are making a disk space
argument). Subversion would never allow an external program to be
involved in this as you could not guarantee integrity. Subversion uses
the same binary differncing algorithm in all file types. The output of
this is used to store the revisions internally in the repository, but this
has nothing to do with svn diff. svn diff just constructs the full texts
of the revisions being compared and then diffs them. The internal
representation is only used to construct the full texts. If you plugin in
an external diff tool, Subversion will just be feeding the full texts to
that tool so that it can diff them.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Sep 7 14:59:04 2005