It's not really a technical question, but there are several other questions here about source control and best practice.

The company I work for (which will remain anonymous) uses a network share to host its source code and released code. It's the responsibility of the developer or manager to manually move source code to the correct folder depending on whether it's been released and what version it is and stuff. We have various spreadsheets dotted around where we record file names and versions and what's changed, and some teams also put details of different versions at the top of each file. Each team (2-3 teams) seems to do this differently within the company. As you can imagine, it's an organised mess - organised, because the "right people" know where their stuff is, but a mess because it's all different and it relies on people remembering what to do at any one time. One good thing is that everything is backed up on a nightly basis and kept indefinitely, so if mistakes are made, snapshots can be recovered.

I've been trying to push for some kind of managed source control for a while, but I can't seem to get enough support for it within the company. My main arguments are:

  • We're currently vulnerable; at any point someone could forget to do one of the many release actions we have to do, which could mean whole versions are not stored correctly. It could take hours or even days to piece a version back together if necessary
  • We're developing new features along with bug fixes, and often have to delay the release of one or the other because some work has not been completed yet. We also have to force customers to take versions that include new features even if they just want a bug fix, because there's only really one version we're all working on
  • We're experiencing problems with Visual Studio because multiple developers are using the same projects at the same time (not the same files, but it's still causing problems)
  • There are only 15 developers, but we all do stuff differently; wouldn't it be better to have a standard company-wide approach we all have to follow?

My questions are:

  1. Is it normal for a group of this size not to have source control?
  2. I have so far been given only vague reasons for not having source control - what reasons would you suggest could be valid for not implementing source control, given the information above?
  3. Are there any more reasons for source control that I could add to my arsenal?

I'm asking mainly to get a feel for why I have had so much resistance, so please answer honestly.

I'll give the answer to the person I believe has taken the most balanced approach and has answered all three questions.

Thanks in advance

  • 3
    It sounds like they're not very far from working with a DVCS like Mercurial. The people who drag their feet could still be "using" Mercurial if the existing folder were actually made into a repository. From their perspective it would look almost the same, and you could commit the changes if they didn't. Commented Oct 5, 2011 at 22:02
  • 19
    UPDATE (Nearly a year after I asked this question): Over the course of the last year, I've campaigned and cajoled and begged and wheedled until I got to the point where I damn near got myself fired for insubordination a few times. I'm pleased to say that the company in question is now finally taking a serious look at source control, with a view to implement TFS after a trial period of a month or so while we ensure all the developers are happy with the new processes. It was largely the positive response I got from this question at programmers.SE that gave me the confidence to pursue it. Cheers.
    – m-smith
    Commented Oct 2, 2012 at 13:57
  • 10
    Developers not using source control is equivalent to surgeons not washing their hands or using dirty utensils to operate. It is professionally incompetent and there is no excuse for that kind of malpractice.
    – Tim
    Commented Oct 2, 2012 at 15:02
  • 1
    Even though electricity has been invented a long while ago and is pervasive in our every day lives some people still choose to work at candle light scribbling code on a waxed board using a pointy stick.
    – Newtopian
    Commented Oct 2, 2012 at 20:26
  • 2
    15 devs is hardly a small shop. Commented Oct 14, 2012 at 14:44

31 Answers 31

  1. It may not be normal, but as Treb says, it's probably not that unusual
  2. As others have said, there are no valid reasons for not having source control in a company your size. So you need to identify and attack the invalid reasons:

    a) the main one is the status quo: "if it ain't broke, don't fix it". This is difficult: you could start pointing out all the things which aren't working as well as they should (which can quickly get you labelled as a 'negative person'), or you just wait for something to blow up (which might never happen), or you could emphasise all the things that could go wrong. Unfortunately people in charge of small companies are relatively impervious to 'things which could go wrong' until they actually do go wrong...

    b) ignorance/fear/uncertainty: "we don't really understand what source control is; we don't know how to use it; we don't know which tool to choose; it's going to cramp our style". This is one reason I definitely wouldn't send them here! It might be a fairly tall order for you on your own, but I think to maximise your chances you need to present a 'turn-key' solution, and not too many variants or alternatives. You need a clear idea of: how you want to fit/transform your working process to work with the given tool; how/if you plan to back-port existing code; how fast you think you can 'train' users and have them up and running; how you can manage the transition period (if there is one); how much it is likely to 'cost' (in hours, if not in dollars).

    c) there may be other reasons (previous bad experiences with VSS for example, or having read 'horror stories' about allegedly over-complicated tools), but you'll have to bat those ones individually when you discover them.

  3. There are ample reasons for source control outlined in the other answers. My advice would be to pick out the main 2 or 3 that could really make a difference to your company and polish them up and present them in a meeting to as many of your colleagues as possible. Try to provoke discussion: even if you don't immediately convince them, you will gain insight into what the sticking points may be.

