[cvsnt] Re: virtual branches ?

[Matt Schuckmann]

Bo, you are close to what I'm asking. What you described is currently 
called Magic Branch. The Magic Branch concept does exactly what you 
described "auto-magically" each time a new version is checked in to the 
HEAD. The problem is just that, it does it automatically you have no 
control over when the branch point "floats" to the HEAD and it might 
break your branch unexpectedly (not to mention that the implimentation 
is somewhat flawed for the corner cases).

I'd like a command (or option to the merge command or option to the 
tag/rtag commands) to float (or move) the branch tag (for all the 
unbranched files) to the HEAD (or to a user specified tag or date). This 
way you have control over when the move happens and you can test it and 
ensure that it doesn't break your branch build and you keep the physical 
branch (i.e. the list of actually branched files) from being polluted 
with changes not relevent to the purpose for the branch.

It could be an option to the tag/rtag command like the -F option, except 
it only works on branch tags and it only moves branch tags which have no 
revisions on the branch.

Matt S.

Bo Berglund wrote:

>I don't remember asking to move branches with revisions on them, that 
>would be a stupid thing to do. I'll try to say it again: It would be 
>nice to have a command that floats branch tags for files which do not 
>have revisions on that branch yet. This is very similar to the magic 
>branch  concept with the exception that you have control over when the 
>float happens. This would be an operation done just before merging from 
>the trunk to a branch.
>The idea being you are starting work on some task so you create a 
>branch, you  modify a few files and check them in to your branch. Mean 
>while changes have continued to happen on the trunk. At some point you 
>feel that the changes on the trunk are stable enough that you want to go 
>through the "expense" and additional testing of bring those changes into 
>your branch for your benefit and testing. First you float the branch tag 
>for the files which have changed on the trunk but not in your branch 
>then you preform the normal merge operation, maybe it should just be 
>part of the merge with a special option to indicate that you want to 
>float unbranched files.
>
>----- my comments below (using Outlook, which wants to top post... -----
>
>I have been reading this conversation for some time without understanding
>at all what it was all about...
>
>But maybe I have realized it now, please tell me if I got it right:
>
>Matt,
>what you propse is that when you create a branch off of HEAD then what you
>want is that all files in the branch should stay on HEAD as long as you do
>not edit them in a sandbox located on the branch.
>This way these files do not need to be constantly merged from the moving
>HEAD state in order to keep the alternate development up to date on the
>files that you are *not* editing on the branch.
>But at the moment you edit such a file on the branch then it will get the
>branch revision when you commit it based on what was current for this file
>when the commit was done. After this the only way to get HEAD changes into
>it is the normal merge from TRUNK.
>
>Is this what this is all about?
>
>If so then I too think it would be a valuable possibility when you branch
>off from HEAD to test a new idea or similar and later merge it back if it
>was successful. Often such things are done only on a few files and they
>need the other files to stay in synch with TRUNK.
>We do this often and we need to constantly merge the branch from TRUNK in
>order to stay current and reduce the merging problems once we get to the
>end of the process.
>
>If I got it right then I was grossly misled by the strange name "float"
>you gave to the branching idea...
>
>/Bo
>
>
>
>  
>