Source control is a problem, not a solution.

Learn to develop without source control, and only then will you see the light ;)

100% of the reasons you use source control are unrelated to versioning, so why not solve your problem instead of adding another one ?

I'm not sure if you're trolling or not? But I'll bite: Care to explain what SC is THE problem?

All form of Source Control is an overhead with the sole purpose to help manage avoidable mistakes through an inherently complex mechanism that brings its own problems along.

This, rather than fixing the original problems, which are bad application design and low developer skill.

I guess you could use unison for commitless synchronisation with a "master" repo. on a central fileserver -- and have a VCS (git, perhaps) watching master backing up deltas for posterity.

I'm going to have to ask:

Why do you need those versions anyway ?

What do you do with them once they are outdated and never run anywhere anymore ?

What is the point of storing deltas when you only need the final working version anyway ?

Because finding out who made a change on a given line of source, at what time, is an extremely useful question that VCS can answer for you. Also, often you need more than the final working version; e.g. if you need to make a showstopper fix to a released version after the development team has moved on to the next version.

1. Wrong. Nobody cares about changes that do not cause problems.

2. Why do you need another version ? Why do you have more than one version ?

1. Wrong. If you are the first person looking at a codebase in years, being able to find where the bodies are buried is extremely useful.
2. At a minimum, you have the last released copy, and the working copy. Presumably you are not shipping to customers every time you hit save in your editor.

1. I don't see how VCS are going to help you look at a codebase. I personally use notepad++ / vi / grep depending on where I am. But feel free to use VCS to read text files, I mean, why not.

2. There is Development and Production. Between commits, Development will diverge, and as it is pushed to Production at least once a day and as the Production version doesn't exist anywhere else than on the production servers, there is no concept of version or version control.

So you never heard of staging or canary deployments?

It's a bad idea. Don't do it. You don't want the entropy.

Do your testing properly, and such approaches will never make sense.

You do want a certain amount of entropy.

A codebase or a team not being able to deal with entropy is fragile - the first significant perturbation to come along will cause a catastrophy.

The only way to learn to deal with entropy is exercising. Look at what Netflix' Simian Army does to their products.

First of all: The Unison suggestion was not even slightly serious. Git, Hg, Svn, P4: all much better options by far.

Secondly: I write machine learning algorithms for a living. It is frequently necessary to re-run old algorithms against new test-data (or newly ground-truth'd test-data) to prove that your performance improvements are actually improvements and not regressions. Being able to reproduce old results is a cornerstone of maintaining credibility with our customers.

Even without the need to re-baseline performance measurements, I still have an occasional need to go back through the source code history to determine when changes were made and why. This need manifests itself maybe 3-4 times a year on average. (More frequently in a large team; less frequently in a small team).

By coincidence, earlier this afternoon one of my colleagues asked me why some code had gone missing. Using git log --follow --patch -- <filename>, we were able to track down when the change was made, who made the change, and (eventually) the reason why. Without this ability, we would probably have assumed that the deletion was accidental, and re-inserted the code, kicking off an unnecessary and completely avoidable edit war.

Finally, using a version control system is the functional equivalent of keeping a good-old-fashioned day book, recording what you did during the day and why. Are you ever going to go back and re-read your day book? The chances are, no, but it cultivates a culture of deliberate action and professional discipline, as well as providing a record to back you up if you are ever involved in any legal disputes.

Why do you start your secondly with an argument you know is flawed ?

The problem that made you use your version control search is a problem of process.

"Some code" just does not go missing without critical problems, in a well-designed system.

"Some code" just does not get deleted by the person not responsible for it, in a well-defined responsibility organization.

"Some code" just does not concern anyone else than that person, in a well-designed system.

I know dividing up programming work is hell, and it probably makes total sense for you to use VC to compensate for the imperfections in your design and processes.

I'm just saying I'd like to hear one good reason why good programmers should use version control.

You clearly have not worked on a system with many people. When programmer A leaves the team, and programmer B shows up, there is no process under the sun that lets programmer B magically get this kind of information.

Its funny - I've been at shops with simple systems, complex systems, big teams and small...

My ideal setup actually works well with a small team (could be a few people per product on many interrelated products) just using boring VCS (SVN etc are fine). We all worked in trunk and had regular weekly releases. Release code got branched off for posterity twice, once as a "release" tag and once as a LIVE branch in case a patch was needed (which would also get copied into a "release" tag). Features were broken down into sub-week chunks (often building interfaces and libraries first, etc).

If anything came up mid-week that would necessitate a branch, it either waited until Monday or we literally tossed whatever we had been working on away and rewritten the next week - or more often 6 weeks later when priorities had settled again.

The problem that we solved was that a lot of times in-process features would be "saved" through VCS branches, but the cost of switching states, merging half-done code back into the system 6-8 small releases later (is it still the "right" fix?), etc, actually outweighed the relatively small cost of the rare cases when something couldn't wait for an extra half week before we got to it.

Also, don't underestimate the value of a moronically simple code/review/build process. It doesn't solve the complex problems that a "modern" approach does, but it does make a lot of them just disappear completely.

Well, the thing is, VCS, OOP, and many other concepts exist solely to enable bad programmers to deliver a working result.

So yes, simple is always better when you think simple, i.e. have great people make great stuff.

You seem to have some larger message here Ludovic. Not just on the usefulness of the trunk stuff I am pushing, but also on tangential things like OOP. Can you put something up on www.ludovicurbain.com please and link to it from here, rather than continue to roll more and more thoughts into the comments hanging off this blog entry? Thanks.

You're saying that perfect programmers would not need all this stuff. Probably true! But not all that interesting?

I'm just saying VCS may not be the right answer to those problems, especially since it's very indirect, requiring a lot more energy due to that indirection, whereas fixing the real problems would probably cost less and cause less problems.

Really, just like OOP, it does help a ton in making average programmers deliver, but is it really the best direction, considering all the other problems it creates ?

I'd definitely like to see more questioning and focus on the real issues rather than one of the solutions that have been used to more or less address them over the years.

So what are these real issues that you think there are better solutions to than OOP and VCS? Those are (among) the best solutions we've come up with so far. You have something better? :)

My point is simply that OOP and VCS are a fitting compromise for people willing to hire average workers, and should be presented as such.

Another possible solution to solve the same problems is to hire only the best, use FP (!strict) for code quality and manageability, build each level as a rock-solid foundation, and succeed by design rather than luck.

Well, my own experience suggests that that is incorrect: even the best developers do better with OO and code control, on any nontrivial project, in any language. But if you are right, then you are in a position to gain fame and fortune demonstrating it. I await the headlines... :)

