[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Thu Sep 6 03:30:42 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:

>>> How is this different to what CVSNT already does?
>> I don't see that CVSNT does this at all. When merging in a sequence of
>> changes (that is, if you're not merging from the top of a parallel
>> branch), I think there are two methods: bug ids and the update merge
>> with two -j options.
> The single -j merge ...

You seem to be talking about the single -j merge exclusively. No discussion
here. I'm talking about the double -j merge (for one thing) and the bug
number (for another thing). 

The double -j merge has two points of interest (on the source branch)
related to the target revision. I don't think CVSNT stores these. Similar
the bug id merge; here it may even be several two-point relationships to
the target revision of the merge.

The business case: every merge has to be diligently documented. This costs
time, and the occasionally inevitable failure to do so costs even more time
later on. The version control system storing the merge commands in a format
that can later be retrieved and processed (e.g. for showing merge arrows)
can help here a lot. (No hard figures in terms of money or time saved, but
I think it is almost obvious that this saves time.) In this category fall
IMO an automatic tag on the root of every branch, and storing /all/ merge
relationships (including double -j merges, and non-contiguous bug id
merges) in the repository.

> Yes.  And I think this is a good thing not a bad thing.  For instance the 
> Eclipse team have written some very nifty functions by using nothing but the 
> basic CVS 1.11 commands, it makes their Java IDE more popular than some 
> others.

Nice, but imagine a business building its version control processes around
Eclipse features based on CVSNT servers and then needing to handle files
that Eclipse doesn't -- even though CVSNT would (as it does all of them).
Just because they switch editors now they have to change their version
control procedures. I wouldn't like that.

> Recent experience shows that adding "features" to CVSNT does NOT result in 
> them getting added to GUI's (unless we do it ourselves), but adding low 
> level functions that can be combined in a number of ways is likely to get 
> used (eg: "cvs ls").

This may be; I'm sure you have observed this much more than I did.

>>> What business problem does this solve?
>> What business problem any of this solves -- or whether it solves a 
>> business
> I generally do not ask rhetorical questions.  If there is no business
> case March Hare wont do it.  

Believe me, I understand that fully. I didn't mean to "request" this
feature; I just wanted to have it mentioned. When I do so, I know that you
have your priorities and will take it or leave it and either is fine with
me. I just think that my mentioning may have been the one thing that got
something rolling that for other reasons already was somewhere noted, and
in such a case it would be a shame to think that I missed that chance :)


More information about the evs mailing list