Create a users file (i.e. users.txt) for mapping SVN users to Git:
user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...
You can use this one-liner to build a template from your existing SVN repository:
svn log -q | awk -F '|' '/^r/ {gsub(/ /, "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt
SVN will stop if it finds a missing SVN user, not in the file. But after that, you can update the file and pick up where you left off.
Now pull the SVN data from the repository:
git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp
This command will create a new Git repository in dest_dir-tmp and start pulling the SVN repository. Note that the "--stdlayout" flag implies you have the common "trunk/, branches/, tags/" SVN layout. If your layout differs, become familiar with --tags, --branches, --trunk options (in general git svn help).
All common protocols are allowed: svn://, http://, https://. The URL should target the base repository, something like http://svn.mycompany.com/myrepo/repository. The URL string must not include /trunk, /tag or /branches.
Note that after executing this command it very often looks like the operation is "hanging/frozen", and it's quite normal that it can be stuck for a long time after initializing the new repository. Eventually, you will then see log messages which indicate that it's migrating.
Also note that if you omit the --no-metadata flag, Git will append information about the corresponding SVN revision to the commit message (i.e. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>)
If a user name is not found, update your users.txt file then:
cd dest_dir-tmp
git svn fetch
You might have to repeat that last command several times, if you have a large project until all of the Subversion commits have been fetched:
git svn fetch
When completed, Git will checkout the SVN trunk into a new branch. Any other branches are set up as remotes. You can view the other SVN branches with:
git branch -r
If you want to keep other remote branches in your repository, you want to create a local branch for each one manually. (Skip trunk/master.) If you don't do this, the branches won't get cloned in the final step.
git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same names
Tags are imported as branches. You have to create a local branch, make a tag and delete the branch to have them as tags in Git. To do it with tag "v1":
git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1
Clone your GIT-SVN repository into a clean Git repository:
git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir
The local branches that you created earlier from remote branches will only have been copied as remote branches into the newly cloned repository. (Skip trunk/master.) For each branch you want to keep:
git checkout -b local_branch origin/remote_branch
Finally, remove the remote from your clean Git repository that points to the now-deleted temporary repository:
git remote rm origin
(This answer has been updated to match SVN 1.8 and 1.9's behaviour)
You have 2 questions:
Marking files as ignored:
By "ignored file" I mean the file won't appear in lists even as "unversioned": your SVN client will pretend the file doesn't exist at all in the filesystem.
Ignored files are specified by a "file pattern". The syntax and format of file patterns is explained in SVN's online documentation: http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html "File Patterns in Subversion".
Subversion, as of version 1.8 (June 2013) and later, supports 3 different ways of specifying file patterns. Here's a summary with examples:
1 - Runtime Configuration Area - global-ignores option:
- This is a client-side only setting, so your
global-ignores list won't be shared by other users, and it applies to all repos you checkout onto your computer.
- This setting is defined in your Runtime Configuration Area file:
- Windows (file-based) -
C:\Users\{you}\AppData\Roaming\Subversion\config
- Windows (registry-based) -
Software\Tigris.org\Subversion\Config\Miscellany\global-ignores in both HKLM and HKCU.
- Linux/Unix -
~/.subversion/config
2 - The svn:ignore property, which is set on directories (not files):
- This is stored within the repo, so other users will have the same ignore files. Similar to how
.gitignore works.
svn:ignore is applied to directories and is non-recursive or inherited. Any file or immediate subdirectory of the parent directory that matches the File Pattern will be excluded.While SVN 1.8 adds the concept of "inherited properties", the svn:ignore property itself is ignored in non-immediate descendant directories:
cd ~/myRepoRoot # Open an existing repo.
echo "foo" > "ignoreThis.txt" # Create a file called "ignoreThis.txt".
svn status # Check to see if the file is ignored or not.
> ? ./ignoreThis.txt
> 1 unversioned file # ...it is NOT currently ignored.
svn propset svn:ignore "ignoreThis.txt" . # Apply the svn:ignore property to the "myRepoRoot" directory.
svn status
> 0 unversioned files # ...but now the file is ignored!
cd subdirectory # now open a subdirectory.
echo "foo" > "ignoreThis.txt" # create another file named "ignoreThis.txt".
svn status
> ? ./subdirectory/ignoreThis.txt # ...and is is NOT ignored!
> 1 unversioned file
(So the file ./subdirectory/ignoreThis is not ignored, even though "ignoreThis.txt" is applied on the . repo root).
Therefore, to apply an ignore list recursively you must use svn propset svn:ignore <filePattern> . --recursive.
- This will create a copy of the property on every subdirectory.
- If the
<filePattern> value is different in a child directory then the child's value completely overrides the parents, so there is no "additive" effect.
- So if you change the
<filePattern> on the root ., then you must change it with --recursive to overwrite it on the child and descendant directories.
I note that the command-line syntax is counter-intuitive.
- I started-off assuming that you would ignore a file in SVN by typing something like
svn ignore pathToFileToIgnore.txt however this is not how SVN's ignore feature works.
3- The svn:global-ignores property. Requires SVN 1.8 (June 2013):
- This is similar to
svn:ignore, except it makes use of SVN 1.8's "inherited properties" feature.
- Compare to
svn:ignore, the file pattern is automatically applied in every descendant directory (not just immediate children).
- This means that is unnecessary to set
svn:global-ignores with the --recursive flag, as inherited ignore file patterns are automatically applied as they're inherited.
Running the same set of commands as in the previous example, but using svn:global-ignores instead:
cd ~/myRepoRoot # Open an existing repo
echo "foo" > "ignoreThis.txt" # Create a file called "ignoreThis.txt"
svn status # Check to see if the file is ignored or not
> ? ./ignoreThis.txt
> 1 unversioned file # ...it is NOT currently ignored
svn propset svn:global-ignores "ignoreThis.txt" .
svn status
> 0 unversioned files # ...but now the file is ignored!
cd subdirectory # now open a subdirectory
echo "foo" > "ignoreThis.txt" # create another file named "ignoreThis.txt"
svn status
> 0 unversioned files # the file is ignored here too!
For TortoiseSVN users:
This whole arrangement was confusing for me, because TortoiseSVN's terminology (as used in their Windows Explorer menu system) was initially misleading to me - I was unsure what the significance of the Ignore menu's "Add recursively", "Add *" and "Add " options. I hope this post explains how the Ignore feature ties-in to the SVN Properties feature. That said, I suggest using the command-line to set ignored files so you get a feel for how it works instead of using the GUI, and only using the GUI to manipulate properties after you're comfortable with the command-line.
Listing files that are ignored:
The command svn status will hide ignored files (that is, files that match an RGA global-ignores pattern, or match an immediate parent directory's svn:ignore pattern or match any ancesor directory's svn:global-ignores pattern.
Use the --no-ignore option to see those files listed. Ignored files have a status of I, then pipe the output to grep to only show lines starting with "I".
The command is:
svn status --no-ignore | grep "^I"
For example:
svn status
> ? foo # An unversioned file
> M modifiedFile.txt # A versioned file that has been modified
svn status --no-ignore
> ? foo # An unversioned file
> I ignoreThis.txt # A file matching an svn:ignore pattern
> M modifiedFile.txt # A versioned file that has been modified
svn status --no-ignore | grep "^I"
> I ignoreThis.txt # A file matching an svn:ignore pattern
ta-da!
Best Answer
No! Bad developer! No donuts for you!
Permissions on Windows is very tricky, especially if shared drives are involved. You should not use the
file://protocol in this instance. You will have problems with permissions. I don't even use thefile://on Unix systems even as my private repository. I always launchsvnserveand usesvn://as a protocol.It's simple to setup
svnserveon Windows as a Windows service. There are quite a few Windows packages that pack Apache httpd and Subversion together, and then automatically setup almost everything for you. There is no reason to use a shared drive on Windows and use thefile://protocol.Check the permissions of all files and subdirectories in your repository. Even though you are the only person using this repository, there is probably a permission issue somewhere. Then go ahead and set everything up as a service.