| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This is needed to make sure that not too many processes are running and
we run out of ressources.
Calling touch only in commit is not enough as startFastImport is called in other
functions as createBranch too - and that can result in too many processes.
|
|
|
|
| |
closed fast-import
|
| |
|
|
|
|
|
|
| |
a branch as deleted.
Thanks Raja R Harinath for spotting it.
|
| |
|
|
|
|
| |
"--debug-rules" flag is active.
|
|
|
|
|
| |
"declare var=value"
now "${var}" in any line will be replaced by "value"
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Creation is already printed at the bottom.
|
|
|
|
| |
tree is not what it seems like
|
|
|
|
| |
prefix option for a rule is used current == svnprefix does not mean that we are dealing with the root of a branch, path needs to be empty as well.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The conflict was mainly around two different approaches to fixing the linear
commitMarks issue. The precise tracking of commit marks per branch is better,
and that's how I resolved the merge conflict.
While at it, I also removed the "revision-*" files, since the "log-*" files
already have the same information, and the branch information too.
Conflicts:
src/repository.cpp
src/repository.h
|
| |\
| | |
| | |
| | | |
into integration
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
into integration
|
| | |/
| | |
| | |
| | | |
Linking against these libraries makes the program build using binutils gold.
|
| |\ \
| | | |
| | | |
| | | | |
git://gitorious.org/~marcguenther/svn2git/marcguenther-svn2git into integration
|
| | | | |
|
| | |\ \
| | | |/ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
from path then fallback to using the latest version and issue a warning
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Suppose you have multiple repositories in SVN that you want to merge into
a single one in GIT, it can get very messy to handle all the special-case
rules.
Instead, we introduce a new "forwarding repository" concept, which looks like
repository subordinate
repository unified
prefix foo/
end repository
This forwards all commits on the "subordinate" SVN tree to the "unified" GIT
tree, with each file prefixed with "foo/".
|
| | | |
| | | |
| | | |
| | | | |
Rename Repository to FastImportRepository. We will be introducing new types soon.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The naming scheme is
refs/backups/r<svn-revision>/(heads|tags)/<branch>
Where <svn-revision> is the revision where the branch is being reset:
either for deletion or to be overwritten.
We use a separate namespace so that we don't clutter up branch-name lists
and tag lists with deleted tags. These refs will keep the commits alive
as far as 'git gc' is concerned, but will be fairly unobstrusive otherwise.
|
| | | |
| | | |
| | | |
| | | | |
Put the slightly tricky qUpperBound logic in only one place.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
While at it, make progress message for the "unknown from" case similar
to the normal progress message. This ensures that any reconstructed
branch data-structure will not lose any information.
|
| | | |
| | | |
| | | |
| | | | |
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.
|