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

C. Michael Pilato cmpilato at red-bean.com
Mon Feb 4 09:38:38 CST 2013

On 02/02/2013 04:43 AM, Daniel Shahaf wrote:
> 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.

Hrm, I think "add" doesn't make sense in this context, because when working
outside of version control, there is no "add" action you can take on
files/dirs.  And the things we might think of as "adding" -- creating new
files and directories.  Well, you really can still do that stuff the same
way even when there's VC involved.

>> +        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).

Ah, good point!  I'll add that.

>> +        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?

Ehh... I know what you're getting at, but it feels a step too far into the
advanced user space.  Remember, the folks who bother/need to read this
section are probably pretty green when it comes to version control.

More information about the svnbook-dev mailing list