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.
Arthur Barrett wrote: >> I still think it would make sense to have start and end of a double j >> merge stored somewhat similar to a merge point. You say it's a rarely >> used feature, but a double j merge is exactly what Tony suggested for >> merging a branch back to its ancestor -- which I wouldn't call a rare >> or exotic situation. (Even though that is a special case of the double >> j merge, it still is one.) > > I remember that conversation differently, I remember both Tony and I > considering it very rare but several people all indicating that they do it > and find it useful. The situation I was talking about (and that was a part of that thread back then) is e.g. a feature branch off a development branch. You keep it for some weeks developing a feature, and during that time you keep the feature branch close to the parent branch (be it trunk or some other branch) by regularly running single j merges, merging changes from the parent branch to the feature branch. At the end of the feature branch, you want the feature code to go into the parent branch. Tony proposed a double j merge for merging the difference between the parent branch and the feature branch into the parent branch. (Of course best used after a last single j merge from the parent branch into the feature branch and resolving all conflicts there.) > My solution is different to Tony's - I think SCM without bugid's is a bit > rubbish, so I'd always be using bug id's in which case a double j merge > would not be necessary I think - though I haven't tested that particular > scenario... It seems that if you mark all commits on the feature branch with a bugid and eventually merge that bugid into the parent branch, you get the same conflicts you get with bidirectional merging, as you would essentially merge back into the parent branch all the code from the parent branch that has already been merged into the feature branch (and has been conflict-solved there). I don't see how bugids would help in such a scenario, where you have to keep the bug/feature development regularly updated with the changes to the parent code. > The "problem" with providing support for a double j merge is defining new > information to go into the RCS file, then getting tools like the > revision graph to support it. It's all feasible, but unless a large > commercial support customer requested it then it's just not going to end > up on the March Hare CVSNT todo list anytime in the near future. This is the reason why I started this conversation here on the EVS group. I'm fully aware that it is a big change to add such information to the RCS files, but I thought that since the internals of the revision storage probably are going to be somewhat redesigned anyway for EVS, you guys may think about adding complete merge documentation to it. > A compromise feature would be the ability to "add" bug numbers to > revisions, which I've been thinking about the need for for some time. If > the bug number plus revision option works on a "backwards merge" (needs > testing) then that would provide a solution within the range of > information already stored in the RCS file... 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. Which may be the case in some scenarios, especially with smaller bugs or features, but with larger features or bugs there are often merges from the mainline involved (to which the bugid code later would get merged) -- so it may not be the general case. Gerhard