(Have you read/heard about The Change Function?)

  • 2
    Thank you for the (sadly) neccessary distinction between normal and unusual. +1
    – keppla
    Commented Oct 4, 2011 at 12:58
  • 29
    +1 for ignorance/fud. If you're a professional software developer, not using SCM, then you're not. period. Commented Oct 4, 2011 at 20:09
  • 2
    Just out of curiosity, who would pay $300 per person for source control (Valut, according to your wiki link), when there are countless free applications?
    – Rob
    Commented Oct 4, 2011 at 22:17
  • 11
    on point 2: I don't see any valid reason for a team of any size (include a team of 1) to not use Source control... ? Commented Oct 4, 2011 at 23:49
  • 1
    Another reason that that some small groups do not have version control -- there is some overhead and learning involved in setting it up. You need a server to host the code base. You need to administer the server and the VC software on that server. You need to back up the VC database, create and test a recovery plan and monitor the backups to ensure that that the backup/recovery is still valid. All this administration takes time. In organizations with poor software management, the time developers spend administering the VC system may be punished rather than rewarded.
    – Jay Elston
    Commented Oct 5, 2011 at 18:30

It is absolutely not normal for a group that size to be working without source control—the size of the largest group of programmers that can work effectively without source control is less than or equal to one. It’s absolutely inexcusable to work without version control for a professional team of any size, and perhaps I’m not feeling creative, but I can’t come up with any reason why you would want to forgo it.

Version control is just another tool—a particularly powerful one, and one which delivers enormous benefits relative to its minimal cost. It gives you the power to finely manage all of your changes in an organised fashion, with all kinds of other handy things like branching, automated merging, tagging, and so on. If you need to build a version from umpteen versions ago, you can check out the code from that point in time and just build without having to jump through any other hoops.

More importantly, if you need to write a bugfix, you can merge it into an update without having to deliver the new features you’re working on—because they’re on another branch, and as far as the rest of the development needs to be concerned, they don’t exist yet.

You’re experiencing resistance because you’re challenging the culture of the company. It will take time for them to adjust, no matter what you say. The best you can do is keep pushing for it, and if the company really won’t budge, find another job that’s better suited to your level as a developer.

  • 45
    Unfortunately, inexcusable does not equate to unusual... Commented Oct 4, 2011 at 10:11
  • 6
    Not to mention that there are FREE source control providers, so it's not as if it's an expensive course of action.
    – Mantorok
    Commented Oct 4, 2011 at 13:50
  • 9
    It can be expensive as far as getting people to change their habits, workflow, and procedures.
    – user1936
    Commented Oct 4, 2011 at 15:39
  • 4
    @Rook: Absolutely. But I would rather have a safety net I don’t need than need one I don’t have. I was programming long before I knew what a version control system was. While it’s not a necessity, to deprive yourself of a good tool is stupid.
    – Jon Purdy
    Commented Oct 4, 2011 at 17:21
  • 12
    I couldn't imagine developing without source control even when I'm the only developer.
    – webbiedave
    Commented Oct 4, 2011 at 17:40

Is it normal for a group of this size not to have source control?

In my experience, it is not the norm, but not as completely unusual as other answers here suggest. The majority of small companies does use source control, but a significant number doesn't, unfortunately.

I have so far been given only vague reasons for not having source control - what reasons would you suggest could be valid for not implementing source control, given the information above?

