Consider a bookmark B that exists both locally and remotely. If B is updated
remotely, and then a pull is performed where the pull set contains the new
location of B, the bookmark is updated locally. However, if remote B is
updated in the middle of a pull to a location not in the pull set, the
bookmark won't be updated locally at all.
To fix this, list bookmarks before pulling in changesets, not after. This
still leaves a race open if B gets moved in between listing bookmarks and
pulling in changesets, but the race window is much smaller. Fixing the race
properly would require a bundle format upgrade.
test-hook.t's output changes because we no longer do two listkeys calls during
pull, just one.
test-pull-http.t's output changes because we now search for bookmarks before
searching for changes.
Publishing server may contains draft changeset when they are created locally. As
publishing is the default, it is actually fairly common. Because of this
"inconsistency" phases synchronization may be done even to publishing server.
This may cause severe issues for subrepo. It is possible to reference read-only
repository as subrepo. Push in a super repo recursively push subrepo. Those
pushes to potential read only repo are not optional, they are "suffered" not
"choosed". This does not break because as the repo is untouched the push is
supposed to be empty. If the reference repo locally contains draft changesets, a
courtesy push is triggered to turn them public. As the repo is read only, the
push fails (after possible prompt asking for credential). Failure of the
sub-push aborts the whole subrepo push. This force the user to define a custom
default-push for such subrepo.
This changeset introduce a prevention of this error client side by skipping the
courtesy phase synchronisation in problematic situation. The phases
synchronisation is skipped when four conditions are gathered:
- this is a subrepo push, (normal push to read-only repo)
- and remote support phase
- and remote is publishing
- and no changesets was pushed (if we pushed changesets, repo is not read only)
The internal config option used in this version is not definitive. It is here to
demonstrate a working fix to the issue.
In the future we probably wants to track subrepo changes and avoid pushing to
untouched one. That will prevent any attempt to push to read-only or unreachable
subrepo.
Another fix to prevent courtesy push from older clients to push to newer server
is also still needed.
This is an alternative fix for issue3518, enabling sharing of repositories with
subrepos, without unconditionally setting the default path in the resulting
repo's hgrc file. Better test coverage is added here, but won't prove this code
is working until f48752441ca0 is backed out.
The problem with the original fix is, if a default path is not available to be
copied over from the share source, the default path on the resulting repo is set
to the source location. Since that's where the actual repository is stored, the
path is essentially self-referential, so push, pull, incoming and outgoing
effectively operate on itself. While incoming and outgoing make it look like
nothing was changed, push currently hangs (see issue3657). In this case where
there is not a real default path, these operations should abort with
"default(-push) not found", like the source repo would. Note this problem with
the original fix affected repos without subrepos too.
Add sorted() in places found by testing with PYTHONHASHSEED=random and code
inspection.
An alternative to sprinkling sorted() all over would be to change substate to a
custom dict with sorted iterators...
This patch is meant to make it easier for tools that wrap the mercurial
output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that
(since 6c419dfc848c) is appended after subrepo error messages, particularly when
the mercurial output is translated to a non-English language.
The message remains the same but the '%s' that was used to prepend the original
error message in front of the 'in subrepo' string has been moved out of the
translatable string.
As an example of the usefulness of making it easy to look for "in subrepo
MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in
order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the
corresponding subrepo).
The original string made it hard for a tool such as TortoiseHg to look for the
translated string on mercurial's output because the translated string contained
the error message itself. This meant that a regular expression was required to
ignore the error message part. With this change TortoiseHg can just get the
translated "(in subrepo %s)" string, substitute %s for the subrepo path (which
it gets from the subrepo exception) and simply search for the resulting string
(no regular expression needed, or at least a much simpler regular expression
could be used).
Additionaly, the existing string could lead a translator mistakenly assume that
it was possible invert the order of the %s (error and subrepo path) fields,
which would not work because the string interpolation was position based.
This change appends the subrepo path to subrepo errors. That is, when there
is an error performing an operation a subrepo, rather than displaying a message
such as:
pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH!
hint: did you forget to merge? use push -f to force
mercurial will show:
pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO)
hint: did you forget to merge? use push -f to force
The rationale for this change is that the current error messages make it hard
for TortoiseHg (and similar tools) to tell the user which subrepo caused the
push failure.
The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods
were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)"
multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception
after the extra message is appended. The decorator will then "ignore" (i.e. just
re-raise) the exception and never add the message again.
A small drawback of this method is that part of the exception trace is lost when
the exception is catched and re-raised by the annotatesubrepoerror decorator.
Also, because the state() function already printed the subrepo path when it
threw an error, that error has been changed to avoid duplicating the subrepo
path in the error message.
Note that I have also updated several subrepo related tests to reflect these
changes.
Color extension achieves colorization by overriding the class of
"ui" object just before command execution.
Before this patch, "diff()" of abstractsubrepo and classes
derived from it has no "ui" argument, so "diff()" of hgsubrepo
uses "self._repo.ui" to invoke "cmdutil.diffordiffstat()".
For separation of configuration between repositories, revision
1498948ee815 changed the initialization source of "self._repo.ui"
from "ui"(overridden) to "baseui"(plain) of parent repository.
And this caused break of colorization.
This patch adds "ui" argument to "diff()" of abstractsubrepo and
classes derived from it to pass "ui" object of caller side.
Files in a subrepo were overwritten on update. But this should only happen on a
clean update (example: -C is specified).
Use the overwrite parameter introduced for svn subrepos in e3640daa4703 to
decide whether to merge changes (as update) or remove them (as clean).
The new function hg.updaterepo is intruduced to keep all update calls in hg.
test-subrepo.t is extended to test if an untracked file is overwritten
(issue3276). (Update -C is already tested in many places.)
The first two chunks are debugging output which has changed. (Because overwrite
is not always true anymore for subrepos)
All other tests still pass without any change.
Do not pass ui because it contains the configuration of the repo. It is the
same object as repo.ui.
When a repo is passed to hg.peer, the global configuration is read from
repo.baseui.
Before this patch, repository local configurations are not isolated
between repositories in subrepo tree, because "localrepository"
objects for each subrepositories are created with "ui" instance of the
parent of each ones.
So, local configuration of the parent or higher repositories are
visible also in children or lower ones.
This patch uses "baseui" instead of "ui" to create repository object:
the former contains only global configuration.
This patch also copies 'ui.commitsubrepos' configuration to commit
recursively in subrepo tree, because it may be set in not
"repo.baseui" but "repo.ui".
svn --version --quiet is implemented since svn 0.14.1 (August 2002)
and prints just the version number, not the long output (21 lines)
of "svn --version".
Additionally I expect this output format to be more stable, at least
it is not changed with different translations.
For example LC_ALL=de_DE.utf-8 would cause the version check to fail,
because "svn, Version 1.6.12 (r955767)" with a capital "V" will be printed.
Using "svn --version --quiet" would only print the version number, but then
matching other messages, e.g. "Committed revision" would fail.
Subversion 1.7 changes its XML output to include an explicit encoding tag:
<?xml version="1.0" encoding="UTF-8"?>
This triggers xml.dom.minidom to always return unicode strings, causing
other parts of the code to explode.
We unconditionally encode path names before handing them back, which
works with both str (actually a no-op) and unicode values.
This introduces a peer method into all repository classes, which currently
simply returns self. It also changes hg.repository so it now raises an
exception if the supplied paths does not resolve to a localrepo or descendant.
Finally, all call sites are changed to use the peer and local methods as
appropriate, where peer is used whenever the code is dealing with a remote
repository (even if it's on local disk).
Add a match object to subrepo.archive(). This will allow the -X and -I
options to be honored inside subrepos when archiving. They formerly
only affect the top level repo.
dbc9f6aea991 introduced "svn info TARGET@REV" to determine if a certain
path exists in the specified revision, but in svn 1.5 the error message
"Not a valid URL" yields exit code 0 so the error is not caught.
Use "svn list TARGET@REV" instead which works with svn 1.5 and is even
faster in some situations.
Popen does not consider "foo.cmd" equivalent to "foo" on Windows.
Unfortunately, the default MSYS Git installation installs only "git.cmd" into
the path by default. This patch probes for both possible names on Windows.
Until now, when calling subrepo.subrepo with a path at which there is no
subrepo, a "nullstate" tuple would be returned. However, this is not very
useful (the tuple can't really be used for creating a subrepo), so we'd just as
soon have the function just fail, and leave it up to the caller to decide what
to do.
The motivation for doing this now is to simplify the solution for (issue3056).
Note that aborting in subrepo.state() prevents "repairing" commands like revert
to be issued. The user will have to edit the .hgsubstate manually (but he
probably had already otherwise this would not be failing). The same behaviour
already happens with invalid .hgsub entries.
The initial version was to take the "Revision" field from svn info. It works
but produces false positive when parent paths are being moved or unrelated
changes are being committed, causing it to change while the svn checkout itself
remains the same. To avoid spurious commit, we took "Revision" and "Last
Changed Rev" for general comparison and kept the latter to answer "what is your
revision?" question. This is better but fails when the subrepo path exists at
"Revision" but not at "Last Changed Rev". This patch adds a check for this, and
returns "Revision" if the path does not exist. We try to avoid doing this as
much as possible at it implies an extra, *remote* call.
Previous code was printing a traceback because it expected some error output
from svn. But sometimes our definition of "changed" differs with the subversion
one. For instance, subversion ignores missing files when committing. And when
there are only missing files, svn commit will be a successful no-op with no
output. Still, we should stick to our definition including missing files in
changes as doing otherwise could cause surprising behaviour for the user.
The warning is similar to the warning that was shown before hgsubrepo revert
support was added, with the exception that now the subrepo type is shown.
For example, when trying to revert a git subrepo located in "include/mygitsub",
the warning message would be:
include/mygitsub: reverting git subrepos is unsupported
- _svncommand() in files() returns a tuple since 1ca3bbcf0c2a not a string.
- _svncommand() in filedata() returns a tuple not a string.
- "svn list" returns files but also directories.
- "svn list" is not recursive by default.
I have no idea what happens to svn:externals possibly embedded in the svn
subrepository.
When a subrepo is reverted but --no-backup is not set, call revert on the
subrepo that is being reverted prior to updating it to the revision specified
in the parent repo's .hgsubstate file.
The --all flag is passed down to the subrepo when it is being reverted. If the
--all flag is not set, all files that are modified on the subrepo will be
reverted.
Reverting a subrepo is done by updating it to the revision that is selected on
the parent repo .hgsubstate file.
* ISSUES/TODO:
- reverting added and removed subrepos is not supported yet.
- reverting subrepos is only supported if the --no-backup flag is used (this
limitation will be removed on another patch).
- The behavior of the --all flag has been changed. It now reverts subrepos as
well. Note that this may lead to data loss if the user has a dirty subrepo.
Merging ancestors with children is allowed if they are on different
named branches. This did not work for subrepo merges before. To fix
this inconsistency, the mergefunc() will now use the simple update
path only if both versions are on the same named branch. If not, they
get merged into a new changeset, just as if you did the merge from the
subrepo's root directly.
When support for handling explicit paths in subrepos was added to the forget
command (155b89136ae7), subrepo recursion wasn't taken into account. This
change fixes that by pulling the majority of the logic of commands.forget into
cmdutil.forget, which can then be called from both there and subrepo.forget.
When support for handling explicit paths in subrepos was added to the add
command (825c4cefde4b), subrepo recursion wasn't taken into account. This
change adds an explicitonly argument to cmdutil.add to allow controlling which
levels of recursion should include only explicit paths versus all matched
paths.
path to subrepo is used to identify or check location of subrepo.
it should be normalized (in "/" delimiter form), because it is also
used with narrowmatcher which uses only normalized path even on
Windows environment.
this patch applies "util.pconvert()" on path to subrepo (called
"subpath") to normalize it.
for this patch, referers of below were checked.
- subrepo.state()
- subrepo.itersubrepos()
- subrepo.subrepo()
- context.sub()
- context.substate()
typical usecase is:
for subpath in ctx.substate:
sub = ctx.sub(subpath)
... ctx.substate[subpath] ....
in this case, normalization has no side effect, because keys given
from substate are used as key itself.
other cases shown below also seem to require subpath to be normalized.
- path components are joined by "/", in "commands.forget()":
for subpath in ctx.substate:
subforget[subpath + '/' + fsub] = (fsub, sub)
- normalized "file" is used to check below condition, in
"commands.revert()", "localrepository.commit()", and
"localrepository._checknested()"
file in ctx.substate
- substate.keys() is passed to dirstate.walk()/status() which use
only normalized pathes
Before, we deleted foo when we determined that there were zero
changesets in the foo subrepo. Any files in foo was deleted too. We
now delete foo/.hg instead, and the normal checks in hg.clone will
then abort if there are untracked files in foo.
Before, running 'hg archive -S' could result in
abort: unknown revision '65903cebad86f1a84bd4f1134f62fa7dcb7a1c98'!
if a subrepo was missing completely or had missing changesets. Now,
the missing changesets will be pulled or cloned as appropriate.
This make Mercurial subrepos match Git subrepos which already took
care to fetch any missing commits before starting the archive.
Up until now the all the push command options were ignored when pushing
subrepos. In particular, the fact that the --new-branch command was not passed
down to subrepos made it not possible to push a repo when any of its
subrepos had a new branch, even if you used the --new-branch option of the push
command.
In addition the error message was confusing since it showed the following hint:
"--new-branch hint: use 'hg push --new-branch' to create new remote branches".
However using the --new_branch flag did not fix the problem, as it was ignored
when pushing subrepos.
This patch passes the --new-branch and --ssh flags to every subrepo that is
pushed.
Issues/Limitations:
- All subrepo types get these flags, but only the mercurial subrepos use them.
- It is no longer possible to _not_ pass down these flags to subrepos when
pushing:
* An alternative would be to introduce a --subrepos flag that should be
used to pass down these flags to the subrepos.
* If we did this, it could make sense to make the --force flag respect this
new --subrepos flag as well for consistency's sake.
- Matt suggested that the ssh related flags could also be passed down to
subrepos during pull and clone. However it seems that it would be the "update"
command that would need to get those, since subrepos are only pulled on update.
In any case I'd prefer to leave that for a later patch.
Change the behavior of the forget command such that explicit paths in
subrepos are handled by forgetting the file in the subrepo. This eliminates the
previous behavior where if you called "hg forget" for an explicit path in a
subrepo, it would state that the file is already untracked.
Change the behavior of the add command such that explicit paths in
subrepos are always added. This eliminates the previous behavior
where if you called "hg add" for an explicit path in a subrepo
without specifying the -S option, it would be silently ignored.
If you specify patterns, or no arguments at all, the -S option
will still be needed to activate recursion into subrepos.
This fixes a regression introduced with the new url handling in 1.9.
This should perhaps be fixed in the url class instead, but that might be too
invasive for a stable bugfix.
A Subversion subrepo checkout uses a url and --revision which does not do the
correct thing when specifying a revision of a branch that has since been
deleted and recreated. The checkout needs to specify the revision as URL@REV
instead.
We do this by ensuring the working copy is clean and then blowing away
the working copy and replacing it with one from the desired path. We
could probably use 'svn switch' to do this more efficiently, but
there's some subtle logic required to get that right and this is
more likely to work reliably.
Currently, if there is a bare git subrepo, but it is at the "right"
revision, calling dirty() will error because diff-index does not work
on bare repos. This patch makes it so bare subrepos are always
considered dirty.
With Python >= 2.6 the original code already works correct, therefore the
fix for issue2556 on Python <= 2.5 broke relative subrepositories with
newer versions of Python.
This happens more often than expected. Say you have an svn subrepository with
python code. Python would have generated unknown .pyc files. Now, you rebase
this setup on a revision where a directory containing python code does not
exist. Subversion is first asked to remove this directory when updating, but
will not because it contains untracked items. Then it will have to bring back
the directory after the merge but will fail because it now collides with an
untracked directory.
Using --force is not very elegant and only works with svn >= 1.5 but the only
alternative I can think of is to write our own purge command for subversion.
This happens more often than expected. Say you have an svn subrepository with
python code. Python would have generated unknown .pyc files. Now, you rebase
this setup on a revision where a directory containing python code does not
exist. Subversion is first asked to remove this directory when updating, but
will not because it contains untracked items. Then it will have to bring back
the directory after the merge but will fail because it now collides with an
untracked directory.
Using --force is not very elegant but it is much simpler than rewriting our own
purge command for subversion.
This changes the prompts on git subrepos to show only the first seven
digits of git changeset IDs (as git's command line does):
$ hg update
subrepository sources for s differ (in checked out version)
use (l)ocal source (32a3438) or (r)emote source (da5f5b1)?
Consider a repository with a single subrepository. The changesets in
the main repository reference the subrepository changesets like this:
m0 -> s0
m1 -> s1
m2 -> s2
Starting from a state (m1, s0), doing 'hg update m2' in the main
repository will yield a conflict: the subrepo is at revision s0 but
the target revision says it should be at revision s2.
Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus
ignore the conflict between the working copy and the target revision.
With this change, the user is prompted to resolve the conflict by
choosing which revision he wants. This is consistent with 'hg merge',
which also prompts the user when it detects conflicts in the merged
.hgsubstate files.
The prompt looks like this:
$ hg update tip
subrepository sources for my-subrepo differ
use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
This makes 'hg update --clean' behave the same way for both kinds of
subrepositories. Before Subversion subrepos did not take the clean
parameter into account, but just updated to the given revision and
merged uncommitted changes into that.
A subversion project revisions are a subset of the repository revisions, you
can ask subversion to update a working directory from one revision to another
without changing anything. Unfortunately, Mercurial will think the
subrepository has changed and will commit it again. To avoid useless commits,
we compare the subrepository state to its actual "parent" revision. To ensure
ascending compatibility with existing subrepositories which might reference
fake revisions, we also keep comparing with the subrepo working directory
revision.
NOTE: not sure if this should go in stable or not.
Just a little change to bring the comments in the dirty() methods of the
various subrepo classes into a uniform structure. This clarifies the
meaning of the states checked.
This makes 'hg update --clean' behave the same way for all three kinds
of subrepositories [hg, svn, git]. Before git subrepos did not take
the clean parameter into account, but just updated to the given
revision and merged uncommitted changes into that.
This patch conforms gitsubrepo code to the variable naming scheme of the other
subrepo implementations. All user-facing path references should be relative
to the root repository.
This patch prevents MQ from creating an inconsistent subrepo state. If
the .hgsub file has been changed, and none of the subrepos have
uncommitted changes, creating or updating a patch (using qnew, qrefresh,
or qrecord) will update .hgsubstate accordingly.
If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord
will abort.
Thanks to pmezard for proposing this solution.
This patch avoids empty commit when .hgsubstate is dirty. Empty commit
was caused by .hgsubstate being updated back to the state of the
working copy parent when committing, if a user had changed it manually
and not made any changes in subrepositories.
The subrepository state from the working copies parent is compared
with the state calculated as a result of trying to commit the
subrepositories. If the two states are the same, then return None
otherwise the commit is just done.
The line: "committing subrepository x" will be written if there is
nothing committed, but .hgsubstate is dirty for x subrepository.
Despite its name, git-diff-index compares a revision to the files in the
working directory. This seems way less sketchy and more future proof than
parsing human-readable git-status.
Using svn subrepos on MacOSX with native python 2.6.1 results in a lot of
unexpected output caused by:
http://bugs.python.org/issue5099
subprocess.Popen.__del__ causes AttributeError (os module == None)
Avoiding dangling Popen instance solves the issue.
In many common cases where the subrepo is up to date with the remote repo,
hg push will only need to run one git-branch command to see that nothing
needs to be pushed.
As well as simplifying the code, this makes subprocess calls about 25% faster.
Tested on a couple linux boxes.
python -mtimeit -s'import subprocess' 'subprocess.Popen(
"git version", shell=True, stdout=subprocess.PIPE).wait()'
python -mtimeit -s'import subprocess' 'subprocess.Popen(
["git","version"], stdout=subprocess.PIPE).wait()'
This continues the strategy of separation between hg pull and hg update in
git subrepos by only dealing with git's branches on an update. This behavior
tries to cover the bare essentials of the semantics of git pull in the subrepo
when the parent repo does hg pull and hg update.
Avoids calls to git push when the revision is already known to be
in the remote repository. Now, when using a read-only git subrepo,
git will never need to talk to its upstream repository.
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)