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.
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 > > > > >