Yup, experiences differ.

Basically, you're arguing we should still live in caves, as hunter-gatherers, because technology, in any form, is just a crux for not-fit-for-survival individuals, right? Why did we bother to develop a brain, then?

OOP, at least partly, emerged when industry projects done in plain C became so big that you simply ran out of good names for functions and global variables. With encapsulation and information hiding you solve this problem.

In the beginning, VCSs didn't exist, and people were simply exchanging patches. This worked well for small codebases and reasonable numbers of patches, but when your codebase gets to millions of LOCs, and you need to juggle thousands of patches from one production build to the next, manual patch management is no longer an option. VCSs are just a tool for such needs.

As for simple, you try make the Linux kernel simple. In an imaginary, dictatorial world, there would be just one disk interface standard, just one video card type, a single processor manufactuer building a single processor type, and of course a single volatile memory brand - with all systems using the exact amount of memory, so as not to create the need of different memory manager implementations for different hardware configurations. And no other type of device or component whatsoever. Which would of course simplify the kernel a lot - for the single, standard OS everybody would use, on phones, tablets, notebooks, desktops, servers, routers, switches, TVs, controllers and any other device containing a processor alike. Go ahead, manage your code just for such an ideal system, I don't mind.

Or are you just trolling?

My dear anonymous coward, OOP emerged when the industry wanted everyone to be a coder, not just smart people with a passion for machines anymore.

OOP does not solve the problem, it makes it worse by making a dozen obscure boxes instead of one large dumb box (C). That's still so much worse than using FP, reducing state to its smallest expression, and having vision over 100% of your project, and not just some collection of obscure boxes.

Patches was old, VCS is old today, I have automated version coherency and I don't need your crappy tools.

The Linux Kernel could be made simpler if it wasn't written in plain C, but rather in a dialect that allowed for pre-compile expansion, thereby limiting the source size and inherent complexity.

But since people struggle with basic things like making mdadm raid10 perform normally, I'm not going to be asking for that right now.

I'm not telling you VCS is bad because it's new, I'm telling you the whole concept is outdated and people should just stop bowing to it when it's obvious it's broken.

Wake up, realize it's broken, fix it. Stop talking about it, stop trying to make it better, transcend it.

<grin/>

The intentional Software people (http://www.intentsoft.com) don't have source as we know it, in their science. Nor source-control as we know it :)

How would you get around source control, in a form or another, when several devs work on the same code base? How about maintaining different branches for different customers?

1) Not have the several devs work on the actual same code base. If you're editing one function and your friend is too, you're doing it wrong yes ?
2) Why would you do that ? Do you like headaches ?

