> > > The main problem with using branches in mercurial (be them in personal > clones or in the main repo) is that they become a permanent part of the > repo history. So if we start to use them, in few months we could have > dozens of branches in our history and they would certainly clutter the log, > both using the googlecode web interface or tortoisehg. As you pointed out > to Steve, I also think branches are used to maintain two different > development trees (maintenance and next-release) inside the same repo, and > probably for nothing else. >
In reality, the main Spyder repo shows branching all over the place. It's just being done anonymously rather than with specific named branches. Any time two devs commit changes from local repos that reference the the same parent Hg automatically branches for you. You resolve this by quickly merging, and the branch goes away. Named branches are just as simple to merge. You can simply close them to hide their names from the list of open branches. The issue about named branches seems to be largely a matter of religion :). For every article decrying their use there is another praising their virtues. Ironically, in one of the most referenced articles on Hg branching, the author suggests named feature branches as one of his *preferred* methods of keeping track of what commits applied to what major feature: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/#branching-with-named-branches I tend to agree with him. I guess the difference between "clutter" and "clarity" is in the eye of the beholder. I created a couple of named branches in my personal clone for simplicity in pointing the reviewer to the right change sets (like bookmarking), but this was by no means an attempt to advocate that every small bug fix should get a named branch in the main repo. Whoever does the "pulling" to the main repo from a clone can decide to pull in the branch name or simply create a patch so as not to propagate the named branch. On the contrary, I would only suggest named branches in the main repo for major features where destabilization and lots of code review is foreseen. > I really don't think googlecode or mercurial are "bad". It's just that > they don't have a such polished interface to do reviewing as github. > Believe me, if github were based on mercurial I would be really happy. But > it's more important to acknowledge that reviewing would be very beneficial > to the project. It could help to discuss changes and approaches between us > without the fear to screw things up. It could also let us learn from the > experience and knowledge of the rest. I think none of us knows the codebase > as well as Pierre but the ones who know some parts better could help the > others and viceversa. > > Hey, I'm a fairly minor contributor to the project, so please weigh that in the decision. I only jumped into the discussion after Pierre expressed second thoughts about making the jump. My goal was not to persuade as much as it was to illustrate that Google Code will facilitate a number of different workflows, including ones that will model github's, and that it's code review interface is quite powerful even if it doesn't look fancy. In the end, I'm sure that the primary devs will make the right call for the project. Once that call is made, a little addition to the project site the describes the preferred workflow would be helpful. -- You received this message because you are subscribed to the Google Groups "spyder" group. To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/HUPmaxD2KggJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
