On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson <finlay...@live555.com>wrote:
> I don't use any revision control system myself. When I'm developing this > code, I use exactly two commands: "emacs" and "make". > > Each source code release - in "tar.gz" form - is less than 500 kBytes in > size. These days, that's not a significant amount of data to download in > order to get the latest revision, and any bandwidth savings obtained by > downloading from a revision control system instead would be insignificant. > And people should not be using any version of the code other than the > latest one, because that's all that we support. > It's not about bandwidth, it's about having a clear history of all changes made to the project, and when. It is extraordinarily difficult to isolate regression without this. > > I suspect that the real reason why some people want to use a revision > control system is that they want to easily update to the latest version of > the code after they've made custom modifications to it (i.e., without losing > their modifications). I'm sorry, but this is something that I explicitly > want to discourage. People *should not* be making modifications to the > released "LIVE555 Streaming Media" code (i.e., inside the "live" directory). > Instead, they should be leaving that directory as it is, and instead > putting their own code in a separate directory (using subclassing, if > necessary). > This is simply not true--I do not want source control so I can "easily update to the latest version of the code." I want it so I can easily have a history of all changes made, readily available diff files, and an easy way to see when changes have been made. Furthermore, most programmers *refuse* to use trunk (this is considered extraordinarily unwise by every decent program I know), which is basically the policy you're advocating. The open source project I manage has detailed download statistics, and the results are clear: people prefer sanctioned releases as opposed to trunk. So I'm going to have to disagree with you; I think your hypothesis here is flat-out wrong. > If there are parts of the code that make it difficult for people to > customize via subclassing - e.g., some class members that should be > "protected:" instead of "private:", then please let us know. Has absolutely nothing to do with this. It's more like, the only way I can get a diff view of the changes made to the project is to cache away the various releases you put out on a bi-monthly basis into my source control, so I can do a compare. I don't expect you to find these arguments compelling, and that's fine--I'll continue to cache away versions of the library so I can roll back to work around regression introduced in subsequent releases.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