Have you ever practiced what you're preaching? I mean, on a non-trivial, non-hobby project. I did, some 20+ years ago, and it's awful, compared to using a version control system.

And no, I don't like headaches - which is why I use version control systems. And I like paying customers, and paying customers like customized product versions (at least in the real world) - and are willing to pay for the overhead.

Anyway, good luck finding a paying customer with some money to spend which will give you work if you tell him you won't use a version control system.

You're not getting it are you ?

You don't need different versions to serve different customers, you need one core framework, and one specific application code for that customer, no VCS.

Apparently, those who meet me realize that the quality I provide is much more important than the use of your beginner's tools ;)

This does not explain, how do they manage to have the "almost never" failing builds. As far as I know about it, the only way to achieve it is to be able to pass the codebase together with proposed change to the same build pipeline which is used for production builds. This is trivially possible with a DVCS, but quite harder for "centralized VCS with a review tool" (but maybe they have implemented it).

I think you can look into the huge review and pre-commit artillery that they put in place (briefly explained in one of the section of this article (https://paulhammant.com/2013... and that you can pipe in the chromium organization and development tools.

> As you ‘pre-submit’ a Perforce change list for review, a daemon side of Mondrian kicks in and takes your pending change list and runs it
through multiple tests, adding more data to the Mondrian code review for that change. This is all available to the developer before they go as far to submit something for review, which is good as most people like to fail in private.

This looks very much like the "Short Lived Feature Branches" as classified in https://paulhammant.com/2013... , but the branches are simulated rather than got used natively from VCS. And this is exactly what I meant in my comment - to get stable trunk one should use some branches, at least short lived ones.

Using the simulated branches could make sense in 2006, because there was few VCS-es with good enough branching, but now mankind has advanced quite noticeably, so it can be just VCS branches with no additional tools like "review storage" or "shelves" or however it named.

We use Gerrit, which is (AFAIK) the open-source grandchild of Mondrian, and yes, if your patchsets sit in review for any appreciable length of time (more than a few minutes), it does indeed start to look a lot like the short-lived-feature-branches approach that Paul Hammant describes. If somebody's Gerrit build is failing, I will sometimes fetch it, fix the bug, and submit a patch back to Gerrit. This probably happens once every couple of weeks. I am not sure that we have yet used pending Gerrit reviews as areas for deliberate, planned collaboration ... but it will probably happen sooner or later.

@maxkirillov:disqus: I think that developers use scms locally, but that those branches remains out of the corporate radar. I think they do so for two main reasons:

- It probably makes easier the corporate scm administration (keeping it responsive when you have a massive code line is probably nothing short from a nightmare and I guess they feel that branches are just dead weight).

- it may make the code changes easier to test (specially in a multi-platform context) with smaller chunks to consider.
- dichotomies can be performed in the main line (this may be helpful for organizations that have a huge number of automated tests at their disposal and cannot run all of them on all commits).

@wtpayne:disqus : you might be interrested in the following (https://github.com/vadims/g... ) once you want to get into planned collaboration ;)

Thanks to you both for your answers.

Amine Chadly - Thanks for the heads-up on the Gerrit plugin.

I was talking about this with one of my colleagues earlier today, and it looks as if we might use secondary repositories to support pre-review collaboration.

I should mention though that I am pretty wedded to the C.I. model of development, so I don't really like anything that distracts people from a focus on doing tiny bite-sized bits of work and integrating very very frequently. (A pre-review "throwaway" integration testing repository might be OK, though).

Thanks for the great conversation ;)
I think additional repositories is too much overhead (admin work + merge pain).
I lean towards strong code ownership, pre-commit testing + optional review ;)
But anything that works for you is just fine !^^!

I can't recall where I read it, but there's a blog post somewhere on the Internet documenting at least Google's process. Basically, when you attempt to commit code, a snapshot of the repo is taken, and all tests in that snapshot that might be affected by your changes are run before your code is actually committed - which tests those are is determined using dependency analysis.

This doesn't necessarily mean bugs don't make it to production, it just means that builds are very unlikely to fail - in fact, they can fail only when two commits happen concurrently and the changes they introduce collaborate to break the build, or when the dependency analysis misses some tests, and those do break due to a change being committed. Both of these situations are highly unprobable, provided commits happen often and don't take long to finish.

Very cool that matter, actually generates much discussion, they know where I can find more about it?

If you think 100% of the reasons that you use source control are not related to version control, so why not solve the problem instead of adding another?