[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge bug -- svn:keywords and conflict resolution

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 31 May 2012 15:53:21 -0400

On Thu, May 31, 2012 at 1:45 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Thu, May 31, 2012 at 12:23 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> >
>> This policy is more a result of the community's capabilities than anything
>> else. The decision to not ship all fixes to 1.6 users is a compromise.
>> We were shipping all kinds of bugfixes for 1.6 users between March 2009
>> and October 2011. That is a long time, and as a result the 1.6 line is
>> now very stable. I would say that it is a good fit for enterprise-class
>> long-term support systems for this reason.
>
> Yes, it doesn't seem that bad today.  I'm just pointing out that there
> will very likely be a large user base continuing to run some version
> of 1.6.x for 5 to 10 years in the future.

How is any of this relevant? Even if Subversion keeps a healthy
stream of 1.6.x releases coming out the door regularly none of those
will find their way into Red Hat's packaged version. Red Hat
selectively chooses which bugfixes to include independent of
Subversion's bugfix releases. If they could be convinced to include a
specific bug fix in their package, I do not think it would matter
whether Subversion itself had released that same fix in a 1.6.x
release. If that issue ever arises, and it is preventing Red Hat from
back porting a fix, than bring it up here and we can look into doing a
release or whatever is needed to help the process along.

I do not think it will ever happen though because generally Red Hat is
only going to backport fixes that have been deemed critical to
security.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-05-31 21:53:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.