SubversionRepo and SVNMeta are now hidden behind svnremoterepo and
svnlocalrepo. It unifies the way svn credentials are read from the command line
and configuration file, at the cost of import cycle between svnrepo and
wrappers. It is currently not a big deal thanks to demandimport.
It has 2 benefits:
- It generalizes the use of hgsubversion.username/password initiated in
push/pull.
- Command line options are no longer need to create SubversionRepo, so we can
move this out of command handling code.
Less obvious things:
- my reordering in the previous was incomplete
- _branch_for_path() was unused, so I removed it
- _svnpath() was removed in favor of identical _remotename()
- I've checked "no cover" bits manually
We can't rely on the most-recent change number matching our most-recent
change number because there can be changes in svn that produce no
corresponding hg changeset.
Use the presence of the UUID file for recognising a Subversion-enabled
repository locally, and the 'subversion' capability in for recognising
them wrappers.outgoing() remotely.0
The change only applies to the ambiguous URL schemes: file, http and
https. The others - svn+ssh and svn - behave the same as previously.
For http and https, the wrapping is implemented in 'svnrepo.py': Only
when the attempt to create a httprepo instance fails, will the URL
be considered for Subversion URL.
For file, the ambiguity is treated much like the Mercurial core
distinguishes bundle and directories. In this case, a directory that
looks like a Subversion repository will *not* be considered for a
Mercurial clone.
Tthe command lines are more similar to before this refactor. The only
option added to push & pull is --stupid; others are only added to
clone. Any of these options specified to clone will be added to the
generated '.hgrc'.
Also, the -r/--rev option now works for clone & push.
