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). 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.
> >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.
> So the automatic update done by CVS eases the distribution of binaries
> but also increases the communication/networking overhead. The overhead
> is particularly irritating if the changes in the binary are minor.
>
> In other words, putting binary files under CVS decreases the need for
> developer to developer communication but increases computer to
> computer communication. Cheers, Ceki
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
