When to start to use source control in early stages of development?

Question

We have 2 kinds of people at my shop:

1. The ones that starts to check-in the code since the first successful compilation.
2. The others that only checks-in the code when the project is almost done.

I am part of group 1, and trying to convince people of group 2 to act like me. Their arguments are like the following:

1. I'm the solo developer of this project.
2. It's just a prototype, maybe I'll have to rewrite from scratch again.
3. I don't want to pollute the Source Control with incomplete versions.

If I am right, please help me to raise arguments to convince them. If you agree with them tell me why.

Answer 1

If I'm the sole developer on a project (in other words, the repository, or part of it, is under my complete control), then I start committing source code as soon as it's written, and I tend to check in after every incremental change, whether or not it works or represents any kind of milestone.

If I'm working in a repository on a project with others, then I tend to try and make my commits such that they don't break the mainline development, pass any tests, etc.

Whether or not it's a prototype, it deserves to go into source control; prototypes represent a lot of work, and lessons learned from them are valuable. Plus, prototypes have an awful habit of becoming production code, which you'll want in source control.

Answer 2

I would say you should start adding the source and checking in before you even build the first time. It is then much easier to avoid checking in generated artifacts. I always use some source control, even for my small hobby hacks, just because it automatically filters the relevant from the noise.

So when I start prototyping I might create a project and then before building it I do "git init, git add ., git commit -a -m ..." just so that when I want to move the interesting parts I just clone over using git and then I can add it to the subversion repository or whatever is used where I am working at the moment.

Answer 3

Start using source control about 20 minutes before you write your first line of your first artifact. There is never a good time to start after you're begun writing things.

Answer 4

some people can only learn from experience.

like a hard drive failure. or coding yourself into a dead-end after deleting code that actually worked

now, i'm not saying that you should erase their hard drive and then taunt them with "if only you had used source control"...but if something like were to happen, hopefully there would be a backup done first ;-)

Answer 5

I try to only write code that compiles (everything else is commented out with a TODO/FIXME tag)... and also add everything to source control.

Argument 1: Even as a single dev it's nice to roll back to a running version, to track your progress, etc.

Argument 2: Who cares if it's just a prototype? You might stumble upon a similar problem in six months or so, and then just start looking for this other code...

Argument 3: Why not use more than one repo? I like to file misc stuff to my personal repo.

Answer 6

I create a directory in source control before I start writing code for a project. I do the first commit after creating the project skeleton.

Answer 7

When someone asked for good excuses not to use version control, they got 75 answers and 45 upvotes.

And when they asked Why should my team adopt source control, they got 26 answers.

Maybe you'll find something helpful there.

Answer 8

Here's my view to your points.

1) Even solo developers need somewhere to keep their code when their PC fails. What happens if they accidentally delete a file without source control?

2/3) Prototypes belong in source control so other team members can look at the code. We put our prototype code in a seperate location to the mainline branch. We call it Spike. Here's a great article on why you should keep Spike code- http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Answer 9

Early and Often. As the Pragmatic Programmers say, source control is like a time machine, and you never know when you'll want to go back.

Answer 10

You don't need "arguments to convince them." Discourse is not a game, and you should not use your work as a debating platform. That's what your spouse is for :) Seriously, though, you need to explain why you care how other devs work on solo projects in which other people are not involved. What are you missing because they don't use source control? Do you need to see their early ideas to understand their later code? If you can sucessfully do that, you may be able to convince them.

I personally use version control at all times, but only because I don't walk a tightrope without a net. Other people have more courage, less time to spend on infrastructure, etc. Note that in 2009, in my opinion, hard disks rarely fail and rewritten code is often better than the code that it replaces.

While I'm answering a question with a question, let me ask another one: does your code need to compile/work/not-break-the-build to be checked in? I like my branches to get good and broken, then fixed, working, debugged, etc. At the same time, I like other devs to use source control however they want. Branches were invented for just that reason: so that people who can't get along do not have to cohabitate.

Answer 11

For me, it's about having a consistent process. If you are writing code, it should follow the same source control process that your production code does. That helps build and enforce good development practices across the development team.

Categorizing the code as a prototype or other non-production type of project should just be used to determine where in the source control tree you put it.

We use both CVS (for non .NET projects) and TFS (for .NET projects) where I work, and the TFS repository has a Developer Sandbox folder where developers can check in personal experimental projects (prototypes).

If and when a project starts to get used in production, the code is moved out of the Developer Sandbox folder into it's own folder in the main tree.

Ron

Answer 12

I would say to them...

