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