Re: [viewvc-dev] Various patches for ViewVC

Виталий Филиппов wrote:
>>> 2) Configurable charset support in annotate, diff, markup views, cvsdb
>>> and logs
>> Configurable how?  And is this source encoding specification with forced
>> conversion to UTF-8 for output?
> 
> via viewvc.conf
> [options]
> encodings = utf-8:koi8-r:iso-8859-1
> ...it's a simple and stupid method :)
> it just tries to decode string from all these encodings sequentially.
> I wondered using enca (pyenca), but thought it would be too complex.

Decoding to ... Unicode?

>>> 9) Use of python libmagic bindings for determining file content-type
>> Concerned about performance here, but interested in your approach.
> 
> I did not perform any measures, but on a "production" instance of ViewVC
> there wasn't any heavy performance degradation with libmagic...

Don't you have to read a block of file data to feed to libmagic?  Do you do
this for every directory listing and other codepath that wants to populate
the "mimetype" entry property?

>>> 10) MIME type checking (configurable regexp) in markup/annotate (for not
>>> annotating binary files as text ones)
>> We had a recent lengthy conversation on-list here about MIME types and
>> binary files and such ... I'm a little leery of adding more complexity in
>> this area, but again, it's easier to evaluate an approach than to speak  
>> in generalities.
> 
> Anyway, displaying annotations for binary files isn't good :)

Agreed.  That's why CVS and Subversion both have mechanisms for marking a
file as "binary" (-kb for CVS, and not-text-y MIME types for Subversion).

>>> 11) Shell scripts for ViewVC deployment on a Linux (tested on Debian)
>>> version control server
>> What's this?  /etc/init.d stuff for standalone.py or somesuch?
> 
> No, it installs ViewVC as an Apache2 virtual host, also it installs
> dependency packages, calls make-database to create database for ViewVC,
> rebuilds commit database for CVS and SVN repositories (only local), and
> installs commit hooks for them. Also it could install "asynchronous"
> hooks, in this case the hook writes the repository name (and revision in
> case of SVN) into a file, and then the script called from cron reads this
> file and updates the DB... Also I doubt this feature needs to be in the
> trunk, I think it's kind of special one...

Yeah, that's a bit "out there".  Cool stuff, but maybe something you could
post to a public blog (and point folks there via this mailing list).

> Also there are some new features since the initial letter:
> - CVSnt ACL authorizer (I've already posted it to the bug found on your tracker)

I saw this!  Very cool stuff.  I wish I had a CVSnt setup so I could test
it.  (Anyone listening -- care to give it a go?)

> - 'grp' authorizer which permits using different authorizers for
> different repositories (I think this feature is very important, though I
> don't know whether the "super-authorizer" is a good way doing this)

The right approach for this is per-root configuration, which sorta kinda
works today already but isn't the most admin-friendly thing in the world.

> - Repository type selection in query form (CVS/SVN/All) without the need for selecting individual repositories
> - Patches from query results

Nice.

---

I know it's a pain to keep these changes separable, but if you look at the
history of mega-patches provided to this project in the past, you'll see
they have a pretty low chance of getting much attention.  It's just poor
open source interaction policy, add causing the cost of code review to
exceed the pain threshold of the potential reviewers.  If you want to see
your changes reviewed and accepted, please submit them as individual issues
in the tracker (either DEFECT or ENHANCEMENT, with the "patch" keyword).

This is not an attempt to make your life harder.  And it doesn't reflect any
disinterest on my part.  It's just a reality that if I can't review the code
in a sane amount of time, I'll never find the time to integrate it.  The
other benefit (to me ... to you ... to ViewVC's users) of getting your
patches reviewed is that if they prove to be generally useful and
well-considered, we can start taking me out of the picture as a bottleneck
and just grant you commit access!  :-)

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=2330761

To unsubscribe from this discussion, e-mail: [[email protected]].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoUDmkACgkQokEGqRcG/W4VaACfYB+TjbyVq6v9ncuM8McBnvWG
GjYAnjcUH9iI2UDlcCaPq3BEMVqPLqJw
=D9Zj
-----END PGP SIGNATURE-----