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: > 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. > 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. > 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. > 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. Bugs tend to happen over a period of time, whereas tags specify a single unchanging moment in time. > 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). 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