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.
"Bo Berglund" <bo.berglund at telia.com> wrote in message news:el9d01d6buoi8jo8hg28sc825geq1e229e at 4ax.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... > First we aren't using CVS, yet, we are evaluating it as a replacement for 2 older systems (MKS and Endevor). We use the system I described with MKS and labels which appeared to be very simliar to CVS tags, possibly with the exception of the stick asspect, There always seemed to be some aspect of stickyness to MKS labels that annoyed me, that probably because it wasn't done very well. Second I did state that the developer would checkout any unpromoted fixes or functions that his work might depend on (or conflict with) this would include updating to tip any files that aren't already checkout at tip. Generally builds don't stay at CERT very long and CERT and TEST are pretty close to the tip. If another developer is working on a different function or fix why would they use the same tag, they wouldn't, so there is no common tag and there is no reason for the tag to move, so there is no problem. Example Bob is working on bug 4343 in the bug database so he tags his files with FIX4343, Jan is working on feature 5653 in the requirements database so she tags her files with FUNC5653, even if the two overlap there is no common tag. When it comes down to promoting the two who ever got done first will have to be promoted first or they may have to be promoted together. Matt S. > > /Bo > (Bo Berglund, developer in Sweden)