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.
