<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 02/04/2013 01:56 PM, Daniel Shahaf
      wrote:<br>
    </div>
    <blockquote cite="mid:20130204185648.GA32127@tarsus.local2"
      type="cite">
      <pre wrap="">C. Michael Pilato wrote on Mon, Feb 04, 2013 at 10:38:38 -0500:
</pre>
      <blockquote type="cite">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.
      </blockquote>
      <pre wrap="">
But it's not the same way:

Without VC:  touch foo.c

With VC: touch foo.c && svn add foo.c</pre>
    </blockquote>
    <br>
    The point of this section is the changes to pre-existing behaviors
    necessitated by the introduction of VC.  Introducing a version
    control system doesn't change the way you "add files" because
    there's no such concept outside of VC.  And it doesn't change the
    way you create files at all.  (Might just have to ask you to trust
    me on this on.)<br>
    <br>
    <blockquote cite="mid:20130204185648.GA32127@tarsus.local2"
      type="cite">
      <blockquote type="cite">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.
      </blockquote>
      <pre wrap="">
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?)
</pre>
    </blockquote>
    <br>
    <i>Version Control With Subversion</i> is about Subversion, and
    intentionally doesn't discuss the gazillion different tangentially
    related software projects in the greater Subversion ecosystem.  IMO,
    the topic is out of scope for the preface and first two chapters of
    the book, for sure.  That said, I could see mentioning it later in
    the text if doing so serves the primary goal of helping folks be
    more successful <i>with Subversion</i>.  As mere informational
    fodder, I'm disinterested.  But, for example, if git-svn is known to
    improve the handling of renames or merging or something else over
    what stock Subversion can offer, that could be of sufficient value.<br>
  </body>
</html>