[evs] Does EVS remove some of CVS limitations?

Arthur Barrett arthur.barrett at march-hare.com
Wed Feb 6 00:56:13 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.


> Late identification also won't address other interpreted languages (such 
> as HTML) where filenames / locations are critical to proper functionality.

Yes - I saw your other post on that topic.  In my experience and supporting 
all our suite/pro customers (a lot of whom use CVS Suite for managing web 
sites) this is not a problem in practice.  Web developers don't make a habit 
of renaming files - it's a killer for a web application because as soon as a 
web site is live people start bookmarking URL's and to change them is a kiss 
of death.  In theory you are right - but in practice wrong.

> Is there a thread somewhere that I can catch up on this conversation?

It was on comp.software.config-mgmt - it'll depend on how long your 
news/nntp provider archives it for how far back you'll be able to read.  The 
thread started out as ' Branch yes, merge no' with my first post on about 
Nov 6th 2007 and changed to 'what differentiates SCM from VC' around Nov 8th 
2007 and changed to 'Specs for future SCM' around Nov 10th 2007 and then 
there were a few branch discussions from there.

comp.software.config-mgmt is a tool agnostic newsgroup - great for 
discussions about SCM in general or SCM methodology - though a working 
knowledge of clearcase is often assumed.  If you are from a technical 
background like me the language used can seem at times quite a hurdle - but 
patience and politely asking for clarification is always responded to 
positively by the old-timers.

The newsgroup is archived on google:

As with most web based news readers the search and threading functions are 
pretty broken so I wont attempt to link to the discussion directly, but you 
can do a search for the subjects specified and you'll get a rough list...

> Forgive my lack of knowledge, but what is clearmake and how does it relate 
> to the issue?

Clearmake is part of the IBM ClearCase build system: I'll not even attempt 
to answer your question in detail - see the above thread if you are really 
really really interested.  Suffice it to say that until there is an decent 
open source build system (better than clearmake hopefully, since noone has 
touched a line of code in that for over 10 years, and it doesn't support 
Java) that there are some business 'problems' that we just can't really 
solve well for an organisation.

> I'm not entirely sure what "late identification" is, but I really don't 
> see the Java spec changing anytime soon.

Agreed - since it was Marc I just wanted to be clear to him that I 
understood the theory.  I thought I was pretty clear in saying that we need 
a pragmatic solution since the chances of a change in javac is slim.

> The whole concept of class /file naming is pretty much a building block 
> for the language, and while it seems incredibly strange to non-Java 
> coders, once you get into it, it actually tends to make things a lot 
> easier to work with.  Coming from a C/C++ background myself, I found the 
> whole concept incredibly bizarre when I first started in Java, but soon 
> got quite accustomed to it.  It is a case of the language imposing a 
> certain organization and structure to the coder.

Yes that's all well and good - but the people who implemented it did not 
think about the impact on build, test and deploy (ie: SCM).  To come up with 
a new language spec in 'modern' times and never think about what it'll be 
like to manage in a large project was negligent.  Marc is spot on - the 
compiler/build system should use late identification.  But you are also 
spot-on: we can't wait for that to happen and must come up with some 
suitable support in the meanwhile.

Furthermore a decent open source build system needs to be built that can 
'work around' this negligent engineering in Java to provide a decent SCM in 
a Java environment.  ie: management need to know which release candidates of 
the java app use eric.functional.Example and which use 
eric.test.TestExample, which changesets (bug1234, bug1235, bug1236) rely on 
which class etc, and finally they should be able to schedule new builds 
using codebase B_1_1_0_3 with either.  We can do all this in CVSNT for 
C/C++, Pascal, Fortran, SQL*Plus, Uniface, Ada, COBOL, MASM and pretty much 
any language other than Java, but the solutions in CVSNT take time to put 
together and are not as 'obvious' (or inuitive) as they are in ClearCase - A 
lot of EVSMANAGER is about fixing the lack of 'obviosness' of the current 
solutions, and we are hoping to release something of our own solution to the 
build issues (including Java) late in 2008 or early 2009.

I think this has gone completely OT though - there isn't a decent SCM build 
solution for Java and wont be for some time - that is not EVS's problem (or 
better said: it is not the problem that EVS was designed to solve).  You are 
right though that EVS needs to support the Java programming methodology 
which effectively implies the need to have an option to propagate renames 
with a merge.  I think an 'ideal' soltution would be able to specify a 
default by file type (so for instance .java files could rename and merge, 
but .c/.cpp files would not - but that's probably just overkill on a project 
that is already late...).


Arthur Barrett

More information about the evs mailing list