You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Verkerk, Onno" <On...@NKF.nl> on 2005/07/04 11:14:33 UTC

Subversion's branching as compared to other VCS tools

Hi there,

I'm currently investigating on some candidate version control systems for
deployment in our company, and Subversion is included in the list. I already
did some testing on svn and found it pretty easy to use. I tested the
combination Subversion+TortoiseSVN connected to Subversion/Apache2.
Everything seems to be there and readily available. But of course, testing
is on small repos, not on the real-life big ones. 

I found out that many people complain about Subversion's branching/tagging
mechanism. For one thing, this seems to become the most dominant issue about
Subversion. I compared it with other tools (BitKeeper, Perforce, ClearCase,
Surround SCM) and they claim to do a better job.

Here are some references that discourage the use of Subversion:
http://www.bitkeeper.com/Comparisons.Subversion.html
http://www.maynidea.com/topics/subversionstinks.html
http://www.pushok.com/soft_svn_vscvs.php?PHPSESSID=392eaa27da6675121041fa261
c30fa49

They all complain about missing features that are already fixed, but
branching remains an issue. I also received a confidential note from Seapine
(Surround SCM) in which branching in Subversion is said to be a disaster.

But I like Subversion! Anyone there with a good opinion on how to
successfully use branching in a team with some 15 developers on the same
code base?

Thanks in advance,
Onno

----------
Onno Verkerk, 
Senior Software Engineer
Optelecom-NKF B.V.                     
The Netherlands
www.optelecom-nkf.com



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion's branching as compared to other VCS tools

Posted by David Faure <fa...@kde.org>.
On Monday 04 July 2005 13:14, Verkerk, Onno wrote:
> Subversion is said to be a disaster

Now that's a rather weird claim. We use subversion in KDE (millions of lines of codes, over
a hundred branches, etc.) and it works fine. The branching concept is a bit different
from e.g. CVS, but once you get used to the rather simple "a branch is a directory" concept,
you will find that it's quite convenient.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion's branching as compared to other VCS tools

Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 4, 2005, at 6:14 AM, Verkerk, Onno wrote:
>
> But I like Subversion! Anyone there with a good opinion on how to
> successfully use branching in a team with some 15 developers on the  
> same
> code base?


What on earth is disastrous about branching?  It's an O(1) operation  
in Subversion.  If you want to learn about branching and merging,  
read chapter 4 in the svn book.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion's branching as compared to other VCS tools

Posted by Tor Ringstad <to...@tandberg.net>.
> Here are some references that discourage the use of Subversion:
> http://www.bitkeeper.com/Comparisons.Subversion.html
> http://www.maynidea.com/topics/subversionstinks.html
>
http://www.pushok.com/soft_svn_vscvs.php?PHPSESSID=392eaa27da6675121041fa261c30fa49

I wouldn't pay too much attention to any of those. The Maynidea
article's just got to be a troll. The Bitkeeper article is purely FUD,
and full of half truths and right out lies. If you haven't read it
already, you should take a look at this:

  Debunking BitMover's Subversion Comparison
  http://subversion.tigris.org/bitmover-svn.html

The CVS/SVN comparison is maybe the most balanced text of the three,
but still contains imprecise and highly controversial "facts" about
Subversion. Among other things, I find it somewhat strange to argue
that "CVS is supported everywhere where you might need it", when it's
CVSNT they're comparing.

> I found out that many people complain about Subversion's
> branching/tagging mechanism.

Subversion is only marginally better than CVS, and still lagging in
functionality compared to a lot of other version control systems (in
particular the commercial ones). A couple of features that I
personally miss a lot are:

- Support for repeated merge
- Support for merge of directory changes (move/rename)

The Subversion web page currently lists these as "medium term goals".

> Anyone there with a good opinion on how to successfully use
> branching in a team with some 15 developers on the same code base?

That depends a lot on how you're working, the structure of your
project(s) etc, but I'm sure it's doable. My department has 50-80
developers and has survived with CVS for almost a decade.

My advice for both CVS and SVN would be that you shouldn't plan on
using branching extensively. Or to be more precise; the problem isn't
really the branching, it's the _merging_ that's the painful part. With
"extensively" I mean that I wouldn't recommend practices like "branch
per user per activity".


- Tor Ringstad -




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion's branching as compared to other VCS tools

