Copy records were not taken in account when telling whether a file was changed
or not. Besides, the only place maybeedits were added was when recording
directory copies.
This means that users should no longer URI-encode their paths. This is
a change from the past, and may require some small changes to .hg/hgrc.
This fixes certain odd issues resulting from inconsistent handling
of URI-encoding throughout hgsubversion.
Telling svn from mercurial repository automatically is not always possible, or
at least not seamlessly. Let 'http://repo.com/svn' be an svn repository,
protected with basic authentication. Trying to clone it directly does something
like:
1- Open it like a mercurial repository:
* send between command, ask for credentials, fail
* fallback to static-http, ask for crendentials two times, fail
2- Open it like an svn repository
Mercurial [auth] facility is helpful here, but few people know about it, and it
may seem weird to store svn credentials in mercurial configuration. An svn-like
password manager would not help either because all connections attempts in [1]
fail and it's unlikely we would store credentials in this situation. Instead,
we can clone 'svn+http://repo.com/svn', which will skip step [1].
Since the ssh+svn URLs depend on supplied credentials, and because we want to
get the actual SVN URL without talking to the remote repository, we duplicate
the work done by SubversionRepo.
svn+ssh URLs are special because the authentication layer is not handled by
svn, so they must contain the username to be resolved seamlessly. Until now,
credentials supplied from the command line were ignored when rewriting those
URLs. Fix that.
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.
I have not included a test case because I can't iron out
the specifics of what causes this bug. This allows
jquery to finish cloning successfully. Further inspection
of the jquery history around 4400:4410 should allow
construction of a meaningful test case.
