Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Matt Schuckmann wrote: > I will admit that I've been working on the assumption that managment > wouldn't let me change our proceedure, since then I've discovered that they > are open to some changes in proceedure, so I'm exploring new possiblities. My experience is that procedures almost always have to change (maybe only slightly, but still) when you change version control systems. > The whole bug ID concept could be used except for a couple of restrictions: I haven't yet worked with the bug ID, and it's still too young to be supported by any GUIs. > Another solution could be that all functions and fixes could be on there own > branches which are then merged back into the TRUNK when they are ready to go > into a release candidate. Developers commiting to the trunk would not be > allowed, except in rare cases. This seems like an awfull lot of branching > and merging, and the potential to merge things out of order greater. It needs a bit of organizing, but this is essentially similar to what I've done before and what Bo just suggested. It doesn't really matter a lot whether your release is on the main branch or in a "real" branch; this is more a matter of taste. I still don't understand how with your current way you get to the fine-grained control of which feature goes into release and which not. The way you described, it seems that every later feature (Jan's FUNC...) is based on the earlier efforts (Bob's FIX...). If this is ok, what's the problem with a development branch and a release branch? (Either one could be the main branch.) On the development branch, you have all fixes, and of course there's always the chance that a later one depends on an earlier one (just like it is now). People could either work directly on the development branch and tag it when they are done with a fix or feature, or they could work on individual branches for every item, but then merge the branches back to the main development branch when that item is completed. This would bring a number of advantages: - it allows easily to identify (and review) the changes each item has brought, - developers can commit freely during work on an item because their intermediate commits with incomplete and maybe buggy code don't disturb anybody else (which gives them centralized backup of their code and the possibility to create diffs to earlier stages in their work on this item), - the merge of the item into the main development branch would be done as part of the normal closing work on an item (when memory about what's important to look for is still fresh), not at some later point, - the merge is only small (reducing the chance of errors and conflicts), because it only needs to merge any other items that have been committed to the development branch during the time it took to implement that item, - and the development branch remains reasonably stable, because it receives only already tested items. You can promote any point in the development branch to the release branch (or before that to an intermediate test branch, which then gets promoted to the release branch). If an item was committed after another one, in general it is not trivial to promote the second but not the first -- but I think this is also true for your current way of doing things. So maybe it's not that different after all... I don't think that developers should have to (or be allowed to) merge in individual fixes when they get a working base. In my experience, merging is not a trivial action and should be done with care -- and not more often than necessary. In my scheme, developers simply get the always current development branch when starting on a new item. Gerhard