Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-09-28 20:01 +0900 (Mon), Stephen J. Turnbull wrote:

> Changing the GUI changes config.h....

Yup. But that's entirely orthogonal to any kind of revision control.
And I'm sure you know how to deal with this, anyway. (Er..."don't make
generic code dependent on a file that changes for every different
configuration?")

> I told you this is a leprous codebase.
> ...
> Again, the only reasonable way to deal with this is to put them on a
> feature branch until either they start consistently running the tests.

Hm. This is starting to sound like, "horrible code base, idiot developers,
but hey, with git's branching, all of this is no problem now!"

> ...and even those who did generally were unwilling to create branches,
> preferring to keep private workspaces and generating patches from
> those against CVS. I never understood why, but the attitude was
> "branches are unusable in CVS."

Namespace pollution, probably. That, and if you've not learned to branch
in CVS, it may well seem easier just to write some shell scripts and
muck about with the patch and merge programs.

> I'm confused.  I thought the "first step" we are taking here is toward CI.

Oh, sorry; I was under the impression that you guys were maintaining
separate branches for various features. Probably it's just the article
echoing through my head.


> I know how to merge feature branches, and it has nothing to do with:
> 
>  > the first step is actually just move both copies to the same
>  > branch, and build both from their entirely separate sources. Then
>  > you can start picking off the parts that are easy to merge (such as
>  > the source files that are exactly the same) and putting them in a
>  > common area, and move on from there.
> 
> because any decent VCS already does that for you.

With what I was trying to say, that statement would be that "any decent
VCS" will take two gui.c files, a Mac one that won't compile under Linux
and a Linux one that won't compile under the Mac, find new, separate
locations to put the two, and tweak the build system to find and use the
right one.

If git does this, it really has solved your idiot developer problem!

> I do believe "cheap branching is good"....

Yeah, maybe I mean more to say, "if you need cheap branching, you have
bigger problems."

>  > If I started hacking on XEmacs, for example, I'd probably start
>  > out by doing a lot of the things you are doing, and doing a lot of
>  > them the same way for quite some time. I'd just call those things
>  > "compromises" rather than "solutions."
> 
> When "quite some time" starts to stretch into decades, you start
> looking for euphemisms, though.

Right. And that's where I think things didn't go so well; it feels as if
(talking out of my ass, here) once a band-aid was found, nobody carried
on with addressing the deeper systematic problems, if they ever were
addressing them in the first place.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com