See this question on SO for a good discussion. The accepted answer says:
"There are no good reasons not to use version control. Not one."

Are there any more reasons for source control that I could add to my arsenal?

The consensus among all developers and project managers I have met, and of course here on Programmers and SO is that source control is a must. It's an accepted best practice. If somebody decides to ignore it, he needs to have some very strong and convincing arguments why this is the right decision for him (i.e. a little more than 'we never needed it, so why should we need it in the future'). The arguments you have presented so far are focused on specific issues, perhaps you should try a wider approach along the lines of 'everybody does it, so why don't we as well?

  • "a significant number doesn't" ... hmm ... with 15 devs on the same code base? Where I am, we added SCC when we were ... 5+2 devs on the same code base and we felt it was high time for it. I sure hope that 15 devs and no SCC on the same code base is highly unusual :-)
    – Martin Ba
    Commented Oct 4, 2011 at 12:01
  • 3
    @Martin: It's not that unusual to find 15 people who all suffer from the not invented here syndrome... I would guess that maybe 5% of all small (< 20 employees) companies have no source control. I hope for you that your experience differs form mine ;-)
    – Treb
    Commented Oct 4, 2011 at 12:57
  • +1 for not unusual, unfortunately.
    – Jonas
    Commented Oct 4, 2011 at 13:46
  • 6
    +1 for not unusual. Some people just don't understand that the benefits of source code control outweigh the costs. They fear the cost, and integrate by copying files or patches into a "central" merge workspace for the "build"; mostly because that's what they figured out would work, and nobody invests in the development environment. Typically this is due to the perception that they have so much work to do on the code, they can't waste development time on the environment. I find the time saved with the more efficient environment more than pays back the investment of a developer working on it
    – Edwin Buck
    Commented Oct 4, 2011 at 15:54

Source-control is good for even a single developer team. Any source control system is basically a version control system that keeps the track of changes. Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?

Just go for a tool that helps you. The size does not matter everywhere. The quality does matter everywhere.

  • 4
    +1, I am a currently one developer team and I use source control. I even use source control at home to manage personal documents not related to software development, like cooking recipes and my resume.
    – maple_shaft
    Commented Oct 4, 2011 at 11:37
  • 1
    +1, Lots of small shops start out using zip files as their archive. Thinking "I may want to get back to this point, so I'll just zip the whole thing". It's not the same, not at all. Once you've gotten familiar with SCM, and the great tools that are built on top (log, diff, blame, etc..), you'll never go back. Commented Oct 4, 2011 at 20:07
  • 5
    Another great use for SCM: I come in on Monday, wonder what the heck I was working on last Friday. I just do a diff or look at the last checkin log, and I'm immediately back in the zone. Commented Oct 4, 2011 at 20:08
  • 1
    Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back? Yeah, I just use the last backup I took by hand, a few weeks ago, and I take backups whenever I want to make a major change. Hasn't failed me yet in a few years, and never needed (or felt like I should've used) source control...
    – user541686
    Commented Oct 5, 2011 at 2:51
  • I am the only one who does development at our company (I also do IT stuff), and when I started up, I didn't use source control, there was never a disaster, but I eventually realized how on the edge we were. I installed Mercuarial myself a bit later on, without ever having used it before and with the windows ui for it, it has become a great help. Commented Oct 5, 2011 at 10:39

It sounds like you are already using a system of version control, but not a very good one. People already seem to recognize the need version control. You just need to introduce them to the next level -- software version control.

If it were me, I would introduce SCM as an improved version of what they are already doing. I would emphasize how using a good tool will automate a lot of the work that is already going on.

  • Instead of recording changes in a spreadsheet, the SCM system keeps track of not only what changed, but who changed it and why.

  • As a bonus, you can go back to any point in the code's life and see what was actually there.

  • Instead of having different versions of code in different folders and needing to move/merge things between folders to port a change, you can keep everything in the same place, and (more importantly), let the tool do the merging.

As others have already said, I would expect some resistance, so I would prototype the system by using it on the stuff I am doing.

