> Thank you, but I'm afraid I don't have the time to maintain my own fork
> of ViewCVS.
> In my opinion:
> * Debian's ViewCVS package should be hijacked, or the maintainer
> should get more serious about dealing with the problems his
> packaging of a CVS snapshot causes;
> * A new upload should be made to unstable, adding an epoch and
> reverting to the last version sanctioned by the upstream
> developers; this way we won't release a snapshot in sarge
> * A viewcvs(-snapshot?) package can be maintained in Debian
> experimental if anyone has the patience to deal with it
> * The package's debconfage needs to be fixed or removed:
> 1) removed, if ViewCVS has a directory browser that can choose
> between repositories (i.e., if ViewCVS can look at
> /var/lib/cvs and/or /var/lib/svn when they don't directly
> ccontain repos, the debconfage can be nuked entirely)
> 2) fixed; scan /var/lib/{cvs,svn} at configuration time and
> use the first repository found as the default_root by
> default (letting the user change it if we're in an
> interactive frontend, of course)
> * The viewcvs CGI script needs to run with its umask set to 0002
> so it doesn't fuck up Subversion repositories. I've attached
> a patch for this.
Sorry, I'm currently working on new viewcvs package.
But I'm waiting for subversion_0.27-0.1 package for i386 to build and
test.
Thanks.
--
Takuo KITAME.
