Erik Huelsmann wrote:
>>>>i.e. "Subversion supports the following platforms Windows 2K, XP,
>>>>solaris xxx, RedHat Linux > x.x, Debian > x.x. Also required are
>>>>Apache > x.x, etc."
>>>
>>>
>>>We don't enumerate all Linux distros, but in the README there is a list
>>
>>of
>>
>>>all prerequisites:
>>>
>>>Apache
>>>APR
>>>Neon
>>>Berkely DB
>>>libxml / expat
>>>libz
>>>gettext
>>>etc.
>>>
>>>
>>
>>This is good. I think you should also list version numbers and stick to
>>them. That way users would have more confidence that they won't have to
>>replace their OS just to upgrade subversion. Today I've seen RedHat 9.0
>>described as EOL. It's less than 2 years old! Granted, I primarily
>>blame RedHat itself for this state of affairs. But still, what features
>>above what the current version of these packages support does Subversion
>>need? Being conservative in what features you'll be using from
>>dependency packages will increase subversion's stability and require
>>less of a bleeding-edge mentality.
>
>
> Some of the dependencies listed are dependencies of dependencies: Apache and
> Neon can build against libz, Neon builds against libxml or expat. We can't
> really make any promises about which version will be the minimum for any
> period time for the deps of deps.
>
> Also, since we built on non-1.0 software (or at least development software
> as in case of SWIG 1.3), we can't guarantee we won't require a new version
> next 1.x release: for example Neon will have some crucial fixes in its 0.25
> release we need to provide better user experience [interruptable checkouts].
>
>
>>>Having a list of minimum requirements by itself does not assure you of
>>
>>that.
>>
>>>Only the intention to keep them stable will help you there.
>>
>>Agreed. That's what I'm asking for.
>
>
> I'm sorry, but we do the best we can. We can't guarantee it. After all, you
> want next releases to get better for you too.
>
>
>>You haven't answered my question. If you can't say, we'll work with any
>>apache back to v. x.x.x and plan to keep it that way, you do not enhance
>>your reputation for stability.
>
>
> Well, I think the example was poorly chosen: of any webserver you can run, I
> think Apache is the most stable one available (depending on which modules
> you load ofcourse).
>
> Apart from that: we try to keep ourselves to patch releases. In case of SWIG
> 1.3, that does not help as even patch releases are just not compatible. In
> case of Neon, a new feature will have major usability consequences (for the
> better). I think *not* adopting such new versions costs us users too.
>
> BTW: Software stability and keeping up with newest version releases might
> not be conflicting. Adopting new code of our own too soon and carelessly is
> going to have
> much more impact.
>
>
>>>Have a look at the testimonials page to see who's using svn:
>>>http://subversion.tigris.org/propaganda.html
>>
>>I'm sure they are. But simpler installs are a big part of "ready for
>>prime time." At this point in time, I would not dream of recommending
>>that my employer adopt subversion. It demands a higher caliber of
>>developer than those I've seen there. Without a GUI, many of them are
>>lost. I hope to be able to recommend subversion there once there is a
>>stable subeclipse. You guys are making progress. Keep it up and you'll
>>get there.
>
>
> Well, in my opinion, 'simple installs' should use pre-built binaries. As
> soon as you have to build yourself (for whatever reason), you just aren't a
> simple install anymore. I'm sorry the summersoft rpms did not work out,
> since that obviously is a BFI (Bad First Impression). I'm affraid it doesn't
> mean anything about the Subversion software though.
>
>
> bye,
>
>
> Erik.
>
For whatever reason? I was happy enough with the prebuilt binaries
(they only took me one whole weekend to load). But if I wanted to use
subclipse I had to have javahl (too slow otherwise). And if I wanted to
have javahl I had to build from source. And that led to a bunch more fun.
Perhaps the subversion team needs to clarify what its "support" for
RedHat 9 and earlier means. Perhaps you need to say going forward that
users of these systems are pretty much on their own after subversion
1.x.y (whatever x and y are). I wouldn't blame you for this. I'm
pissed at RedHat for dropping support for a distro less than a year old.
(Then again, I didn't PAY for it, so who am I to complain - but it is
an unwelcome change from a pattern that I was previously used to from them).
I can understand why subversion is not ready yet to put a line in the
sand and say what its minimum configuration going forward is going to
be. But there is a price you pay for this, and no, it's not all your
fault, and maybe it's not too high.
When you say it doesn't mean anything about the Subversion software
though, I disagree. Subversion is the whole package, not just its core.
As difficult as that may be for you to accept, I think you need to
accept it. You will be judged by it, just as CVS is judged by its
Eclipse support.
I'm still willing to help you guys as much as I can, with my postings of
whatever educational value my various missteps may have, but you're in a
difficult place. You're placed yourself in a market developing software
with developers as your end users. We're one tough crowd. As long as
your product requires users to make OS-level changes, it won't be easy
for you.
Anyway, I have the whole package up and running now. It took me two
weeks. But I did it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 16 03:08:20 2005