Merging to the release_1_6 branch

[Blair Zajac]

Caspar Florian Ebeling wrote:
>> 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.

Well, we should have feature branches in svn for half-cooked and half-done and 
when they are ready, have them reviewed and merged into trunk.

The differences between svn/git isn't the issue here, it's how the code is being 
managed.

We can have a MacPorts policy that all new work is being done on a branch and 
trunk is pretty stable code in it.  Having one other review the work before 
merging into trunk could be required.

Blair