Interesting and good points. Perhaps the answer to your concerns could be
addressed by the commercial support offerings of Collabnet for SVN?
On 1/10/07, Steve Bakke <firstname.lastname@example.org> wrote:
> There is one area of concern I had which relates to bugfix support for
> versions. The development pace of Subversion has been lightning-fast
> compared to typical open-source projects:
> V1.2.0 Apr. 25, 2005
> V1.3.0 Jan. 3, 2006
> v1.4.0 Sep. 10, 2006
> The current support policy is that patch releases are planned as necessary
> for the current release and the previous release. Only critical
> data-integrity bugs are fixed in prior releases. In my view, April of
> isnšt really very long ago. There are a number of bugs in the 1.2.xrelease
> that have only been fixed in the subsequent major releasees.
> Some of the changes from release to release can be substantial. As a
> result, when using this on a major project youšd generally rather stick
> a stable version for long periods of time so as not to cause diruption
> the project you are working on. In my own situation, I ran into a case
> where svn 1.4.0 had a number of undocumented behavioral changes from prior
> releases. (I didnšt get much sympathy since I have an atypical usage
> The point is that this can happen with any change of major release.
> What happens if there is a bug which is *important to you* which shows up
> and you are still using a major release which no longer gets primary patch
> support? It seems that the options are as follows:
> 1. If at a non-critical stage of your project - consider upgrading.
> 2. Lobby to have the bug fixed...
> 3. Patch fix the bug yourself if you are able.
> 4. Implement some sort of workaround if possible.
> Any comments from developers? This is just my take things. While I think
> it is reasonable that older releases would no longer be primarily
> 17 months is an awfully short time between initial release and the end of
> primary support.
> On 1/10/07 11:36 AM, "korebantic" <email@example.com> wrote:
> > Over the past year I have been using SVN for both personal projects, and
> > couple of smaller scale projects at the company I work for. I'm
> convinced on
> > multiple levels that SVN is superior to CVS in a number of respects, and
> > it would be a good fit for my company, which currently uses CVS.
> > I have been given the opportunity to sell SVN to upper management. I
> have done
> > my homework with regards to what some of the capabilities of SVN are,
> > technical infrastructure required to support it, and the client and
> > side stability of the project overall. Additionally, as I mentioned
> earlier, I
> > have been using it for about a year.
> > However, I can't yet claim to be an expert SVN user. I haven't yet used
> it in
> > a project that had more than two developers. I know that SVN is being
> used on
> > a much larger scale by many OSS projects -- projects I have deep respect
> > Particularly I'm a bit uncertain about what the "gotchas" or wrinkles
> are with
> > using SVN in a more branch intensive project. Yes -- I have read through
> > red bean book a few times, and gone over the branching section multiple
> > I did enough branching/merging in CVS to feel I can claim I'm not a
> novice in
> > this area.
> > So my request is two fold:
> > (1) Links, white papers, or analysis that others have done with regards
> to CVS
> > vs SVN. Even better if some of this information plays devils advocate as
> > why SVN would be a bad choice.
> > (2) Commentary, anecdotes, etc about your experience with medium sized
> > projects (10-20 developers) and branching.
> > Thanks in advance...
> > PS This is in no way meant to stir a flame war against CVS -- I've used
> it for
> > years and appreciate the efforts of all those that have worked on it.
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
Received on Thu Jan 11 02:09:06 2007