Posted by Bob Proulx <bo...@proulx.com>.
Verkerk, Onno wrote:
> I'm currently investigating on some candidate version control systems for
> deployment in our company, and Subversion is included in the list.

Nice to know it is on the short list of top tools to use.

> I already did some testing on svn and found it pretty easy to use. I
> tested the combination Subversion+TortoiseSVN connected to
> Subversion/Apache2.  Everything seems to be there and readily
> available.

I take it by this that you will be primarily using this in a MS
environment?

The worst problem I have heard of so far is that on slow filesystems
the organization of many small files can cause slower performance by
comparison to operation on faster filesystems.  MS notably has a slow
filesystem and so there have been complaints of performance problems
there.  The functionality is very good though and personally I run on
a slow filesystem (HP-UX) and I accept one to get the benefits of the
other.  On a fast filesystem it is awesome!

> But of course, testing is on small repos, not on the real-life big
> ones.

Subversion is used on many other large projects.  I doubt you will
find anything truly interesting there.  It is solid.

> I found out that many people complain about Subversion's branching/tagging
> mechanism. For one thing, this seems to become the most dominant issue about
> Subversion.

Tools like RCS and CVS have been around for a long time.  People
accept that they work as they work and that is just the way that it is
going to be now and into the future.  They don't really support many
of the newer types of global development being done today.  But
subversion being an active project people want it to be better than
previous tools.  Therefore the most obvious thing to look at is how to
do active development on a global scale.  This is clearly on the
roadmap for subversion development.  It just keeps getting better and
better.

But to be fair subversion does not have distributed development built
in as a core feature.  That is because CVS did not either.  That was
not the design goal.  Instead the design goal was to keep the CVS
model but significantly improve it.  Subversion is a better CVS.  If
you would not consider CVS at all in the past due to the feature set
of CVS then you might not be happy with Subversion today either.  That
is okay.  Subversion is not for everyone.  But if you were a previous
user of CVS then moving to Subversion is a step up in capabilities and
performance in almost every feature.

> I compared it with other tools (BitKeeper, Perforce, ClearCase,
> Surround SCM) and they claim to do a better job.

First it is amazing that you are comparing those tools to each other.
One of those tools is clearly different from the rest.  Which ones are
closed source proprietary commercial products and which ones are open
source free software projects?  RCS, CVS, Subversion, others not
mentioned, are free today and will always be free in the future.  You
will never lose your license to operate on the data.  You will never
be prevented from using it at the whim of the company offering it.
That is a huge benefit just by itself in terms of data security.  But
if that is not seen as a benefit to you then that is okay too.
Choices are being offered and differnet needs will make different
choices.

> Here are some references that discourage the use of Subversion:
> http://www.bitkeeper.com/Comparisons.Subversion.html

Be very careful of marketing from the commercial organizations.  They
make their money selling their product.  They don't make any money if
they don't sell their product over all others.  As I read that
marketing I had to choke back several outbursts of denial about
several of the bullet points there.  But they are carefully crafted to
elicit such a response.  If that were posted to a news group it would
be called "a troll".

GNU Arch, Monotone, Bazaar, others are designed as a distributed
version control system.  Their paradigm is different.  Technically
these can be much more flexible than a centralized system.  They have
a lot of advantages.  But they are also much harder for the user to
understand and grip upon mentally.  I am going to be teaching them how
to use this new system and that affected my choice.  Having the
distributed VCSs as a choice for my team I pushed for Subversion over
them because of the ease of use and administration aspects.  Svn is
not perfect.  But it does the 95% case of what we need very well.  It
is quite easy to get someone up to speed using it.  My needs at work
are not the same as the Linux kernel.  Different needs mean different
choices.  What are your needs?  You will need to understand that and
make your own choices.

> http://www.maynidea.com/topics/subversionstinks.html

That just seems like a "rant" that is typical of the unhappy person.

There are as many rants bashing reserved-lock systems as there are
bashing copy-modify-merge systems.  Really you just need to ask
yourself which model you prefer.  Then by all means select a system
that supports what *you* want to do.

Note that subversion 1.2 has reserved-locks.  It is a new feature just
introduced to subversion.  So much of the previous documentation will
refer to the previous capability list which does not have locking.

  http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

> http://www.pushok.com/soft_svn_vscvs.php?PHPSESSID=392eaa27da6675121041fa261
> c30fa49

