Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Introduction to my situation

I work for a small web development company. We have a team of four ASP.NET developers, including me. Almost all of our projects (> 98%) are one-person projects that take about 1-4 weeks to complete. We don't use source or version control. The only thing we have is a shared folder on a local server that contains the latest source (== the source of the live application) of all projects.

On the rare occasions that we do need to work on the same project with more than one person, we use... Beyond Compare. One or two times a day the developers ask each other if they have a version that compiles and then they synchronize their code using Beyond Compare. When only two people are working on a project, this works "rather well", but as soon as a third developers enters the process, it becomes an unmanageable piece of rubbish. Especially when everyone starts making changes to the database.

I (and one or two of my fellow developers) have already told my boss several times that we should start using some form of source and version control like Git, Mercurial or TFS (our boss is very Microsoft minded). Unfortunately, my boss doesn't see the advantage of switching to a source and version control system, because in his eyes everything works just fine now and he doesn't want to invest time and money in setting up a new system and making sure everyone knows how to use it. Even after I explained the advantages (like simplified collaboration, different versions of an application, safer way to change code, ...) to him, he still doesn't think it is something we need.

Of the four developers, only two (including me) have experience with source control (Git). And that experience is very limited. I know how to clone a Github repository to my computer, make some changes, commit them and push them back to Github. That's it.

Explanation of my problem/concern

In a few weeks we are going to start working on a rather big project for our standards. It will probably take 2-3 developers a few months to complete it. I will be the project lead (project manager and lead developer) and I will be responsible for everything. I've had my share of problems with our Beyond Compare approach and I don't want to take this road with this big project that will be my responsibility.

Since I doubt that we will be able to

  • set up our own Git server,
  • teach everyone to work with Git and
  • employ Git successfully in this big project,

I am interested if any of you know some good ways to allow multiple people to collaborate on the same project without using source or version control.


I would to thank everyone for their answers and comments. Here is the plan:

  1. Have a meeting with the developers to make sure all the technical people feel the same way about implementing source control. We'll make a stronger point when everyone is behind it.
  2. Present the idea to the boss and tell him that we really need source control.
  3. Implement it as soon as possible.
