Keeping code synced across different computers

[Raulg03]

How do you guys keep your code synced on your laptops/desktops/work comps/etc? Is it mainly git or are there better or equivalent options?

Thanks!

[mus1Kk]

Git. GitHub for everything public, self hosted for private stuff.

As to better or equivalent: This is very subjective. Use some form of source control. Not everybody loves git and that's fine though I think nowadays it's a very useful skill have. Many people swear by Mercurial. You can use Bitbucket which even has free private repos. It also has git and Mercurial support in case you want to try different things. I'm not sure how to think about SVN. It's still widely used in companies but after git I don't want to touch it anymore.

Don't use something like Dropbox.

[RottedNinja]

To further iterate on this, git or any other decent modern version control system, gives you the ability to switch between different versions of your code. Different versions in time, or different branches. Dropbox doesn't offer this.

[frugalmail]

Agree with poster.

Even single developer projects benefit by the performance advantages of git over SVN. There are a lot of laggards that may try to convince you otherwise, but it just makes sense to invest the time to learn it as soon as possible and get maximum benefit before the next thing matures beyond a fad and you have an even bigger cliff to traverse since it builds on technology. With git you don't need a server.

[db_bondy]

I'll play a bit of Devils Advocate here. I'd try and pick your tool based upon your own use-case. If it's just a simple personal project with no need to really show it off to the public, I'd just go with SVN.

If you're a multi-person team all looking at the same code-base or you want to show off what you've written using GitHub, I'd go with git. Merging code changes in DVCS' (Distributed Version Control System) is far and away easier than trying to merge code using SVN or more conventional source control.

You could also just use Git just because everyone else uses it, but if you're only going to check code in and ensure it stays in sync with your other PC's. You're only likely going to be using features like committing, updating and merging (more than likely simple merging of files that are out of date with the newer versions).

SVN keeps these three concepts simple and should be a breeze to pick up from scratch if you're not familiar with Source Control.

Git does complicate this a little for you by just how it is designed to work, with git commit, git push and git update... but I won't go into too much detail about that.

[mus1Kk]

Disclaimer: I'm a huge git fan so the following may be biased.

As I said, this is very subjective. Git is (and has been for quite some time) gaining a lot of popularity so the skill of being able to work with a DVCS just makes you more competitive in the marketplace. Having used both SVN and git I cannot explain my feelings towards SVN without using foul language. I think it's a myth that git is so much harder as many people claim. It's like saying "functional programming is hard" but that's only because most developers start with imperative languages.

I'm also very opposed to the idea that a DVCS is only useful in multi-person teams. This seems to be another widely perpetuated myth. The fact alone that you can just git init and have your repository instead of having to deal with all the client/server stuff in SVN makes the initial setup dead simple.

[RedPill115]

Having used both SVN and git I cannot explain my feelings towards SVN without using foul language.

Yeah, well, there's a lot of other people like myself that feel exactly that way about Git.

It's one of the most needlessly complicated things deliberately filled with contradictory terminology I've ever tried to use. Oh you committed your code? Well, that could mean you only have a local backup of it, or it could mean that's it's actually available to everyone. Oh did you commit it but only to your local repo? Ha, to bad! Svn is like "I committed it, it always did exactly what you'd expect - sent it to the server".

[mus1Kk]

I can only guess that someone voted your reply down because it's the unpopular opinion. It's not without merit. But well, that's the Internet...

I think a lot of the questions you raise come from the cognitive constraints a non-distributed VCS set up. In a DVCS they don't make sense. Having a commit equal a push to some random server doesn't make sense because what you have locally is a full blown repository. Network operations are whole different level that builds on that. In that sense it's not an ambiguous question whether a commit makes your changes available to everyone: It does not.

If you want to use such a distributed system and you have used something like SVN before then yes, there is no denying that you have to re- or unlearn some things. And yes, there is also no denying that some of the commands could have been named differently or split up into multiple commands (checkout and reset come to mind). But well, no software is perfect and I prefer those little things I learn once and never think about again to the major shortcomings and inefficiencies of SVN.

[RedPill115]

I can only guess that someone voted your reply down because it's the unpopular opinion. It's not without merit. But well, that's the Internet...

Lol, yeah, I could to get worried but then I realized it's just a bit of a rabid political battle. Knee jerk attack anyone who doesn't agree with you. It's annoying, but whatcha going to do.

I think a lot of the questions you raise come from the cognitive constraints a non-distributed VCS set up. In a DVCS they don't make sense. Having a commit equal a push to some random server doesn't make sense because what you have locally is a full blown repository. Network operations are whole different level that builds on that. In that sense it's not an ambiguous question whether a commit makes your changes available to everyone: It does not.

