| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
A single SVN revision can affect multiple branches in the same repository.
Keeping track of only one mark per revision loses information and makes
the history incorrect.
|
|
|
|
| |
15 commit parents.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use a literal meaning of multiple commit parents to allow us to infer
some partial repository copying as merges. This helps us
1) track history despite some directory reorganization
2) link subset commits to parents
3) infer some merges which were achieved by overwriting
a subtree with contents from another branch
This seems to work well enough even with cvs2svn monster commits. The
heuristics have been tuned by gut feel to work reasonably well with mono's
SVN repository. They can definitely be improved.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we support arbitrarily reseating branches, the branch can be
reset to older SVN revisions or derive from a different branch point.
The "only fast-forward" rule of git branch imports gets in our way.
Note that the application of the rule is fairly unpredictable since the
checking happens only at 'checkpoint's.
Let's trust our handling of SVN history and override the sanity-check.
Note that we don't lose any information since reseated branches are
snapshotted before reset.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the progress log for commit and branch creation more uniform and
machine parse-able. Add 'mark' information to log so that it can be
cross-referenced against the fast-import marks file.
The log-* files now have enough information in a convenient enough form
that the export can eventually be made fully resumable and incremental.
The format is essentially
progress SVN r<svn-rev> branch <git-branch> = (:<mark> | <other-git-branch>)
with a possible trailing # comment. Any line not matching this can be
The incremental mode would prime the internal structures with
if (<mark>) repository->commitMarks[<svn-rev>] = <mark>;
repository->branches[<git-branch>].commits.append(<svn-rev>);
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, all the SVN commits were tracked in a linear array, and we searched
for nearest commits in that array. However, SVN history is not linear, and the
'next smallest commit' search was picking the wrong commit.
I've moved the commit array into the 'Branch' structure.
As a minor subtlety, the branch creation revision is also noted in the
'commitMarks' structure, by copying the commit mark of the branch point.
We need this to ensure that the commits array is strictly non-decreasing.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the logic of commit 209e6ce4ddf114494d6d72455690af819dcbf18c
qLowerBound doesn't have the desired semantics -- it returns the position of the
first item which is not smaller than the search key.
The intended semantics seems to be to find the given key, or the next smallest one.
This is almost given by qUpperBound -- it returns an element one past the desired result.
I've also added some additional debugging code to help debug this.
|
|
|
|
|
|
|
|
|
|
| |
Branches and marks are now long-lived. The marks have to survive even
if the fast-import process goes away. So, use the --import- and --export-marks
feature of fast-import to persist marks.
These marks are only meant for the duration of this 'svn-all-fast-export' and
don't confer any new incremental behaviour. You'll need a mark to SVN commit map
for that, at least.
|
| |
|
|
|
|
| |
Ensure that marks start at 1, now that they're visible in the logs
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The GPLv2 is incompatible with the Apache 2.0 License used in the SVN libs.
So everyone was using this software under the GPLv3 anyway. Formalise it now.
|
| |
|
| |
|
|
|
|
|
| |
Instead of failing with an unhelpful error in fast-import we create the
repositories we require to import into if they don't exist.
|
| |
|
| |
|
|
|
|
|
| |
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Thiago Macieira <thiago@kde.org>
|
|
|
|
|
| |
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Thiago Macieira <thiago@kde.org>
|
|
|
|
| |
SVN revision
|
|
|
|
| |
I don't know what went wrong, but importing KDE revision 296047 there was a mixup with the marks. So instead avoid the trouble and store the thing in in cooked format already
|
| |
|
|
|
|
| |
git-fast-import
|
|
|
|
|
|
| |
the end.
Though I have the impression that this doesn't do much
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
shouldn't have used QTextStream.
|
| |
|
| |
|
|
|
|
|
| |
output to a file rather than garble the output of 10-15 process in
stdout.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|