Summary:
Our reverse sync job is too slow when pushing to svn. It seems like the slowness comes
keep doing push-pull-rebase which doesn't seem necessary in our case.
From my understanding, we need to do push-pull-rebase because we have multiple writers.
In our sync job, we only have one writer and therefore can we skip the pulls and rebases?
Reviewed By: DurhamG
Differential Revision: D16442559
fbshipit-source-id: 926d1c516e8e6d59298d310fc67927ace37f72c9
Summary:
This was removed in D16381346. The problem is in the ui which is always new. Lets keep a
reference to it when adding configs.
Reviewed By: xavierd
Differential Revision: D16494854
fbshipit-source-id: d206b6211c004e0fec57a2aeef6549b2f96cec17
Summary: This newly added test keeps failing. Let's remove it from now.
Reviewed By: DurhamG
Differential Revision: D16381346
fbshipit-source-id: 11146d44fbbcd1e1c960fe4a0b6e3c28854f456d
Summary:
When we are migrating www to hg as source of truth, we would like to maintain the
reverse sync for some time in case we need to rollback.
In order to achieve that, we need to know the latest svn and hg commit to operate on. We
would like to record this information in the svn commit itself so it doesn't require
extra syncing and transaction.
In ordre to get this info, we can run `svn log -l 1` and parse the commit message from
there.
Reviewed By: quark-zju
Differential Revision: D16337012
fbshipit-source-id: acf66babdb48c07f95e9eb49daac0d3d3e6a96a0
Summary:
The hgsubversion tests are flaky because they select a random port between
`socket.IPPORT_USERRESERVED` (5000) and 65535 for the subversion server to
listen on. The port that is selected may not be free, as it might be in use by
another service running on the same host.
Ports above 5000 are a wild west, so there is no guarantee of any particular
port being available for svnserve to use. Check that the randomly selected
port is actually available by trying to bind to it. If the bind fails, assume
the port is not available and pick a different one.
Reviewed By: quark-zju
Differential Revision: D15554733
fbshipit-source-id: c37d61488449bb0b93907eeee91f6fa404c959cf
Summary:
Let's move hgsubversion to absolute_import, just to be consistent with the rest
of Mercurial codebase.
Reviewed By: markbt
Differential Revision: D15392154
fbshipit-source-id: e4c32939aff0616790828da508f3feea158669e1
Summary:
This is probably not the proper fix but we're getting rid of svn too.
Remove tests coupled with named branches. Modified some critical tests (ex.
"push") so they can still pass.
Reviewed By: DurhamG
Differential Revision: D14210968
fbshipit-source-id: 62e02179b0e4745db8f90f718613afad42d7376a
Summary:
During pushrebase there is code that says 'for each file, do some work
that involves listing the changed files'. Because we reparse the list each time,
this becomes n^2 behavior. Let's cache the list to avoid this.
Reviewed By: singhsrb
Differential Revision: D13944830
fbshipit-source-id: 4fd0dbf26b6cee9d0c01879cafb9837262f7afa0
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary: We'd like to identify which of the three underlying conditions cases this exception.
Reviewed By: quark-zju
Differential Revision: D12870572
fbshipit-source-id: 45724ad6bb3582c04a6ea3c0b7a748bf72219b93
Summary:
Previous code format attempt (D8173629) didn't cover all files due to `**/*.py`
was not expanded recursively by bash. That makes certain changes larger than
they should be (ex. D8675439). Now use zsh's `**/*.py` to format them.
Also fix Python syntax so black can run on more files, and all lint issues.
Reviewed By: phillco
Differential Revision: D8696912
fbshipit-source-id: 95f07aa0c5eb1b63947b0f77f534957f4ab65364
Summary:
This migration allows `./run-tests.py` to run `hgsubversion` tests. Since hgsubversion
tests are actually python unittests, we don't care about their output at all,
they fail differently. But the behavior of the test suite require us to match
whatever the tests prints. We do this later in the stack.
Depends on D6719886
Test Plan: - check that tests are runnable at least
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6719890
Summary:
This is in line with our general spirit of renaming things into test-extname-smth.
Depends on D6719883
Test Plan: - test fixes and runs follow in the stack
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6719886
Summary:
Move tests to where we are used to them.
Note that I don't move comprehensive tests to the `tests` directory, since
I think that having them not run when `./run-tests.py` is run without arguments
may be a useful thing. In general, we may adopt this concept for the core as well.
If we decide we do want to move them, it's very easy to do.
Depends on D6719879
Test Plan: - fixups and test runs follow in the stack
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6719883
