When the contents of .hgsubstate are stale (either because they've
manually been tweaked or partial updates have confused it), we get
confused about whether it actually needs committing.
So instead, we actively consult the parent's substate and compare it
the actual current state when deciding whether it needs committing.
Side effect: lots of "committing subrepo" messages that didn't
correspond with real commits disappear.
This change is fairly invasive for a fairly obscure condition, so it's
kept on the default branch.
I modified check-code.py "$?" detection because I thought my use was legit, we
cannot test exit status of pipelines commands except for the last one without
this. So it now tolerates "[$?" which is unlikely to be added by mistake.
Tested on:
- OSX + svn 1.7.1
- Linux + svn 1.6.12
- old-style patterns without ^ were getting improperly anchored
- finditer was matching against beginning of line poorly
- \s was matching newlines
- [^x] was matching newlines
so we:
- remove earlier hacks for multiline matching
- fix unified test anchoring by adding .*
- replace \s with [ \t]
- replace [^x] with [^\nx]
- force all matches into multiline mode so ^ anchors work
This uncovers a number of test issues that are then repaired.
This changeset flips the default value of ui.commitsubrepos setting
from True to False and adds a --subrepos flag to commit.
The commit, status, and diff commands behave like this with regard to
recusion and the ui.commitsubrepos setting:
| recurses | recurses
| by default | with --subrepos
--------+---------------+----------------
commit: | commitsubrepo | True
status: | False | True
diff: | False | True
By changing the default from True to False, the table becomes
consistent in the two columns:
* without --subrepos on the command line, commit will abort if a
subrepo is dirty and status/diff wont show changes inside subrepos.
* with --subrepos, all three commands will recurse.
A --subrepos flag on the command line overrides the config settin.g
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.
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.
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.
This adds a " (glob)" marker that works like a simpler version of
(re): "*" is converted to ".*", and "?" is converted to ".".
Both special characters can be escaped using "\", and the backslash
itself can be escaped as well.
Other glob-style syntax, like "**", "[chars]", or "[!chars]", isn't
supported.
Consider this test:
$ hg glog --template '{rev}:{node|short} "{desc}"\n'
@ 2:20c4f79fd7ac "3"
|
| o 1:38f24201dcab "2"
|/
o 0:2a18120dc1c9 "1"
Because each line beginning with "|" can be compiled as a regular
expression (equivalent to ".*|"), they will match any output.
Similarly:
$ echo foo
The blank output line can be compiled as a regular expression and will
also match any output.
With this patch, none of the above output lines will be matched as
regular expressions. A line must end in " (re)" in order to be matched
as one.
Lines are still matched literally first, so the following will pass:
$ echo 'foo (re)'
foo (re)
