[cvsnt] Re: commit followed by a tag

Matt Schuckmann matthew_schuckmann at amat.com
Sun Feb 6 22:35:55 GMT 2005


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





More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook