Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Why do you want/need to use portable storage? –  Bernard Jan 16 '12 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 Jan 16 '12 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 Jan 17 '12 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) –  voroninp Nov 18 '12 at 19:12

4 Answers 4

up vote 30 down vote accepted

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.

share|improve this answer
8  
And if you used github, you wouldn't even have to carry around a USB drive –  CamelBlues Jan 16 '12 at 20:54
    
Thank you. Can it be setup to use a portable storage as the repository? –  billpg Jan 16 '12 at 20:55
    
@billpg - Yes. It simply lives in a directory structure. –  Oded Jan 16 '12 at 20:56
    
@CamelBlues or bitbucket or kilnhg or probably various others that may or may not be appropriate... –  Murph Jan 16 '12 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). –  David Thornley Jan 16 '12 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.

share|improve this answer
    
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). –  Jason Lewis Jan 16 '12 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 Jan 17 '12 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.

share|improve this answer
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. –  Mike Baranczak Jan 17 '12 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. –  Keith Thompson Jan 17 '12 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. –  Mike Baranczak Jan 17 '12 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. –  Keith Thompson Jan 17 '12 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.

Note:

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.

share|improve this answer
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 Jan 17 '12 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 Jan 17 '12 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 Jan 17 '12 at 18:58
    
I'm not sure what this answer adds that I didn't already say in mine. –  Keith Thompson Jan 17 '12 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 Jan 18 '12 at 10:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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