[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Tue Sep 11 02:59:47 BST 2007


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


More information about the evs mailing list