Open Sourcing with (Imperfect) Revision History?

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?"

Publish the current version

[str8edge]

Why bother deaing with old or historical releases? Unless there is functionality or features lost in the current release that someone could resurrect by going through the historical code, there really wouldn't be any advantage.

Dont split the history

[mrderm]

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.