Merging to the release_1_6 branch

[Caspar Florian Ebeling]

> Git is just another version control system and does not decide if we make
> feature branches or not. Yes, merging in Subversion is not the best, but
> this will become a lot better with Subversion 1.5. I don't think we have to
> discuss different version control systems and their advantages here.
> Basically, they are all the same. You got a main line and branches. So we
> have to decide how to use branches, not which system stores our branches.

I could have argued this way. Actually I used to think that people who
want to solve problems with tools were quite dumb. But Git makes a bit of
a difference.

> Jordan brings up the idea not to use branches at all, but to make releases
> from the main line. I don't agree that this would be sane, even if it comes
> from his experience. How would we do minor releases for bugfixes without
> branches? I can only think of checking out the tag, applying (multiple?)
> patches and creating a new tag from it. Which would not give you any control
> to see what you applied and you would also need to apply that separately to
> the main line without any connection between the two commits! Gosh.

Yeah, and that's the whole problem. With svn you dump all your new half-cooked,
half-done features into trunk. With Git it's the reverse situation.
You do the dangerous
things in branches and can assume that mainline is reasonably in shape. That's
only a tendency. But I know from exprience why I don't want to release things
from trunk under svn usually. And if only complete, well-understood
features would go
into it, I would feel different. It's a bit like not comitting with
subversion for 10
days, but having everything in the undo history, or something.

>> But git mostly makes branches a private thing, so that effectively
>> their number rather gets reduced, or at least the number of public
>> ones gets reduced. The existing branches tend to be feature-specific,
>> and mainline
>> stays sane because branches only get merged in once they are
>> not questionable anymore.
>
> So who tests your new code? You privately and nobody else? And you never
> test it together with other features which could even break it? Doesn't
> sound like a good idea to me.

Of course you would have it tested by a broader audience, after merged to
master. And you would sync releases so that you have a grace period for that.
But you don't run trunk all the time, with half-feature A, 3/4 of B and
all of C, but only C. And then all of B, when it's author is happy. Etc. That
does not solve eberything, but it's better.

New tools are not always not the solution :)

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com