Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Sourcing with (Imperfect) Revision History?

Posted by Cliff on from the missing-dependencies-frustrate-compilers dept.

AArnott asks: "My company is open-sourcing a private project that has been in development for 4 years. It's history is all in our internal Subversion server. The history of the project includes dependencies on source code that we are not open-sourcing. Should we just publish the latest version (now that we've removed the dependencies) and leave out the old history? Or should we publish the history, even though no previous revision will build, due to the dependencies that we are not including?"

4 of 27 comments (clear)

  1. No good deed... by Otter · · Score: 4, Insightful

    The only thing releasing the full Subversion history is going to get you is complaints from idiots that you're violating the GPL by not open-sourcing the dependencies. I applaud your concern for thorughness but just go with the current version.

    --
    What I'm listening to now on Pandora...
  2. Start fresh from the latest version. by rossifer · · Score: 4, Insightful

    Just start a new public repository with the latest good version. Keep the history, but don't worry too much about making sure that everyone has access. Long term storage is fine.

    CM systems improve communication between developers by allowing them to synchronize their work as well as preventing simple developer mistakes from turning into massive code rewrites (but you don't need more than two weeks of history to accomplish these goals). The reasons you usually carry around all of the extra baggage of the old versions is for (1) establishment of legal ownership (copyright information) (2) simultaneous maintenance of multiple versions in the field and (3) to show some history of how you got to where you are.

    Legal ownership is important, but you get that by keeping a few backups in your long-term storage. You don't have versions in the field (not of the open-sourced version anyway) so that's a moot point. The "how we got here" argument is also of minimal value as long as someone who knows the code is still around. The knowledge of how things were developed in a decent developer's head will be much easier to use than attempting software archeology on a stale file repository.

    Regards,
    Ross

  3. Learning utility by hackwrench · · Score: 4, Insightful

    When learning about certain code bases, I find it extremely valuable to start with whatever beginning code there is because it illustrates the core concepts while not being a thicket of code. It also helps to see what design decisions were made and then rescinded.

  4. Dont split the history by mrderm · · Score: 3, Interesting
    Ignoring whether the old history will be useful to anyone outside your organisation, it is more useful to you if it is all stored in one place. 'svn blame' works, and it is one less thing to explain to new engineers who join your organisation.

    I went through this with my current company a few years ago, and we decided to publish only the current revision. I wish we hadnt.