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 Berglund wrote: > AFAIK the merge operation will for example take data from a branch and > 'push' it into the *working copy* in my sandbox. But this is not to > say that this edit actually will be committed! I have made several > attempts at merging some code that lived too long on the branch and > found that the result was less than acceptable. So instead I have made > some manual adjustments and committed this (basically just replacing > the HEAD code with the tip of the branch without merging anything). Yes that works OK... we do that with some of the nastier merges to save time. > If the server notes the request for a merge and remembers where it was > done and then assumes that these changes are what gets committed then > in my view it is assuming too much. Not really... you have a merged sandbox, which gets committed... whatever happens in the meantime it's reasonable to assume that what's in the sandbox is the result of the merge. Of course if you then do an update it'll forget the mergepoint (because the file/sandbox isn't purely the result of a merge any more). > What happens for example if multiple merge requests are done with > varying parameters or if several developers ar trying to merge at the > same time, or if the merge result is abandoned for now??? If you do multiple merges to the same sandbox without committing it'll only remember the last one, but that's a pretty unsolvable problem really... the more complex cases will still require some use of tags. In the common case where you're merging two parallel streams of development it works well. Multiple developers don't matter... the second one to commit will get a conflict, as normal, if they're marging the same part of the tree. Tony