Open AnLupoTamTamy opened 2 years ago
I am also migration our SVN repositories to Git and can answer some of your questions.
if I have to run it directly on the SVN server or not
The tool works directly on the SVN repository folder on the server. You could even copy your production SVN repo folder and run the tool on the copy.
Thus, I would execute it directly on the server. This also has the benefit of fast file access without network in between.
However, it might be possible to mount the SVN repo folder on the server as some network drive on another machine. But I did not try this and would not recommend it.
can I migrate different repositories in different times?
Yes. You can run the tool with different rule files. Each rule file could migrate one of your SVN projects and ignore the others.
For example, you could use the following rule file to only migrate the trunk of OldSvnProject
:
# Declare the repositories we know about:
create repository NewGitProject
end repository
# Declare the rules. Note: rules must end in a slash
match /trunk/OldSvnProject/
repository NewGitProject
branch main
end match
# Ignore other trunk folders
match /trunk/
end match
# Ignore all branches
match /branches/
end match
# Ignore all tags
match /tags/
end match
It would be useful, apart from the ruleset files, to add a more explicit example about the configuration in the README.
There are more examples here.
You can test the tool with only a little portion of your whole repo. To do this, use min revision
and max revision
.
If you run the command without parameters, then it shows a help text with available parameters.
Where do I have to run this tool?
The tool takes the path to the SVN repo folder on the server. It will create the corresponding Git repositories in the current working directory.
Thus, I suggest to run the tool in the folder, where you want to have your new Git repositories. But of course, you could also move the new Git repositories afterwards to a new location. It is not really important where you run the tool.
FYI: I noticed that the option --ignore-svn
can have a dramatic performance impact ( #144 ). I suggest to start with as little parameters as possible and then add further parameters if the previous run works for you.
Thank you so much for the detailed answer and the suggestions!
I didn't get a point, so I'll try to ask a more detailed question: after I have built this program and I have the svn-all-fast-export
executable, in which location I have to execute this executable? Do I have to copy the executable in the SVN server where I have the repository and then execute it there?
I tried to run it after I did a checkout of the project locally on my machine and it didn't work.
If I have a repository structure on SVN server like this, whith many projects which willl become each one a specific git repository:
base/
- group/
- - project1/
- -- trunk/
- -- branches/
- - project2/
- -- trunk/
- -- branches/
- project3/
- -- trunk/
- -- branches/
And I want to migrate the project1
repository, the actual steps that I have to do are:
svn-all-fast-export
executable on the SVN server (for example, in the base
directory)project1
and exclude the otherscreate repository
in the rulesetIn this configuration, do I have to run the executable directly in the project1
folder so that the paths defined in the ruleset file are related to this folder?
Thus, I suggest to run the tool in the folder, where you want to have your new Git repositories. But of course, you could also move the new Git repositories afterwards to a new location. It is not really important where you run the tool.
This means that I have to run the tool on the SVN server, but it's not important in which folder inside it, right? Of course the new git repository will be only local and after that I can push to a remote repository.
I must have access to the SVN server itself to do all this process.
I tried to run it after I did a checkout of the project locally on my machine and it didn't work.
As I said, you need to run the tool on the SVN folder on the server. You MUST NOT run it on any checkout / clone of the repository.
The folder structure in your example looks like a checkout. An SVN repository on the server side typically looks like this:
conf/
db/
hooks/
locks/
format
README.txt
svn.ico
Copy the svn-all-fast-export executable on the SVN server
The tool is available in some Linux distributions. On Ubunut, I was able to install it via sudo apt install svn-all-fast-export
.
Location of the tool executable is irrelevant.
Create a rule file that says to include only project1 and exclude the others
Yes.
Run the executable
Yes. With the rules file.
As I said, the tool prints available parameters when called without arguments.
Usage: svn-all-fast-export [OPTION] [Path to subversion repo]
Options:
--identity-map provide map between svn username and email
--identity-domain provide user domain if no map was given
--revisions-file provide a file with revision number that should be processed
--rules the rules file(s) that determines what goes where
--msg-filter External program / script to modify svn log message
--add-metadata if passed, each git commit will have svn commit info
--add-metadata-notes if passed, each git commit will have notes with svn commit info
--resume-from start importing at svn revision number
--max-rev stop importing at svn revision number
--dry-run don't actually write anything
--create-dump don't create the repository but a dump file suitable for piping into fast-import
--debug-rules print what rule is being used for each file
--commit-interval if passed the cache will be flushed to git every NUMBER of commits
--stats after a run print some statistics about the rules
--svn-branches Use the contents of SVN when creating branches, Note: SVN tags are branches as well
--empty-dirs Add .gitignore-file for empty dirs
--svn-ignore Import svn-ignore-properties via .gitignore
--propcheck Check for svn-properties except svn-ignore
-h --help show help
-v --version show version
As you see, Path to subversion repo
is a parameter for the executable.
But there is no parameter for the Git repo because the Git repositories to be created are read from rules file.
In this configuration, do I have to run the executable directly in the project1 folder so that the paths defined in the ruleset file are related to this folder?
Again, as I said, you do not run the tool on a checkout of your SVN repository. Run it on the server where the SVN repository is hosted.
For example, you could call it like this:
svn-all-fast-export --identity-map my-identity-map.txt --rules my-rules.txt --add-metadata /home/svn/my-svn-repo/
As you see, the location of svn-all-fast-export executable is irrelevant. Git repos will be created in the current working directory,
Your rule file might look like this:
# Declare the repositories we know about:
create repository Project1GitRepo
end repository
# Declare the rules. Note: rules must end in a slash
match /base/group/project1/trunk/
repository Project1GitRepo
branch main
end match
# Ignore other projects, tags, branches
...
The rule file conisders the paths inside the SVN repository (like it would have been checked out). These do not correspond to paths directly on the file system, but to paths inside the SVN data structures.
I've a SVN server with many different repositories, which often are not in standard layout.
My goal is to convert one or more of these repositories into git repositories, but I need to do this in different moments since each of these repo is huge and for other reason we cannot migrate them all together. Just for clarity, when I say "repository" I mean a specific project, which will become a git repository with its own history.
First of all, I get that I have to run the tool not on a local machine, but I don't get if I have to run it directly on the SVN server or not. The second point is, can I migrate different repositories in different times? It would be useful, apart from the ruleset files, to add a more explicit example about the configuration in the README. If more details are required, please tell me. Thank you for the help! We can't see to migrate to Git :)