Ask HN - When is right time to start using version control for a project?
I've been working on an iPhone app for about a month and I'm waiting until I finish a key set of features before I put it under version control. I'm making so many big changes that I'd rather not keep track of them all yet. Regular Time Machine backups and archiving a copy of the code after implementing a key feature are the only things I'm doing at this stage.<p>I'm curious though, at what point in a project do you guys normally start using source control management (ie. subversion, git, mercurial)?
6 comments
Every single text file you use should be in version control! Git is great for this, handles large files nicely and it's very easy to setup backup scripts across multiple machines. The line about making so many big changes is total nonsense! Get your text files into version control and do it right now, I think you should really consider what kind of release engineering you are doing for your app. How are you doing code branches so you can do bug fixes on released versions of your software without including experimental new code if you're not in version control??? You should seriously look into branches for your software for this and automating your build process as much as possible, in the end you will be grateful for the meta-work done today.
I'm making so many big changes that I'd rather not keep track of them all yet
For what other reason is source control used but to maintain track of code changes like this!
Regular Time Machine backups and archiving a copy of the code after implementing a key feature are the only things I'm doing at this stage.
Then your using rudimentary source control anyway :) I'd switch to something more structured asap.
Im with the others: at the start. :) With hosting so cheap now (my choice is mercurial and bitbucket) and with private repositories barely a few clicks away there is no reason not to IMO.
For what other reason is source control used but to maintain track of code changes like this!
Regular Time Machine backups and archiving a copy of the code after implementing a key feature are the only things I'm doing at this stage.
Then your using rudimentary source control anyway :) I'd switch to something more structured asap.
Im with the others: at the start. :) With hosting so cheap now (my choice is mercurial and bitbucket) and with private repositories barely a few clicks away there is no reason not to IMO.
It sounds like the source control you are using has too much friction, setting up a Git repo and keeping it up to date is quick and easy so there is no reason not to do it right away.
Coding without source control is like using an editor without undo.
Use source control from the very start. Git is pleasant to use.
Use source control from the very start. Git is pleasant to use.
Yesterday.
If your version control system has so much overhead that putting code under VC is a chore or something to be put off and planned for, then it has a problem - and you need a new VCS, or at the very least, a new set of tools and workflows.
If your version control system has so much overhead that putting code under VC is a chore or something to be put off and planned for, then it has a problem - and you need a new VCS, or at the very least, a new set of tools and workflows.
Before you write your first line of code.
I'm probably not the only person on here who keeps any notes and planning documents for projects under version control. I also regularly import research notes into comments before I write the code in question, but I'm weird and I've been told I do too much design up front.
I'm firmly of the opinion that only 10% of writing software is typing code. I have all my text documents in git, experimental ideas, budget plans, everything. The only complaint I have is that I haven't figure a solid plan for doing encryption inside version control effectively yet, but I haven't tried too hard either.
Whole volume encryption works, although it can be a bit cumbersome.
How is the performance? I have no experience with whole volume encryption, do you have any useful links?
There are actually several ways to do this I use encfs which uses FUSE to mount an encrypted directory as another directory, the advantages are that it works in userland and it's braindead simple. I wouldn't want to run a database off of it, but for a bunch of text files it's perfectly adequate. A lot of people are fans of truecrypt and if you are seriously concerned about devoted efforts to get at high-value data you probably want to just encrypt the disk partition you are using.
This post http://www.debianadmin.com/filesystem-encryption-tools-for-l... has a fairly good introduction to the most popular flavours. It's going to vary depending on your needs.
This post http://www.debianadmin.com/filesystem-encryption-tools-for-l... has a fairly good introduction to the most popular flavours. It's going to vary depending on your needs.
Thanks for the article, there is lots of great info on there. I need to figure something out where I can make secure backups to some remote server. I guess there is no real perfect solution, but TrueCrypt looks good. I ran across this one talking about some deeper security constraints with this that I think offers a nice insight. http://www.schneier.com/blog/archives/2008/07/truecrypts_den...
No, you're not alone. I keep all my docs under version control and it has saved me more than once.
One interesting feature Google code has implemented is placing notes about the code in the web view of the repository.
I'd love to see this feature reach other SCM providersm, it's something i would use a lot.
I'd love to see this feature reach other SCM providersm, it's something i would use a lot.
I strongly disagree. It should be immediately after you write your first block of code :)
I have a hangup about every atomic commit needing to be a functioning version of the software. Following this logic, an initial commit that is just notes is not viable. Even if it's just some function/class prototypes that only 'raise NotImplementedError', the first commit has to do something you can execute.
I've noticed a trend of boilerplate projects on GitHub for people to use as a foundational branch, and I think that's terrific.
I have a hangup about every atomic commit needing to be a functioning version of the software. Following this logic, an initial commit that is just notes is not viable. Even if it's just some function/class prototypes that only 'raise NotImplementedError', the first commit has to do something you can execute.
I've noticed a trend of boilerplate projects on GitHub for people to use as a foundational branch, and I think that's terrific.
Yup.
$ mkdir newproject
$ cd newproject
$ git init
Initialized empty Git repository in /home/mbrubeck/newproject/.git/But you're not actually using version control (and newproject isn't a valid git repository) until you make a commit.
While that's a bit of git wonkery, it exposes an underlying truth about VC in general: You need to have something to commit to be using it. Whether you init the repository before or after the first file hits the disk is irrelevant.
While that's a bit of git wonkery, it exposes an underlying truth about VC in general: You need to have something to commit to be using it. Whether you init the repository before or after the first file hits the disk is irrelevant.