Re: The essential problems of moving from CVS

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

On Fri, Jan 15, 2010 at 01:03:55PM +0900, Curt Sampson wrote:
> On 2010-01-14 20:25 +0000 (Thu), Thomas Adam wrote:
> 
> > I can certainly help answer the question of developer workflow....
> 
> Ah, well, I didn't clearly state what I think we need here. Your answer,
> while good, re-iterates general information that's widely available, so
> I don't think we need to do a lot of work on that part.

Sure -- I agree with that, it's just from all the cross-fire, people talking
past one another, etc., etc., the overall impression was that some people
really *didn't* understand the basics.  But that's fine; reference other
works like this, and move on.

> Perhaps you can think of it as saying:
> 
>     * what features we'd gain, and why this is something that NetBSD
>     developers want,

I really haven't done much NetBSD development (although I have done some).
But I think this question and the other ones about ease of transition,
versus some pain, and perhaps change in workflows, are going to depend
entirely on how most developers work -- and will *want* to work.

By that (and most likely not immediately apparent to anyone who hasn't used
Git day-to-day), I mean because CVS more or less ties your hands to one way
of working, the benefits to switching are difficult until people can see for
themselves *how* they *can* work to suit themselves.

>     * what we'd have to change, and why this won't be too painful for
>     NetBSD developers (and why the pain is worth it, where it is painful),
> 
>     * what we'd lose, and why it's worth paying that cost.

To be honest, I don't think you'd be losing that much -- the cost and time
will be in people having to potentially learn a new set of commands.  I
don't mean that flippantly, but even now, if people wanted to, they could
still use Git in a CVS way.  Many people I know at work still do, alas.

> Particular Git features I can think of that I think most developers
> would agree would be big wins are:
> 
>     * much, much better branch maintenance support, particularly for
>     multiple merges from one branch to another;

The multple merging is probably something you never want to do, IMO.  But
yes, branches and merging in Git are painless.

>     * easier development by and integration of patches from people
>     without a commit-bit;

This is the big one for most maintainers -- if the person submitting the
patches has set up their git repository properly (i.e., set their name and
email address, etc), merging in patches from this person will be trivial, as
all the meta-data about the author is maintained in the patches.

> The branch maintenance one is huge because we spend a lot of effort on
> dealing with merging things between branches in release engineering.

This is more effectively solved by having a clearly-defined workflow about
public branches, their use, and how they're managed/integrated with other
branches potentially.  If you get this right, and commiters appreciate what
each branch's role is for, it makes things easy.  This is something I've had
first-hand experience with, thankfully.  I don't know where we'd be without
that.  ;)

> That said, a lot of the work is not going to be in coming up with this
> NetBSD-centric document selling the change, but handling the huge number
> of objections you're going to get when bringing up the discussion.
> You're going to need to understand the NetBSD culture very well, have a
> very thick skin, be prepared to suck up very hard to some of the most
> annoying and hostile developers, be prepared to handle several people
> trying to subvert you for no apparent reason, keep track of every last
> detail, and do this for months without getting frustrated to the point
> of flaming anyone.

Oh sure -- no one likes change, especially those people for whom change is
perceived as a threat.  But it's OK, everything you've said in this
paragraph sounds exactly like being at work, and I've yet to kil anyone
there,  so... :)

If I am to do this -- and I am willing to try -- what I need is a list from
people who don't understand how their way of working is likely to fit into
Git -- if there's a pattern to the questions raised from this, I can go
about forming such a document.

The general "benefits" about using Git are well-established, and written
elsewhere.  (Curt has already mentioned some of these above).  I don't
really want to concentrate too much on comparing those to CVS as it's
already been done to death.

But if I can identify people's concerns about their own way of working -- be
it, handling patches, merging of information, how best to work within their
own checkout, and then how best to integrate that upstream -- that'd be
grand.

So, the invite is there.

-- Thomas Adam

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