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

Re: Merge by file type

From: tekHedd <tekhedd_at_byteheaven.net>
Date: 2005-04-09 03:53:53 CEST

Dale Worley wrote:
>>From: tekHedd [mailto:tekhedd@byteheaven.net]
>>
>>The phrase "plugin architecture" comes to mind.
>>
>>Or even a mapping of "mime-type --> external merge program", although
>>this isn't quite as cool. (Coolness is overrated.)
>
>
> Although it seems like it would be sufficient if there was some way for the
> diff program to know the MIME media type of the files (really, the
> svn:mime-type property). The user's diff program can decide what to do
> based on that.

svn probably knows the type of the file at the time it's mergeing it, so
it could pass that info to the external program along with the other info.

The only real negative I see here is that you have to pass the various
things you're merging to the external program, so it won't be possible
to do anything cool optimizing the bandwidth involved. Not that I know
anything about that.

Looks to be possible without compromising anybody's principles. The
question is, who has time? :-} This one could sit in the enhancement
queue for quite a while unless someone gets inspired or paid. (I guess
one is a subset of the other.. :)

Cool feature though, especially since a) merge technology is always
evolving, and b) it allows the removal of algorithms if it is discovered
that they are patented or whatever (or their use only in countries where
the patents don't apply, etc etc).

<sigh> Not enough time in the world!
tom

-- 
Tom Surace                )                 ,~~v~~,
tekhedd@byteheaven.net    )                ,`.   .`,
http://www.byteheaven.com ) ------------- ===  +  === ---
                                       Hamster was here

Received on Sat Apr 9 04:27:39 2005

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.