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.
Tony Hoyle wrote: > Matt Schuckmann wrote: > >> Surely there is a need for it or else people like me and whomever >> implemented the Move Branch to Head macro in WinCVS wouldn't be doing it. >> >> If I remember right if a file changes on the main line but not on a >> branch when you do a merge from the mainline to the branch a new >> revision is created on the branch that is identical to the revision on >> the mainline. In my mind this is wasteful and unnecessary. Plus it makes > > > Revisions are a few bytes.. even if it created hundreds, even thousands > of them it wouldn't make any difference. > > What is important is reproducability - you need to be able to checkout a > branch and get *exactly* what you got before, otherwise any testing done > is meaningless. That's the whole point of a source control system - and > is why it's not uncommon to have the whole build system under revision > control, not just the source code. No I'd say that's what a tag is for. A branch is an alternate line of development for one or more files. Anybody can check in new revisions one or more of the files with a branch tag and all of the sudden you get something different when you check out a branch. What I'm suggesting is really no different checking in new revisions on a branch or performing a merge from trunk to branch. > > You can't simply move the branches around in many cases - the branch is > a delta from the revision that it was created at. Moving branches with > revisions on is error prone and IMO dangerous. Magic branches handle > the non-revision case for the (rare) cases that it's useful (the > original example was template configuration files with customer specific > changes to a few of them). > 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. Matt S. > Merging is a nontrivial operation for a reason - you can't just take two > random branches and stick them together without operator intervention. > Where did that come from, it has no bearing on anything that has been said so far. > Tony