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.
On Sun, 6 Feb 2005 14:35:55 -0800, "Matt Schuckmann" <matthew_schuckmann at amat.com> wrote: ...snip... >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. ..snip.. >(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. How could a CVS user check out files on a tag that is not on HEAD and commit his changes unless you make a branch right there??? In CVS that is simply not possible to do. If you want to edit and commit to a file it MUST be on the "tip" of that branch before you commit. HEAD is the tip of the main TRUNK. Say that you are on HEAD and commit a few files to cover the bug, then tag this to the common tag name for this type. Next some other developers are working on another bug and they too want to commit some of the same files. The only way they can do this is to first update their sandbox to get your changes then commit it all again. Now they tag with the same tag as you used, thus moving it forward. Later it is found that your fix was OK but theirs not. How do you propose to resolve this once the common tag has been moved away from where you fixed the bug??? And the above is not even possible unless the developers start out on head checkouts... /Bo (Bo Berglund, developer in Sweden)