What's the least painful way to transfer local Subversion changes to another machine?

Question

I'm working on a change on my laptop. It's not ready to be submitted to repository yet but I'd like to keep working on my desktop too. My change set is quite big and not only it contains modifications, it also contains new files and deleted files as well.

I could copy the complete local working copy to another machine and get the changes in place. However it sounds like a dirty solution (because I'm polluting metadata on another machine), and I'm transferring build artifacts unnecessarily too.

I tried transferring .patch files using TortoiseSVN but it keeps complaining about "patch belongs to an older revision" (not true and why do you care?) or "lines do not match" (yeah they don't because i changed them). I didn't like "continuous error popups" experience at all.

I don't want to install Cygwin, so command-line patch is out of question.

I guess the last option would be forking a new branch for this feature and go into a loop of "checkin/update". However these are shown in trac history creating pollution there.

Any better ideas? Or anything I'm missing?

Answer 1

Branching is the clean solution. And has the additional advantage of giving you a backup while you're working on this huge change. Not to mention, easy synchronization of future changes between machines.

But, you can probably get away with just zipping up the whole working directory and dumping it somewhere on the other machine.

Answer 2

I would create a temporary branch for this purpose. This way, you are only using SVN tools at your disposal and you are not polluting the meta-meta or copying the artifacts.

In addition, it looks like you are checking in your code at spaced interval and having a branch will also prevent data loss in case your hard drive crashes.

Answer 3

Not the last option, the first: You should have created a feature-branch already long ago, if there are really so many changes.

You can do this still by doing a svn copy from working-copy to branch-directory on server, so you do not need a "loop of checkin/update", just one checkin, just one update/switch, really.

Like svn copy MyWorkingCopy svn://theserver/project/branches/features/my-feature-branch

Answer 4

Well, most people would argue that if your "change set is quite big" you should definitely check the changes in (in a branch in necessary)!

Answer 5

Have you tried creating a new branch and using svn switch. It will transfer you to a different part of the repository and maintain your changes if you branch from your initial working revision.

Answer 6

As for alternate approaches, you could add GIT to the mix. GIT's distributed source code control model would allow you to push changesets back and forth between your desktop and laptop. And since GIT manages its changeset information on the local filesystem the commits that you're making on either side wouldn't appear in the stream that your TRAC system is monitoring.

So, you basically go 'offline with subversion' and complete your work using GIT commits. Once you're done, check in the whole kit and kaboodle to your subversion trunk.

Feature branches are lightweight in Subversion and are perfect for insulating feature specific work like this. If you're using subversion 1.5 or greater then the whole syncing and merging process is much easier than it was with 1.4.

Answer 7

If you just need a replica on your desktop, I find that Live Sync works perfectly for that scenario. I have it set up to replicate my checkout folder on my laptop and two desktops, which gives me exactly the same state on the three machines. And it all happens continuously on the background.

Or you could go for a branch and make sure you don't forget to commit any changes on the laptop before you move to the desktop. :-)

EDIT: In reponse to the comment - yes, it is possible to get in trouble if you start editing files while the two machines are in the process of synchronising. The worst that can happen is to loose some edits on one of the machines. In practice, the chances for this to happen are quite small.

Answer 8

You can try SVK. From the blog post and SVK site, Typical SVK usage scenario is

• mirror existing remote repositories,
• then create branches on your machine,
• locally work on these branches , and
• when you are done, merge them back into your mirrored trunk,
• the last step will transparently updates the remote repository.

I don't have any hands-on experience of using SVK. But I think it matches your scenario. This blog post describes it in more details http://www.bieberlabs.com/archives/2004/11/30/using-svk/

I think a windows version of SVK is available (SVKWin32) and TortoiseSVN can then use the local mirror of repository for update/commits.