views:

42

answers:

2

Hi All,

I currently develop a lot of my work on my laptop while on train to and from work most days. But it is no way near as good or easy as my main machine at home. My issue is how to keep the files in sync. I use subversion but also have a CI Server that rebuilds on each check in. There is a question here that deals with multiple machines and says to use source control. But what if there is a CI server, this would lead to broken builds.

My first thought (which seems a bit daft) would be to use two sets of source control, or at least two repos for the same code. One for the CI server and one to transfer between machines. Not sure you can even do that with SVN. Was just looking at Mercurial after Jeol's blog. Not sure if this would be able to work as you still have the issue of pushing to central repo would be where the CI server pulls from.

I guess the crux is how do you share code that is still buggy or doesn't compile so you can switch machines, without braking the build?

Thanks

+2  A: 

You're actually on the right track with the multiple repository idea, but Subversion doesn't natively support this sort of thing. Look into using a so-called DVCS (Distributed Version Control System) such as Git or Mercurial, where you can have multiple repositories and easily share changes between them.

You can then push changes to the central server from either your desktop or your laptop machine, and your source control system will sort it all out for you. Changes that are not yet complete can be done on another branch, so if one morning on the train you write some good code and some bad code, you can push the good code up to the repository used by the CI server, and the bad code over to your desktop development machine, and carry on from the point you left off.

Greg Hewgill
Are you saying you can choose where you push the changes, so I don't have to just push to the central repo, I can choose where it goes? That would be cool!
Jon
@Jon: Yes, that's exactly right. DVCS *is* cool. :)
Greg Hewgill
Thanks Greg, just found this: http://www.selenic.com/mercurial/hg.1.html#push which explains it briefly, Mercurial here I come!
Jon
+1  A: 

What about branches? Develop on one branch and only reintegrate after you finished a piece of development?

Roald van Doorn
I already use branches. What happens if a bug is found on the trunk and I get half way through fixing it on the train and want to finish it on the decent monitor / machine. If I check it in I break the build, branching the trunk to fix the bug and then merge it back in for every change seems OTT, (also don't have net access on the train).
Jon
But is this bug only on the trunk and not any other branch? My guess would be to:1. Keep a second branch that you keep as much in sync with the trunk as you can.2. If you are on the train, you can fix stuff on this second branch.3. When you get off the train and into the office or home, you can commit on this branch, check it out on your decent machine and continue working on it, without breaking the trunk.This does however require you to switch your office/home machine to different branches.
Roald van Doorn
I see where your coming from. Seems like extra work (compared to DVCS), but if I had to stay with SVN that would seem like the sensible approach. Thx
Jon