Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-07-23 14:16 +0900 (Thu), Stephen J. Turnbull wrote:

> Sure, but "cheap branching is good" doesn't depend on "merging is
> (nearly) free".  It depends on "those who don't have history are
> doomed to repeat the bad parts and forget the good parts".

Well, I think that's true whether or not you have history. How often
does one really look at it? For me it's pretty rare to spend much time
on that, since there's so much of it. Just finding anything in the many
thousands of commits per year in our busier projects is rather a lot of
work.

At situations change, anyway. I've had plenty of occasions where what
was once a bad idea later becomes a good one.

> I think you spend a lot of time writing relatively straightforward
> dedicated apps, and not much working on maintenance of large-scale,
> multi-module, complex, user-driven programs that were designed by
> people who may or may not have been even brighter than you but sure as
> shooting didn't think like you, and maintained by people who didn't
> have the stamina to insist on quality control as you do.

That's true. I suppose when I've got problems with the development
process, I just prefer to try to fix them before using tools to
compensate for them. It helps that, in my environment, I can manage
things to have fairly light-weight processes, which tends to directly
reduce the need for tools.

>  > Well, yeah. I call that a "checkout." :-) 
> 
> Why not record it?  With really cheap branching, it can be done in the
> background without you noticing it unless you want to.

I would generally prefer not to record every little change because that
a) gives me more commits to look through should I decide to go back and
look at something, and b) may give me revisions that don't build and
test cleanly.

>  > But being rather less sarcastic for a moment, I do wonder about this.
>  > There are some experiments in your codebase you can do all by yourself,
>  > of course. But for a lot of the significant ones, I find I'm not sure
>  > whether I've actually made some better sense of the world (or discovered
>  > something about the world) until I involve a few other people
> 
> Sure.  So?  Cheap branches make that easy to do.

Actually, putting it on a branch makes it more difficult, because then
you have to get other people to switch to the branch, rather than just
getting the changes in what they're working on at the moment. I very
rarely branch not because branches are more expensive in my VCS than
some others (they're not really), but because a branch, no matter how
easy the VCS makes it, has an integral cost associated with it that I
don't care to pay.

> Problem is, you can't *force* others to become involved with a branch,
> you have to make them want to. If everything goes into the mainline,
> hey, *fsck you harder, you got NO choice, hah-ha!* Maybe that's cool
> in a company, but in a volunteer organization, that drives workers
> *out*.

Could do. Depends on the volunteers, I suppose.

>  > And the cost of going back, not by a VCS revert command but by
>  > painfully undoing what you've done, is just part of the risk.
> 
> What's wrong with going back via VCS revert?  (As long as that doesn't
> mean deleting history, of course.)

If you introduce changes into the mainline and decide you don't like
them later, you can't just revert to a previous revision, because you'll
lose all of the unrelated changes that people have been making since you
introduced your change. By the statement above I meant that this is a
risk, but only part of it; there are other risks as well with which that
this needs to be balanced.

> Again, "forcing" is something that management should do, not the VCS.

I agree with that. I'm not trying to say that cheap branching is
unnecessary for everyone, here, just that there are ways of software
development where it's not particularly necessary.

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