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