Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think that is a confusing way to compare them.
 > It focuses on similarities in implementation
 > rather than on similarities in use and role.

Exactly.  Let's try the use and role explanation.

Usage summary:

    cvs commit ~ git commit ; git push
    cvs update ~ git pull

Discussion:

In CVS, there normally is no local repository, and even if there were
one, CVS provides no mechanism for communication between the local
repository and the "official" one.  So to record your changes as a new
version *and* publish your changes, you simply commit:

                   you
  workspace --- cvs commit --> public repo
                               on server

To get others' changes, you pull:

                   you
  workspace <-- cvs update --- public repo
                               on server

In git (and all the others under discussion), to record your changes
as a new version, you commit, and then to publish your changes, you
push:

                   you                            you
  workspace --- git commit --> private repo --- git push --> public repo
                               on laptop                     on server

To get other's changes, you pull:

                                   you
  workspace <-- private repo <-- git pull --- public repo
                on laptop                     on server

Note that the update of the local workspace is implicit (automatically
done by "git pull").  For you personally, frequently disconnected but
(I assume) carrying a laptop, that's all you *need* to know, and
that's all you'll see of what's happening.

The omission of discussion of which branch or trunk etc is deliberate
and correct.  All VCSes have a notion of the "default branch".  All
you *need* to know is that the "default branch" of the "official
repository is the "trunk", and that the "usual way" of setting up a
local clone results in CVS-like behavior, except that to update the
trunk, you must first commit locally, then push to the official
repository.

This separation of commit from push is a huge advantage to those who
are often disconnected.

I should also mention that some dVCSes *require* that you explicitly
select the commits you wish to make.  For example, if you want git to
behave recursively the way "cvs commit" does, you need to say "git
commit -a".  However, the analog of "cvs commit file1 file2 ..." is
"git commit file1 file2 ...", so I would guess you won't find it hard
to acquire the habits.

There are many other advantages to these tools, but you can acquire
those skills at need.  You'll also *want* a deeper understanding of
the various operations before making a decision, I'm sure.  My purpose
here is merely to show how to map your current workflow into the
workflow you'd need to use with a dVCS to accomplish the same tasks.

Note that others can be doing all the wild-sounding things like "local
branching", "pulling from private repos", "cherrypicking", and
"rebasing", but you don't need to notice until it suits your purpose.

Finally, you probably already know this, but I should caution the
reader that words like "commit" and "push" alone do not necessarily
have the same meaning as "$VCS commit" and "$VCS push" do.  In fact,
the various VCSes differ quite a bit in usage, and often end up with a
set of commands implementing the same semantics but with the command
names permuted!  But those are fine points.  The basic roles of the
commands (at the eagle's eye view given above) remain intuitively
similar.