Re: branches off of branches

[Peschko, Edward]

> 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