At 15:04 12.04.2001 -0700, Craig R. McClanahan wrote:
>On Thu, 12 Apr 2001, Ceki [iso-8859-1] Gülcü wrote:
>
>> At 12:55 12.04.2001 -0700, Craig R. McClanahan wrote:
>>
>> [removed text]
>>
>> >> Why do you think that it is wrong to have binaries in CVS?
>> >>
>> >
>> >All the disadvantages you listed.
>> >
>> >All the disadvantages Sam listed.
>>
>> Sam objects to early binding. In other words to packages assuming a
>> certain version of a dependency project where different versions of
>> the dependency package behave differently. Is that correct?
>>
>> I fail to see how this is *directly* related to putting binary files
>> in CVS. Gump works regardless of what people put in their CVS modules.
>> Right?
>>
>
>Gump does that by overriding properties (same as a build.properties file
>does in the proposed approach).
Build.properties in the proposed approach? Doesn't compute.
> Given that you can make it work without
>JARs in CVS, let's turn the question around - what does it buy you to have
>them there?
>
>Yes, it's nice to newbies to have the defaults set up to minimize the
>effort of trying things. But that can be accomplished in other ways,
>without the disadvantages.
You are suggesting that users download the necessary dependencies using a mechanism
other than CVS. Right? While that is certainly reasonable it is not clear if any
fundamental issues are solved by this approach.
>> >The irrationality (IMHO) of checking generated artifacts into a source
>> >repository (same goes for HTML that's generated from XML in some projects,
>> >but we won't go there right now ;-)
>>
>> :-) That is a different issue.
>>
>> >The fact that, once in a while, you have to do maintenance on a dialup
>> >connection instead of a nice fast DSL line. Case in point -- I had to
>> >update jakarta-site2 while at O'Reilly Enterprise Java over a modem
>> >connection, just after all the checked-in JAR files were updated to recent
>> >versions. It took 45 f*cking minutes to do the CVS update. Suffice it to
>> >say that the web site can go hang the next time I'm in that position.
>>
>> I certainly empathize with that. One question that needs to be asked
>> is whether placing the updated binaries in CVS is the culprit.
>>
>
>The "jakarta-site2" repository has the following JARs checked in:
> Ant 1.3 (296k)
> Jdom "b6" (78k)
> Velocity 1.0 (370k)
> Xerces 1.3 (1605k)
>
>All four had been updated.
>
>> I just compared downloading ant.jar (295'948 bytes) using CVS update,
>> scp and http. The results were roughly the same. A 512Kbit/sec link
>> was used to perform the tests. Results may vary depending on server
>> load.
>>
>> Assuming performance scales up or down linearly with bandwidth, then
>> the logical conclusion is that the problem lies with the automatic and
>> recursive updating done by "cvs update" and not the cvs/ssh channel
>> per se.
>>
>> Probably, what you really wanted was to update the files under xdocs/
>> but not the jar files under lib/.
>>
>
>I could certainly do that, but what if someone updated a doc and needs one
>of the new features? Doing this (re)creates a version incompatibility,
>which would defeat the whole point of having the JARs in CVS in the first
>place.
Exactly. The problem is not with CVS or any other distribution mechanism. Or? The
binaries changed and needed to be updated one way or another. CVS is one relatively
convenient way to do that. Did you have a more efficient approach in mind?
My current goal is to understand why some developers consider CVSed binaries as being
evil personified. With all due respect, I have yet to see a convincing argument to the
inherent evil in CVSed binaries. On the other hand, the advantages of CVSed binaries
are not that decisive either. Live and let live, et cetera, etc.
This is beginning to feel like "un coup d'epée dans l'eau" or striking water with a
sword. Regards, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
