[evs] Does EVS remove some of CVS limitations?

Arthur Barrett arthur.barrett at march-hare.com
Fri Feb 8 06:41:44 GMT 2008

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.


> Agreed, but you'll forgive me for saying so, but that seems like a very 
> closed-minded approach.  One of the great sounding things about EVS is 
> that it seems to be incredibly flexible and allows for a lot of different 
> interaction between different types of applications.  One of the ways that 
> I would see this as being open architecture would be to provide the 
> ability for other web applications (such as Bugzilla, Jira, Wikimedia, 
> Confluence, Fisheye, etc, etc, etc) to comunicate directly with EVS 
> instead of needing to parse log files, read the repository DB, etc....

Quite the opposite - we've written a C++ API that works terrific.

As I wrote in my last post:
> I suppose in theory we could provide web api's for everything from the bug 
> tracker to browsing version to commit logs, but there is no plans to do 
> that in EVSr1 (Tony and I have got enough to do already).

Other people can of course create other API's.

> It's a shame you didn't choose Java as the language of choice for EVS 
> given all the OSS libs and frameworks that could have helped make 
> development easier.  (yes - I have become a Java convert over the last 
> years).

Two of the requirements that excluded Java are:
* high-performance
* ease of deployment (no Apache or other 3rd party apps other than the DBMS)

I suppose EVSMANAGER could have been written in Java, but we have no 
in-house expertise in that and specifically wanted to leverage existing 
expertise in C++ and it would have made deployment reliant on something like 



More information about the evs mailing list