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: >>> Instead of doing a double j merge, commit with a bug id and use a >>> single j merge plus bugid, then only the changes represented by the >>> changeset will be merged. >> >> Yes, I knew that. And it is not the merge process I'm talking about, >> it's the documentation of the merge: being able to run a log on a file >> later and see what got merged from where to where. Merge points now >> provide this for normal single j merges from branch to branch, but I >> don't think that bugid merges do (and neither do double j merges). > > The -B "changeset" option must also be specified with a single -j, so if > you merge with a -j and -B then yes you do end up with a mergepoint that > you can "see" in the revision graph view of TCVS. > > The reason why you have to specify a -j with a -B on merge, is the same > bug can be fixed on many branches (in different ways), so the -j > specifies WHICH branch changeset you want to merge to this branch. Interesting -- I already wondered how CVSNT deals with this situation of the same bugid on several branches. Makes sense. But I think I still don't get the whole picture, as far as merge documentation is concerned. First question is whether the start of the merge is documented in the RCS file. A bugid changeset in the simplest case is a range of revisions that has a start and an end. You say the merge point is stored in the RCS file, but as I understand merge points, that just identifies the end revision of the source branch and the target revision on the current branch (where the merge happened) -- it doesn't identify the start revision of the merged change set on the source branch. This can be expanded to several ranges with a start/end revision pair that belong to that one bugid. Does this all appear in the log output? The other question is about the bugid. I think it would definitely be helpful to have the bugid stored together with the other merge information and be able to retrieve it later. With both of these, you could pull up a revision graph of a file, and see which bugids have been merged, from what branch, and what revisions did get merged in for each bugid. > None of this is obviously in the manual... ;) Do you want commit rights > to the repo so you can amend the docbook? You can either get a docbook > editor (I can dig up the name of the one Tony uses) or you can just use > notepad for small changes (which is what I do). On this feature I'd have to do some testing to understand it better before I write about it, but on other things I may be able to help with the manual. So yes, I'd like that (and the name of Tony's docbook editor). Thanks, Gerhard