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've already read If you use multiple computers, how do you sync everything? - but that was off topic... I am specifically thinking about this from a programming side.

I have powerful desktops at home where I do personal projects and work where I obviously do work related projects... I also have a laptop that I use for programming when I get the chance.

I use dropbox and other sync tools for the majority of my work, but, I have found no decent solution for programming projects.

Recently, I started to use GIT and whilst I like it for source control, I don't like pushing in tiny changes as it feels a waste when there hasn't been many significant changes.

So, I am just looking for some advice, people who work with multiple computers - how do you effectively develop on multiple machines?

I am thinking at present that keeping my working folder in Dropbox may just be the easiest solution, however, I can't help but feel there is a better solution out there.

share|improve this question
    
how this question is different from one you mention? –  gnat Dec 25 '13 at 16:03
    
Because I felt that the one I linked to was someone who has never synced anything before and I am specifically looking for an answer relating to programming from people who actually do it... I feel like github/similar aren't really a good solution for minor changes as I said here... I have never seen a good solution and there must be one! –  wilhil Dec 25 '13 at 16:16
18  
"I don't like pushing in tiny changes as it feels a waste" - honestly, this is clear sign of beeing unexperienced with version control. The smaller the commits, the better! Overcome your "feelings" and your problem is solved. –  Doc Brown Dec 25 '13 at 21:00
    
@Doc Brown - I am seriously inexperienced with version control, but, I am fine with checking in actual changes all be it small... it just doesn't seem right to check in tiny things... e.g. If I am on a train, I am in the middle of making a change and almost home - I want to finish the bit on my home pc and then check in... Version Control helps me to go back and find changes, it seems a waste of time if I need to find an old version of something and have 300 versions where there were tiny little non important changes :/ but, maybe I am just using it wrong... –  wilhil Dec 25 '13 at 22:54
1  
@wilhil Also look at tags and how people do versioning with git –  Izkata Dec 26 '13 at 17:22
show 2 more comments

6 Answers

DocBrown is right. Version control should be your everything.

If you have minor changes that are not ready for your main branch, then create a new short-lived branch. Pull the short-lived branch from your other computer and continue on with your work. Once the short-lived branch is ready, merge it back to the main branch and delete the short-lived branch. See Git Branching - Branching Workflows for more details.

You should never put your self in a situation where you need to merge in changes from your previous history. Merging multiple HEADs is hard enough, don't make the pain worse for yourself.

share|improve this answer
    
Beside version control for source code and the like, it's nice to have a web-based collaborative text editing tool (like e.g. Google Drive, or something simpler) to edit texts together in real time. Imagine videoconferencing and creating a tech design doc across continents. A good videoconferencing tool helps much in general, additionally to an always-on chat room / IRC channel and regular IM and email. (Disclaimer: I worked remotely a lot, with people all over the globe.) –  9000 Dec 26 '13 at 4:47
add comment

I think you'll find many opinions about how to do this, because most developers feel chained to their desk and want more freedom of when/where they work.

The solution is not simple.

There are problems in keeping two development machines usable:

  1. It completely depends upon the type of development you're doing, and how complex your build process is.
  2. Syncing source code is the easy part, but it has to be synced. Many times I've picked up my laptop and gone out the door to only find that it requires a large update to the source code. That can sometimes not be practical to do while on the go.
  3. Keeping your tools versions matched between machines is a real pain, and productivity is lost if you're laptop takes 10x longer to compile.
  4. You have to remember to keep the laptop in a ready state. If you leave it turned off on your shelf for a week or more. Don't expect to be able to just grab it and go.
  5. Databases... omg. Don't get me started on the problems of syncing databases.

The only solution that has consistently worked for me is remote desktop. I can take a lightweight low-feature laptop to a location with WiFi and connect to my desktop remotely. This allows me to effectively continue working right from where I left off. You are only limited by data connectivity issues.

Some wireless providers offer LTE data connections for $10 per month. You could buy a Google Chrome book, and remote desktop into almost any kind of desktop setup. LTE is very fast with little latency, plus these laptops often have a 10 hour battery life.

Still you are limited to your bandwidth caps.

