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

Re: Merge mode (Was Classifying files as binary or text)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 18 Nov 2009 11:09:52 +0000

Mike Samuel wrote:
> What are the advantages of taking into account file path and mime-type
> over having autoprops look at mime-type and squirrel information away
> in the mime-type?

Two things:

1. Not coupling the data to knowledge of what tools will available to
the user. So it will allow me to install a special merge tool that
handles XML, for example, or MS-Word documents, for example, and hook
that into Subversion with a svn:mime-type and/or file names, even though
other users of the project may not have those tools available and would
therefore still need to be using the basic text-or-nothing merge modes.

2. Recognizing a stored setting is only half the problem. How to get
that setting set to sensible values consistently on all the files is the
other half of the problem. The proposal lacked a solution to that,
because auto-props is severly under-powered. (Auto-props cannot "look at
mime-type", nor can it examine file content; it can only match filename
patterns.)

> If file name is taken into account, how does diffing with ancestry
> work when a file has been added as a result of an svn mv or svn cp?

You mean, how would we handle the case when diffing a file that has two
different names that might map to two different merge-modes? The answer
would be some simple rule such as "use the later one".

(It is the same issue as how to decide what to do if it had two
different svn:mime-type values, or two different svn:merge-mode
properties. We already deal with similar issues with most of the other
svn:* properties.)

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419453
Received on 2009-11-18 12:10:27 CET

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

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