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.
"Tony Hoyle" <tmh at nodomain.org> wrote in message news:cu18he$vau$1 at paris.nodomain.org... > Matt Schuckmann wrote: >> Ok your starting to make a little sense now. >> One thing that I want to clarify is when you say bug you mean bug fix as >> in >> this revision of the file fixes this bug, right? >> And your saying that the bug maybe fixed on multiple branches of the same >> file and tags can't express that, right? >> >> Ok sounds like a feature that is a start in the right direction but still >> needs some work. >> The fact that you can't apply a bug id after a commit is done is a bit of >> a >> draw back. > > Mostly this is just a matter of knowing what you're working on before you > start work on it... it's a matter of process. What if a developer forgets to set the bug id when he checks in a file? A pretty easy thing to do. > >> The fact that you can't apply more than 1 bug id to a revision is a >> anther >> drawback I can easily envision 2 bug fixes relying on the same >> file/revision. > > Possibly... it'll probably be extended at some point in the future. It's > not really a limitation normally as most people work on one thing at a > time. > Yes most people work on one thing at a time but I've seen more than non case where one persons fix is dependent on another persons fix and it would be nice be able to express that dependency. >> The fact that you apparently can't remove a bug id is also a problem. > > That'd be changing history - modifying existing revisions is very heavily > discouraged. > I don't see this as changing history it's just removing a revision from a change set because you decided that it's not necessary for that fix or feature. Or god forbid you miss typed or made a mistake and inadvertently applyed a bug id to a file you didn't mean to. >> The fact that the same bug id can be on several revisions of the >> trunk/same >> branch doesn't make much sense. > > You can fix the same bug on multiple branches (in fact in the normal case > it'd be expected - you wouldn't normally merge to the stable branch for > example as it can risk polluting it with devel code). It's also perfectly > expected that a bug fix may take several revisions - I've had bug fixes > take weeks before now. You assume that everybody uses branches. Our process has been not to use branches unless it's a very large/long development effort for a new feature. For us everybody pretty much works on the main trunk, builds are tagged points on the trunk (called release candidates). We do a new release candidate once or twice a week. At all times there are up to 4 release candidates at different levels of release: CERT (very basic functionality has been verified), TEST (most functionality has been verified), EAT (very stable, considered good enough for the rest of the engineering staff to use), and REL (reserved for actuall releases to the customers, very few release candidates make it to REL). No branching is done for a release (unless we have to create a patch for a previously released release). When a developer starts work on a fix he updates to either the TEST or CERT build (this ensures that he is working with a stable build) plus any unpromoted functions or fix that his work may depend on (usually none). Developers check into the tip and label/tag thier checkins with a fix or function number. When a developer is done with work on a function or fix they tell the release manager that the fix is ready to go in to a release canididate. A new release candidate is a join of the previous release candidate and any functions or fixes that are done (again no branching or merging just applying new tags). If a uncompleted fix or function is in the way of completed fix or function the completed fix or function can't be promoted to a release candidate, but this rarely happens. It is very rare that someone checks out the very absolute tip. This gives us fine control over what goes into each release candidate and even allows us to back out a fix if testing determines that it's not ready. There is very little branching and merging involved and it works very well. > > Bugs tend to happen over a period of time, where as tags specify a single > unchanging moment in time. Agreed but are you really interested in seeing all the revisions that it took to fix a bug or just the moment when the bug was finally fixed, which is in effect a unchanging moment in time and all your really interested in anyway. > >> It still doesn't work for my senario, i.e. I want to create a Change Set >> that defines a fix or feature that a build manager can use to create a >> new >> build. If a bug id is on multiple revisions of the same file how does the >> tool (or the build manager) know what version to take. It still sounds >> like >> I want to use tags which brings me back to the point about applying a tag >> at >> commit. > > I can't see how that doesn't work? You can extract a fix from one branch > and merge it into another branch. If it covers multiple revisions that > change it is the product of all the revisions that are affected by it > (actually the minimum and maximum, as you can't just extract revisions out > of sequence). > It doesn't work because we don't use branching and merging and this bug id concept depends on it. Are you saying that cvsnt is smart enough to get the latest revision of a file with a bug id on a given branch? > Your build manager can do this himself if he likes, but it'd be simpler > for him to just keep an updated sandbox of the development tree and test > things when the bug is marked as fixed. > > Normally most people just create a tag at a pre-specified time (eg. the > end of the day, or at code freeze) then tell the testers to checkout that > tag and test everything that's marked as fixed. If that passes the tag is > then used to merge devel->testing for final release testing (pretty much > how cvsnt development works... the snapshots get taken and I tell people > what's fixed, and if it works it gets promoted to testing. Eventually the > testing release becomes stable when everyone is happy and the commercial > side agrees). > > Tony I don't thing that we are only people to use the release cycle process that I decribed which seems to be fundimentaly differnet from what you expect. This isn't a bad thing it just means that CVSNT isn't as good of a fit for us as we'd like. Matt S