[...] >> As a side note, I noticed that we seem to have several large branches in >> various repositories right now. These are becoming more and more >> divergent and difficult to integrate as they grow, they are hard to >> understand for newcomers (like me) and functionality cannot be easily >> split out. In addition to that, I find that merge commits clutter up >> histories. In my opinion hg and bitbucket are partly responsible for >> this. > > The other part are the users, including me. Personally I hardly care > about a merge commit every ten or so changesets. > > I have changed my workflow a bit, though, separating the upstream > branch from my local work branch.
I would suggest keeping small "topic branches", e.g. changes grouped together by functionality, and frequent merges with -dev if maintaining these branches is costly. It isn't for me, but I can see how it can be a pain with hg. BTW, I also tried maintaining functionality to be submitted in patchsets using Mercurial queues, but that didn't work out too well. I found I really prefer a branch to a "patch queue" for development. I guess part of my criticism is because I do not know how to get a cloned repository as a branch. E.g. instead of fully cloned monolithic weblocks-dev-with-modern-dispatching I would much rather pull in a branch off weblocks-dev called modern-dispatching. I could then see where it split from the mainline and possibly cherry-pick things from that branch. I do not know hg well enough to figure this out. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. 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/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
