[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Fri Sep 7 16:05:57 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:

> Yes exactly - we already support this, just in a way that gives more
> features, so trying to implement the monotone way would just confuse
> people...  Using the changeset id /bug id means you can then use this
> information over and over again, eg: to create release notes, to back
> changes out etc etc.

Just to make this clear: I'm not talking about changing this; I think this
is a very good feature.

>> Every such bug fix merge is essentially a double j merge (or a few of
>> them) -- independently of whether you use a bug number in the command
>> or two tags with two j options. In the end, you might have merged the
>> changesets between revisions 1.5 thru 1.7 and 1.11 thru 1.15 into
>> (for one file).
> 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).


More information about the evs mailing list