Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
How does he motivate this idea by the way? If he haven't given you any reasons, have you asked? –  Anto Apr 27 '11 at 21:20
6  
Does "Joe" understand Branching? Some gentle questions to find out could be interesting. –  James Apr 27 '11 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 Apr 27 '11 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 Apr 27 '11 at 22:46
4  
Read this question and a little voice in my head just screamed "NOOOOOOOOOOOOOooooooooooooo". –  Kevin D Apr 28 '11 at 8:06

13 Answers 13

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
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 Apr 27 '11 at 21:40
3  
an excellent point, even with your bias against vodka. –  Covar Apr 27 '11 at 21:44
    
Pretty much? I'd say he is dead wrong. No question about it. –  Steve Evers Apr 27 '11 at 22:06
2  
@Covar: I don't pollute my vodka with vermouth :) –  Wyatt Barnett Apr 28 '11 at 0:09

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.

share|improve this answer
    
Oh, I'd agree that he has weird ideas about the tools of the trade, but he's actually a very good developer. He knows ASP and SQL very well, and delivers good product. Let that be clear. –  Mr. Jefferson Apr 27 '11 at 21:28
11  
But he is not skilled in working as a team member. –  Ladislav Mrnka Apr 27 '11 at 21:28
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 Apr 28 '11 at 5:06
1  
@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 Apr 28 '11 at 20:25
3  
@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 Apr 29 '11 at 1:33

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.

share|improve this answer
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 Apr 27 '11 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 Apr 27 '11 at 22:05
    
@Ken: nice suggestion! It seems a bit baroque but it has the potential to allow Tom and the other dev to work "properly" without impinging on Joe at all. –  Carson63000 Apr 27 '11 at 22:52
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 Apr 27 '11 at 23:51
    
@maaartinus: I'll check that out, but it doesn't solve the issue of code backup; if my machine goes down, my modifications are lost, are they not? –  Mr. Jefferson Apr 28 '11 at 0:16

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

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer
    
SVN can do that too. –  Phil Lello Apr 28 '11 at 4:40

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.

share|improve this answer
    
dollar investment in svn server would be no more than the dollar investment in a git repo server... –  TZHX Apr 28 '11 at 8:07

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer
    
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 Apr 28 '11 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 Apr 29 '11 at 6:49

Your Answer

 
discard

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.