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.
On 2003-11-06, John Peacock <jpeacock at rowman.com> wrote: > Glen Starrett wrote: > > When I'm about to merge in a branch back to MAIN, I first merge MAIN onto > > the branch so that testing and conflict resolution happen on the branch, not > > on MAIN. Then when I merge the branch to MAIN it is seamless, shortening > > the time my sandbox is being updated on MAIN. > Merging is _always_ performed against the local sandbox. You > shouldn't need to do this double hop unless you are trying to > do the merge on a sandbox that is being used for something else > (like a web site). [...] Glen's approach (which happens to be the same as the one we use) is extremely useful for certain types of development. [Slightly off topic paragraph coming up...] The problem with the "do everything on the branch and only worry about mainline merging at the end" is that the merge can be non-trivial. Especially if the branch has lived a bit too long. We do *all* development on branches, and do test-driven development. This means that we have a set of unit tests, and the mainline is "guaranteed" to be in a state that passes them all. To minimise the amount of effort to merge branches to the mainline, we "lock" the mainline when we do it - for *this* to work, it makes sense to merge the mainline to the branch as the last stage of the process, get everything working, and *then* do the merge to mainline. (That way, if the merge is harder than expected, we can "unlock" the mainline, sort the problems, and start the process again - and mergepoints *really* make this easy to do. We find that we do lots of mainline-to-branch merges now-a-dats because it *is* so easy.) > As for why your method causes every file to be marked as modified, > without your actual commands (so it can be reproduced) anything I > say is speculative. [...] [back on topic again] :-) The sequence is (for a single file): 1. branch the mainline 2. on the mainline commit a new version of the file 3. on the branch, merge the changes from the mainline, and commit 4. merge the branch to the mainline At this point, the mainline will indicate that the file is changed, but diff will show no differences. A simple "cvs update" on the file (which would normal reset such a problem) won't do anything - the mergepoint information itself is viewed as a "change" that needs commiting, even though the delta would be null. It all makes sense, and CVSNT is doing the right thing. It is important to be able to commit a null-delta because the result of the merge *might not* have been the same - and then the developer looks at the conflict and decides the mainline version is the one that should be kept so winds back the conflicts. This ends up with a file that is no different to the "BASE" version but *is the result of a merge*. The patch Tony was talking about makes the server identify at the point *it* does the merge that there are no differences and then doesn't send back any changes. Result: no mergepoint recorded, and no change to the file. The problem is... well, it is a quite tricky area that is being played around with and it although I'm pretty darned sure it works properly, I wouldn't like to bet my archive on it *just* at the moment... (It passes all my tests, but my tests aren't exhaustive.) phil -- change name before "@" to "phil" for email