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.
Last week I had a meeting with the march hare staff to discuss where the prioriries where going, plus some technical discussion about how best to implement it. As a result I've had rethink and rewritten the vfs layer to be independent of CVS or RCS (EVS is supposed to be a version control platform that happens to have CVS as its primary protocol, not simply a reimplementation, so this makes sense). This has several effects: 1. We get the transition to a database only version a lot earlier. The advantage being we don't have to do things in an 'rcs way' in the lower levels of the code. This has freed me to implement a lot of things I wasn't going to do until version 3. 2. The DAV layer can be written native on top of the VFS/CVSAPI rather than through a hacked up evs client as it is now, which means it will be running at native speed (currently hitting F5 to refresh a mapped EVS network drive takes a while..). 3. I've got to write another layer (cvs translation layer) so that the main evs.exe can make sense of it all. 4. This will delay the next test release a week or two - *but* it'll be worth waiting for :p. What we do get from this is a real fast tag and branch, symbolic links (probably replacing modules2 - symbolic links are much more powerful as they're versioned and can point across branches), and of course the reliability that having a database gives you (ACID compliance, etc.). Tony