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.

Improve this question
7
  • 2
    How does he motivate this idea by the way? If he haven't given you any reasons, have you asked?
    – Anto
    Commented Apr 27, 2011 at 21:20
  • 8
    Does "Joe" understand Branching? Some gentle questions to find out could be interesting.
    – James
    Commented Apr 27, 2011 at 22:28
  • 2
    @Anto - I think it's best summed up by "it’s not production and should not be part of a production repository".
    – Mr. Jefferson
    Commented Apr 27, 2011 at 22:45
  • 1
    @James - I don't think he knows SVN in general very well, so no, I don't think he does know about branching. But given the responses below, I think that's the solution.
    – Mr. Jefferson
    Commented Apr 27, 2011 at 22:46
  • 4
    Read this question and a little voice in my head just screamed "NOOOOOOOOOOOOOooooooooooooo".
    – Kevin D
    Commented Apr 28, 2011 at 8:06

13 Answers 13

Reset to default
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.

Improve this answer
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.

Improve this answer
4
  • 6
    Please emphasize the branching and tagging issue. It's -- I think -- the important feature that causes folks to insist on production-only in SVN.
    – S.Lott
    Commented Apr 27, 2011 at 21:40
  • 3
    an excellent point, even with your bias against vodka.
    – Covar
    Commented Apr 27, 2011 at 21:44
  • Pretty much? I'd say he is dead wrong. No question about it.
    – Steven Evers
    Commented Apr 27, 2011 at 22:06
  • 2
    @Covar: I don't pollute my vodka with vermouth :)
    – Wyatt Barnett
    Commented Apr 28, 2011 at 0:09
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.

Improve this answer
6
  • 12
    But he is not skilled in working as a team member.
    – Ladislav Mrnka
    Commented Apr 27, 2011 at 21:28
  • 2
    @Tom Hamming: Cutting code is not developing software. I'm sure he's good at programming, but these days version control isn't a 'tool' anymore than the IDE is a tool. Sure, you can technically do without it, but no-one in their right mind does.
    – Steven Evers
    Commented Apr 27, 2011 at 22:01
  • 2
    @SnOrfus - While I agree to a certain extent about the utility of SCM, my purpose with this question is not to bash Joe and/or his skills as a developer. Again, he turns out great product, he's knowledgeable, and he's done fine without SCM for the past 10 years. My objective with this question was to see if his perspective was a widely-held one that I had simply not encountered; I am, after all, just out of school and relatively inexperienced in this industry. In any case, I do believe he honestly wants to ensure quality and reliability of workflow.
    – Mr. Jefferson
    Commented Apr 28, 2011 at 5:06
  • 3
    @Tom: I can tell you right now that regardless of what you think of the quality of his work, he is not a skilled developer if he doesn't know how to properly use source control. There is no other option, other than that maybe he's been working alone in a basement. Even in my own projects where I'm the only developer, I use source control to its fullest extent.
    – Jordan
    Commented Apr 28, 2011 at 20:25
  • 5
    @SnOrfus: I can work very happily without an IDE. I won't work without version control. If the team isn't using it, I'll run it on my own.
    – kevin cline
    Commented Apr 29, 2011 at 1:33
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.

Improve this answer
8
  • 1
    I've thought about this and done a little bit of investigation (and heard good things), but my hesitation lies in the fact that we've already got VisualSVN Server purchased and installed, and neither of us have any experience with Git or Mercurial. It'll be even more of an uphill battle if I try to convince everyone we need to buy more software and/or throw away an existing investment. But good point.
    – Mr. Jefferson
    Commented Apr 27, 2011 at 21:26
  • 3
    @Tom: If it has to be Subversion on the back end, you can use Git's or Mercurial's Subversion interoperability layer for the stuff that's not production ready, and push the work into subversion when it's ready.
    – Ken Bloom
    Commented Apr 27, 2011 at 22:05
  • 2
    @Tom Hamming: I switch from SVN to GIT nearly one year ago. After some initial swearing, I started to love it (although under Cygwin it doesn't work as good as under Linux). I never spent any money for it, I'm quite satisfied with the command line and the two free tools included. I don't even work to integrate it into my IDE (eclipse). YMMV, but if I were in your place I'd use my private git repo and git svn for the interaction. You don't need to buy anything and you don't need to convince anybody; they don't even need to know.
    – maaartinus
    Commented Apr 27, 2011 at 23:51
  • 1
    @Tom Hamming: As an individual developer, you can choose to regularly git push your changes to some other machine (as a backup). It doesn't have to be the "master" repository.
    – Greg Hewgill
    Commented Apr 28, 2011 at 0:39
  • 1
    @Tom Hamming: Sticking with SVN because you've purchased and installed an SVN server is really a sunken cost fallacy. Git and Mercurial are both free, and the cost of VisualSVN has already been paid, so look at your options as going forward each has the same (zero) initial setup cost.
    – Cercerilla
    Commented May 4, 2011 at 14:17
7

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

Improve this answer
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.

Improve this answer
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

Improve this answer
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.

Improve this answer
1
  • SVN can do that too.
    – Phil Lello
    Commented Apr 28, 2011 at 4:40
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.

Improve this answer
1
  • dollar investment in svn server would be no more than the dollar investment in a git repo server...
    – TZHX
    Commented Apr 28, 2011 at 8:07
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
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).

Improve this answer
2
  • Interesting that you should note that binaries were included. A separate discussion we have is whether to include the compiled binaries in source control. I say no, because it wastes space and means that you can dirty your checkout simply by compiling. Why were compiled files historically included?
    – Mr. Jefferson
    Commented Apr 28, 2011 at 15:42
  • the binaries were included because it was impossible to recover the sources of a release reliably. So the binaries were stored instead in case they would ever be needed to restore a server to an older release... Compromise based on bad decisions made years earlier.
    – jwenting
    Commented Apr 29, 2011 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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