I have a large Subversion repository with nearly 15 GB of data spread across ~500,000 files. Now I need to check out this repository to a remote host which would take days to complete.
The host I'm checking out to already has a complete copy of the data in the repository. But seeing as the files weren't checked out directly from the repository, they do not constitute a working copy (no ".svn" folders).
I'd like to avoid copying all this data across the network, especially when it already exists on the target host. Is there a trick I can use that will turn a preexisting directory into a working copy without replacing the local files with identical copies from the repository?
Moving files and folders select the files or directories you want to move. right drag them to the new location inside the working copy. release the right mouse button. in the popup menu select Context Menu → SVN Move versioned files here.
The easiest way to copy files and folders from within a working copy is to use the right drag menu. When you right drag a file or folder from one working copy to another, or even within the same folder, a context menu appears when you release the mouse.
Right click on the checked out folder, then use TortoiseSVN → Repo-Browser to bring up the repository browser. Find the sub-folder you would like to add to your working copy, then use Context Menu → Update item to revision....
svn Getting started with svn Checking out a working copy Your local copy of the project is called a working copy in Subversion and you get it by issuing the command svn checkout <URL> where <URL> is a repository URL. e.g. Alternatively, you can use svn co <URL> as a shorthand in order to checkout a local copy.
As of SVN 1.7 (but not before) you can do this easily with:
svn co --force http://path/to/repo
This will respect the local copy as existing, and you'll see the "E" for existing before each file name in the output: E some/existing/file
If the file is different (new or modified) from the repository it will handle that gracefully too according to the book:
Prior to version 1.7, Subversion would complain by default if you try to check out a directory atop an existing directory which contains files or subdirectories that the checkout itself would have created. Subversion 1.7 handles this situation differently, allowing the checkout to proceed but marking any obstructing objects as tree conflicts. Use the --force option to override this safeguard. When you check out with the --force option, any unversioned file in the checkout target tree which ordinarily would obstruct the checkout will still become versioned, but Subversion will preserve its contents as-is. If those contents differ from the repository file at that path (which was downloaded as part of the checkout), the file will appear to have local modifications—the changes required to transform the versioned file you checked out into the unversioned file you had before checking out—when the checkout completes.
Also note that SVN 1.7 can lead to situations where this a more common problem (perhaps motivating the solution). I hit this problem when moving a sub directory to a new location on disk. In pre-1.7 that would have moved the .svn
directory with it and it would have stood alone just fine. In 1.7 the directory became effectively unversioned. But svn co --force
saved the day.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With