I develop personal projects on two machines without use of a shared server or a network connection between the two.

Do any common version control systems reliably support use of portable storage (such as a USB flash device) as the shared repository?

  • Why do you want/need to use portable storage?
    – Bernard
    Commented Jan 16, 2012 at 20:46
  • To move code between two machines in the same way that a normal version control system does with a shared server. (I don't have a shared server.)
    – billpg
    Commented Jan 16, 2012 at 20:48
  • I used to use a set of mercurial repositories on a USB flash drive to update manufacturing tools in the factory and it worked really well. You could even see when technicians on site had been modifying the code on the local machine, while you were away, and merge in (or reject) their changes before synchronising their changes back to the flash drive.
    – Mark Booth
    Commented Jan 17, 2012 at 15:13
  • It's already said here that SVN supports local storage and you can use usb. But I prefer to store it's DB in my private DropBox folder ;) You can also use many free services (like assembla or tfs.visualstudio.com) Commented Nov 18, 2012 at 19:12

4 Answers 4


Use a DVCS such as Git or Mercurial.

Distributed version control systems do not have a shared central server.

With a DVCS, every copy of a repository holds the complete history - everything. This means, that when used on a USB key any changes you make are make to the repository on the USB key and when moved between computers will hold this history.

  • 9
    And if you used github, you wouldn't even have to carry around a USB drive
    – CamelBlues
    Commented Jan 16, 2012 at 20:54
  • Thank you. Can it be setup to use a portable storage as the repository?
    – billpg
    Commented Jan 16, 2012 at 20:55
  • @billpg - Yes. It simply lives in a directory structure.
    – Oded
    Commented Jan 16, 2012 at 20:56
  • @CamelBlues or bitbucket or kilnhg or probably various others that may or may not be appropriate...
    – Murph
    Commented Jan 16, 2012 at 21:36
  • 3
    I've got my main personal Mercurial repositories on DropBox. Works great, and automatically implements backup (since DropBox is unlikely to go away at the same time that I lose all my computers). Commented Jan 16, 2012 at 23:04

Apart from GIT, Mercurial etc suggested above, also have a look at Fossil - It has the advantages that the run time binaries are small (1Meg or so for Windows and Linux), portable and zero installation needed. Therefore unlike the others (as far as I am aware of) it can be put onto the storage device and run on any machine the storage is plugged into, without first having to install the app on the machine. It includes a Wiki and change/defect tracking system with the repo. It also has a gui built in.

I have not used it seriously (I mostly use GIT), but was impressed by it's light weight approach and the inclusion of a Wiki and defect tracker makes it ideal for small projects. My only concern was that some of the more powerful features of GIT may not be possible, and unlike GIT, the user community is not so large that it's easy to find answers to questions.

  • Although Git takes the Unix commandment to do one thing and do it well seriously, you can have these features in Git through extensions like ticgit (ticketing system) and gollum (repo-based wiki). Commented Jan 16, 2012 at 23:24
  • @Jason Lewis: You are correct, and as it's open source, you can just modify it to meet your requirements anyway, so GIT (or any other tool) can be everything to anyone (who can be bothered, has the spare time and resources to download, install and debug all the "plugins". All I was saying is for a solution that "Just works out of the box", it's worth considering Fossil.
    – mattnz
    Commented Jan 17, 2012 at 0:35

Using a DCVS is probably a good idea, but it's not the only option.

I have a small CVS repository on a USB thumb drive. When I want to access it, I just need to use cvs -d <path> or set $CVSROOT to the path of the root of the repository (which of course requires the thumb drive to be mounted on the system).

If you're already accustomed to use CVS, this should be workable. The same should apply to SVN. It just means your central repository is on the thumb drive, and isn't always visible.

There are arguments for using a DCVS rather than CVS in general. I don't think those arguments are particularly affected by whether the central repository is on a thumb drive or somewhere else. For example, you could just as easily create a git repository on the thumb drive.

  • 1
    I'm normally not a huge fan of DVCS, but I think DVCS would be better in this case. The problem with non-distributed VCS is that the repo is a single point of failure. If it's sitting in a climate-controlled data center and gets backed up regularly, that's not a big deal - but something like a thumb drive will get lost (or stepped on, or eaten by a dog, or dropped into a White Russian) sooner or later. Commented Jan 17, 2012 at 3:45
  • 1
    @MikeBaranczak: Good point -- but anything on a thumb drive should be backed up regularly, whether it's a CVS repository or not. Commented Jan 17, 2012 at 4:15
  • with a distributed system, each client already has a full copy of the repo. So there's no reason for a separate "back up" procedure. Commented Jan 17, 2012 at 22:04
  • 1
    @MikeBaranczak: Sure, that's a good reason to use a DCVS. My point is that the choice of a DCVS vs. a centralized system doesn't depend on whether you're using a thumb drive or not. Commented Jan 17, 2012 at 22:06

As an addition to the other answers:

While a DVCS fits this problem very well, you could technically also use Subversion, if you feel more comfortable with it. Subversion can use a local directory instead of a central server. You could just put that onto a thumb drive, and use it.

The disadvantage, compared to a DVCS, would be that you can only work with Subversion (i.e. commit, view logs etc.) while the thumb drive is plugged in. Also, it must always be the same thumb drive (or at least an up-to-date copy), because with Subversion you should not use more than one repository (that's the non-distributed part). So if you ever forget your thumb drive, you can't use it, unlike with Git or Mercurial.


As explained above, and in the comments, a DVCS is really a better fit for your problem. I only mentioned Subversion for completeness sake, and in case you have some special reason to use Subversion.

  • 1
    As with Keith's answer, the problem with a VCS in a local directory is that it is a single point of failure. Also, if you move from machine A to machine B but leave the thumb drive plugged into machine A, then you are much less likely to care if you are using a DVCS (you can always merge in your local changes later) whereas with a VCS, you would have to go back to mechine A, get the drive and go back to machine B before you could continue.
    – Mark Booth
    Commented Jan 17, 2012 at 15:32
  • @MarkBooth: I'm not advocating this solution, I just wanted to point out it exists, for completeness sake and in case OP has some special preferences for Subversion. I edited my answer to make this clear.
    – sleske
    Commented Jan 17, 2012 at 17:15
  • Thanks @sleske, I agree that a preference for svn (or indeed Cvs) could weigh in favour of using that solution, but in the interests of full disclosure, the downsides of that approach should also be mentioned. Feel free to edit the points from my comment into your answer. If you do, I'd be happy to clean up (delete) my comments. *8')
    – Mark Booth
    Commented Jan 17, 2012 at 18:58
  • I'm not sure what this answer adds that I didn't already say in mine. Commented Jan 17, 2012 at 22:06
  • 1
    @KeithThompson: It adds the information that SVN can use a local directory instead of a central server. That is explained in the SVN docs, but since most people use SVN via a central server, it might not be obvious that SVN does not require a server.
    – sleske
    Commented Jan 18, 2012 at 10:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.