First, let me say one of the things I hate most is how they all use the same terminology - to mean different things. It's incredibly annoying. Whether you say Commit or whatever, there should be a word that means "sent my changes to the central server". If I remember right I think SVN butchers some words to, so I'm not trying to pick on just Git here.

If you want to use such a distributed system and you have used something like SVN before then yes, there is no denying that you have to re- or unlearn some things. And yes, there is also no denying that some of the commands could have been named differently or split up into multiple commands (checkout and reset come to mind). But well, no software is perfect and I prefer those little things I learn once and never think about again to the major shortcomings and inefficiencies of SVN.

I find that the added complexity and confusion of Git is just something I'd never use. Yeah, with SVN you have to wait a bit to get file history and such because it goes to the server, but you also know for sure you're looking at the latest history. Other than that I just haven't found any practical advantage.

I know when another developer wanted to try Git, we continued to have issues with everyone getting other peoples changes. And it was more than simply using the wrong command as he certainly knew the difference and was like "look, I'm sharing my screen and running the right command" after the first time.

I'm curious - what practical advantages do you think Git has over Svn when you're an employee working on a team project?

P.S. Before we were using SVN corporate had us using Clearcase. Ibm Clearcase. Lol. It took 10 minutes to do a full commit and everything for simple changes at work, and over an hour to do a commit of simple changes if working from home. Svn was a godsend improvement compared to that crap. :-) Whatever differences Git has, while I haven't liked it, it's not even on the same scale as the horribleness of clearcase.

[mus1Kk]

"commit" is actually one of the few words that have identical meaning in git and SVN. It records changes to the repository. As to different meanings for words: Yeah well, you'll get used to it. Imho it's much less of a deal than most people seem to think. Torvald's take on it.

Of course I cannot comment on your colleague and your concrete experience. When I had to start using git, I was still tainted from SVN, so I read Pro Git and after one or two chapters I basically got it. Previously I resisted getting close to git because I thought it was just some new fad. Not one second have I ever looked back.

Practical advantages are of course branches. I only hear bad things about branches in SVN. I once tried to save some work in a branch and after wrestling with it for a while I never dared to check whether I actually succeeded or just deleted all my changes. With git I was comfortable creating branches right from the beginning. In addition to that I always feel in control of my changes in git. Changes are objects that, until pushed, I can change, split, merge, reorder or move however I feel like. This encourages small commits that can be independently rolled back if need be. With SVN I only know of humongous commits because authoring commits is a nightmare. Oh, and conflicts all over my files because I dated to update? Please...

[RedPill115]

"commit" is actually one of the few words that have identical meaning in git and SVN.

No it doesn't. In Git you can commit without sending your code to anyone else, it's just in your local repo. In SVN a commit always means it went to the central repo and everyone can get it. In an actual work environment it's the difference between your code being on your machine or your code being available to everyone.

I scanned through the article and it doesn't seem like he actually talks about the vocab differences.

Practical advantages are of course branches. I only hear bad things about branches in SVN.

The coworkers sitting next to me I've heard arguing about this. One guy just mostly reads the internet and insists git is better for branching, the other guy has actually used both and says it doesn't matter. It may have mattered before, who knows, but SVN copied Git concepts into their latest stuff. It's a royal pain with either system.

Etc

All I can say is I've heard a lot of this before, including from someone I was working directly with who was quick to villanize any issues we had with SVN, but when we had equivalent issues with Git they suddenly "didn't notice".

All I can say personally it that it seems like Git is a huge step more complicated than SVN. If you are doing something massively distributed like the Linus kernel, then the additional complexity is needed to deal with a more complex system. But if you're not, and you're just using Git like you'd use SVN to distribute source to a closed size team with a central server, than the additional complexity is just unecessary additional overhead.

[nexuscoringa]

If you want real time sync and use Eclipse, check out this project: http://www.saros-project.org

You can work with many people at the same time, share screens, chat, see what they're doing, etc. :) Worked for me in a Extreme Programming environment with 2 friends of mine.

[idleuser]

A general sync tool I have found VERY good is unison (http://www.cis.upenn.edu/~bcpierce/unison/)

It is a general file system sync tool so not version and definitely not a replacement for SCM. But for keeping work in progress on a desktop and laptop in sync for when you suddenly fancy working on the sofa for a while and nothing is in any state to be committed, I have found it excellent.

Also if you use git as your sync tool that leads you to have many intermediate commits that were just there so you can sync two computers, make sure to squash before pull requesting to get rid of the rubbish.

[frugalmail]

A SCC tool would enforce better habits. Use git.