Copying a directory that is version controlled

Question

I am curious whether it is OK to copy a directory that is under version control and start working on both copies.

I know it can be different from one VCS to another, but I intentionally don't specify any VCS since I am curious about different cases.

I was talking to a coworker recently about doing it in SVN. I think it should be OK, but I am still not 100% sure, since I don't know what exactly SVN is storing in the working copy.

However, if we talk about the DVCS world, things might be even more unclear, since every working copy is a repository by itself. Being faced with doing this in bzr now, I decided to ask the question.

Later edit:

Some people asked why I would want to do that. Here is the whole story:

In the case of SVN it was because being out of the office, the connection to the SVN server was really slow, so me and my coworker decided to check out the sources only once and make a local copy. That's what we did and it worked OK, but I am still wondering whether it is guaranteed to work, or it just happened.

In the bzr case, I am planning to move the "main" repo to another server. So I was thinking to just copy it there and start considering that the main repo. I guess the safest is to make a clone though.

Answer 1

I would suggest not, as you're circumventing the source control mechanism.

But perhaps you can explain 'why'?

Answer 2

You could also just check out two working copies (at least with SVN) to say work/copy1 and work/copy2 and work on the two versions in parallel.

I wonder though what it is you are trying to achieve, since copying may not be the best solution to your problem.

Answer 3

It will depend on the VCS. I know in CVS that it stores (hidden) directories inside every version-controlled directory. These files are, of course, then copied with any copy of that directory.

It's so frequently the case that you do NOT want to copy those hidden files that the rsync tool comes with an option (-C) to ignore these files the same way CVS does.

Answer 4

I do this occasionally in SVN and I haven't run into any problems. I believe that in SVN all that is stored is the original state of the directory and a pointer to the repository directory it came from.

So basically it works as you would think it should.

• If File1 in Copy1 changes and File2 in Copy2 changes both can commit
• If File1 in Copy1 changes and File1 in Copy2 changes whoever commits second will have an error and will have to update/merge first.

For those curious as to why I had to copy, I have had problems with checkouts over our network being very slow when first checking out one of our larger projects. By contrast, simply copying from another computer seemed to provide me with all the same benefits.

Answer 5

In svn, it's no problem. You can just working with the copy as if you had made a second checkout.

I'd recommend just checking out a second time, though. If you want a copy without the .svn files, svn export will create one.

Answer 6

I've had a few headaches with SVN when I've reorganized the folder layout from within Visual Studio. A folder moved within a solution will literally move the folder in the filesystem, including the hidden .svn folder. This causes commit problems because the .svn data is associated to the old path and I haven't found a way to reassociate to its new path. SVN clean up runs OK but fixes nothing. SVN switch doesn't allow you to change it after the folder was moved. I've only been able to fix this by deleting all .svn folders within the moved folder and its subfolders, then re-add the folder.

The problem I have with this fix is that you lose your version trail on those files because SVN sees it as brand new. Also, it doesn't store the file contents as efficiently by storing the diff from the previous version.

Per the SVN documentation, it is recommended to allow the svn client to do all your folder move/create/delete to keep everything in sync for the next commit. This isn't always acceptable from Visual Studio. Fortunately, most problem cases are caught during commit-time, particularly if you use TortoiseSVN.

Answer 7

In Subversion, every .svn folder has whatever is necessary for the containing folder. And since all local paths are stored as relative, you are safe while copying whole or partial trees outside the original checkout tree. They will continue to function in their new homes.

I frequently copy subtrees from my trunk outside, switch the new copies to other branches/tags and do whatever is necessary on the "cloned" local copies. This way, if, for any reason, I need to go back and do something in the trunk, I have an undisturbed trunk copy in the original location.

Copying source-controlled directories into other source-controlled trees, on the other hand, is unsafe. If you will be overwriting any .svn folders, you'll most probably be corrupting your target copies.

Answer 8

For SVN, this will generally work as others have already stated.

If you are copying between machines, you probably will run into trouble though. For example, if you are accessing your SVN repo using file:// repository URL, things will most likely break. Same applies to http:// or svn:// URLs where server access might be different.

To stay safe, I'd just to a checkout at the new location. If you have a lot of uncomitted changes in one that you want to have in the new working directory (generally a bad idea), you could then use rsync to copy your source across without bringing in the .svn directories.

Answer 9

For bzr, if you just copy the .bzr directory to another location, it'll work. It doesn't store any information about the path it's in or the host it's on, so you can copy it wherever and expect it to work out OK.

Answer 10

Seems to me like GIT might also serve your needs, as you mention being disconnected or over a crappy connection. GIT also has very nice SVN support so the two are complementary and you'll end up with a nice versioned file system.