subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Mielke <>
Subject Re: Subversion in 2010
Date Mon, 04 Jan 2010 18:01:14 GMT
I know it's been a trouble-some subject, and a lot of effort has been 
invested already, but -

I would like to see "ensuring reliable merges across branches" remain as 
a priority, even if it is only a priority to address defects.

Parallel development is one of the most important features of a source 
management system. Reliable merging across branches is a huge part of 
this for large projects that cannot work on trunk and hand manage 
porting changes from one release to another.

We are still seeing reports that Subversion merges across branches are 
failing in areas where we expect them to succeed. I am encouraging our 
teams to move from ClearCase to Subversion, and the merge limitations of 
Subversion that can either lead to lost productivity in performing the 
merge, or downstream consequences in the case of a faulty merge that is 
not detected, is a major obstacle. I cannot in good faith say that 
Subversion merging is at the same maturity as ClearCase merging.

In my experience, I find GIT merging between branches to be superior to 
Subversion merging between branches. Where Subversion too frequently 
ends up with the incorrect results, GIT only rarely results in incorrect 

I would like to see Subversion catch up in this crucial area.

Again, I appreciate the unique difficulties that the Subversion 
architecture introduces, and I appreciate the efforts done so far - 
merge tracking in 1.5, tree conflict resolution in 1.6 - but this area 
still needs work. From Subversion 1.4, it has gone from extremely poor 
support for merging across branches, to 1.6 where I would call it 
"nearly complete, still containing known defects".

Another related area of limitation here is the "reintegrate". This seems 
fundamentally broken to me. That the branch needs to be removed and 
re-created in order to "reintegrate" again indicates a flaw in the 
design. Under ClearCase and GIT, they both support reliable repeated 
merges in both directions. This may be another issue where the 
Subversion architecture introduces unique difficulties - but to any user 
of the system, we do not care what unique architectual limitations exist 
- we just want a reliable product that works in our standard work flows 
and that works just fine in other competing products. Why doesn't it 
work in Subversion?

For many projects - switch to GIT or another system is a preferable 
option. It has other features that make it desirable over Subversion. 
However, there are projects that would work best under a centralized 
model such as Subversion. I think chasing the de-centralized solutions 
will leave Subversion in the past. Subversion's architecture limits it 
from providing many of the capabilities of the de-centralized solutions, 
and I tend to think that Subversion should not try to be everything to 
everyone (and fail), but work to its strengths. Subversion's main 
benefits in my opinion are: 1) Wide tool integration, 2) Ease of use, 3) 
Centralization. Perhaps it should become the work to maintain and 
enhance it's title in these areas?

I'd like to help where I can. I haven't found an opening to start 
contributing yet.

Another priority I have is performance. I find Subversion extremely slow 
for large projects. This is all relative - as I find ClearCase similarly 
extremely slow, but there are particular cases where it seems Subversion 
exhibits worst case behaviour for. For example, commits of 100,000 files 
is an area where Subversion seems to crawl. Importing a vendor branch is 
this sort of scenario, but it extends to having downstream consequences 
if Subversion replication (svnsync?) is used or if other tools consume 
the results (FishEye?). The merge problems are easier to define than 
performance problems, as merge problems can effect everybody and can be 
shown to work or fail with reproducible test cases, whereas performance 
problems are related to productivity expectations and harder to put $$$ 
value on that everybody would agree to.


On 01/04/2010 11:31 AM, C. Michael Pilato wrote:
> A hearty +1 to all of what you've indicated!
> Additionally, in 2010, I'd like to work with other devs that care to restore
> some sense direction to this product.  At a minimum, that means identifying
> and killing the bugs and misfeatures that are impeding forward motion, and
> thinking farther ahead than just "the next release" in terms of feature
> planning.  If asked to name specific TODO items, I'm not sure I'm ready to
> do that today (which itself is probably a symptom of the overall problem),
> but surely amongst the lot of us we can begin to shape the future of
> Subversion.  We may never achieve a vision as concise as "to be a compelling
> replacement for CVS".  Or maybe we will.  "To be a compelling replacement
> for git/Mercurial", perhaps?

Mark Mielke<>

View raw message