[cvsnt-dev] The cvsnt modular architecture

Tony Hoyle tmh at nodomain.org
Mon Mar 22 15:04:18 GMT 2004


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.


These are my big 'hangups' as a coder, which annoy me intensely.

1. Code quality. If you write properly to start with then it's easy to
maintain and will take longer to become a rats nest (it'll happen
eventually... even code seems to suffer from entropy...  that's why
periodic rewrites are a good idea).  This isn't the 1970's... Use
objects, keep similar functionality together and be aware of the APIs
for each object.  C++ helps, but you can write object oriented code
in C (it's harder to maintain, but possible...  Not sure i'd bother
though in new code).
2. Modularity... related to 1.  Writing one huge single project that
does everything including wash the dishes means that you risk being
unable to change the design later (eg. CVS itself - it was originally
separate from RCS, then it was added to the same code but not
carefully enough, and now it's impossible to separate the two because
they're completely interdependent).
3. Assuming everything is Unix.  Big one this...  no we don't all run
ext2 filesystems and don't all have the same file formats even.  I
like Unix (I'm a diehard Linux user myself) but if it isn't usable
from a Windows desktop without any farting around with things like
cygwin and grabbing obscure libraries from halfway across the galaxy,
then its barrier to entry is too high.  Assuming OS semantics is a big
problem (CVS itself suffers from this, hence the case sensitivity
issues and the space in filename issues).

I've probably been guilty of all 3 multiple times...

That's partly why I came up with the modular architecture.  I'm too
lazy to bother writing everything myself if I can avoid it...  however
I'd like something that is going to be future proof whatever way the
VCS market goes (it's in flux at the moment...  difficult to see what
it'll be like in 5 years), and be nice and neat and maintainable.

(I did do a pretty diagram for ths but it won't translate to ASCII so
well).

Basically the first part is the lockserver (version 2) (already done),
which is linked via an IPC layer (already done) to the fileserver -
the fileserver abstracts the low level file I/O to whatever backend is
required (eg. RCS or a database, or even another VCS where
appropriate).
On top of these will be the generic versioning functions (diff, merge,
etc.).
On top of that lot goes the clients - the CVS Client/Server protocol,
a DAV server, SOAP, XML/RPC, etc. - whatever people want.

Each part is relatively small, and I can do each bit independently of
the main CVS exe, which will still work.  Of course most of it is
still vapour at the moment...  the design though can be changed
relatively quickly.

If for example everyone goes subversion in the next year or so, I just
change the backends to talk directly to subversion servers (possibly
even the subversion databases directly) and the frontends still work
transparently.

Well that's the plan, anyway...

Of course it'll not work out like that, but it'll be fun working out
what does work and what doesn't.

Tony



More information about the cvsnt-dev mailing list