On 23 February 2015 at 16:48, Glen Harvy <g...@aquarius.com.au> wrote:
> I am using ToirtoiseHG to keep track of my projects however I rarely need > to actually fallback onto using it and am certainly no expert in its use. > > Having said that, I am thinking of changing my licencing methodology to > issue licences for specific versions of my application. When substantial > features are added to my application I want to charge at least some upgrade > fee. At present, end-users can take out a support contract which enables > them to upgrades and support but very few actually do this. > > Anyhow, the point is that I can see that some users will stick to their > current version but expect bug fixes whilst they have a support contract > for the version they own. Whilst I would expect some of these fixes to be > passed up to newer versions, not all fixes will need to be and in fact > could cause more bugs. > > To be in perspective, I wouldn't think that non-current versions would > require support beyond say a 2 year time frame. New major versions would > only come out once or twice a year. > > It's seems that I should create projects for each version and any > cascading bug fixes will need to be applied manually. > > I would appreciate any feedback to enable me to make some proper planning > now rather than later when they may be forced upon me. > Mercurial and TortoiseHG can do everything you need. You should read "Mercurial: The Definitive Guide" by Bryan O'Sullivan [1]. You will need to know all about push/pull and merging. Rebasing can also be very useful in some advanced scenarios. If your source code is modular and sensible, you should be able to merge patches between branches quite easily and manual backporting should not be necessary. Still, merge conflicts are inevitable so you will need to become familiar with a good diff tool. But before beginning parallel streams of development, there is one thing you should do now that will save you many hours of headaches later: make sure your projects 'build out of the box'. By this I mean that you must be able to build your project successfully from a fresh clone of your repository. If the build fails, your project probably depends on something that is not versioned, which *will* cause inconsistent builds. This commonly occurs when a project has references to other projects or assemblies outside its repository. Using NuGet correctly with your own package source can solve this. With regards to your workflow, there are about as many ways of using Mercurial as there are humans that use it. Still, you will generally have several clones of your repository going at the same time. Some of these clones may be "task branches" for specific patches. Others may be "development branches" for ongoing development of new features. Others may be "release branches" for preparing future releases. You will pull and merge changesets between your clones. Mercurial also lets you name branches but many people don't use that. Instead they just create a clone in a directory called "2.0" and call that their 2.0 branch. You must also know that a version control system is *not* a substitute for making backups. Changesets are no more permanent than any other file on your computer. When you have parallel branches of development you will be creating new clones and deleting old ones all the time. If you accidentally delete the only clone that contains a changeset, the changeset is gone forever unless you made a backup. [1] http://hgbook.red-bean.com/ -- Thomas Koster
