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.
This whole discussion has brought us back to my origonal point, why can't you tag when you commit? Tony said it doesn't make sense, he also said that to use tags to discribe change sets is incorrect. However, you and Bo have both descirbed scenarios where change sets are described by tags and in those cases it makes perfect sense to tag the files your commiting at the point that you commit, when things are fresh in your mind and the chance of forgetting something is small. Tags can be moved up the tree as additional revisions for a fix are checked in and tags don't have to span the whole project. Additional comments below. "Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message news:1kxxdzhhi2ff5.pqq3fwfrilq6$.dlg at 40tude.net... > 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. IMO the BugID feature is too young and incomplete to be useful. The fact that GUI's don't support it is another major detractor. > > > 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...). > Yes every later feature is dependent on earlier efforts but only where those efforts overlap, in most cases they don't overlap. The whole point of the system is that you always know the intent of a set of changes (because the fix labels points back to a bug in our bug database) and (barring any dependency on earlier efforts) it is easy to identify and promote a particular function or fix to a release candidate. > 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... Yes this is true for our process. > > 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. > It would be nice if developers could base thier working sandbox on a known good, at least marginally functional, sandbox. Matt S. > Gerhard