> makes sense or not is a different issue. In the above scenario, merging > as you suggest is certainly the most sensible way to do it.) > > > but it then behooves you to remember when you've done > > the damn merge.. > > It always behooves you to remember (typically with tags) what you've > merged, unless you intend to merge the branch exactly once and then > abandon it. >
yes, but I want *cvs* to remember it. If I say: cvs update -j TEST from head, then I'd like to have all further updates from test go from the point of where I last updated. Or, at least have the option of doing this via a command line argument: cvs update -j TEST -m (for mnemonic) Likewise.. cvs update -j TEST -j DEV -m means migrate changes from TEST to DEV, and remember the migration. Then, if, inside head: cvs update -j TEST -m this would migrate the TEST changes into head... on a cvs update -j DEV -m it would remember that the DEV changes have already been put into test... etc. etc. In short, it'd be cool if merges could remember their merging, and if there was some sort of repository of the changes that have been merged. It'd save one hell of a lot of tracking down conflicts. If this was true, I wouldn't have to worry about branching off of branches, or what not. As far as I can see, merges would all 'snap to'. Or am I missing something? Ed _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
