aboutsummaryrefslogtreecommitdiffstats
path: root/src/repository.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Only print warning if it appliesTorgny Nyblom2011-01-151-1/+1
|
* Fix serious performance regression.Nicolás Alvarez2010-12-231-0/+3
| | | | | | | In Repository::commit, don't call startFastImport() if we have nothing to write to the fastImport stream. startFastImport() may start new git-fast-import processes if they were previously killed, so it may be extremely slow to call it frequently if it's not necessary.
* Make sure that there are merges recorded before trying to read the last oneTorgny Nyblom2010-12-211-1/+1
|
* Try and fix cvs2svn multiple merge points for branches and tags.Torgny Nyblom2010-12-211-19/+27
| | | | Might still need some logic for detecting the correct from branch.
* Make the tagging commands visible in the gitlog aswellTorgny Nyblom2010-12-201-6/+6
|
* Only call startFastImport when neededTorgny Nyblom2010-12-161-1/+1
|
* Be more clear about what are warningsTorgny Nyblom2010-12-161-11/+11
|
* Move branch creation/deletion/restting to Repository and write these inTorgny Nyblom2010-12-151-5/+16
| | | | | | commit() Prepare for handling cvs2svn borked tags/branches
* Ditch PrefixingRepository in favor of a memmber variable inTorgny Nyblom2010-12-151-256/+29
| | | | | [FastExport]Repository Some minor reordering
* call startFastImport where it is used.Torgny Nyblom2010-12-131-4/+2
|
* Code styleTorgny Nyblom2010-12-131-1/+2
|
* Make sure fastImport is started before adding fileNiko Sams2010-10-071-0/+1
|
* Unify debug messages and Match structsTorgny Nyblom2010-09-281-1/+1
|
* call startFastImport() in commit()Niko Sams2010-09-241-1/+1
| | | | | | | | This fixes importing large svn commits that get imported into a large number of git repositories. It happened that a process was closed (in ProcessCache::touch) before commit() and so the commit wasn't imported correctly. And remove the touch() call as that is done now in startFastImport()
* touch fastImport process in startFastImport()Niko Sams2010-09-241-0/+2
| | | | | | | 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.
* add assertions to write() methods to make sure nothing is written into a ↵Niko Sams2010-09-241-0/+8
| | | | closed fast-import
* output repository name that crashed, helpful to know which logs to look atNiko Sams2010-09-241-1/+1
|
* Readd br.marks.last() to various places as a mark of "0" is used to markTorgny Nyblom2010-09-171-4/+4
| | | | | | a branch as deleted. Thanks Raja R Harinath for spotting it.
* Fix assert when br.marks is emptyTorgny Nyblom2010-09-151-1/+1
|
* Make the fastImport into a logging instance, logging is enabled when the ↵Torgny Nyblom2010-09-131-7/+67
| | | | "--debug-rules" flag is active.
* Better log messagesTorgny Nyblom2010-09-091-2/+2
|
* Spaces not tabsTorgny Nyblom2010-09-081-1/+1
|
* Inter branch merging causes git log to break with fatal internal errorsTorgny Nyblom2010-09-081-4/+4
|
* Don't print the same message as in Transaction()Torgny Nyblom2010-09-081-4/+0
| | | | Creation is already printed at the bottom.
* White space cleanup & debug statmentsTorgny Nyblom2010-09-041-121/+141
|
* Merge branch 'master' of git://gitorious.org/svn2git/svn2gitRaja R Harinath2010-08-241-4/+16
|\ | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Merge commit 'refs/merge-requests/1' of ↵Torgny Nyblom2010-08-091-1/+1
| |\ | | | | | | | | | git://gitorious.org/~marcguenther/svn2git/marcguenther-svn2git into integration
| | * Merge branch 'master' of gitorious.org:svn2git/svn2gitMarc Guenther2010-05-061-12/+24
| | |\
| | * | small typo in debug messageMarc Guenther2010-04-201-1/+1
| | | |
| * | | If a branch is created from a previous commit that doesn't touch the branch ↵Torgny Nyblom2010-08-091-8/+25
| | | | | | | | | | | | | | | | from path then fallback to using the latest version and issue a warning
| * | | Save the exported marks along with the associated revisions for later use.Torgny Nyblom2010-05-181-0/+13
| | | |
| * | | Make git fast-import save the used marks and hashes for later use.Torgny Nyblom2010-05-181-1/+6
| | | |
| * | | Initialize lastmarkTorgny Nyblom2010-05-181-1/+1
| | | |
| * | | Add debugTorgny Nyblom2010-05-081-0/+1
| | |/ | |/|
* | | Provide a way to merge repositoriesRaja R Harinath2010-07-221-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/".
* | | Extract out public methods of Repository into an abstract base classRaja R Harinath2010-07-221-26/+127
| | | | | | | | | | | | Rename Repository to FastImportRepository. We will be introducing new types soon.
* | | Move backup branches and tags to refs/branches/Raja R Harinath2010-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Carve out Repository::markFrom from createBranch(), and noteCopyFromBranch()Raja R Harinath2010-07-211-43/+41
| | | | | | | | | | | | Put the slightly tricky qUpperBound logic in only one place.
* | | Make Repository::createBranch use resetBranch now that they're similarRaja R Harinath2010-07-211-24/+1
| | |
* | | Re-arrange Repository::createBranch to be closer to resetBranchRaja R Harinath2010-07-211-19/+19
| | | | | | | | | | | | | | | | | | 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.
* | | Add a resetBranch() to help refactor createBranch and deleteBranch.Raja R Harinath2010-07-201-4/+11
| | | | | | | | | | | | Only deleteBranch uses it for now.
* | | Remove exit(1) in createBranch. Return EXIT_SUCCESS/EXIT_FAILURE insteadRaja R Harinath2010-07-201-3/+7
| | | | | | | | | | | | | | | | | | 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.
* | | Make error handling of --incremental and --resume-from idempotentRaja R Harinath2010-07-111-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | make --incremental robust to inconsistent import directoriesRaja R Harinath2010-07-101-12/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Reduce size of fast-import marks file by not persisting file-level marksRaja R Harinath2010-07-101-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Ensure deleteBranch() actually writes to git-fast-importRaja R Harinath2010-07-091-0/+1
| | | | | | | | | | | | Use startFastImport to start off the git-fast-import process if necessary.
* | | Introduce incremental mode with --incremental flagRaja R Harinath2010-07-091-18/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Handle SVN directory deletes that lead to branch deletesRaja R Harinath2010-07-081-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* | | Move SVN revision to fast-import mark mapping to the per-branch datastructure.Raja R Harinath2010-07-051-26/+31
| | | | | | | | | | | | | | | | | | 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.
* | | Properly implement the 16-parent limit, rather than conservatively stopping atRaja R Harinath2010-07-051-8/+8
| | | | | | | | | | | | 15 commit parents.
generated by cgit v1.2.1 (git 2.21.0) at 2024-06-29 16:24:41 +0000