I'm the solo developer of this project.

And when you leave or hand it off we'll have 0 developers. All the more reason to use source control.

The code belongs to the company not you and the company would like some accountability. Checking in code doesn't require too much effort:

svn ci <files> -m " implement ajax support for grid control

Next time someone new wants to make some changes on the grid control or do something related, they will have a great starting point. All projects start off with one or two people. Source control is easier now than it ever was--have they arranged a 30 minute demo of Tortoise SVN with them?

It's just a prototype, maybe I'll have to rewrite from scratch again.

Are they concerned about storage? Storage is cheap. Are they concerned about time wasted on versioning? It takes less time then the cursory email checks. If they are re-writing bits then source control is even more important to be able to reference old bits.

I don't want to pollute the Source Control with incomplete versions.

That's actually a good concern. I used to think the same thing at one point and avoided checking in code until it was nice and clean which is not a bad thing in and of itself but many times I just wanted to goof around. At this point learning about branching helps. Though I wish wish SVN had full support for purging folders like Perforce.

Answer 13

Let see their arguments:

1. I'm the solo developer of this project.
2. It's just a prototype, maybe I'll have to rewrite from scratch again.
3. I don't want to pollute the Source Control with incomplete versions.

First, the 3rd one. I can see the reasoning, but it is based on a bad assumption.
At work, we use Perforce, a centralized VCS, and indeed we only check in source that compile successfully and doesn't break anything (in theory, of course!), after peer review.

So when I start a non trivial change, I feel the need to intermediary commits. For example, recently I started to make some changes (somehow, in solo for this particular task, so I address point 1) on a Java code using JDom (XML parsing). Then I was stuck and wanted to use Java 1.6's built in XML parsing. It was obviously time to keep a trace of the current work, in case my attempt was failed and wanted to go back. Note this case somehow addresses the point 2.

The solution I chose is simple: I use an alternative SCM! Although some centralized VCS like SVN are usable in local (on the developer's computer), I was seduced by distributed VCS and after briefly testing Mercurial (which is good), I found Bazaar better suited to my needs and taste.
DVCS are well suited for this task because they are lightweight, flexible, allow alternative branches, doesn't "pollute" the source directory (all data is in one directory at the root of the project), etc.
By making a parallel source management, you don't pollute the source of other developers, while keeping the possibility to go back or quickly try alternative solutions.

At the end, by committing the final version to the official SCM, the result is the same, but with added security at the level of the developer.

Answer 14

I'd like to add two things. With version control you can:

• Revert to last version that worked, or at least check how it looked like. For that you would need SCM which supports changesets / uses whole-tree commits.
• Use it to find bugs, by using so called 'diff debugging' by finding commit in history that introduced the bug. You would want SCM which support it in automated or semi-automated fashion.

Answer 15

Personally, I often start version control after the first sucessful compile.

I just wonder why nobody mentioned distributed version control systems in this context: If you could manage to switch over to a distributed system (git, bazaar, mercury), most arguments of your second group would become pointless since they can just start their repository locally and push it to the server when they want (and they can also just remove it, if they want to restart from scratch).

Answer 16

It's called branching people try to get with the program :p Prototyping? Work in a branch. Experimenting? Work in a branch. New feature? Work in a branch.

Merge your branches into the main trunk when it makes sense.

Answer 17

I guess people tend to be laid back when it comes to setting up source control initially if the code may never be used. I have projects I coded belonging to both groups and the ones outside source control are not less important. It is one of those things that gets postponed everyday when it really should not.

On the other hand I sometimes commit too seldom complicating a revert once I screw up some CSS code and not knowing what I changed e.g. to make the footer of the site end up behind the header.

Answer 18

I check-in the project in source control before I start coding. The first thing I do is create and organize the projects and support files (such as .sln files in .NET development) with the necessary support libraries and tools (usually in a lib folder) I know I will use in my project. If I already have some code written, then I add it too, even if it is an incomplete application. Then I check-in everything. From there, everything is as usual, write some code, compile it, test it, check-in it...

You probably won't need to branch from this point or revert your changes, but I think it is a good practice to have everything under source control since the beginning, even if you don't have anything to compile.

Answer 19

i'm drunk and and i do first git -init and then vim foo.cpp.

Answer 20

Any decent modern source control platform (of which VSS is not one) should not in any way be polluted by putting source code files into it. I am of the opinion that anything that has a life expectancy of more than about 1/2 an hour should be in source control as early as possible. Solo develpment is no longer a valid excuse for not using source control. It is not about security it is about bugs and long term history.