Bug#382995: ITP: nekohtml -- HTML parser for Java

[Marcus Better]

Stefan Gybas wrote:
> I've added you to the project. Welcome and have fun! :-)

Thanks! I have a few questions about the SVN policies. Why am I not allowed
to check in the whole upstream source tree? Are we concerned about disk
space?

I need to repack the upstream sources to remove jar files etc, and it would
be much easier to commit the modified upstream source tree to SVN and work
from that, instead of keeping a local tree.

Also, I really dislike using dpatch/quilt in conjunction with SVN since it
defeats the purpose of having version control (which is to track changes).
Instead one can use branches for debian-specific changes. My preferred SVN
layout would be something like:

  branches/nekohtml/upstream/0.9.5    (modified upstream source goes here)
  branches/nekohtml/feature/debian   
       (copy of upstream with debian/ dir added)
  branches/nekohtml/feature/fix-compile-warnings
       (another copy of upstream with some build fixes)
  branches/nekohtml/feature/broken-links-in-docs
       (another branch for doc-related bugfixes)
  trunk/nekohtml:
     this is the "integration branch" where all feature branches are merged
to produce a release.

All the Debian-specific work happens on one of the feature branches (which
would correspond to individual dpatches or sets of patches). Then these are
merged onto trunk. The result is released and tagged as usual.

Moreover I find it convenient to store the repacked orig tarballs in SVN.
This enables everybody to build the package with a simple svn-buildpackage
command. Otherwise there would be no official source for the tarballs,
which would complicate cooperative maintenance.

Regards,

Marcus