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

Re: special property for text types

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 07 Feb 2008 13:11:31 -0500

Karl Fogel <kfogel_at_red-bean.com> writes:
> Is one knob enough to indicate all the things we need to indicate? Is
> it always the case that (1) and (2) travel together? If so, a boolean
> 'svn:is-text' property would be enough. But the things we need to
> indicate might be disjoint, in which case either multiple properties
> or one property with multiple possible values may be needed.

The more I think about it, the more sense an 'svn:is-text' or
'svn:line-based' boolean property makes. (But I can't shake a feeling
that Mike Pilato and I had a long conversation about this once, and
that he wrote up some subtle and unexpected thoughts somewhere, and
that we really should find those now.)

The reason I mention 'svn:line-based' as the name is that being
line-based is the real issue here. XML is always text, in the sense
of being UTF-8 or (in rare cases) some other Unicode encoding. The
question is merely whether it's organized into lines, such that
diffing and merging work.

It may well be that when people think "texty", they really mean
"liney", in which case maybe we should call it "svn:is-text" anyway,
just to match people's instinctive terminology.

Oh, and one other thing:

As pointed out in the users@ thread, the presence of 'svn:eol-style'
should also be sufficient to mark something as "text". In other
words, these things would all have the same meaning:

   - svn_mime_type_is_binary() returning false
   - svn:eol-style being present at all
   - new special property ('svn:is-text' or whatever) being present.

This minimizes the chances that someone would ever have to futz with
the new property, which is good -- existing properties, that might be
present for other reasons anyway, will have the magical effect of
causing diffing and merging to Just Work.

A UI contrarian, such as Jack Repenning, might say "But that's not
actually better, because then in the cases where diffing and merging
don't work, the user won't understand why -- Subversion will seem
arbitrary and inconsistent, sometimes working and sometimes not!"
Such a contrarian would have a very good point, and I would have no
convincing answer for that person, I mean, were he to exist. There
are advantages and disadvantages either way. But I think the best
general principle is for Subversion to use all the information
available to it in any individual case, and document how it works so
(some) users know what's going on.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-07 19:11:59 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.