Merging to the release_1_6 branch

[Rainer Müller]

Caspar Florian Ebeling wrote:
> This is exactly what I have been preaching, but I think it changes
> with Git. I know that saying this might well be boring by now, but Git
> eases the whole branch handling a lot. And svnmerge.py is really
> not a substitute here. I used it for a feature branch of a project and
> some file renamings made things go haywire. It was certainly not
> the reassurement your actually want to get out of version control.

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.

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.

I really don't think we want to do it this way.

> 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.

Rainer