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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev