[svnbook] r4387 committed - Finish issue 65 ("Please talk about the cases where a true DVCS like...

Daniel Shahaf d.s at daniel.shahaf.name
Sat Feb 2 03:43:47 CST 2013

svnbook at googlecode.com wrote on Fri, Feb 01, 2013 at 18:39:35 +0000:
> Revision: 4387
> Author:   cmpilato at gmail.com
> Date:     Fri Feb  1 10:39:22 2013
> Log:      Finish issue 65 ("Please talk about the cases where a true DVCS 
> like
> Git would be better than SVN") to the degree that I plan to do so.

Overall, LGTM.  A couple of suggestions:

> +        of performing that administration yourself.  When working with
> +        the data on a daily basis, you won't be able to copy, move,
> +        rename, or delete files the way you usually do.  Instead,

I'd add "add" to the list of file operations.

> +        you'll have to do all of those things through the version
> +        control system.</para>
> +
> +      <para>There are pros and cons to each version control approach.
> +        Perhaps the two biggest benefits delivered by the DVCS tools
> +        are incredible performance for day-to-day operations and
> +        vastly better support for merging between branches.  The
> +        downside is that distribute version control is an inherently

Another difference is that Subversion supports mixed-revision wc's and
DVCS's generally don't.  Not as an implementation detail, but due to the
use-cases it enables ('svn up -r PREV foo.c', for example).

> +        more complicated model, which can present a non-negligible
> +        challenge to comfortable collaboration.  With centralized
> +        version control, you may find a greater degree of control over
> +        your versioned assets, especially as regards access control.
> +        Fortunately, many wise organizations have discovered that this
> +        needn't be a religious debate, and that Subversion and a DVCS
> +        tool such as Git can be used together harmoniously within the
> +        organization, each serving the purposes best suited to the

Maybe at least mention the option of having a centralized Subversion
server with developers using any combination of svn/git-svn/hgsubversion/*
to work against it?

> +        tool.</para>

More information about the svnbook-dev mailing list