[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: Mike Samuel <mikesamuel_at_gmail.com>
Date: Wed, 18 Nov 2009 12:11:39 -0800

2009/11/18 Branko Čibej <brane_at_xbc.nu>:
> Mark Phippard wrote:
>> This probably is an example of our OCD getting in the way.  Why did we
>> even add this mime.types feature to begin with?  Who thought it would
>> be a brilliant idea to add a "proper" mime-type to every file in the
>> first place?  Basically, we added a feature that was not needed that
>> cascades to create a problem.
>>
>
> Couldn't agree more ... we badly misjudged that one. Using mime.types is
> OK if you're setting svn:mime-type, but not if you're also telling SVN
> how to diff/merge/whatever that file.
>
> (BTW ... we could have a different prop name instead of merge-mode to
> indicate that it can, in fact, cheerfully apply to diff and blame, too.)

I'm still collecting property names so we can compare all at once.
Merging/diffing/etc. are all about breaking a document into smaller
chunks based on semantic or structural cues.

From natural language, breaking into semantic units is "segmentation"
From CSV parsing, one has "field separators" and "record separators"
From parser theory, splitting a stream into context-free chunks is
"lexing" or "tokenization."
Multipart envelopes tend to deal with "chunks."
Video/audio codecs and other diff based streams with checkpointing
tend to deal with "frames."

Maybe
    svn:segments in ('none', 'line-based')
    svn:lex-mode in ('none', 'line-based')
    svn:chunking in ('none', 'by-line')
    svn:framing in ('none', 'by-line')

> -- Brane
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2419677
Received on 2009-11-18 21:12:01 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.