Re: [tlug] Baby Steps for Command Line Backups . . . . . . . . . . . . . . .

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Jim" == Jim  <jep200404@example.com> writes:

    Jim> Alain Hoang <hoanga@example.com> wrote:

    >> I've found using RCS is a decent way to track configuration
    >> file changes over time.  If anyone has smarter methods I'm
    >> always happy to hear new ideas.

With the advent of git and darcs, RCS is now (finally!) obsolete.  RCS
has the great advantage that it's independent of a separate server,
and if you have a bunch of version-controlled files in a directory and
want to move them or copy them, you just tar them up and send them
off.  Well, git and darcs have the same advantage.

git is of course the Official Source Code Manager of the Revolution,
er, Linux kernel, and some CoolTools[tm] like gitk (it shows the
version graph while browsing the repo).

darcs has a truly superior UI, plus an interesting abstraction called
the Theory of Patches.

But neither git nor darcs makes any more requirements of the user than
rcs does.  (Well, git is pretty immature and hackish, but you can get
away with the same number of commands with git as with rcs.)

If you're already using RCS, the advantages of switching are small,
but perceptible:

    1.  Unify the UI with your version-controlled large projects.

    2.  Subsystems like X11 or rc.d have multiple, interrelated config
        files, and modern SCMs keep related changes together across files.

    Jim> After super simple backups with cp, one should learn tar
    Jim> next.

You mean like "tar -C here -cf - | tar -C there -xf -" instead of "cp
-a here there"?

The big advantage to using a version control program is that they
encourage documentation (except RCS derivatives) with the "-m" flag.
Ie, if you don't give -m with darcs or git (and maybe arch), they'll
fire up an editor at you.  tar and cp are no help with the WTFDIDAY
(what the fuck did I do and why) problem.  (Of course RCS, CVS, and
Subversion permit the -m flag, but they don't discipline you to it.)

Sure, you can use diff, but the version control programs provide a
convenient interface to that, and have the advantage that you don't
have to keep explicit copies of the base versions around.

Here's the git version of Al's tutorial:

   Method
    1. cd /etc/X11
    2. git init-db              # only once per tree
                                # you keep the subdirectories in
                                # the same repo
    3. git add xorg.conf
    4. git commit -m "Import" xorg.conf
    5. Edit xorg.conf with some changes.
    6. git commit -m "This is what I did." xorg.conf
    7. Test to see if changes worked.
    8. If changes did not work go to step 5.
    9. git tag 1024x1280-works-ok

For darcs, just s/git/darcs/.

Note the micro-commit at step 6---this is best practice.  Commit
early, commit often.  It doesn't matter for config file tweaking, but
in more complex development, or team environments, often you want to
be able to separate out controversial from routine changes, and make
each change coherent.  git makes reshuffling your microcommits easy;
darcs makes teasing apart a bunch of unrelated changes into a small
number of "clean changesets" easy.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.