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, This is an old thread, but I am just coming back to it. If you have the time I have a question again, now that I finally got around to implementing this *embarrassed smile* Tony Hoyle wrote: >>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? >> > > I'd normally do that kind of rollback with: > > cvs update -j <branch> -j HEAD > > but your way should work. > If I understand the update -j code correctly, it will merge changes between the versions into the current code base. So considering this scenario: - Run Build Script. Creates the branch. - Commit several changes on the branch. - Need to run build script again and overwrite all changes in the branch with HEAD Am I correct in thinking that update -j <branch> -j HEAD won't kill the changes in the branch? Whereas 'cvs tag -l -F -B <branch>' (as I am doing now) will work, but only if HEAD has been checked out into the current directory? -kz