The test_push_command test was failing on our machines because the machines are
ipv6 but expose ipv4 on the 127.0.0.1 loopback interface. This caused the
svnserve process to listen via ipv4, but the connecting process would attempt to
connect on ipv6 and fail. Using the hostname causes it to listen using the
primary network interface, which matches the interface that is used when the
connecting client resolves the hostname. So the test now passes.
Not comparing sorted lists was probably always a mistake, but it became an
actual failure when upstream Mercurial changed to using lazymanifest, which
always returns keys in sorted order.
We previously updated to the repository tip after pushing a revision,
presumably on the assumption that tip would be the last revision we
just pushed. This assumption is flawed for high traffic repositories.
In particular, you previsouly would sometimes end up on a completley
unrelated commit if someone else commits to a different branch in
between the time we push a revision and pull it back from the server.
This changes to instead update to the branch tip of the branch we were
on at the beginning of the push. This should be either the revision
we just pushed or a linear descendent of the revision we just pushed,
with a fair degree of reliability.
http://svn.apache.org/viewvc?view=revision&revision=1223036 exposes
what is arguably a bug in hgsubversion push code. Specifically, when
we are receiving text from the server in an editor, we prepend a "link
" to the text of symlinks when opening a file and strip it when
closing a file. We don't, however, prepend "link " to the base we use
when sending text changes to the server.
This was working before because prior to that revision, the first
thing subversion did was to check whether the entirety of the before
text or the entirety of the after text was less than 64 bytes. In
that case, it just sent the entirety of the after text as a single
insert operation. I'd expect most, but not all symlinks to fit under
the 64 byte limit, including the leading "link " text on the
subversion end.
After the change, the first thing subversion does is check for a
leading match that is more than 4 bytes long, or that is the full
length of the after text. In this case, it sends a copy operation for
the leading match, and then goes into the if < 64 bytes remaining send
the whole thing behavior. It also looks for trailing matches of more
than 4 bytes even in the <64 byte case, but that's not what breaks the
tests.
Incidentally, changing the destination of long symlinks was broken
even before this subversion change. This diff includes test additions
that cover that breakage.
This let me determine a little bit of a disturbing test failure:
test_push_existing_file_newly_symlink is broken against svn 1.8.8 for
me (and against svn 1.8.9 for Sean). This isn't a regression on our
part, but we need to work around this in the near future.
This requires a few changes to wrappers.push() to use obsolescence
rather than strip and to make the rebase -- which is non-destructive
with obsolete active -- to no longer keep the originals. Possible
future work involves no longer relying on rebase for non-outgoing
revisions, and simply leaving them in the troubled state.
We test this feature by adding setting obsolete_mode_tests to True in
classes that push changes.
The assumption that len(repo) corresponds to the count of actual,
usable revision in the repository fails in presence of hidden
revisions. Instead, we use a dedicated method in test_util, and change
all tests to use this for obtaining repository length -- just to be
safe...
The failure was occuring during push when a new file is added inside a new subdirectory and push is being called from this subdirectory.
This subdirectory disappears when the commit is being rebased[during push] causing the push to fail with 'no such file/directory' error.
When pushing multiple commits, push would do one rebase
per commit. This changes it track the files that have been
changed as part of the push and only perform a rebase if
the commit touches a file that has been changed previously.
On our repo, push used to take 25 seconds per commit. With
this change it takes closer to 10 seconds per commit (if
there are no conflicts).
Previously when pushing n commits, push would rebase n,
commit 1, rebase n-1, commit 1, rebase n-2, etc. This
caused push to be very slow on large repositories. Pushing
10 commits on our repo took 75 seconds per commit, and that
grew at n^2 with the number of commits being pushed.
This changes push to rebase each commit individually. Now
pushing 10 commits on our repo takes 25 seconds per commit,
and is constant relative to the number of commits being
pushed.
This causes problems on platforms where the encoding is actually different,
if the manifest contains a path which no longer matches the checkout, a
following bailifchanged() actually fails.
This happens on Windows with a repository containing UTF-8 encoded filenames
checked out on a cp1252 environment.
This solves a problem with startrev tests sporadically failing in ra.get_log()
with some kind of svn corruption error. Loading each svn repository in a
different place solved that, or at least prevented me from reproducing it. What
is interesting is this is the same fixture being loaded each time. Also, before
loading the fixture, we take care of removing an existing repository. Loading
with the same options twice also failed reproducing the issue. Same thing if
the first load only load the svn repository but does not convert it.
So, I have absolutely no idea what was wrong, blame python subprocess,
subversion or some kind of filesystem write ordering bug.
The middle-term goal is to make TestBase repo_path and wc_path private, so they
can be changed for every load call. This is not required to use nosetests
multiprocess facility as the fixtures create temporary directories but it makes
things much clearer and avoid weird cases where a repository was loaded several
times at the same location in a single test (cf test_startrev). That way we
will be more confident the tests can be parallelized.
The long term goal is to make hgsubversion compatible with nosetests
--processes option.
Basically, all the IOErrors we ever raise inside a file commit function
that is sent to commitctx should be ENOENT. This suggests a change
should be made in commitctx to not overload IOError.
We can't rely on the most-recent change number matching our most-recent
change number because there can be changes in svn that produce no
corresponding hg changeset.
The 'hg svn url' command has been killed; the replacement is
'.hg/hgrc'. More stuff related to its disappearance has been stripped,
including two tests.
HgChangeReceiver now takes a UUID argument, which it uses to ensure
that remote repositories remain unchanged. This is a temporary
solution, and I'm not entirely satisfied with how it's done either.
Access to the UUID file has been isolated in a HgChangeReceiver
property.
Some more tests have been updated to use ui.pushbuffer()/popbuffer(),
and to pass through the Mercurial API.
Moved the arguments to wrappers.pull() to the UI configuration.
Also, remove HgChangeReceiver.opts in favour of a 'usebranchnames'
instance & configuration variable. The name is taken from the
ConvertExtension.
