Re: property co-existence problems.

[kf...@collab.net]

Jani Averbach <ja...@jaa.iki.fi> writes:
> I like the idea, but: What about if this property could contain a value and
> the name is in fact svn:merge (or what ever):
> 
> svn:merge=diff
> svn:merge=xml-diff
> svn:merge=my-very-special-binary-diff
> 
> This way we won't paint ourselves in the corner, if and when, we have
> some day any other merge support than ordirany diff. Or the semantic
> of the value could be that if it is NULL, then use default (diff)
> otherwise the system specified by the value.

Heh -- now we're already experiencing feature creep, or something like
it.

There are several different problems going on here, I think:

   1) We determine textiness from mime-type.
   2) We determine mergeability from textiness.
   3) We determine eol-mungability from textiness.

The proposal for the "svn:text" property solves problem number (1).
Now we would have a way to determine textiness.

But is "textiness" the right determinant for how to merge something?
And is an object's preferred merging behavior related to its proper
diff behavior?  And are either of these two things related to whether
svn:eol-style should be honored?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: property co-existence problems.

[Julian Foad <ju...@btopenworld.com>]

kfogel@collab.net wrote:
> There are several different problems going on here, I think:
> 
>    1) We determine textiness from mime-type.
>    2) We determine mergeability from textiness.

Determining mergeability from the MIME type (directly or indirectly) is 
basically the right thing to do: that is exactly the sort of thing a MIME type 
is for.

>    3) We determine eol-mungability from textiness.

One can see the attempted logic in that, but as we can't universally define 
"textiness" this doesn't universally work.

> The proposal for the "svn:text" property solves problem number (1).
> Now we would have a way to determine textiness.
> 
> But is "textiness" the right determinant for how to merge something?

Only in the limited world where there is just one merge algorithm - and we 
already claim to support pluggable merges.  So: no.

> And is an object's preferred merging behavior related to its proper
> diff behavior?

Related, yes, but not very closely.  In practice we need to be able to specify 
them independently.

> And are either of these two things related to whether
> svn:eol-style should be honored?

In my opinion: no.  I think we need to move carefully but positively towards 
obeying the EOL style regardless of MIME type and diffing and merging.


I see the problems as:

     A) We determine mergeability and diffability from MIME type regardless of 
which merge or diff program is to be used.  Thus pluggable diff/merge aren't 
invoked when they should be.

     B) We ignore svn:eol-style for certain MIME types, though there is no need 
to do so.

     C) Our interpretation of svn:mime-type is not extensible.

Proposal: we read and use a configurable mapping from MIME types to diff and 
merge methods.  This would initially be in the per-user configuration file 
(though, as often before, this may bring up the desire for some way of 
distributing such configuration from the repository).  An example of a typical 
configuration (syntax yet to be determined):

[[[
# For each list of MIME type patterns, a diff command and a merge command
#   are specified.  If a command is empty, no diff/merge is performed.
#   For the built-in diff/merge, write svn_internal_diff/_merge.
#   (n.b. We currently say "diff3" for "merge".)

# Plain text files. (There would be a built-in default configuration
#   something like this, matching the old, built-in behaviour.)
For MIME types: text/*, blah/xml
   diff-cmd=/usr/bin/diff
   merge-cmd=svn_internal_merge

# Default (non-)actions. (This section need not be specified)
For MIME types: *
   diff-cmd=
   merge-cmd=
]]]

I think this addresses A and C.  B would be addressed by phasing in 
unconditional processing of svn:eol-style.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org