(BTW, I actually put my Resume and other documents under SVN. Then again, I've been played the roles of Configuration and Integration Managers several times.)


I have so far been given only vague reasons for not having source control - what reasons would you suggest could be valid for not implementing source control, given the information above?

  • The product you're developing is a version control system; managers are concerned about preventing existing products from influencing the design and implementation of the new product.

  • Between weekends of BASE jumping and running with bulls, thrill-seeking managers enjoy driving to work wondering whether everything's gone to hell yet.

  • Avoids hostile takeovers. Who would want to acquire a software development outfit that's managed this way?

Are there any more reasons for source control that I could add to my arsenal?

  • You're already doing version control, but you're currently doing it in the least efficient, most labor-intensive, most error-prone way imaginable. Using a VCS will save money, save time, and improve quality.

  • Saves disk space. Most version control systems save only the deltas between files. Currently, you're saving an entire copy of every version of every file. (Backing up all those copies must take a lot of time and space!)

  • Several developers can work on the same file at the same time and reconcile the differences without too much trouble. Merging changes is of course possible without a VCS, but it's nearly impossible to keep track of who changed what, when, and why in that case.

  • Gives developers freedom to try new ideas knowing that they can recover any version at any time.

  • Better process makes it easier to hire and retain talented developers.


Is it normal for a group of this size not to have source control?

No definitely not. When I started at my current company, there was one person whom you should send your changed code to, and he would merge it. I could convince everybody within days to use SVN.

I have so far been given only vague reasons for not having source control - what reasons would you suggest could be valid for not implementing source control, given the information above?

I think the reason you only heard vague reasons is because there are no valid reasons for not using version control.

Are there any more reasons for source control that I could add to my arsenal?

Yes, there are a lot of reasons.

  1. Branching gives you the possibility to develop new functionality without interfering with other developments.
  2. Each commit gives you the information about what exactly has been changed, who did that change, and when that change was made.
  3. You can easily commit bugfixes, and deploy them to the customers, and leave out the unfinished new functionality.
  4. You can maintain different versions, if customers are afraid of going to a newer version.
  5. You can work on the same project (even the same source files!) with ease.
  6. You can easily revert a mistake, with preserving the changes after that committed mistake.
  • "there was one person whom you should send your changed code to, and he would merge it" -- That doesn't sound so bad. A lot of opensource projects work this way. You send patches to the maintainer. But that won't scale to large teams obviously. Commented Oct 4, 2011 at 18:40

Some people have trouble realizing how bad the status quo is until they see something better for themselves. What you need is a good demo. Show some actual examples of tasks it could improve. "This took me 4 hours to track down with our current system, but this one source control command told me instantly."

  • This is something I would benefit from, too. I have only read about the benefits of source control, but have never experienced it for myself. I have considered setting up SVN at home (but currently doing up my house and don't have much time..!)
    – m-smith
    Commented Oct 4, 2011 at 14:41

Not using source control is asking for problems, even for a solo developer. The simple fact that you can edit ruthlessly without risking to lose anything makes up for the learning effort within weeks or days.

That said, if you can't convince your managers to introduce source control, do yourself a favor and at least use something like git or mercurial locally - if things blow up due to lack of source control, at least you won't be the one who did it.

  • 4
    ya, no reason not to use it yourself, then coincidentally show its power to a coworker when he least expects it.
    – gtrak
    Commented Oct 5, 2011 at 17:15

My company uses GIT for version control. The company is one developer, one CEO, one security guard, one cleaning lady and one recepcionist. All of them are me. Source version control is a MUST everytime.


I work on a lot of projects by myself and I still use version control. The size does not matter. It always helps to have version control.

There is a reason it is #1 on The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

Also, it makes #2 and #3 on the list possible.


We were in a similar position with a 6 person team a few years ago. One of the developers took the step of installing SVN on a dev server where the shared folder was and just started using it.

Everyone followed suit, and wasn't long before we implemented CI (CruiseControl) and revolutionized our build and release process to include automation and quality checks.


WTF?! This may be the most ridiculous question I've ever seen. You need to find a new job. 15 developers?! You think that's a small team? This is insane. Manager should be immediately terminated. Honestly, I'm going to have nightmares after reading this question. Please tell us the product you sell so we all know not to buy it! I don't know what's scarier, this question, or answers saying this is not unusual!


I cannot imagine how 15 developers can work without any source control. However, from:

(...) uses a network share to host its source code (...)

I assume you have created your own poor-man's version control like VSS (also based on shared folder). It's risky and not efficient.

Explain to your boss how bad it is, invest in some 2-days SVN or GIT training, and start using real version control system while you still have your code in reasonable shape.

  • 2
    I'm not sure you need two days to learn SVN. With 15 developers, they can't all be "fresh out of school." Surely half have used it somewhere before. Commented Oct 4, 2011 at 15:14
  • 1
    @MichaelBlackburn: I agree. I didn't make my self clear. I was thinking about 2 days for training and setting things up (setup repo, import code, etc.) Commented Oct 4, 2011 at 16:19

If I don't commit several times a day, or at least before I leave for home, I feel like .. somethings missing, somethings wrong.

I once worked in a company with just 2 developers (me + long haired admin guy), back in 1998. Even then we used svn. It's just so convenient.

Several times in my career I lost a days of work because I did something like mv instead of cp and then rm -rf. Made me cry and wander around in the city streets in despair.

I worked in 5 companies over my 13 years of being in the SE, been to some conferences, and never encountered a company not using version control.

However, my favorite interior design company, 20 employees, use a white board for project management + collaboration. They know its plain wrong, but they don't seem to find time to upgrade. Somehow it works though. Don't ask me how.

  • 1
    svn didn't exist in 1998. Commented Oct 4, 2011 at 19:26

Be a leader. Being a leader means doing what's right; proactively solving problems. Leadership is not doing nothing because there's not enough consensus. And a good leader learns to recognize situations when one should build consensus and when to do. This is clearly a doing situation. The lack of code control WILL blow up in your faces sooner or later.

Leaders often are not in official management positions. People will follow good, decisive leaders regardless of title.

If your decisive efforts get slammed down, especially if it's from management then it's a clear sign for you to get the hell out of there. It's a drag on your professional development; and Competent developers and incompetent management do not mix, and an incompetent with power will screw you.

OK, the flashbacks are getting to me. Signing off. Good luck.

  • Thanks mate. I like the definition of leader "doing the right thing", which differs from the definition of a manager "doing things right". I.e. the manager is doing what he's doing in the right way, but it may not be the right thing to do. The leader does the right thing, but often needs a manager to do it right. Definitely worth a +1 :)
    – m-smith
    Commented Oct 7, 2011 at 9:40
  1. Get a stopwatch,
    • Count the time you spend in the spreadsheet just for synching up versions
    • Count the time you spend repairing broken versions
    • count the number of times people shout in the hallway "i'm editing main.c!, just to make sure nobody else is right now!".
    • count the number of complaints you get from customers because their bugfix contained other changes
    • count the time delay of release just because you were unable to synch up the versions
  2. Make a powerpoint with this data, compare with how vcs would work.
  3. Show management

This is just an accident waiting to happen. You have no code history, and in one fell swoop, one of your developers could wipe out months of work. As a small company you can't afford this kind of setback.

You are also very exposed on that share drive. Even with a good backup, how long can you afford to not be working. 1 hour, 1 day, 1 week. How long would it take to get a new server in place, restore from backup etc. Again as a small company you probably don't have extra hardware on standby and might not be able to readily drop the money to get expedited shipping etc.

Think about offsite storage as well. A flood or fire is not really that unusual. What would happen if there was a fire in the building after hours. How many months of work would be lost. A managed code repository like github would be valuable for this. Even using a simple SVN server on a hosted service would be a step up in this area.


LordScree, I am in an almost identical predicament as you, my immediate team is about 15 developers. I am in disbelief (almost horror) that source control is not used. My initial response to "we should be using source control" was "we don't have time to implement". To me, like wearing underwear, source control is not optional. After a few months, I too have approval to implement TFS, chosen by the org because it is MS and comes with a 90 day trial. Bottom line, it is very difficult to convince an organization of the need for source control when they've been chuggling along without it. I tell developers that anytime you find yourself backing up files, especially with a date in the backed up filename or directory, is an example of when you'd put something in source control. I don't have any brilliant answers for you, but I do believe this is uncommon. I'm fighting the same battle and will keep you posted on progress. And, hopefully there will be progress else I may looking elsewhere cause I can't work in chaos!

  • I think my strongest argument for source control was for the risk to the business of not having it. A product release gone wrong could cost the business hours or even days of time to sort out - not to mention the damaged relationship with the customer. This is a real risk without managed source control due to the number of manual steps needed to release the software and track things like versions for each customer. Try to make your approach from a business perspective, as managers are more likely to listen to these arguments than simply 'everyone else is using it, so we should be'.
    – m-smith
    Commented Oct 15, 2012 at 10:51
  • Another contributing factor was that the ISO 9001 accreditation my workplace is looking at marks IT businesses down for not having source control. The accreditation is useful to put on bids for new projects and business partnerships, as it's something that is often looked for on tender documents. Best of luck with your fight!
    – m-smith
    Commented Oct 15, 2012 at 10:54

we have 3 members of development staff and use source control. On my personal projects I have one developer and I use source control. It's not just useful for team management, it's useful for being able to get into doing experimental work without fear you're doing to destroy something.

Easiest way to convince management? There's less risk to the overall product, and it'll increase developer productivity in the long run. Both are true as well, and both appeal to managers.


It is by no means a normal scenario and i think you should give a tough fight for getting this setup in your company. It has far reaching benefits and has no point in realizing the same when you approach doomsday and it ain't the situation which fall under If it ain't broken don't fix it

Any reason for not implementing it could be only an excuse for bad work or a blunder waiting to happen.

Just tell them how great its to find what the app was on 1 Jan this year

how about hey this functionality was added in March i think we need to expand a bit more on this.

Wow this bug 154256 has been fixed in this commit.

i can branch out the app and send out the deployment no problem guys you can carry on working.

This can go on and on ... (remember to add comments on commits later on else that would be coming in as another question )


I use version control for my one-man projects and my work projects, where we have upwards of 30- 40 people working on the same code at once. Version control has its organizational advantages, but the ability to revert files and stash changes can really take the headache out of managing code... and in the end that is the best scenario for a programmer, so they can just focus on coding.


Reasons to support not using version control are fairly limited. All that I can think of is the technical aspect of things.

  • There is too much of a learning curve to convert your entire staff's workflow to incorporate a versioning system to be cost effective.
  • Your project manager does not feel that it would be beneficial to introduce the overhead into the workflow of managing and maintaining a repository. (Primarily an issue with older Versioning Systems)

There are many reasons to use a versioning system. At the very least stop moving things around. Work with patches. Versioning systems can do exactly what it is that you say you do.

  • You can work on the next version at the same time you are doing bug fixes and release them separately.
  • Instead of moving files from one location to another to work on it you can create a branch and merge it into the master upon completion.
  • Each developer can have their own copy of the source code to prevent the issues with the same project open on multiple machines.
  • Accidents happen, if the code becomes severely broken all you need to do rollback to the last working revision number.
  • Version control works well paired with bug trackers and continous integration systems.

I personally as a one person team use versioning, bug tracking, continous integration, code review, code consistency checking, unit testing, selenium tests, source code analysis, and there may be more I'm forgetting. I admit, there is a slight learning curve. There's also a tradeoff of additional administration time necessary to the addtional steps you automate. In my experience, the effort saved outweighs the additional administration time.


On my first serious job in 1990 I was the only developer working in my department and didn't know to use source control.

Pretty soon thereafter I learned, from then on I've never seen a project that didn't make it one of the first things they set up.

I nearly lost all my work at that job because I deleted a folder at the wrong level. Luckily I had brought a copy home on a 5" floppy the week before and was able to re-create the weeks work in a few long days.

So I guess I'd consider it acceptable if it was the first project for everyone on the team and nobody knew better, but if even one person could actually explain the benefits and the team still didn't listen I'd re-categorize my opinion of the group from "naive" to "dangerously incompetent" (Resistance to using a tool with such widely-demonstrated benefits is almost criminal--it's like if your team didn't trust "Compilers" and insisted in doing everything in assembly language).


I have encontered this a lot...in small engineering/electronic companies where they do lot of embedded software/ hardware.

In these places SCM is not part of the electronics engineering culture. They usually have one engineer per project, who just needs to back up the latest release.

So branching/merging and even sharing code is considered irrelevent. Also, these companies are probably ISO9000, so the process, albiet weird, is probably documented.

In any case I/other developers have just started using SCM personally.


Where I work we have the same problem. I'm currently trying to slide source control in "under the radar" to get around the same issues you have. I use fossil for the projects I develop personally.

I recently got a fossil server set up on the company LAN, so now its even more convenient. I'm hoping that as I demonstrate the usefulness on some smaller projects that I'll undermine the resistance and move us away from the status quo of network folders.

The biggest reasons I've heard for not using fossil, or some other VCS are:

  1. Many of the "programmers" are script kiddies, and won't understand how to use it
  2. Those who could learn, think it is a nuisance to use
  3. These people are the old guard, comfortable with the network folders, so everyone should be
  4. No one has time to set it up right, or learn how to use it
  5. While the features might be great, none of them are necessary

As you can see, I'm trying to get around these by demonstrating that it's simple to use, already set up, easy to learn, and the features are completely worth it.

Finally, even if you don't get them to use source control, it's all in a network tree. Fossil can version everything in the entire tree, and you can set it up to run whenever a file change occurs, or at least every hour. I've done that for some of our projects that "didn't need source control" and it ended up allowing me to roll back to a good version when something went wrong.

Do it right, and they won't even know you've done it. Then you can be the hero who restores the broken build, and demonstrates how useful your tool is.


Now that DVCS tools like Git and Mercurial are available, and incredibly easy to set-up and use, there's really no excuse for even a team of 1(!) not to use source control. It's not about size of team, it's about having a commented history of your changes and the ability to support workflows such as fixing production issues whilst working on a new release, and tracking the state of the source code for different versions.

If I were offered a job in a team that had got to that size, and not one of the developers had suggested using a VCS, or if "management" had prevented them, I'd turn it down flat. It's just not an acceptable way of working these days.

  • Version control was easy to set up using Source Safe and SVN. Even CVS. (Git is NOT easy to set up and use in a Windows environment)
    – Tim
    Commented Oct 2, 2012 at 15:04

You should get yourself a GIT version control immediately. You can use it even from Google Code Project Hosting. When the others see you commiting changes in just a click while they manually copy things, perhaps they change their mind about it.

  • I totally agree. The Git installer is incredibly easy to use and you're up and running in minutes. Advanced functions can wait, basic version control can't wait. cd topleveldirectory ; git init ; git add * ; git commit -m "initial commit" Commented Oct 4, 2011 at 20:37

Wow, just wow. While I don't think it's the best way to handle code control, it's not entirely unusual I worked at a company with 6 developers and no source control was used, they kind of had their own internal way of managing files, a release manager and whatnot would oversee all changes. In-fact the mantra was that new functionality could be added in to projects as long as some kind of switch was wrapped around the functionality.

For example we were working on a b grade social network written in PHP and the client wanted functionality to be able to subscribe to a users profile. Basically the functionality was wrapped in a check like this if ( ENABLE_SUBSCRIBE_FUNCTIONALITY == true ) { then execute the code }

The place I worked at as well never had more than one developer at a time working on a particular file, mostly everything was modular so in that instance there was no need for source control. However, I believe the advantages of source control far outweigh the disadvantages of not having it in most cases.

The very fact your company is resorting to spreadsheets documenting file changes and what was changed when something like Git or Subversion can handle that for you is just absolutely ridiculous.


It seems that you are some convinced, but someone in the organization is not empowering you to do it. As you can read from the other comments, you should do it.

You can find some information here: http://www.internetcontact.be/scm/?page_id=358

The most important factor is that your customers are forced to the last 'instable' branch and if your contracts with your customers makes you responsible for deploying instable versions, your company is losing money. You should really focus on release stability here. This is the main reason for source control, and as it seems your main failure. The others will not be improved that much by using source control as you already have alternative systems in place.

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