Re: Subversion in 2010

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
results.

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.

Cheers,
mark

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<mark_at_mielke.cc>