Open Sourcing with (Imperfect) Revision History? 27
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?"
No good deed... (Score:5, Insightful)
Start fresh from the latest version. (Score:5, Insightful)
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
Publish the history (Score:3, Insightful)
Re:Publish the history (Score:2, Insightful)
Learning utility (Score:4, Insightful)
value of information is always positive (Score:3, Insightful)
so... realease as much as you can.
Bugs may bite sometimes (Score:2, Insightful)