[viewvc-dev] Re: [viewvc-users] Don't display binary files
JJ <[email protected]> Thu, 6 Nov 2008 11:59:19 -0600
| Newsgroups | gmane.comp.version-control.cvs.viewcvs.devel |
|---|---|
| Message-ID | <eed30ed90811060959u511da685j2e234335c5277885__30533.2448719584$1225994456$gmane$org@mail.gmail.com> |
Per the thread below, I have some local changes working that add the following variables to revision.ezt. changes.view_href changes.log_href changes.download_href changes.download_text_href changes.prefer_markup changes.annotate_href As discussed below, I did this because I need to check if a particular change prefers to be marked up to determine if they should get the markup view or the checkout view. This is to avoid binary files being displayed with garbled characters in the markup view. prefer_markup is set (in my code and in the existing code) as follows. prefer_markup = default_view(mime_type, request.cfg) == view_markup mime_type is set as follows. mime_type = mime_type or guess_mime(where) This is fine, but this guessed mime type is later redefined based off the value of svn:mime-type for the file. So prefer_markup may be set to true based off the guess (e.g. for a .jpg file) but then if that file has a mime type such as application/octet-stream, the image is once again displayed as garbled characters. It seems like we either need to stop guessing the mime type and always check the svn:mime-type property, or always guess and ignore the svn:mime-type property when displaying the file in the markup view. What do you think? Any other ideas for how to solve this? Thanks, JJ On Tue, Nov 4, 2008 at 9:35 AM, C. Michael Pilato <[email protected]>wrote: > Well-written patches are always welcome. I suspect that the patch needed > here is likely to make use of get_file_view_info(), if that gives you a leg > up on it. Sadly, the revision view was added (by me, I admit) without a > great deal of fore-thought. Hopefully that fact doesn't work too hard > against the development of a solution here. > > (As an aside, we should probably move this conversation to dev@ if we > continue along this line of discussion.) > > JJ wrote: > > Let me know if there is anything I can do to assist. I'm not terribly > > familiar with the code, but I know Python and Subversion and am quite > > interested in getting these variables added and having an official > > release before I move ViewVC into production where I work. > > > > If you want me to make the variables below (and any others you can think > > of) available in every template and you point me in the general > > direction in the code, I can try to produce a patch. > > > > JJ > > > > On Tue, Nov 4, 2008 at 9:21 AM, C. Michael Pilato <[email protected] > > <mailto:[email protected]>> wrote: > > > > I'm basically finished with the stuff I'd planned to accomplish for > > 1.1. I > > branched the source tree for 1.1 stabilization last week (I think it > > was). > > I'd like to do some sanity testing and release a beta tarball this > > week. My > > ultimate goal is to have 1.1 released by the end of this calendar > > year, but > > time is flying so we'll see how that goes. > > > > JJ wrote: > > > Great! Sorry to bother you again, but would mind answering my > > question > > > about release timing, if you have any idea when it will be? :-) > > > > > >> Also, do you have any idea when the 1.1 release will be? Once I > get > > >> these changes in place I'm going to do some performance testing on > > >> ViewVC and then move this to production. > > > > > > On Tue, Nov 4, 2008 at 7:22 AM, C. Michael Pilato > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Yes. There's a handful of data that I'd intended to be > available > > > everywhere: > > > > > > view_href > > > log_href > > > download_href > > > download_text_href > > > prefer_markup > > > annotate_href > > > > > > and maybe some others. This is the set I'll be trying to > > introduce > > > into the > > > revision view. > > > > > > JJ wrote: > > > > Another thing that would be great is if the download_href > > could be > > > > accessible from revisions.ezt. My hope is to have the links > to > > > > individual files take me to file.ezt if prefer_markup is > > true, and if > > > > not link to the download_url. > > > > > > > > Would that be possible? > > > > > > > > Also, do you have any idea when the 1.1 release will be? > > Once I get > > > > these changes in place I'm going to do some performance > > testing on > > > > ViewVC and then move this to production. > > > > > > > > Thanks again. > > > > JJ > > > > > > > > On Mon, Nov 3, 2008 at 6:59 PM, C. Michael Pilato > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > > > Hrm. I had intended for the log, directory, markup, > > annotate, and > > > > revision > > > > views to all carry this type of information uniformly. > If I > > > missed the > > > > revision view on this, that's unintended. I'll try to > > fix this > > > > before 1.1 > > > > is released. > > > > > > > > > > > > JJ wrote: > > > > > I mean "I also need to check prefer markup", not > "change > > > > prefer_markup". > > > > > > > > > > On Mon, Nov 3, 2008 at 3:40 PM, JJ > > > <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto: > [email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>>> wrote: > > > > > > > > > > Sorry for the delay in replying. > > > > > > > > > > It looks like that approach will work, except that > I > > > also need to > > > > > change prefer_markup from revision.ezt, but that > > is not an > > > > available > > > > > variable there. Do you know of another option, or > > will this > > > > require > > > > > a code change to ViewVC? > > > > > > > > > > Thanks, > > > > > JJ > > > > > > > > > > > > > > > On Mon, Oct 13, 2008 at 9:48 AM, C. Michael Pilato > > > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> wrote: > > > > > > > > > > JJ wrote: > > > > > > > > > > Thanks for the reply. > > > > > > > > > > I have a couple questions. > > > > > > > > > > 1) I'm experimenting with file.ezt, > > having it check > > > > > mime_type before deciding if the file > > should be > > > displayed. > > > > > Is there a pattern match option in ezt? > > I can do > > > > something > > > > > like... > > > > > > > > > > > > > > > Why are you playing with file.ezt at all? If > > a user > > > requests > > > > > the markup or annotate view of a file, ViewVC > > should > > > try to > > > > > display such. I think what you want instead > > to do is to > > > > change > > > > > things like directory.ezt and log.ezt to not > > link to the > > > > > markup/annotate view for files for which > > > prefer_markup is "0". > > > > > > > > > > -- > > > > > C. Michael Pilato <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>>> > > > > > CollabNet <> www.collab.net > > <http://www.collab.net> > > > <http://www.collab.net> <http://www.collab.net> > > > > <http://www.collab.net> <> > > > > > Distributed Development On Demand > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > C. Michael Pilato <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>>> > > > > CollabNet <> www.collab.net <http://www.collab.net> > > <http://www.collab.net> > > > <http://www.collab.net> <> > > > > Distributed Development On Demand > > > > > > > > > > > > > > > > > -- > > > C. Michael Pilato <[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > CollabNet <> www.collab.net <http://www.collab.net> > > <http://www.collab.net> <> > > > Distributed Development On Demand > > > > > > > > > > > > -- > > C. Michael Pilato <[email protected] <mailto:[email protected]>> > > CollabNet <> www.collab.net <http://www.collab.net> <> > > Distributed Development On Demand > > > > > > > -- > C. Michael Pilato <[email protected]> > CollabNet <> www.collab.net <> Distributed Development On Demand > >