NOTE: THIS PAGE IS STILL A DRAFT AND NEEDS DISCUSSION.
Rationale: This page and the pages linked from here document best practices for using version control systems in the Java packaging team. It should make it easy to maintain a huge number of packages in an efficient way. But this is not a strict law. You MAY use your own rules if you document them in a central place: README.source. The words MAY, SHOULD, MUST, and others are used as in RFC 2119.
The Java packaging team uses either subversion or git as a version control system (VCS) on Alioth. All team maintained packages SHOULD use one of those VCS. Packages that do not follow this rule MUST explain their VCS or state the fact of a missing VCS in README.source. Failing to document such deviations in README.source might lead to a bug report with severity serious. All packages MUST use appropriate Vcs-* headers in debian/control. Those headers SHOULD point to the VCS address that allows anonymous access (svn: or git: instead of svn+ssh: or git+ssh:).
You MAY freely choose between subversion or git if you are starting a new package. Pick the VCS that you are more familiar with.
You MAY move an existing package from subversion to git if there is a good reason. Maybe all active maintainers agreed on moving to git. Maybe upstream uses git and you want to merge and cherry-pick from the upstream repository. You SHOULD leave a file README in the subversion repository that mentions the new VCS address. NOTE: WE NEED SOME EXPLANATION / TOOLS FOR THE TRANSITION.
You SHOULD NOT move package from git to subversion because we would certainly lose the history.
Please read Java/JavaSvn for subversion guidelines and Java/JavaGit for git guidelines. You SHOULD follow those guidelines. You MUST document any differences of your packaging workflow in README.source. Failing to document them in README.source might lead to a bug report with severity serious. NOTE: BOTH PAGES ARE CURRENTLY INCOMPLETE.