Before, the right-hand side of a .hgsub entry was used, as is, to
match the left-hand side of a subpaths entry. This turned out to be
less useful than expected since a .hgsub file with
src/foo = src/foo
has little context to do remapping on. The new idea is therefore to
prefix the parent repo path *before* the remapping takes place.
If the parent repository path (as defined by _abssource) is
http://example.net/parent
then the remapping for the above .hgsub entry will be done on the
expanded path:
http://example.net/parent/src/foo
If this expanded path is not changed by the remapping, then we remap
src/foo
alone. This is the old behavior where the right-hand side is remapped
without context.
Some of these instances could be rewritten as clever getattr(x, y,
default) ladders, but that felt like it impeded readability too much
to be worth the modest efficiency gain.
As with push, the optional destination path is ignored for the
subrepositories, i.e., they are always compared with their default
push path. Fixing this is Issue1852.
The \d was used in a normal (not raw) string and was only passed
through to re.search because Python does not define that escape
character itself. Using 0-9 makes it clearer what is happening.
Given a .hgsub file containing
lib/libfoo = http://server/libfoo
the 'lib/libfoo' subrepo will be cloned from 'http://server/libfoo'.
This changeset introduces a remapping mechanism whereby the source
paths (the right-hand sides) in the .hgsub file can be remapped. This
subpaths section
[subpaths]
http://server = /local
will result in the 'lib/libfoo' subrepo being cloned from
'/local/libfoo' instead of from 'http://server/libfoo'.
The patterns (left-hand sides) are really regular expressions and the
replacement strings (right-hand sides) can refer to matched groups
using normal backreferences. This can be used for more complicated
replacements such as
[subpaths]
http://server/(.*)-hg/ = http://hg.server/\1/
which replaces 'http://server/foo-hg/' with 'http://hg.server/foo/'.
All patterns are applied in the order by which they are listed in the
config files.
Subrepositories used to be created empty and then filled with data
using pull. This is wasteful when you do a clone from a local source
since it means that no hardlinks are created for the subrepos.
This patch make the hgsubrepo._get method check for an empty subrepo
and in that case do a clone instead of a pull. This brings in the same
data as before, but creates hardlinks when possible.
The Mercurial 1.9 release is moving a lot of stuff around anyway and we are
already moving path_auditor from util.py to scmutil.py for that release.
So this seems like a good opportunity to do such a rename. It also strengthens
the current project policy to avoid underbars in names.
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
It should be possible to do better than this with 'svn switch', but
the logic required woud be significantly more complex. Until someone
needs the performance improvements of using switch, we'll just use the
same strategy for everything.
This ensures that subrepositories are pulled in a well defined
order when cloning the parent repository.
BEFORE:
$ hg clone http://hg.gerg.ca/allextensions
destination directory: allextensions
requesting all changes
adding changesets
adding manifests
adding file changes
added 10 changesets with 20 changes to 6 files
updating to branch default
pulling subrepo caseguard from http://bitbucket.org/alexandru/caseguard
real URL is https://bitbucket.org/alexandru/caseguard
requesting all changes
adding changesets
adding manifests
adding file changes
added 81 changesets with 100 changes to 13 files
pulling subrepo hg-prompt from http://bitbucket.org/sjl/hg-prompt
real URL is https://bitbucket.org/sjl/hg-prompt
requesting all changes
adding changesets
adding manifests
adding file changes
added 114 changesets with 176 changes to 35 files
pulling subrepo hgpaste from http://bitbucket.org/birkenfeld/hgpaste
real URL is https://bitbucket.org/birkenfeld/hgpaste
requesting all changes
adding changesets
adding manifests
adding file changes
added 18 changesets with 18 changes to 2 files
...
AFTER:
$ hg clone http://hg.gerg.ca/allextensions
destination directory: allextensions
requesting all changes
adding changesets
adding manifests
adding file changes
added 10 changesets with 20 changes to 6 files
updating to branch default
pulling subrepo Artemis from http://hg.mrzv.org/Artemis
requesting all changes
adding changesets
adding manifests
adding file changes
added 55 changesets with 108 changes to 47 files
...
This works around an issue in older versions of Python that would
strip double slashes from SSH URLs when using urlunparse() on a parsed
URL.
Related issues:
- issue1755: WinXP: cmd line hg 1.3 clone of subrepo fails, due to %5C
'\'? (originally fixed by f7e3eaf7ec0b).
We explicitly want to update bookmarks from a remote. This will avoid
duplicate calls to listkeys if we clone (which calls pull) and keep
bookmark related code together.
This makes more sense when using multiple levels of
nesting.
This happens to help a lot in a case where 3 projects
of mine all use the same makefile helper project as a
sub. A fourth project use these first three projects
and current output made it very hard to figure
which makefile helper was committed. it looked more
like the project was committed/pushed/pulled three times
in a row than dealing on three different repos.
For a "all projects at root" repo layout eg:
/main
/sub
Where subrepos are used such that a clone of main has this layout:
./main/
./main/.hgsub
./main/sub/
And the .hgsub content is:
sub = ../sub
This allows a pull from a hgweb where main and sub are exposed
at the root (or same directory level)
The current code doesn't normalize the path component of a pull
url. this results in trying to pull from
http://server.com/hg/main/../sub
Current hgweb implementation doesn't reduce the path component
so this results in a 404 error though everything is setup logically.
This patch adresses this 404 error on the puller side
normalizing the URLs used for pulling sub repos. For this
example, the URL would be reduced to http://server.com/hg/sub
Fix + test
There are two bugs in current subrepo ctor:
- hgrc paths were using parent repo (ctx._repo) instead of self._repo
- it was joined with local extract path, not its source repo path
Fixed both bugs using _abssource on self once it is fully initialized.
It gets the job done perfectly for pull and push urls.
Previous behavior was to put in the cloned subrepos the path found in the original main repo.
However it isn't valid for relative path and it seems more logical to reference instead the subrepos
working copy path of the original main repo.
That's especially true with status flags: there are different fields and values
for regular changes, meta changes, externals changes and externals meta
changes.
My reasons to do 877151efa5f3 were wrong. We want to have non-localized svn
output while preserving current locale for input arguments and svn internals.
This is achieved by setting LC_MESSAGE=C.
This fixes a bug seen when merging a main repo which contains a subrepo when
both repos have been merged before. Each repo (main and sub) has two
branches, both of which have been merged before.
In a subrepo, if the revision to merge to is an ancestor of the current rev,
then the merge should be a noop.
Test provided by Steve Losh.
this way, extensions' reposetup will be called, which allows for git
subrepos to be handled by hg-git (and I believe the same goes for
svn and hgsubversion)
Parser only knows about en_US output. Forcing the encoding to UTF-8 might not
be the best thing to do since the caller may receive some of the subversion
output, but at least it should prevent conversion errors from svn client.
