On Mon, Jun 21, 2010 at 7:50 PM, Ross Finlayson <span dir="ltr">&lt;<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I don&#39;t use any revision control system myself.  When I&#39;m developing this code, I use exactly two commands: &quot;emacs&quot; and &quot;make&quot;.<br>
<br>
Each source code release - in &quot;tar.gz&quot; form - is less than 500 kBytes in size.  These days, that&#39;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&#39;s all that we support.<br>
</blockquote><div><br>It&#39;s not about bandwidth, it&#39;s about having a clear history of all changes made to the project, and when.  It is extraordinarily difficult to isolate regression without this.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
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&#39;ve made custom modifications to it (i.e., without losing their modifications).  I&#39;m sorry, but this is something that I explicitly want to discourage.  People *should not* be making modifications to the released &quot;LIVE555 Streaming Media&quot; code (i.e., inside the &quot;live&quot; 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).<br>
</blockquote><div><br>This is simply not true--I do not want source control so I can &quot;easily update to the latest version of the code.&quot;  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.<br>
<br>Furthermore, most programmers *refuse* to use trunk (this is considered extraordinarily unwise by every decent program I know), which is basically the policy you&#39;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&#39;m going to have to disagree with you; I think your hypothesis here is flat-out wrong.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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 &quot;protected:&quot; instead of &quot;private:&quot;, then please let us know.</blockquote>
<div><br>Has absolutely nothing to do with this.  It&#39;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.<br>
<br>I don&#39;t expect you to find these arguments compelling, and that&#39;s fine--I&#39;ll continue to cache away versions of the library so I can roll back to work around regression introduced in subsequent releases.<br>
</div></div><br>