share|improve this question
Why set up your own git server? If it is a big project, get yourselves a GitHub account. Takes about 5 minutes :) Our entire company recently migrated from SVN to Git and GitHub without any new infrastructure. – fresskoma Mar 26 '11 at 18:50
IMO, doing a big (or midsize, or even small-ish) project without source control is madness in today's world. I'd actually go so far to call it unprofessional (if you're getting paid by someone to do your job properly.) – Macke Mar 26 '11 at 18:53
I get twitchy if it's just me and one line in a file and I don't have revision control. – dietbuddha Mar 26 '11 at 19:11
In addition to all the other answers and comments related directly to version control, your boss' perspective of "something hasn't gone horribly wrong yet therefore there must be no problem" is a terrible attitude to have in business. – Michelle Tilley Mar 26 '11 at 19:40
As well as asking yourself "is a few weeks long enough to get source control up and running?", you should probably ask yourself "is a few weeks long enough for me to find another job with a professional web development studio?" – Carson63000 Mar 26 '11 at 20:15

14 Answers 14

up vote 43 down vote accepted

Please take a day to install version control and teach everybody on the project to use it. It's not that hard. Personally I've not used Git, but I have set up and used other version control systems and they are not that hard to get working. Make sure you choose one that integrates with your development environment. This will make using it virtually seamless.

This will not be wasted time.

The time you will lose when someone overwrites or deletes some code will cost you much more.

If you don't have version control you will also spend an inordinate amount of time backing up your project and worrying about which version everyone has and which version is on the server etc.

If you need to convince your boss make an estimate of the time that it will take you to set up and monitor any non-version control solution and add in the cost of rewriting a few days lost work. Don't forget to add in the cost of manually merging edits from 3 developers working on the same source file and the extra cost of getting that merge wrong. Good version control gives you this for free

Then compare that to the cost of getting version control - nil (if you go open source) and setting it up - 3 man days.

Don't forget that an error later in the project is going to cost more than one early on. If you have to redo the entire project because of a mistake anyone can make this will cost far more than just the rewrite time, it might cost your boss the reputation of his firm.

share|improve this answer
+1 The answer to your title question is to start using source control. Take a look around programmers.SE and Stack Overflow; the evidence strongly supports the argument that this is the absolute best thing you can do in your scenario. – Michelle Tilley Mar 26 '11 at 18:44
@Kristof - point him at some of the questions here and on SO. – ChrisF Mar 26 '11 at 18:50
@Kristof Claes: If I was you, I'd quit my job. Seriously. No SCM -> bye. Its like an architect planning a large building on a cave wall, with finger paint, in the dark, surrounded by vicious cannibal tribes... – fresskoma Mar 26 '11 at 18:52
@Kristof But it is broken; you've admitted in your questions to having "your share of the problems" with the approach, not to mention the potential disasters waiting to happen. Besides, if you're responsible for the project, you should be allowed to set the standards you feel are necessary to get the job done. If your boss doesn't agree with these points... well, I don't know what the best course of action is for you but I know I'd never work on a team where my opinions (especially one like this where the repercussions are serious and the community at large agrees) are ignored. – Michelle Tilley Mar 26 '11 at 18:53
Version control and a bug tracker is the software development equivalent of wearing pants. – Tim Williscroft Mar 27 '11 at 23:18

If you share the source on a folder, you could share repo's there as well. The boss won't know about it except that there's a .git folder in there.

You should never have to ask permission to do your job properly - Seth Godin.

share|improve this answer
+1 if only for the citation. I am paid to do my job, doing it properly is part of the deal we both agreed to when we signed the contract. – Matthieu M. Mar 26 '11 at 19:13
There is no good reason not to use source control, and every reason to use it. – Frank Shearar Mar 26 '11 at 20:45
+1 for the citation. – bancer Mar 26 '11 at 22:13
You can even use git without your colleagues realising. – Alison Mar 26 '11 at 22:35
@Macke yep, and sooner or later someone will notice that you don't have such a bad time with the merges, and they will want to use it too :) – Alison Mar 27 '11 at 19:53

Setup source control, learn how to use it and don't tell your boss. I normally don't advocate disobeying management, but in this case your boss is being stupid. If you really think git will take too long to learn, then start with a more simplified version control system like svn - it doesn't do all the cool things that git does, but it's even easier to gain a basic understanding of.

Don't wait until you are into the middle of it and seriously in trouble before you implement something. Just do it, and get the job done.

Edited to add: What your question is really asking is 'how do I do source control without using a source control system'. You've recognized the need, and I think everyone here is really telling you the same thing: There's no sane way to do source control without a source control system.

share|improve this answer
I personally would not take a job at a company that did not use source code control (and was offered such a few years back). If you are there and want to stay I would say install git and don't tell the boss. Chances are he will never notice. – Zachary K Mar 26 '11 at 19:20

I only have your summary to go by, but from that it looks like your boss is making a time and money argument, and you are making a technical superiority argument. You need to be making a time and money argument. Learn the git way of doing things and keep track for a while of the time it could save, then present a log to your boss with entries like "3/28/2011 had to wait 30 minutes for Joe to get back to a compilable build so we could do a merge, git merge command against his last commit would have been approximately 5 seconds" with a nice total at the bottom.

If training and setting up a server are business roadblocks, there are an infinite number of ways to set up a git workflow, including having only one team member actually using git, with shared folders for the "server."

Instruct your colleagues to copy their code to a given shared folder whenever it is at a good point to share. You can keep a repository for each of them and do all the source control stuff yourself, and slowly pass more and more of the source control responsibilities onto them as you become confident enough to train them. That's far from the ideal way to do it, but compared to what you have now, even that will save you time on merges. It's easier to convince your boss with less team learning curve, and you get all the rollback and versioning benefits you want.

I don't do much database work, but to my knowledge merging of database schema changes isn't handled very well by source control. If those merges are difficult, you may want to consider a process change where all database changes go through a single gatekeeper.

share|improve this answer

This is insane. You should use a VCS even if you work on your own. Not using a VCS in a company should be forbidden. Just do it. Right now! Really... You don't need advanced stuff right from the beginning. Github and codaset are very straightforward to use, but I'm sure that you can find some more Windows-compatible hosting services if your boss insists (even though it's not hard to setup and use Git on Windows).

share|improve this answer

The think you ask is impossible. If multiple people are working on the same project without using any source control, you will quickly have lots of problems, and since you will be the lead developer, you will have to deal with them.

From my personal experience, working on a project without source control becomes impossible from two developers. Not three. Not four. Two. You may probably be able to manage the situation with two developers in some exceptional circumstances: if those developers are very organized and professional, if they interact well, if they can easily exchange (so are located in the same room at the same hours, every time) and if they are able to avoid human errors (modifying by mistake the file which was modified by another person at the same moment, then erasing the changes made by this person).

In my case, it was always more or less a disaster when it came to making two people participate to a project without version control. In best cases, one person was sending changed files to the second one, and this second one used a diff tool to apply the changes manually. In worst cases, one person tracked the changes she was doing, then reapplied them every time the second person modified the source code. Result: a huge loss of time, money and productivity.

Now, from my point of view and my own experience, I see three solutions to the issue you have:

  • Install a version control which is easy to use. I used to install CollabNetSubversion as the SVN server, it's quite fast and easy to setup, if you don't care at all about security. If you use Visual Studio, AnkhSvn may be installed to enable the developers to update/commit the source code easily from within Visual Studio.

  • Convince your boss that Joel test is written by a person who knows very well his job, and if Joel test suggests having a version control, there is a good reason behind it. After all, he can also decide that developers don't need an IDE/syntax highlighting tools to write code. Windows Notepad is just fine, isn't it? And also, why having internet access? All we need is a very, very old PC running Windows 3.1.

  • Quit this company, since I have some doubts that everything except version control is perfect and professional there.

share|improve this answer
Its certainly not impossible. How do you think software was developed before source control was common place? – GrandmasterB Mar 26 '11 at 22:01
Not sure I'd explicitly reference the Joel test, since it includes things like private offices which this type of manager might dismiss as pinko commie weird stuff. – JohnMcG Mar 26 '11 at 23:52

Not using a VCS on any larger project because you don't want to invest the time of setting one up is like taking a long journey barefoot, because you don't want to invest the time of putting shoes on.

Any VCS is orders of magnitude better than having none at all.

A dead easy way to set up a VCS is to get TortoiseSVN (since you seem to be using C#, I assume you're on Windows). You create a repository in a local folder you choose (navigate to it, right click > TortoiseSVN > Create Repository Here). Share this folder in your network (it should preferably be on a machine, that is always available) and make checkouts with the url file://computername/path/to/that/repository. Download excluded, this takes no longer than a minute to set up.

share|improve this answer

Your answer is a simple link to your boss... mail this page to him/her and highlight the number of times the words "quit" appear from professionals.

While the word "dumb" appears probably as many times, I am certain that your boss is not. It is just not clear to him the absolute value of this. The question to ask him is what business related question would result in the same response ( perhaps an accountant suggesting "Rather don't insure this building that you are bonded to the max it will save you a few dollars!" )

share|improve this answer

Source control is only necessary where the number of developers on a project is > 0. I'm starting to think that one might say the same about continuous integration...


As you're ASP.NET developers I'd suggest you want to go with one of Subversion, TFS or Mercurial - but to be honest it doesn't matter which just so long as you go with something. Developing without version control makes no sense whatsoever - even less so when the tools are more or less free to deploy and the overhead for using them is minimal.

TFS will give you a stunning level of integration. DVCS (mercurial or git) will probably give you the most flexibility and capability. There is no good reason NOT to do this.

If I were starting from scratch it would almost certainly be with Mercurial.

Once you have version control you can progress to a build server (TFS, TeamCity) and from there to continuous integration and at that point you start winning hand over fist.

To come back to your start point:

I will be the project lead (project manager and lead developer) and I will be responsible for everything

Right, you're responsible so you decide you need version control (because you do), you decide that you need an build server (because you do), you decide that you need to have deployable output from your project from the very first day (because if you can always deploy it - and hence facilitate more testing) and that the deployment will be highly automated - these are steps that you are taking to ensure the success of your project (for which you are responsible...)

share|improve this answer

As mentioned above, you can put a repository on the shared folder you already have. You don't need to spend time configuring a server if you use a distributed source control system, like Git, Mercurial or Bazaar.

I'd suggest you to use either Git, as you already have some experience with it, or Mercurial, which has good integration into Visual Studio.

If in the future your boss will tell you to switch to TFS, that is still better than to have no version control at all.

share|improve this answer

Back in my Powerbuilder days, we had a whole team working on a suite of applications without using source control. Oh, Powerbuilder had source control, but actually using it was a crapshoot - if PB crashed while you had a file checked out (and it crashed a LOT), that propriatary, binary sourcecode file was now inaccessible. Some flag got set in the file, and no other copy of PB could load it, even the same person who had it checked out.

So what we did was pretty simple. "Hey, Tom, I'm gonna work on xyz.pbl. So dont make any changes". In the grand scheme of things, we rarely had any problems.

share|improve this answer

Assuming you can't convince your team to adopt version control or that your boss gets wind of the subterfuge and insists that the team stop, there's a less-than-optimal approach you can take.

Install Git or Mercurial on your own machine. Version your own work. When the team syncs their work via the Beyond Compare process, add the changes to your local repo as a new commit. You will always be able to retrieve a previous working version from your local repo should the team's sync break something.

Using a DVCS ensures that there's no requirement to have a server and no complex setup process. Installing Mercurial and getting up and running with the basics should take no longer than about 30 minutes.

It's not an ideal solution, but it's better than nothing.

share|improve this answer

My initial reaction to this was that you already have an ideal working process without version control. You all seem to have a good way of managing merging and so on. From a managerial perspective, this is seemingly a good situation. I've met teams that use version control, but have to struggle with the development process itself.

So convincing your boss solely basing your argument on that version control would yield "a better process" is quite pointless. There is however another much more important argument on why you need to use version or source control in the first place, which can easily be calculated to money. And that is:


The issue is not that using source control makes your development process better. It is more of an issue what would happen if you don't have source control at all. What are the risks?

Say someone mistakenly deletes a function in code or a whole file? How much would that cost to repair? Hopefully someone has that covered, so the fix is marginal.

But what happens if no body had a backup of the lost file? How much man hours would that cost to fix? That would maybe take days, and that is easily calculated in average of man hours. Would that be too much for the company? Could this be remedied somehow quicker?

Yes, with some kind of source control. In contrast: how long time it would take to set up version control and back it up? Most open source ones such as git or mercurial don't take up much time to set up. Teaching people how to use it wouldn't be that hard, considering you already know how to merge with Beyond Compare and you "check in" to a shared folder. This is a one-time set up cost. Would these man hours be less than the ones that the risks have? If this is true then using source control should be a priority.

As long you can show a business reason why it is useful to have source control, and risk management would be one such huge factor, that would convince most bosses.

share|improve this answer

Use dropbox, it has automatic version history. You can share dropbox-folder between multiple users.


You can also download TortoiseSVN-client, and create "local repository" on network drive. Then people can checkout the source code by network folder location.

share|improve this answer
But merging?? – user1249 Mar 26 '11 at 21:48
Well you can keep local copy of all source codes, and merge them once in a while with dropbox folder using Winmerge. – AareP Mar 27 '11 at 8:02
Have you actually TRIED this for a real project? Sounds brittle to me... – user1249 Mar 27 '11 at 8:03
Actually you can develop streight into dropbox folder, if it's a web-project that doesn't require all source codes to be compiling at once. – AareP Mar 27 '11 at 8:09
I Think you should try it before recommending it to others! – user1249 Mar 27 '11 at 9:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.