Going through your points in turn:
This one really worries me. Clearly a source control system that loses changes is only marginally better (or arguably slightly worse) than none at all. Of course we test as many different scenarios as we can and random data loss while doing typical operations would be a very large red flag to me. I have heard so few reports of this that I’m suspecting some odd interaction with something on your particular system – I’ll follow up on that with you separately if you’re willing. If anyone else reading this has just been angrily cursing at data loss and keeping quiet, please let me know.
It sounds like there are two issues here – the software and the interaction paradigm.
I think it’s fair to say CVS has a head start with a good ten years more experience on the software front. OK, so some of the GUI-based interfaces are a bit younger, but still, Workspaces is a mere infant by comparison 🙂. Yes, the backend we’re using is well-proved but the front-end interfaces (Windows Forms, HTML, VS.NET plugin) were all built from nothing, based around the web services architecture Workspaces created. These tools will improve with time, but I have to ask for patience. Likewise, integration with build systems, unit tests and other such marvels are all things that are possible in the future.
The lock-modify-unlock (LMU) model was picked for both its simplicity (it’s relatively easy to pick up and understand if you’ve no previous source control experience) and its familiarity for users comfortable with Visual SourceSafe. The exclusive checkout enforcement is something I’d like to relax as it definitely can be overly restrictive at times. Of course, that requires some merge/diff logic in the clients which again takes time. Allowing multiple checkouts of the same file brings things far closer to the CVS-like copy-modify-merge (CMM) approach you’re more comfortable with.
This, I’m pleased to say, is due to change. With an increasing number of Workspaces and activity, performance has notably degraded. We’re taking some immediate measures to improve database performance (which should have a visible effect on the GotDotNet.com site, as well as Workspaces’ source control) in the next couple of weeks.
Believe it or not, we really do care about site downtime. Earlier this week, we suffered some hardware-related failures with our database server; thankfully our backup practices and redundancy avoided any data loss, but it has certainly kept us very busy. We do try to mitigate such problems as much as possible, but as I’m sure everyone who works with computers knows, the occasional tantrum habits of the machine get you sooner or later.
Later this year (think July), we’ll be making some big changes in the Workspaces world but it won’t be a feature release. Instead, we’re reworking much of the infrastructure for performance and availability – no more 30 second delays viewing the directory or apparent hanging while syncing a folder. More details on that in time.
In the bigger picture, Workspaces is more than just a source control system. It turns out that different people have different needs – some look at it as a source control service with extra frills, other projects don’t use source control at all and rely on the bug tracking and other collaboration features. Balancing these requests to steer a course that provides the most needed features for the most is the challenge, but we’re working on it.
Yes, things are moving forwards, and you’ll be welcomed back as and when 🙂