| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Only deleteBranch uses it for now.
|
| |
|
|
|
|
| |
Allow graceful exit of all fast-import processes when createBranch fails.
For consistency, add return value to deleteBranch, even though it always
returns EXIT_SUCCESS.
|
| |
|
|
|
| |
With the changes made to Repository::reloadBranches when --incremental
was introduced, the older mode wasn't working, anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When creating branches/tags off a branch that use "prefix" rules,
svn2git used to create new commits rather than just copying the git
ref over. This was due to SvnRevision::exportInteral() using
'path.isEmpty()' to determine if a change related to the whole branch
or not. If a "prefix" rule is used, then 'path' will not be empty.
We change it to instead look at how much of the change string was
chomped up by the rule match. If the whole string was chomped up, it
means that the change describes the whole branch.
|
| |
|
|
|
|
|
|
|
|
|
| |
When --resume-from failed in incremental mode, the log files that detected
the error condition were truncated. So, if the same command line was executed
again, the invocation would go through.
We now restore the log files from backup when we detect we're going to fail.
The restored log files may not all be the same as we originally started with,
but we only truncate information that would anyway be truncated on the
next successful run.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
An interrupted import (say with Ctrl-C) can leave the import directory in an
inconsistent state. This can be due to checkpointing fast-import only
occassionally, but updating log-* files immediately, and/or other reasons.
The incremental mode can detect certain such situations and rewind back to a
safe state. Note that since the default commit-interval is quite large, this
rewind can end up backtracking a lot.
Note also that import interrupted under the control of svn2git, say, for
missing rules should leave the import directory in a consistent state for
the purpose of svn2git.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use two allocators for marks, one persistent commit counter that starts at 0
and counts up commits, and a transitional counter, for files, that counts down
from maxMark, and is reset on each SVN revision.
Note that the marks file will still have marks for some, but not all, files.
The number of such marks is limited by the size of the SVN revision that affects
the most files.
For instance, this changed the size of one marks file from 19M to 3.2M.
fast-import issues: We currently set maxMark = (1<<20)-1. Anything large seems
to trigger a bug in the sparse array dumping routine in git-fast-import in
certain versions of git.
|
| |
|
|
| |
Use startFastImport to start off the git-fast-import process if necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We use the progress logs that we carefully maintained to recreate the
branch data structures, as described in earlier commits.
A major change/improvement is that reloadBranches() now uses the marks file
and internal data structures to prime the fast-import rather than using
git-rev-parse.
We also handle --resume-from properly, by truncating the log file to revisions
that only precede the revision resumed from. Note that git fast-import allows
marks to be reused without any extra processing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SVN directory deletes often indicate one or more branch deletions. However,
since the deleted directory isn't present in the resulting revision, several
of the indicators used by the rule-application mechanism aren't present.
This forces us to introduce several useless dummy rules to avoid errors.
We now note deletions and use the previous revision to determine several
properties, including whether the deleted item is a directory or not, and to
enumerate the contents of the directory in recurse mode.
We add an additional heuristic for unknown repositories -- i.e., when a rule
fired, but it's repository was invalid. We recurse in this case hoping to
catch a more specific rule. I believe this is safe: because some other rule
must've seen the same directory before, when it or a subdirectory was created,
and decided _not_ to create a repository at that point -- so recursing and/or
ignoring the contents of the just deleted directory won't corrupt the history,
it can only improve it.
We use mark :0 to note mark deletions internally, and in the progress logs.
(Note that cvs2svn creates wierd commits where a whole tree is copied first,
and then subtrees are pruned. In such cases, neither the previous revision
nor the current revision have the deleted directory -- we ignore this case
as before. There's no information loss since the final contents of the revision
are exactly what is desired.)
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Experience with the mono tree shows that it isn't too annoying, and
there might be some useful history hidden in there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
branch tip to an older revision.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
namely the FreeBSD svn rep
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/svn.cpp
|
| | |
| |
| |
| | |
prefix and path under certain conditions.
|
| |/ |
|
| | |
|
| |
|
|
| |
Improve the ruleparser so that prefix never starts or ends with a '/'
|
| |
|
|
| |
correct :))
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rootdir /a/path/
This should be the part of the match that shouldn't be included in the
commited path.
Ex:
match /trunk/kdenetwork/kmail/
rootdir /trunk/kdenetwork/
repository KDE/kdepim
branch master
end match
This would but all matched files/directories under kmail into the
repository under the subdir kmail
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
