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 wrote: > On Thu, 22 Jul 2004 11:27:49 -0400, "keith d. zimmerman" > <lists at kdz13.net> wrote: > > > >>The way we were doing things was to run rtag on the top of the sandbox >>at the time that we ran our build script. But since our repository is >>so large this could take a *long* time. Users were complaining about >>getting lock errors, etc, etc. So we changed the script. > > > The new version only ever locks individual files so that isn't an > issue any more - directory level locks have been removed (assuming the > lockserver is used, which is the default) For a while CVSNT has had > checkout atomicity which also works with rtag - partial commits aren't > tagged (or shouldn't be, anyway). > > Tony > Interesting. New version means above what version number? Do I have to enable atomicity? Are there any implications of the above? So, if I am understanding all this correctly, this is what i should do to make a new release. First, background. We have branches to denote our major releases, and in those branches we have tags to denote a minor release on that branch. Our major release may diverge very much from the HEAD branch by the time it's done. BUT sometimes we decide the release branch is too fscked up (especially early in the testing/release cycle) and just redo the whole mess from HEAD. Occasionally this will orphan changes in some files, but we don't really care. So, what I should do in this case, if I am hearing correctly is this: cvs rtag -F -B <branch> * cvs co -A -r <branch> whereas I am now doing cvs co -A -C and recursing 'cvs tag -l -F -B <branch>' through that tree. is this all correct? thanks, -kz