Ask HN: Transitioning / Habituating myself to use a Version Control System | Hacker News Reader

Ask HN: Transitioning / Habituating myself to use a Version Control System

3 pointshypr_geek5 comments

Hi,

I've been developing for Android for almost a year now, and a couple of days ago, I read some posts by Zach Holman & HN comments on those articles, and got me thinking if using a VCS while being the sole developer is really productive.

What I've been doing till now is, use eclipse to export the project to a folder on every release, and place a txt file with changes in the folder (an ancient technique). I just copy-paste the project if I ever need to revert back (done only once), but I wonder if I should get used to using proper revision system. I was in an IT (services) company (quit in 2010) where we used Visual SourceSafe (doubt if anyone uses this) during the initial training.

I've finally zeroed in on Mercurial (mostly coz I use AndEngine, and its on Mercurial, if it works for Nicolas, it should work for me :]), and would like to know if anyone has some dos and donts to use it efficiently, while keeping my focus on development instead of getting overwhelmed by the vcs.

Thanks. :)

I've been using Git for version control for all of my own personal projects as a sole developer. I've heard that Mercurial and Git are very similar, and your reasoning for choosing Mercurial is very similar to my own choice of Git :-)

I like Git because I can easily track changes, see what I've done since the last time I commit (which is pretty often), and also keep separate branches for different sets of functionality without crossing over. I do mostly web development, so I will often start working on a new feature or a big change, only to be pulled off to fix a bug or add a smaller, more urgent feature, and push those live before finally getting back on track and finishing up. Using Git branches for all of those separate trains of thought helps me to keep things straight, and to be able to move quickly and easily between them.

As far as disciplining yourself to continually check into version control, maybe I'm too paranoid, but I used to always find myself creating copies of files before making big changes to them, just to be safe, or commenting out code instead of deleting it, because I might need to reference it again. Once I started using version control I broke myself of those coding habits, now I delete when something needs to be deleted, I overhaul files when they need overhauling, and commit regularly enough that if I ever need to look back at or restore a previous version of a file I can do so easily (and with date/time stamps!) Also, because I'm building a business around my software, it's nice to know that if/when I bring on other developers I will have a long history of the work I've done.

Good luck!

I've been using Git for version control for all of my own personal projects as a sole developer. I've heard that Mercurial and Git are very similar, and your reasoning for choosing Mercurial is very similar to my own choice of Git :-)

I, too, thought about using git and github to host my code, but then found that github is free for open-source projects only and the generally accepted notion looked like git was more powerful but required more time to learn. This also lead to me try out Mercurial.

And the tutorials at http://www.hginit.com really made it look easy to get into.

As far as disciplining yourself to continually check into version control, maybe I'm too paranoid, but I used to always find myself creating copies of files before making big changes to them, just to be safe, or commenting out code instead of deleting it, because I might need to reference it again.

This is exactly I am (almost) right now. My code has a lot of previous code I've just commented instead of deleting, just because I thought I might need them again, or the new code wont work. Like, when I'm trying to do the same thing using more optimized solution. I guess using version control helps me get out of this habit. :)

Thanks for your reply. :)

I've very recently had to have a bit of a holy war with a friend of mine over the merits of a VCS.

We were collaborating on a small project, he doing the front end work and I doing the middle and backend. He is not a developer in any sense of the word; WordPress Assembler is more of an apt description. He had never needed to use, nor came across any reasons demonstrating a need for, a VCS.

Trying to get him to realize why it was such a good idea is still an ongoing battle, but I eventually won him over with the following argument:

"Just take my word for it. I can sit here and keep trying to hammer home the same points, over and over, and you'll sit here and keep denying them. So lets just stop this, and you just take my word for it. This project is going to live in source control. If you hate Mercurial and want something simpler, we can switch to something else. But you aren't getting away from this. And any projects we do in the future, will ALSO be in source control. So you may as well make peace with it now."

