There is one area of concern I had which relates to bugfix support for older
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 2005
isnšt really very long ago. There are a number of bugs in the 1.2.x release
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 with
a stable version for long periods of time so as not to cause diruption with
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 model)
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 supported,
17 months is an awfully short time between initial release and the end of
primary support.
-Steve
On 1/10/07 11:36 AM, "korebantic" <korebantic@gmail.com> wrote:
> Over the past year I have been using SVN for both personal projects, and a
> 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 that
> 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, the
> technical infrastructure required to support it, and the client and server
> 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 for.
> 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 the
> red bean book a few times, and gone over the branching section multiple times.
> 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 to
> 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 10 18:16:59 2007