They don't like the current tagging and branching model.  There have
been complaints about it.  See the list for lots of discussion.
Everyone agrees that subversion operates differently.  They do not
like how it works.  Others do.  The important question for you is do
you think it works okay for you to use or not?

They rant about other things that I completely disagree with.  They
really seem to like the cvs edit feature.  I find that to be
completely useless.  There are other points that I could debate with
but why?  Actually that was a much more balanced rant than most.  If
they want to use CVS that is fine.

> They all complain about missing features that are already fixed, but
> branching remains an issue.

Branching is certainly functional.  It just has some warts that make
it less pleasant to use in some cases than others.  I understand the
warts.  They are not really *that* bad.  I usually have to keep track
of the versions from which I am branching and merging.  It would be
nicer if svn tracked merges.  But that does not make it impractical.

It would be better if you tried a few of the cases discussed in the
book.  Then you could come back and discuss the specific details of
the operations.  What in particular is or is not working for you.

> I also received a confidential note from Seapine (Surround SCM) in
> which branching in Subversion is said to be a disaster.

Ahem, you may not have noticed but this is a public list.  If that was
really confidential then you just violated your agreement with them.

Branching in subversion is quite good and is certainly not a
disaster.  There are a number of better but harder to implement ways
of doing branching.  Improving things is under heavy discussion.
Things are quite a bit better than in CVS.

> But I like Subversion! Anyone there with a good opinion on how to
> successfully use branching in a team with some 15 developers on the same
> code base?

That question does not have an answer.  Because the obvious answer is
just use subversion and branch normally.  Don't do anything crazy.
Just do normal things.  Read the documentation.  Use the tool in the
documented manor.  Please don't take this harshly but you have to have
something more specific in mind or there is no way to respond to this.

What version control system have you been using previously at your
company?  I would be willing to bet that subversion is already at
least as functional as what you have been using and likely more so.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Subversion's branching as compared to other VCS tools

Posted by Hernán Martínez Foffani <he...@ecc.es>.
> I found out that many people complain about Subversion's
> branching/tagging mechanism. For one thing, this seems to become the
> most dominant issue about Subversion. I compared it with other tools
> (BitKeeper, Perforce, ClearCase, Surround SCM) and they claim to do a
> better job.
>
> Here are some references that discourage the use of Subversion:
> http://www.bitkeeper.com/Comparisons.Subversion.html
> http://www.maynidea.com/topics/subversionstinks.html
>
http://www.pushok.com/soft_svn_vscvs.php?PHPSESSID=392eaa27da6675121041fa261
> c30fa49

Thanks for posting those links.  If that's what they have to
say about SVN then I rest assure I made a good decision by choosing
Subversion.

To me, BK's report is disgusting to say the least.  There were a thread
here in this list about Linus opinions about Subversion.  The dev-team
replied to those messages with repect to both Linus and BK.
After browsing BK's web I'm asking myself if they deserve it.

> They all complain about missing features that are already fixed, but
> branching remains an issue. I also received a confidential note from
> Seapine (Surround SCM) in which branching in Subversion is said to be
> a disaster.

The dev-team decided that to open the gate you have to slide it.
Others may say:
"What????  No push-pull doors????.  Shame on them!!!
That's not the way you are supposed to come in.  Disaster!!!"

It just takes a minute to learn to slide the door.
It's not a big deal.  Really. :)

> But I like Subversion!  Anyone there with a good opinion on how to
> successfully use branching in a team with some 15 developers on the
> same code base?

IMHO it doesn't depend on qty of developers but on the organization
internals procedures.  In our site the branch/merge cases explained
in the Subversion book are enough to cover all our demandings.  YMMV.

Branching is not a problem.  Given a suitable client you might even
branch with a drag-n-drop operation.
Merging back is not as easy as branching, though.  But it is *not*
rocket science.  Before you branch you may have to browse older
commit messages looking for specific revision numbers and then
issue the merge relative to those.  That's it.

While I do share the opinion that merge tracking is a place where
Subversion can improve by calling it unusable or a disaster
the competitors disqualify themselves.

Finally, even if BitKeeper, Perforce, ClearCase, Surround
can branch/merge by reading my mind they all share a big "bug"
that makes them unusable for me: the price.

Regards,
-Hernán.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org