21

I graduated from college in Computer Science a year ago, and am now working at a small web development company (me and one other developer, plus managers, customer service and tester). Until just before I started, there was no source control system. We're now slowly starting to implement SVN, but the other (senior) developer (henceforth referred to as Joe) insists that the only code that should be committed to our SVN repository is that which has been tested and approved as production-ready. That means that, on larger projects, there might be no commits for weeks at a time or more.

Is this a normal practice? It seems to me like we lose a lot of the benefits of source control, including:

  • Fine-grained tracking of project progress
  • Tracking of issues as they appear and are resolved
  • Easily rolling back mistakes
  • Easy backup of code, so we don't lose much if a workstation goes down
  • Easier to identify exactly what code is running in which production sites, assuming we stamp revisions into executables as described here
  • Easy collaboration (though we don't do any teamwork; it's all solo projects)
  • Etc.

EDIT: I should emphasize that historically, there hasn't been any true teamwork in this company; just two developers working on separate projects. Also, a lot of the projects are small, so they can be completed in a couple of weeks. And the company has been in business for more than a decade and has gotten along fine without source control. Projects are usually completed within their estimated timeframe.

Community
  • 1
Mr. Jefferson
  • 1,361

13 Answers13

42

Joe is pretty much dead wrong. Now, you can make the argument that you have one "clean" branch that represents the vetted, production-ready code. But not using source control until stuff is ready is frankly self-defeating. Kind of like trying to make a martini without the gin.

Wyatt Barnett
  • 20,787
22

The "senior" is actually very unskilled. Any code which can be compiled (and passes tests if you have them) should be committed to source control. Source control is central asset for sharing code and building SW incrementally.

The good point is separating production code (last stable version) but for such case source control systems contains features like tags / labels and branches.

Our team takes very suspicious if somebody does not commit anything within two-three days. It means that he has some problems and perhaps needs help. Another point of source control is that it is usually regularly backed up which is not the case for development machines. If your disk crashes you lose your work for several weeks.

Ladislav Mrnka
  • 7,356
12

Putting aside the question of whether Joe is right or wrong (he's wrong, by the way), it seems to me that a compromise could be reached if you used a distributed version control system like Git or Mercurial.

That way, yourself and the other dev would work on your local repository, committing your changes to source control early and often, but not push your changes to the "production" repository until they are "tested and approved as production-ready". You'd have a full history of every that you worked on over the course of weeks, and Joe would have a pristine repository which only had the history of changes that were blessed as ready for production.

Carson63000
  • 10,490
7

It makes no sense, for the very reasons you listed. It is like using version control without the benefits of using version control.

Anto
  • 11,197
5

I believe Joe has not understood that source control systems are not glorified backups of source code production releases, but a helpful tool for programmers by putting words on the smaller steps of code progress and maturation for your future self and colleagues. Perhaps Joe is not accustomed to working in teams with other peoples code?

Ever considered "why was this code line added"? Locate the commit that introduced it, and see its comment. If you only commit when going in production, the comments will not be specific enough to be useful to you.

I would also suggest that you use a more powerful tool than SVN. You can see a good introduction on the possibilities at http://hginit.com/ by Joel Spoelsky.

He uses mercurial, and there are several contenders these days. Git is considered very powerful, and https://github.com/ has some very, very useful tooling and provides free starter accounts so you can try it out for real.

3

Joe doesn't look like knowing about SVN, try to find out about Branches, Tags and Trunk... Tags is consistent with what Joe wants. Some reading on SVN best practices wouldn't hurt

IvoC
  • 139
2

Never used SVN so I don't know what the procedures for this would be. We're using ClearCase, and the practice around here is for each developer to have their own development branch, then an integration branch that we merge to when we're ready to start testing, and one or more release branches for integrated and tested code.

John Bode
  • 11,004
  • 1
  • 33
  • 44
2

Joe is a hacker, not a developer. He sounds like a very good hacker, but he is wrong about how to use revision control. So what to do about it?

It seems to me your organization has an investment in SVN, and it would be career limiting fro you to challenge Joe and invalidate the dollar investment in the SVN server. Set up a GIT repo and use git svn interface to work the way you want to (This is all free software and will take a an hour to a day to setup, all on you workstation). Socialize your workflow with Joe - he can preserve his "unpolluted SVN repo" belief system and maintain his credibility over the expensive white elephant in the corner (and ego).

In a short time I expect Joe will look at how you work, and start doing the same. In a year or two, the SVN server will become a Git repo.

mattnz
  • 21,490
2

You could try to convince Joe with the arguments above. If this doesn't succeed use SVN locally for your own development work and hope it will sometime be picked up by Joe. If you can't convince them with arguments do the thing your convinced of and show them it works. Kind of the distributed approach but with the existing tooling.

refro
  • 1,386
2

I'm going to echo @Carson63000 here and say that I've seen this attitude before, and it's largely caused by the horrible branching/merging capabilities of the VCS. Having a branch that compiles and passes tests, with tags for each release, is a great approach but it shouldn't be followed to the point that no other code is committed. DVCS in general, and git in particular, make branching an easy and common operation and it reduces a lot of the difficulty with this workflow.

Cercerilla
  • 1,969
1

If projects are completed within their estimated timeframe, is it safe to assume that the clients are happy clients? :)

It seems that the company is starting to take on new types of projects as well and going through some growing pains or some "shifting pains". Lots of assuming going on here... Please bear with me!

If you are confident that the organization and control of the code can help you and your team internally then SVN should be considered, IMHO. You get bonus points if going this route actually works and the company is able to make higher quality products therefore making happier customers!

Be careful if it seems that a struggle with management is going to make a tense work environment. The fact is the owners have made the company. And not only that, they have made a successful company. It is unlikely they hit a jackpot because they're good at gambling.

Be respectful and you may end up being heard.

Hopefully this will end up resulting in a more efficient and happier team. In my experience, that is difficult to obtain with frustrated management.

1

The reason version control systems support tags is because you can tag the certified code and still have your everyday work commited. Whenever you have production quality code you commit it grate a tag and you are done. You know the exact point in 'time' you have to go back in order to get what the customer has. And you can always check and compare different versions of your code. This way you can both be happy with what you have in the source control data base. It works for the company I work for, which has 100 developers, all working on the same project. It wil deffinately work for you as well.

Gus
  • 368
0

It's quite common to only store things in version control systems that are ready for delivery to production. That's how it's been done historically for decades, since the olden days when disk storage cost hundreds of dollars per megabyte and storing everything was just too expensive.

It's no longer considered the best way to do things, but I can fully understand why people still do it, as many older version control systems are still in use that make it hard if not impossible to do anything else and still retain knowledge of what your each release is (or rather, there's no way of knowing what any release is without checking the tags on each and every file if you do need to go back. I've seen more than one repository where the only way to get back an old release was to retrieve from the repository a zip file with the source code and binaries for that release).

jwenting
  • 10,099