Hi Philip, > Sounds like feature branches to me which I think are generally evil > and best to be avoided. You inevitably end up with various complete > or incomplete features lying around and no easy way to share the > changes without merging them up. If git has solved this problem, well > maybe feature branches would be slightly more tolerable, but I still > think they should be avoided unless necessary.
Subversion branches and git branches only shares the name, they are quite different. A subversion branch is no more than a copy, and once it has been created it can not be removed (it will be part of the subversion history forever). But, git branches are meant to be merged, git philosophy suggest to keep a branch with the current "main track", then you create a branch to do some amount of work, after several commits you merge the new branch with the main branch, and you get rid of the new(auxiliary) branch. You can call that a feature branch, but it is not mean to develop features separately keeping a branch for each one, as soon as you consider that some new test/feature/improvement can be merged you should merge it, and forget about that branch. In my opinion that's a very good choice, because several features can be implemented at the same time, by different people, in parallel. With subversion most of the time a big feature implies just one commit to the repository, with git you can easily commit several times to the repository without affecting other people or other feature's development. Also branches can be truly deleted, and only the parts of the branch that are merged into other branches persist, without polluting the "branches namespace". Mercurial instead share the same concept of branches than subversion, a branch in Mercurial is like an independent project in the same repository, once created it can not be removed (well you can edit history... but that will mess other people's cloned repositories). The equivalent concept of git-branches in mercurial is called "heads", they work in the same way as the git... but as I've said before, mercurial concepts are much easier to understand for the beginner. In fact, what mercurial recommends for the feature-branch-thing is to clone the "main" repository into a local repository, work there, and finally upload to the "main" repository the changes made. It doubles the space needed, is redundant compared to the power of git branches, but is very very comfortable, people feel a lot better working in a different directory, they feel more secure about making changes. My experience with git is that you have to keep an eye in which branch you are currently working, it's not the first time that I missed the branch where I wanted to commit changes and it was a little disaster. That's why we are using Mercurial at work, it was easier to adopt for all the people that were used to work with subversion before. Cheers, JL. -- Jose L. Hidalgo Valiño (PpluX) ---- http://www.pplux.com ---- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
