Re: [viewvc-dev] Re: [viewvc-users] Don't display binary files

JJ <[email protected]> Mon, 24 Nov 2008 12:38:15 -0600
Newsgroups gmane.comp.version-control.cvs.viewcvs.devel
Message-ID <[email protected]>
On Mon, Nov 24, 2008 at 12:09 PM, C. Michael Pilato <[email protected]>wrote:

> JJ wrote:
> >> [Stop me here if the goals are different, or ordered differently]
> >
> > I agree.
>
> Good.
>
> >> The only clean, not-configuration-complicating solution I can come up
> with
> >> is to add "is_text" (alongside "prefer_markup") to the set of data
> >> dictionary items for the files.
> >
> > I agree.
>
> Good.
>
> > I personally still think we should give users the following options
> > (with different names if you prefer) in the config file.  This is
> > basically what I did in the patch, now altered to apply to is_text
> > instead of prefer_markup.
> >
> > # List of mime types for text files, specified using UNIX shell
> wildcards.
> > # These files will have is_text set.
> > # If not set, all mime types will have is_text set.  You can then exclude
> > # specific types by listing them in binary_mime_types.
> > text_mime_types = text/*
> >
> > # List of mime types for binary files, specified using UNIX shell
> wildcards.
> > # These files will not have is_text set.
> > # These values will override those in text_mime_types.
> > #binary_mime_types =
>
> Why?  Why do you need both of these?  The world can be cleanly split into
> those files which are human-readable, and those which aren't.  Period.  The
> very presence of a configuration option that allows folks to define the
> members of one of those sets implies that members *not* in that set are in
> the other one.  If it ain't text, it's binary.  Why force folks to spell
> out
> both cases?
>


The idea isn't that they have to specify both.  The idea is that some
companies / projects will want to treat the majority of files as text, while
explicitly mentioning a few binary mime types.  Others will want to treat
the majority of files as binary, while explicitly mentioning a few text mime
types.  Only one or the other would have to be specified.  It's a
convenience, not a burden.



>
> > # If a file has no mime type, should we set is_text?
> > no_mime_type_is_text = 0
> >
> > Sure, they could modify the mime types file, but for some users it may
> > make more sense to only list binary files instead of text files.  In
> > addition some people might be dealing with numerous files that have no
> > extension at all.  Some will want those files treated as text and others
> > will want them treated as binary.
>
> And some will want some of them treated and binary and others as text.  You
> can't please everyone.  Fortunately, folks using Subversion can set real
> svn:mime-types properties on their files and not have to suffer ambiguity.


Setting an option in a config file is *much* easier than requiring that
every extensionless file have svn:mime-type set.  Some teams will want
extensionless files treated as text, and others will want them treated as
binary.  An intelligent default value and clear comments should avoid
confusion for users who don't care.  True, this option won't cover the case
where they want some treated as text and some as binary.  I still think it
is a reasonable thing to allow them to configure.

If you relied on mime types instead for extensionless files, does that mean
the svn_ignore_mimetype variable would have to be set to 0?  If so, I'd
still have to deal with images being garbled due to messed up mime types
(the default mime type Subversion gives images).


>
>
> > What do you think?
>
> I've been on the ViewVC mailing lists for years now, so I think I have a
> pretty good idea what folks do and don't like about the tool.  The average
> user doesn't care that ViewVC shows links to diffs and annotations of
> binary
> files (or they don't care enough to complain on these lists about it,
> anyway).  They simply don't take those links because they know what they'll
> find.  And in the future, they might not find errors -- some folks have
> already expressed an interest in allowing diff plugins that could generate
> deltas of binary file formats that support them (such as Microsoft Word).
>

Regardless of whether or not users put up with it, it does not make sense to
display links to functionality that doesn't work.  ViewVC should do the
right thing and prevent users from doing  something that doesn't make sense,
when possible.


>
> The average administrator is not going to want to try to figure out if
> extension-less files are binary or textual in nature as a rule, and what
> that all means.  I certainly don't want to think about that stuff every
> time
> I setup a ViewVC instance, and as I mentioned, Subversion already provides
> the mechanism for eradicating that ambiguity.
>
> Few folks bother to change the templates to make use of the prefer_markup
> bit at all.  Why?  Because in the absence of perfect algorithms, folks want
> the power to tell the tool what they want it to do even if it thinks that's
> not what they want.
>
> I'm sorry that this conversation has dragged on so far, and I appreciate
> your patience, but I think I'm convinced that goal #2 is a non-goal.  +1 on
> text_mime_types, but nothing else is really impressing me.
>

No problem.  I'm still in favor of the changes though.  :-)

I'm totally open to other ideas, but am not satisfied with ViewVC displaying
binary garbled characters.  I haven't seen this problem with tools like
FishEye for example, though they maintain a database after scanning the
repository.  Does ViewVC have this problem when using a database backend?

Thanks,
JJ