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

Re: Action request: mime-type of xml-dtd should be treated as text

From: John Peacock <john.peacock_at_havurah-software.org>
Date: Tue, 05 Feb 2008 14:02:57 -0500

John Aldridge wrote:
> Granted there will be cases where the text representing the XML infoset
> is changed radically although the infoset itself remains constant. Even
> though regarding the file as text is not useful in those circumstances,
> I don't see what harm is done. The worst would be that an inappropriate
> merge happened which resulted in the file becoming invalid XML -- again,
> I don't see a difference between that and a merge which renders C++ code
> uncompilable.

Well, for one thing unless you are using a DTD-aware editor, the odds
are you won't necessarily notice a badly merged XML document change
nearly as quickly as you would if your compile broke.

I'm going to continue to argue that it would be wrong to make
application/xml* be anything other than binary, if only because at some
point, Subversion *will* have the hooks to call an appropriate diff
editor to resolve conflicts.

I can certainly appreciate that for *you*, and indeed for many users of
XML documents, being able to treat them as text would be acceptable
(i.e. you acknowledge /a priori/ that this mapping is imperfect, but
most of the time it will be fine). But I'd much rather there be a new
property that overrides the binary/text handling, rather than globally
forcing everyone to accept your assumptions. If only there were more
hours in the day, I could even offer to produce a patch to implement it
in time for 1.5's release...

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-05 20:03:23 CET

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.