The thing I believe he was really missing, and that we (I) haven't implemented yet is a continuous integration solution, with simplified deployments directly from the checked in source. His major gripe about not developing directly on the production server was the time it took to see changes. Which is a little silly, but when I look at it from his perspective, I can see his point. If I had taken the time to set that up from the start, he would've seen the benefit of it more immediately.

The moral of my story? Always use some kind of VCS. It may seem like a waste of time with just yourself on the project, but you'll always know for sure you have a copy of your work, safe and sound, accessible from anywhere you need it from. Just make it a part of your life, and before you know it, the "overhead" of using one will more or less disappear from your life. It's an essential building block to a successful project.

I can completely see how, if you had been forced to use VSS for anything, you'd see VCS as something that could get in your way. VSS was/is a blight.

Trying to get him to realize why it was such a good idea is still an ongoing battle, but I eventually won him over with the following argument:

"Just take my word for it. I can sit here and keep trying to hammer home the same points, over and over, and you'll sit here and keep denying them. So lets just stop this, and you just take my word for it. This project is going to live in source control. If you hate Mercurial and want something simpler, we can switch to something else. But you aren't getting away from this. And any projects we do in the future, will ALSO be in source control. So you may as well make peace with it now."

No offence, but I do not think that's called winning over. It's more like he was forced and who knows, he might still be doubting or having apprehensions about using it.

The thing I believe he was really missing, and that we (I) haven't implemented yet is a continuous integration solution, with simplified deployments directly from the checked in source. His major gripe about not developing directly on the production server was the time it took to see changes. Which is a little silly, but when I look at it from his perspective, I can see his point. If I had taken the time to set that up from the start, he would've seen the benefit of it more immediately.

I'm afraid I don't really understand this point, can you give an example? I thought everyone can pull one's own copy, make code changes and check out their output/results, and if all's good, just merge/save into main mercurial repository.

The moral of my story? Always use some kind of VCS. It may seem like a waste of time with just yourself on the project, but you'll always know for sure you have a copy of your work, safe and sound, accessible from anywhere you need it from. Just make it a part of your life, and before you know it, the "overhead" of using one will more or less disappear from your life. It's an essential building block to a successful project.

Well said, I do intend to make it a part of my life, as I don't think I will always be working alone. :)

I can completely see how, if you had been forced to use VSS for anything, you'd see VCS as something that could get in your way. VSS was/is a blight.

It wasn't that bad, but I didn't have an "oh, this is so radical" kind of moment when I first used it (even though it was). I mean, I was used to taking backups with text file of changes, as I previously mentioned. I guess such an automated system would show its true potential when working in a team, or collaborating over the net.

Well, thanks for your thoughts. Appreciate it.

Well, you're right about one thing: I haven't really "Won" the argument with him. He's a bit of a stubborn guy (as am I), and until it really "clicks" for him, I know hes not going to see the benefit. Since he isn't really a developer, and he isn't using these systems day in and day out, he doesn't have nearly as much of a chance to really understand the benefit; Which is why I finally just took the tone of a stern parent and told him he was going to wash his hands before dinner whether he liked it or not, and one day hed thank me.

I honestly believe I'd be doing him a disservice to let him think it was ok to develop straight on the production machine, and that VCS just "got in the way", and so I'm happy to butt heads with him over this all day long.

About your second point, what I meant there wasn't about how Mercurial worked, it was about what I had called the "missing leg" of the table: Continuous Integration. He was upset because, when developing live on the server, he immediately got to see his changes. Now, he had to commit them, then pull them down onto the server, and copy them into the deployment directory manually. To him, this is a complete waste of time. So had I set up some kind of CI solution by which new builds could be run automatically upon checkins, and a copy of the built artifacts deployed onto the server directly, we could have a test deployment that he could access and see changes almost instantly on, before moving the approved changes over to the main site (This is still very much a work in progress, and so the deployment site is little more than a test bed in and of itself right now).

I feel if I had taken the time to set that up from the get-go, he would have had a much more positive reaction than to call VCS "needless overhead".

He is also very much "anti-cloud", and the concept of storing our repository in BitBucket gave him hives. So all in all, he's completely out of his comfort zone with this project.

Reply on news.ycombinator.com