Thursday, 1 November 2007

Don't check in binaries!!!

How difficult is source control to understand??? I can understand keeping libs in source control (I don't agree with that anymore), but why the hell do people check in binaries of the project they are working on? You don't check in the /bin or /target directories (or whatever it is in your project).

Is this a difficult thing to understand? When you're doing a commit and (in the case of java), you see that you are checking in .class files, doesn't that cause you to pause and stop?

Agghhrrrhggh!!!

5 comments:

  1. I agree ...but not quite as far. My version of the rule is not to check in anything to source control which can be generated from source already in the project.
    External JAR libraries are excluded from that rule because specific versions of the JARs are required for the project to compile. The project should be easily buildable right out of source control, assuming the person has the correct version of Java installed.
    Having said that, these external JARs should have version numbers on the filename and removed when they are updated to the next version or no longer needed.
    Other types of binaries, like images, are also nice to have in source control. The project should be self-contained.

    ReplyDelete
  2. Sorry, when I said binaries I meant the ones built from the project - I exclude things like images.
    After using maven for a bit, I'm okay with external libs NOT being checked in. Check-ins/outs are faster and you don't end up having 1000 copies of the same jar in your corp source control. I enjoy tools that can pull in the needed libs from the net / lan without me having to do anything.
    They have something like that for Ant, but I can't recall what it's called...

    ReplyDelete
  3. As long as the needed libs are the correct version!
    I don't see why you'd need 1000 copies of the same jar. Check it in once and you're done. Over the life of the project it might be updated a dozen times.

    ReplyDelete
  4. As, yes, as that's true.
    Since using maven I've really enjoyed the whole "standard" naming of files and how it gets it auto-magically... As long as someone doesn't corrupt the public repo, it's all good.
    Sorry, I didn't think that I explained myself very well. If you are making a rails app, and it needs 5 libs to run, you check them in. Now you make 20 app's per year like that: 100 libs. Over 10 year: 1000 check-ins of the same lib.
    That's a pretty brain dead example, but I'm pretty brain dead right now. Time to go home. :-P

    ReplyDelete
  5. Yeah, but how big is a library really? A couple megs? Unless you are using some really big library, it's probably best to keep it in source control with the rest of the project. Have you ever checked out these size of your repository. Something like SVN which only saves the changes can actually keep quite a bit of change history in a very small space. Only once you start adding images that are constantly changing do you ever run into large repositories. And besides, storage is cheap now. you really shouldn't worry too much about the size of the repository.

    ReplyDelete