For whatever it's worth, my $.02 as a Subversion newbie:
I can empathize with the disappointment that a project as large as
Subversion has no binaries. My life would be a lot easier if binaries were
available, and I too get disappointed when binaries are not available for
releases.
[You're also welcome to use any binaries I create if it's easy for my to
package them (eg, if I can get checkinstall to work on my Redhat9
system...which it's not...see my other thread). Not sure if Windows has a
nice package thing. But you're on your own for support. Ask me later if
you're interested, I'll gladly provide stuff, but with no strings attached.]
Having said that, here's my _experiences_ with managing binary
distributions that made automated-binary-control-and-release difficult for
my corporate process (for those who might wish to debate these points,
please remember: these comments reflect my past *experiences*, and I'm not
necessarily saying that all projects are like this, but I do believe that
it might hold true in this Subversion case):
* Binary auto-builds across diverse platforms proves challenging
I've managed projects that built releases across 6 different unix platforms
plus Windows (and this was a cross-platform, multi-client-and-server
architecture much like Subversion). Albeit this was back in the
mid-to-late 90's, this was a rather difficult process to setup and
automate, and it required significant budget from a large company that made
$50MM (grew to $250MM) total revenue. It wasn't easy.
Having said that, maybe the Windows platform could be specifically targeted
for an auto build first if that was ever done.
* Managing binaries can be tougher then managing source
Binary distributions have to be pristine and general (static- and
dynamic-library management, etc, among other things), and I found it a
challenge (although it was a fun challenge) for me to get around all that
stuff.
Furthermore, Subversion has a lot of other 3rd-part application integration
stuff, namely Apache and Berkley DB (although I'm happy to see the latter
dependence mitigated with fsfs) and others. Seemingly even more difficult.
When built from source, your building (presumably) from the system you'll
be using, or something similar because it's in our environment. On the
flip side, the binary files are not exactly the same across the world, and
thus maybe harder to track bugs, etc.
* User-admin understanding increases significantly when building manually
(I call it "user-admin" instead of "user" because I define a "user that's
being an administrator to other users.") When building on your own, you're
forced to learn a lot more, whether you like it or not. This certainly
helps the people supporting the community, and it probably helps the
builder, too. The cost up front can be problematic given the situation,
though. In such a case, you have a choice: use an older build that has
binaries.
* The target usage market already knows how to manage builds
If you're using the "latest" release of Subversion, you're probably already
managing software builds. And if you're already managing software builds,
then you probably are not intimidated by building Subversion--just maybe
inconvenienced.
* General consensus: create product value rather then automation
I suspect (and we are seeing it in this email thread--wether or not the
thread is indicative of the general usage community, I don't know) that the
user community would prefer that Subversion first get better then get
automated. I agree with this approach. I'll take the time to build it;
I'd rather have those in the "flow of the know" (as I like to call it)
stick with what they are good at, and that's enhancing Subversion value by
adding features, fixing bugs, and in the process getting a better
understanding of their target usage market...and I'd rather do the mundane
stuff of building and save on these precious development resources...for
now. (There may be a point where it just gets HUGE...and I'm hopeful that
people like use--as in admin-users--and others will hopefully have
developed more auto-build processes on our own that we can flush
recommendations back into the "system" and everyone can benefit.)
* Oh yeah: it's free of charge
There's that little point. I'm sure VSS or Clearcase or Perforce will
happily take one's money if one can not accept
lack-of-quick-binary-release-for-new-release syndrome. But alas, we're all
here for a reason, and I'm sure many of us don't want to go back. ;)
There's my $.02, for better or worse.
Enjoy 1.2-rc1. I have been thus far. I'm sure I'll have more questions
later...because I'm a newbie.
-Matt
At 4/12/2005 11:42 AM, ed.wittmann@fiserv.com wrote:
>Probably because of the list of dependencies. The Subversion team would
>spend as much time supporting a binary version as developing - it's far
>easier for them to hand out a list of dependencies and a good makefile.
>
>You should try build from source - you can learn a lot from it. I'm not a
>developer at all, and I know I have. It takes like 4 hours to setup and
>build totally from scratch, and that's with absolutely no previous
>knowledge. And if it broke, you'd have far more people willing to help you
>out than you'll get by indignantly demanding binaries.
>
>The team has probably spent more hours making sure the Subversion will
>compile cleanly on Windows than they have on Solaris (my platform of
>choice). No binaries probably because then you get requests for every
>platform under the sun (no pun intended), "Why isn't AmigaOS supported
>with binaries???" "My iPaq segfaults and I installed your binaries".
>
>Honestly, the ability to understand how the tool is built is quite helpful
>in understanding source code development itself. This isn't elitism at all
>- you simply will understand the product and the requirements better. And
>if you don't want to build (which is not totally unreasonable), someone
>will eventually get the binaries out for you - you just have to wait a
>bit.
>
>I'd rather have the Subversion team fixing bugs than packaging
>distributions.
>
>
>-----Original Message-----
>From: Eric J. Smith [mailto:eric@ericjsmith.net]
>Sent: Tuesday, April 12, 2005 12:10 PM
>To: users@subversion.tigris.org
>Subject: RE: Subversion 1.2 RC1 Binaries
>
>First of all, let me say that I think Subversion is awesome and I really
>appreciate the efforts of everyone involved.
>
>That being said, how ridiculous is it that a project as huge as Subversion
>doesn't have official binaries? It seems pretty ridiculous to me. Even
>without "official" binaries, it seems like a project this big would at
>least have an unofficial repository where automated nightly builds and
>releases are stored. Are there no corporate sponsors that would be
>willing to provide a build server?
>
>I'm not ungrateful for the efforts of everyone involved here, but I am
>just pointing out what I think is a huge hole. I mean, how are we
>supposed to help test these releases if there aren't any official
>binaries?
>
>Eric J. Smith
>
> > I don't know if you noticed it (it's a bit buried, halfway down the
> > page), but the following statement appears on the download page on the
> > Subversion website:
> >
> > "The Subversion project does not officially endorse or maintain
> > any binary packages of the Subversion software. However,
> > volunteers have created binary packages for different
> > distributions and platforms, and as a convenience, we maintain a
> > list of links to them here."
> >
> > If the generous efforts of these volunteers doesn't meet your
> > schedule, perhaps you should volunteer to prepare Subversion binaries
> > for the Windows platform yourself?
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 12 19:57:30 2005