Test Plan: Tests are made to pass in later commits.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6698523
Signature: 6698523:1515628418:39f509c8422cdc223f5e84ae18dfd7cfe9344b2e
Summary: Move's the extension code into hgext/
Test Plan: Tests are fixed in a later commit.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6698506
Signature: 6698506:1515628404:0006a07cef299eb3cd719f2fc0d5d381fdc2a3d5
The `fromsvn()` revset implementation could cause weakref error when using
sqliterevmap like:
File "hgsubversion/util.py", line 357, in <lambda>
return subset.filter(lambda r: tonode(r) in hashes)
File "hgsubversion/maps.py", line 542, in __contains__
return self.get(key) != None
File "hgsubversion/maps.py", line 533, in get
for row in self.revmap._query(
ReferenceError: weakly-referenced object no longer exists
Basically the seemingly harmless assignment could break surprisingly:
# dangerous: `hashes` does not have a reference on `meta.revmap` and may
# become unavailable after `meta`, `revmap` are released.
hashes = meta.revmap.hashes()
Avoiding cycles is still nice. This patch removes `revmap._hashes` so the
revmap no longer owns a reference of a `ReverseRevMap` object so the
`ReverseRevMap` object no longer needs to use weakref for `self.revmap`.
This could actually be caught by `comprehensive/test_sqlite_revmap.py`.
I was not careful enough verifying the "fromsvn()" patch.
See hg change 0980979a0d48. Since the interface has changed
more than one time, switch to explicit keywords arguments to avoid
surprises.
Since hgsubversion targets hg >= 3.2.4, drop support for hg 3.0 and 3.1
here.
Some versions of hg have bits of the config registrar code, but lack
dynamicdefault. Despite that, if they see reigstered config knobs,
they'll set off devel-warn nonsense about how you're holding the
config system wrong.
Ugh.
The config registrar doesn't load extension config values until after
a repo is created, meaning you can't access non-core config items in a
repository constructor.
Caught with a hack to turn develwarns into crashes. Unfortunately, I
can't check that in because a couple of commitctx() calls in tests
turn into deadlocks when I try and fix them.
Summary:
In repos where converted revisions come from different sources it's
not nice of hgsubversion to assume that all converted rev are coming
from SVN.
Test Plan:
Ran all current tests, nothing is broken. Not sure how to test new
behaviour withour much overhead. I suppose I could write something
that overrides commit extras
The upstream is going to add an `order` argument to `revset.methods`
functions. Let's update our code to be compatible with it.
[1]: https://phab.mercurial-scm.org/D451
Previously, when devel.all-warnings is set to True, hg subversion will crash
when pushing with the error:
ProgrammingError: transaction requires locking
Tracking that down, that is because "createmarkers" was called without
locking.
A comprehensive test was added to run test_push_command with obsstore turned
on to cover the code paths.
Upstream Mercurial has added a new 'missing' argument to the dirty function. We
need to add it as well. The default argument should mean this is backwards
compatible with older Mercurials.
I don't understand the subrepo or hgsubverison code 100%, so this patch is my
best attempt at a fix.
A future patch will modify dirty() to match an upstream change. Let's first
refactor it to be a bit cleaner so the next patch is readable.
This patch should not change any logic.
obsolete._enabled is the old deprecated way of checking if obsolete markers is
on. Instead we should be using obsolete.isenabled() to check if individual
features are on.
A recent patch introduced svnopts as a way of sharing the svn command options
between the old and the new way of registering a command. It turns out 'svnopts'
was already used further up in the module to define the flags that should be
added to *all* Mercurial commands. So our definition of it here cause us to add
all of these options to all Mercurial commands.
This was caught because it changes --rev to be '' instead of [], which breaks a
number of assumptions in the other commands.
Given that none of the subversion tests are command line tests, I'm not sure how
to test this. It was caught in other extensions tests.
(grafted from 3b1334407783a4379fd515e2ed9acc61e3f175ff)
(grafted from 6db63ead5556f2bf72e423ca8c6df08ea3a5b009)
'util' in hgsubversion is a different type from hgutil, which is the one from
core hg. This was hidden by the fallback logic, but I'm not sure why it didn't
cause errors in the tests. Maybe I ran the original tests against an older hg.
This time I've ensured the tests pass against the latest version of hg.
While fixing other test failures, I saw stack overflows related to the clone
function being wrapped too many times. I believe it's because this wrapping
logic doesn't put the unwrap logic in a finally statement.
This particularly bad in the tests, which do many things in one process. Hence
the stack overflow.
Python sqlite has 5 seconds timeout by default, which means if a writer holds
the lock, and the second writer will error out after 5 seconds.
In our use-case, it makes sense to just wait. However, sqlite does not support
waiting forever (see sqlite3_busy_timeout). Therefore use a while loop to
workaround.
