Earlier this week I uploaded all of the history for PyMOTW to BitBucket.org.
BitBucket uses Mercurial as its DVCS, and after a couple of hiccups with the initial conversion I've had pretty good luck. I think I have the workflow down far managing local changes vs. updates pushed to the central repository.
I still need to work out how (and whether) to use branches. I have a sense that I can use local clones in the way I used to use branches: starting an article that was going to take several sessions, without committing the changes to the trunk. What are the typical practices for hg branching? Do people use them?
Today's PyMOTW post is the first post since the change-over. If you encounter any problems, please report them as an issue via the BitBucket issue tracker.
4 comments:
Many people just use clones as their branches. Only when your repository grows very large (as in number of files), that may be problematic.
Named branches (as we call the built-in branch support) can also be nice, though many people don't grok the way it's done at first.
I'm one that doesn't grok hg named branches, I guess. I had some changes submitted to virtualenvwrapper, but was unable to merge them in a way that let me push the results back to my main repository. I ended up just copying the files into a clean clone using cp and losing the history.
The errors ranged from merge conflicts (I finally found the -m option to hg merge) to "abort: push creates new remote heads!", which I never resolved.
I use hg to manage branches of some fairly large projects at work, and I always just use a clone of the original. I've never liked the git-style "everything in one directory" workflow (especially since it makes it hard to view two branches side-by-side), and once you get used to the workflow of pulling and merging from the right place it goes pretty easily.
@James - Cloning the original does make more sense to me, for all the reasons you list. I don't know if it's because I'm used to svn's version of branching, or just dense. Either way, I'm going to try to stick to simple clones for my own work.
Post a Comment