[evs] Branching on commit, merge documentation

Arthur Barrett arthur.barrett at march-hare.com
Thu Sep 6 00:27:59 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.


Thanks for your comments and suggestions.

>> 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 does not necessarily have to come from a single parallel 
branch.  As long as there is a shared root at SOME point it works.  I've 
never seen an instance where a single -j (ie: a mergepoint) does not work. 
If you have one please give a diagram or talk us through the branches and 
when/why they were created.  Basically the single -j merge is simply 
merge -j this-branch to my current one.  I do almost always qualify a -j 
merge with a bug number, so there may be something I've never seen here, but 
then again I don't know why anyone would not use a bug number...

>> How would making this "one command" be significantly better?
> The difference is that if it is a command of the versioning system, you
> have a higher probability that you can build a procedure on top of it,

That seems to be similar to saying that "ls" should have a "grep" option 
since doing "ls -la | grep drw" has a low probability of working...

> because you're more likely to find consistent support for that. If it is a
> TCVS feature, the people who can't use TCVS have to provide their own
> support for it (which is relatively easy on the command line, but more

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 

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").

Occasionally someone will ask me "what GUI should we use" or the variation 
"why does CVS Suite include so many GUI's" and the answer is that different 
people/teams work different ways and the different GUI's are designed for 
different audiences.  My limited understanding of your "combined 
branch/update/commit" command (should be call it "cvs buc"?) is that only 
people following a very specific CM process and in a particular dev env 
would find it useful - an ideal target for a specific GUI...

We've intended for some time to ship a "combined client" that includes 
everything needed to get going in one installer - we already provide it to 
commercial clients but we are starting to move towards that in the open 
source version with 2.5.04 too, and it'll eventually get further.  At the 
moment I think a lot of people discard CVSNT since there is no "GUI" and 
almost everyone I've ever met has no idea TCVS has any dependence on CVSNT 
(which shows how sealmess TCVS's result is).  I'm personally all for 
increasing our relationship with other FOSS projects so that ideally we can 
each offer our own "pieces" but also offer a "combination" that makes it 
easy for people to get started.

With regard to your particular "problem" - I suspect the problem lies 
elsewhere and as a CM architect I'd be reluctant to solve it technically. 
If conflicts at commit are occurring so regularly to cause delays to the 
project then "cvs buc" simply moves to problem to another person (QA?), and 
the problem really lies in the design of the project (probably one file 
should be split into 20 or 30, or there should be several variations, eg a 
US, a EMEA, Asia etc).

If you or someone else wanted to add "cvs buc" you are welcome to and we'd 
happily add the code to the base, but as it stands I do not see 
justification for March Hare to spend time on it, at least not in CVSNT or 
EVS, but in TCVS it'd be a possibility and very little effort.

>> 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.  Before any line of code get's approved there is a 
specific audience, $ value (in terms of increase sales of the commercial 
product) and comparison to competing products and industry analyst or media 
comments (eg: SOX requires auditing so CVSNT got Audit, CMI determines that 
value in SCM implementation derives from finding relationships between 
changes so CVSNT got but id's).  So show me an analyst report that describes 
what a problem this is for business and how much it is costing, show me a 
media article decrying the lack of this feature in a competitors product, 
show me your company's annual report citing this as a reason for a lower 
than expected financial result, show me some business benefit - not just the 
desire for a new verb and I'll happily reconsider.  I think the easiest one 
to pick would be "lack of developer productivity due to complexity of 
software, resulting in additional overheads and slip in project schedules", 
however that plainly points to TCVS as the solution (or CM process 

Of course just because I am not interested in spending time coding this 
feature doesn't stop you, since you have the source.  In addition to Tony 
being paid to work on this stuff 8 hours a day, he also spends some of his 
own time on it and adds some things that he just wants to add, everyone are 
entitled to do that - it's the "free(dom)" in "free software".

I can say that it is eventually our goal to have each EVS verb to be a 
separate DLL/shared library so that any 3rd party can add an EVS verb 
without affecting the rest of the app.  This should make it easier to add 
new verbs that needing to re-compile all of CVSNT or EVS, however I do not 
think that is a version 1.0 deliverable, and I also do not know if Tony has 
given any thought to one verb calling another verb...




More information about the evs mailing list