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

Daniel Shahaf d.s at daniel.shahaf.name
Mon Feb 4 12:56:48 CST 2013


C. Michael Pilato wrote on Mon, Feb 04, 2013 at 10:38:38 -0500:
> 
> 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.
> 

But it's not the same way:

Without VC:  touch foo.c

With VC: touch foo.c && svn add foo.c

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

Fair enough.  Would it make more sense to mention that workflow in a
later chapter?  (or as a "dangerous bend" (i.e., "Advanced" box) in the
current chapter?)




More information about the svnbook-dev mailing list