Re: The essential problems of moving from CVS

[Thomas Adam <thomas.adam22%gmail.com@localhost>]

On Thu, Jan 14, 2010 at 12:58:49PM +0900, Curt Sampson wrote:
> Anyway, though I'm not going to push this further myself, I will be
> happy to help support anybody else who wants to take up the torch of
> contemplating the effects on developer workflow (as opposed to technical
> conversion difficulties) of a move to Subversion or a DVCS.

I can certainly help answer the question of developer workflow -- although I
am not terribly familiar with the current workflow in terms of how other
developers commit their code other than what I've read [1], so with that
information in mind, I am going to assume Git, since it's the one that's in
question and the one I know about.

Of course, I don't care whether some of this reads as teaching others to
suck eggs, but if you're easily offended by such a notion whilst reading this,
I'll apologise in advance.

So, presumably there's one or N number of CVS repositories.  Assuming
they're Git repositories, then the following would happen:

(Apologies for my artwork, I am no artist.  Hope it renders though.  You'll
need a fixed-width font.  :P):

              

                       +------------+
                       |Main NetBSD |
            +----------|Repoository |<------------+
            |          +------------+             |
            |                 .                   |
            |                 .                   |
            |                 . git clone         | git push
   git pull |                 .                   |
            |                 .                   |
            |                 v                   |
            |           +-------------+           |
            |           | My own      |-----------+
            +---------->| clone       |
                        +-------------+


That is, in "My own clone", I am free to create as many branches as I like,
commit to them, do some work, and so on.  Obviously (as I have seen from
other discussions in this thread), the notion of other branches is quite
common.  So, let's say the "Main NetBSD Repository" has some official
branches with some meaning.  I'll make them up:

NetBSD/NetworkingStack
NetBSD/NewFuseImplementation

In "My own clone", I have access to these branches.  But remember they're
only references points in *my* local copy -- what I do there has no bearing
on anything going in "Main NetBSD Repository".  Let's say I want to
contribute code to "NetBSD/NewFuseImplementation".  I could do something
like this:

# As a one-off, create my tracking branch.
% git checkout -b NetBSD/NewFuseImplementation 
origin/NetBSD/NewFuseImplementation
% [Hack, hack, hack]

# Add some files to the index -- to stage my commit.
% git add foo bar/baz frozt.file

# Commit those staged files.
% git commit

... but that's dirty -- because what happens in the meantime if some other
person has pushed some cool new feature to the
"NetBSD/NewFuseImplementation" branch on the "Main NetBSD Repository"?  I
might get conflicts when I try and pull that change in on that branch.
Worse yet, how do I get my changes reviewed?  (Rhetorical -- there's a few
ways).  I can't just bindly push back the changes and hope they're OK, that
goes against the guidelines.  This is where topic branches come into their
own.

Most workflows with Git make extensive use of branches because they're
cheap.  I don't know what the current usage of them is like in the NetBSD
CVS repository.  But to replay the example above, it's more likely I'd use
the following workflow:

# As a one-off, create my tracking branch.
% git checkout -b NetBSD/NewFuseImplementation 
origin/NetBSD/NewFuseImplementation

# Decide on the feature I want to do, and base it off the HEAD of
# NetBSD/NewFuseImplementation.
% git checkout -b ta/fuse-cifs-support
[ hack, hack, hack ]
% git add foo bar/baz frozt.file
% git commit

... and at this point, I can switch back to NetBSD/NewFuseImplementation --
pull the repository and get any changes on that branch, whilst keeping my
new CIFS support separate from what's going on with the code on that branch.

I'm going to skip the mechanics of what you'd do in terms of making the code
on "ta/fuse-cifs-support" part of the code proper on
NetBSD/NewFuseImplementation as there's a few ways of doing that, and I'm
considering it out-of-scope for this.

At this point though everything I've done on "ta/new-cifs-support" is
something only I can see.  If I wanted others to see this I have some
choices:

* Publish the entire repository somewhere (github?) and send an email out to
  perhaps core@ telling them the information they want can be found on the
  "ta/fuse-cifs-support".  (Perhaps via "git request-pull" if the repository
  is hosted somewhere.)

* Actually push my local topic branch "ta/fuse-cifs-support" up to "Main
  NetBSD Repository" -- although there are caveats in doing so.  (Rebasing
  -- skipping this for now.)

* Or, if the number of changes are small, use "git send-email" to formulate
  a set of patches and send them as an email to some address.

The latter option is quite common when receiving bug-reports, for instance.

Where I work, I've just implemented this type of centralised pushing
(emulating CVS) style of working -- going as far as to enforce the names of
local topic branches, names of collaboration branches, etc.  That level of
detail is quite involved though -- and I want to get an idea as to whether
what I've mentioned so far is useful or a load of old bollocks, and actually
you're after other areas of information entirely.

-- Thomas Adam

[1]  http://www.NetBSD.org/developers/commit-guidelines.html

-- 
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.