[suggest] Subversion 1.6.2 fo r RPMforge comments.
nkadel at gmail.com
Wed May 13 14:24:02 CEST 2009
> Message: 2
> Date: Tue, 12 May 2009 13:40:56 +0200
> From: Christoph Maser <cmr at financial.com>
> Subject: Re: [suggest] Re: suggest Digest, Vol 47, Issue 9
> To: "suggest at lists.rpmforge.net" <suggest at lists.rpmforge.net>
> Message-ID: <1242128456.4033.39.camel at HUB8071NC4.financial.com>
> Content-Type: text/plain; charset="utf-8"
> Am Dienstag, den 12.05.2009, 13:12 +0200 schrieb Nico Kadel-Garcia:
>> Fedora users might have excellent reasons to stay away from Fedora 11
>> until after it's released, and since Fedora 7 through 10 are still
>> active, they might appreciate an updated subversion in the RPMforge
>> repository. This is especailly because the new subversion 1.6.x has a
>> better security model (it does not store passwords in clear text
>> unless you explicitly give it permission, and that's a *MASSIVE* old
>> Subversion security issue).
> Well you could backport the security fix to 1.4 for EL4. Anyway people
> have been living with this one for ages i don't see any reason to cut of
> my arm now to get 1.6. to compile on all platforms. Also you could file
> a bug agains fedora 7-10 to have this one included. I don't see to many
> fedora builds in rpmforge anyway.
It's usually easier to switch people over to using git (which I now
strongly prefer), or upgrade them to a more recent RHEL or Fedora, than
to do that extent of backporting. I've been there with Subversion,
writing the SCO OpenServer 5.0.6 port for Subversion. Backporting it is
pretty painful, due to the up to date toolchain needed to build it. I
still prefer git's well-managed SSH key integration, its speed, its
compactness, its support ofr actually deleting material, its superior
merging capability, and its handling of every checked out copy as its
own repository that you can merge or switch to as your central
repository. Subversion still wins in its familiarity, especially to
antique CVS users, its broader availability and its superior TortoiseSVN
client. (Tracking and decoding parallel branches in git is.... pretty
awkward for a long time until you wrap your brain around its displays.)
The fixes are a bit more sophisticated than that: they also provide
hooks into Gnome and KDE wallet applications to hold Subversion keys for
users, much like TortoiseSVN does in the Windows world. But in fact, I'm
someone who's been screaming about Subversion security for roughly 5
years: I'm glad they finally switched that model.
>> And 1.6.2 apparently allows 'svn:external'
>> to store individual files, which allows making tags with individual
>> tags that come from elsewhere for software releases. That makes it
>> much more usable for managing SRPM patch lists and source files, for
> Well sounds like a feature.
> If you really want this to work well we certainly need python24 and a
> newer neon packaged in a way not conflicting with base installations.
> Also if you don't want to overload the spec with conditionals we would
> need different spec files for different target OSes. Something rpmforge
> does not do now.
I saw that yesterday building Subversion 1.6.2 under mock, darn it. I'll
try leaving out the 'autogen.sh' today: Rebuilding your autoconf related
toolchain every time you build a packages is theoretically a good idea,
but very dangerous to stable compilation trees on older platforms.
> My personal focus is on el4 and el5 and my personal opinion is that
> people needing this bleeding edge software should use fedora11 (in 14
In general, yes. I thoroughly agree. RPMforge has been a wonderful
repository for just those little modern utilities being backported to
where I can use them in my production environments.
RHEL 4 has about reached the end of its usefulness to me, though. All
the backporting is getting painful.
More information about the users