[Chandler-dev] Using svn instead of builds for tarballs?

[Andi Vajda]

On Fri, 10 Nov 2006, Phillip J. Eby wrote:

> At 11:01 PM 11/9/2006 -0800, Heikki Toivonen wrote:
>> Andi Vajda wrote:
>> > On Thu, 9 Nov 2006, Heikki Toivonen wrote:
>> > I know, I know.... the logic is incomplete though, if svn tends to be
>> > unavailable more often than builds, then putting all eggs into the svn
>> > basket
>> > would be unwise. I sure don't know that that is the case, I was just not
>> > convinced by the argument...
>> 
>> I don't understand that logic.
>> 
>> Currently:
>> 
>> svn | builds | can checkout and build
>> =====================================
>> no  | no     | no
>> no  | yes    | no
>> yes | no     | no
>> yes | yes    | yes
>> 
>> All in svn:
>> 
>> svn | builds | can checkout and build
>> =====================================
>> no  | no     | no
>> no  | yes    | no
>> yes | no     | yes
>> yes | yes    | yes
>
>
> While I'm not advocating *either* approach, I do want to point out that your 
> tables above are misleading because they don't take uptime percentages into 
> account.  If SVN and builds are up 99% of the time, for example, then 
> buildability is 98.01% uptime in the first scenario, and 99% in the second.
>
> Thus, an argument for going to SVN should probably not focus on reliability, 
> but on such issues as speed, simplification, reduced server maintenance, etc.

While I'm not advocating either approach either, my earlier replies were 
intended to point out that Heikki's proposal seemed to be a solution in search 
of a problem.

The most recent experience I've had with this is with Java Lucene. PyLucene, 
when built from Java Lucene svn sources, does an 'svn export' of that tree.

A few months ago, a contrib project part of that tree, has started adding a 
growing number of .jar files into the Java Lucene svn repository. 
Because PyLucene only includes some of these contrib projects and because it 
is not so trival to make the 'svn export' more discriminating in a non-brittle 
way, any PyLucene user building from Java Lucene svn sources gets to download 
all these unused jars. A PyLucene user in Belarus, where bandwidth is a 
measured resource, has actually complained about that. For various other 
reasons, such as licensing restrictions, other Java Lucene contrib projects 
download the .jar files they depend on during build.

I guess, I am actually advocating caution with this :)

Andi..