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.
Gerhard, > I think it only works if the bugid commits never contain any code that has > been merged in from a branch to which you merge that bugid code later. Err yes - my example was backwards. So when you make "real" changes to the branch then you use unique bug ids, and you then merge those bug id's down to the trunk, which obviously don't exist there... But that is potentially more than just a single merge, since there may be 20 or 30 or any number of them... Back when this was frist described I had never heard of it being needed, and I still am in the same boat. If a bug is found on the branch that is applicable to the trunk then that bug is applied down to the trunk at the time (either by merge -j branch -B bug or by recoding), not some arbitrary point later... But I understand you are describing a process that works for you - I can't help myself suspecting that if changesets were used more then a change a little here and a little there to the process and most of this "problem" would go away. Suggesting a double j mergepoint for EVS now we have all the details makes sense I think, but I still remain sceptical that you'd really do things that way if you were using changesets... Or if not maybe changesets need to support this process better... Regards, Arthur