share|improve this answer
1  
+1 for pointing out that there's more to synching than just the source code. I generally use remote desktop / VNC in this situation too. Heavy duty cutting and pasting is sometimes a bit slow, but it works well overall. –  user949300 Dec 26 '13 at 16:02
    
I actually use RDP to develop every day at work. Our development boxes are about 70 miles away. The only time I have any issues is developing from home if my bandwidth drops I get some delay. On cable internet but through a VPN. Still a viable solution. –  Rig Dec 26 '13 at 16:17
add comment

On one side, committing more often is a really good practice. Still, sometimes things are too half-baked, you're in the middle of a concept, so it might not be a good moment to commit but you want to switch machines.

What I do is to sync most of my /home/ directory. In particular, the whole ~/devel/ subtree. Your problem is that dropbox is really a very sub-par sync method.

What I currently use is Unison. Another interesting option I'm currently evaluating is Bittorrent Sync.

The great thing with both of these is that you don't have to keep a copy on somebody else's server, so the size limitation simply disappears. Also Unison uses the rsync protocol, making it immensely more efficient than the naive file copy used by dropbox.

share|improve this answer
    
Another vote for Unison. It's fast enough that I can even sync remotely over the internet. –  Alan Shutko Dec 26 '13 at 16:46
add comment

I am in favour of using your VCS (in this case Git) to maintain all your source code. In your specific scenario I would commit my changes switch computers, pull the changes and start off from where I left. There are several reasons why this is better than using a file synch solution -

  1. Git is very good at tracking changes to content. This means that it is quite efficient at saving just the specific changes to the files rather than the entire file itself. This translates to efficiencies in space and bandwidth savings and better performance.
  2. Git is good at detecting conflicts and provides tools for you to go through and selectively resolve them. This would be more of a problem if you are working with others on the code but even when working on your own you might have made a few minor fixes in one machine that you missed or you forgot to pull into the other. Git is better at tackling this sort of thing than Dropbox for example.
  3. Your main concern about committing in every small change leading to messy commit history can be easily addressed in Git. You have powerful tools to rewrite your history - checkout git squash and git rebase - http://git-scm.com/book/en/Git-Tools-Rewriting-History

Having said that VCS is good for maintaining source code, its bad at maintaining certain types of files. The main scenarios arise when you have to deal with binary files like images, videos etc. Putting this in Git is inefficient as it cannot save just the differences in the different versions of these files and it ends up keeping copies of the whole file in the repo. In this case having an rsync or dropbox like solution (unison is a great option as well) is the way to go.

I use a mix of the two solutions and it works for me mostly. The main dependency in these solutions is that you need good internet so you can sync seamlessly. Otherwise it becomes a pain.

share|improve this answer
add comment

Source control.

If your IDE is the bread and your source code the butter. Then source control is very much the butter knife.

Using your knife

Distributed source control like Git and Hg makes branching incredibly easy. Take advantage of that. Create a named branch and track even your smallest changes on that branch. When you're done working for the day push that branch to the repo. Is your database schema in source control? It should be. Do you have scripts you run to populate test data? They should be in source control too. If you do all that your current work is always available to you on any machine.

Other Tips and Tricks

  • When you keep every change, no matter how small, in source control it gives you several points in time to rollback to if necessary. Don't underestimate that convenience.
  • Don't forget, not only is your work always at your fingertips, it can easily be pulled by coworkers too.
  • Don't know what language you're working in, but try a framework like Migrator.NET on a project if it is an option. This makes versioning your database even easier and sets you up for even easier builds/deployments. For example, on one of my projects, deploying to production requires nothing more than pushing my source code into the correct branch.
  • Your own personal named branch is perfectly fine for any change you choose to push to it. The main development branch is a different story though, never push something there that will break the build.
  • Source control comments are you friend, and in my opinion, are far more useful than comments inside the source code.
share|improve this answer
add comment

I am in the same situation. I have a tower and a laptop, both running Linux. I use git for version control. However, like you said, pushing in small changes may seem frivolous.

One option that I have thought of although I have not implemented it myself is to use another computer as a version control server. A computer that could do this would not have to be very powerful.

The strategy that I have found works very effectively for me is to use multiple SD cards. I use these to sync files back-and-forth. It's a very small form factor as in they fit in your pocket very easily.

share|improve this answer
add comment

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.