This change means that files located in the actual branches directory will now be wholly
ignored. If we want to handle those correctly, it will take a reasonably large amount of work
and probably a configuration flag. Also, any non-related paths outside of branches/trunk will
be explicitly ignored, which is similar to the somewhat accidental pre-branch-refactor
behavior. Finally, any unrelated files located as children of branches will cause the directory
in branches to be used as the branch - not, as recently was the case, the directory immediately
containing that file.
We now calculate the last known revision by iterating over all known
revisions and finding the highest number. Theoretically, we might be
able to simply read the latest entry, but in practice, that's a bug
waiting to happen. For instance, we might want to achieve
compatibility with '.hg/shamap' as generated by the
ConvertExtension, and it not only cannot offer a guarantee of
linearity, but it also allows more than one conversion to source exists.
I'd say we have other problems to care about until this turns up as a
hotspot in profiling. Such as why we leak circa 100MB of memory per
1000 revisions converted ;)
This should allow fixing of several outstanding issues with branch handling. Note that this is a *massive* change to one of the oldest parts of hgsubversion, so it might introduce bugs not caught by the testsuite.
Project items copyfrom revisions are irrelevant to parent revision detection,
only the project one or those of its ancestors matter. Items copyfrom is
useful when retrieving items content.
Former code resulted in incorrect converted graph for pyglet repository,
especially on the following revision:
------------------------------------------------------------------------
r274 | r1chardj0n3s | 2006-12-21 02:02:14 +0100 (Jeu, 21 Dec 2006) | 2 lines
Changed paths:
A /branches/richard-glx-version (from /trunk:269)
M /branches/richard-glx-version/pyglet/window/xlib/__init__.py
R /branches/richard-glx-version/tests/test.py (from /trunk/tests/test.py:270)
R /branches/richard-glx-version/tools/info.py (from /trunk/tools/info.py:272)
R /branches/richard-glx-version/website/get_involved.php (from /trunk/website/get_involved.php:273)
Branching to horribly mangle GLX
Here is what happen in jquery repository:
- kelvin-dev branch is created in r1617 with an empty directory for the
datePicker plugin
- commits are done
- datePicker plugin is merged in trunk
Before the fix, the converter assumed the initial empty commit had for parent
some other commit of trunk, therefore adding all its files, which was wrong.
And we ended with 'alignDemo.html' in converted trunk@5946 while it was not in
the source revision.
- SubversionRepo.get_file() strips the symlink prefix
- Enforce that hg_delta_editor symlink data always contains the prefix. The
alternative was seducing and more consistent with hg content but it makes the
code more complicated since svn:special can be set before or after the content
is set, and we need it in apply_textdelta()
This issue fixes jQuery repository conversion at r3674.
Handle copies of items from revision X into revision Y where X is not the
parent of Y. This cannot happen in Mercurial because copies always happen
between parents and children. A file copy is recorded if:
1- Source and destination revs are in the same branch.
2- The file is unchanged (content, type, removal) through all revisions between
destination and source, not including source and destination.
Directory copies are registered only if the previous rules apply on all copied
items.
[1] is there because file copies across branches are meaningless in Mercurial
world. We could have tried to remap the source rev to a similar one in the
correct branch, but anyway the intent is wrong.
[2] is more questionable but I think it's better this way for we live in a
non-perfect svn world. In theory, 99% of copies out there should come from the
direct parent. But the direct parent is a fuzzy notion when you can have a
working directory composed of different directory at different revisions. So we
assume that stuff copied from past revisions exactly matching the content of
the direct parent revision is really copied from the parent revision. The
alternative would be to discard the copy, which would always happen unless
people kept updating the working directory after every commit (see
tests).
changes that fix problems when trunk is not the oldest branch. Also includes
fixes for copying from a tag that we chose not to create (eg tagging a vendor
branch) and includes tests for all of those things.
