Which source control paradigm and solution to embed in a custom editor application?

Question

I am building an application that manages a number of custom objects, which may be edited concurrently by multiple users (using different instances of the application). These objects have an underlying serialized representation, and my plan is to persist them (through my application UI) in an external source control system. Of course this implies that my application can check the current version of an object for updates, a merging interface for each object, etc.

My question is what source control paradigm(s) and specific solution(s) to support and why. The way I (perhaps naively) see the source control world is three general paradigms:

1. Single-repository, locked access (MS SourceSafe)
2. Single-repository, concurrent access (CVS/SVN)
3. Distributed (Mercurial, Git)

I haven't heard of anyone using #1 for quite a number of years, so I am planning to disregard this case altogether (unless I get a compelling argument otherwise). However, I'm at a loss as to whether to support #2 or #3, and which specific implementations. I'm concerned that the use paradigms are subtly different enough that I can't adequately capture basic operations in a single UI.

The last bit of information I should convey is that this application is intended to be deployed in a commercial setting, where a source control system may already be in use. I would prefer not to support more than one solution unless it's really a deal-breaker, so wide adoption in a corporate setting is a plus.

Update: I'm specifically looking for a few bits of reasoning:

1. Which paradigm makes sense either because it's commercially accepted? (I think this one has been answered by @Andrew Colson, but others' experience may differ)
2. Is it a reasonable assumption that an average commercial development shop would prefer to utilize an existing source control system, versus maintaining a second one for my application (given that my app fulfills a non-trivial need that is separate from normal development processes)?
3. For my needs, am I correct in assuming that #2 and #3 cannot be reasonably captured into a single set of operations, without distorting one of those paradigms?
4. For the paradigm you think I should use, which specific implementation(s) do you think are critical to support?

Answer 1

If you want wide commercial support, you're looking more at #2 than #3 currently (or potentially even #1..).

EDIT: Of course, it depends on what you mean by "commercial", but large commercial organizations tend to be behind-the-curve in developer tools. I've primarily seen SCM-per-project/group, but I'm sure less-technical commercial organizations might just use a single SCM solution provided by their IT group.

Answer 2

#2 and/or #3

#1 Single-repository, locked access - are rarely used nowadays so they're not really worth mentioning.

#2 Single-repository, concurrent access - are called VCS or CVCS (Centralised Version Control System) are still widely used.

#3 Distributed - are the next-big-thing because they remove a lot of the artificial barriers that the other systems impose on the developer.

First, answering your questions/concerns:

1. Commercial acceptance depends on the organization and it's developers. If the managers are the ones in charge of the software being used and they tend to hard-line conservative decisions with little actual evidence, they'll probably default to whatever Microsoft has to offer. In which case, good luck. All I ever hear about MS version control (SourceSafe specifically) is bad things and I'm not sure if MS has a DVCS option yet.

OTOH, if the developer teams are in charge of picking their tools (or the managers are open minded), probably git or mercurial are the way to go. git will be a pain to adjust to because it's overly complicated. mercurial is a pretty easy transition from CVCS, be sure to download the tortoisehg GUI client to get a feel for the workflow. Both are completely stable and ready for production. Mercurial, and Subversion are used on Sourceforge.net as well as Google Code which both to host many thousands of projects. Any bug they might have, they either know about of they've already resolved.

2. I'm pretty sure I speak for developers as a whole when I say that, "In this day and age, rolling your own version control system is a ridiculous waste of time and energy."

Sure, you could probably make a special purpose version control system that is small and fits your application; but, before you decide to, consider all the time and effort involved in the undertaking. Not to mention, you'll need to put the code for your version control system under version control. nuff said...

3. No you're not, you can actually use both together. Lots of people use CVCS (usually subversion) for centralised version control on an organisation-wide level while using a DVCS to develop locally in smaller groups or individually (there are even stories that Microsoft engineers use git secretly in their developer subgroups). Since a DVCS is represented in the file system by nothing more than a hidden folder and maybe an ignore file, it's easy to add all that info to the CVCS ignore file so that info isn't tracked in the central repository. Easy peasy, you can leverage the advantage of both if necessary.

I think there's even ways to transfer the commit history of the DVCS to the CVCS when you commit to it. Although, I wouldn't know exactly how since I've never had a reason to.

4. #2 and/or #3 definitely.

I say both if there is already a CVCS in place and you're expected to use it.

Subversion could probably do everything, but the problem is, all of the version history for a CVCS is kept on the server. IE, if you don't have direct network access you can't commit or update. This can be fine for some developers but most developers are on the move and can't always find a network connection when they need to work. The bad part about that is commits get dragged out and they end up working on source that is further out of sync with the trunk development branch. Subversion (or CVCS in general) is also notoriously bad at handling branches, meaning, if you have two developers testing ideas out on two different branches of the mainline and they decide to merge them back together things will get ugly. DVCS are much better at branches.

If there is no CVCS in place already use DCVCS only.

DCVS is capable of doing everything since you can have a remote clone of the repository act as a depositing point. The difference in workflow is, when you commit to a CVCS you if there are no issues, it goes straight into the remote repository. In a DCVS when you commit it commits to the local repository if there are no changes. Then, after you're ready to release a set of changes you push (or synchronize in mercurial) your commits to the remote.

Since repositories in a DCVS are all the same, you can push/pull from any other repository, no matter the location. It's a little tricky to wrap your head around at first but it has some distinct advantages. First, you are always carrying the project's history wherever you go so, if the central server goes down, all of your developers are carrying backup copies of it around so it's not a big deal. Second, it's hugely beneficial to allow developers to commit whenever they want without limitations. The more developers commit, the more detailed the version history will be, and the faster you'll find problems if the code needs to be rolled back.

To implement what you're describing. Create the starter repository wherever you want it to be located. All it needs is network access.

Copy the initial files to the project folder and commit them.

Have all the people working on the files clone their own copies of the repository.

If you need to do updated programmatically you can check whether changes need to be pulled from the central repository or commit and push new changes out when necessary all using the command line.

As long as you can write the serialised data to a text file in the folder under source control it's not an issue. You'll have to resolve conflicts by hand when you commit/push but that's to be expected from any version control system.

If you want to make sure there are few or no conflicts between the remote and local repositories, have the local copies always pull before committing. That way, if there is a conflict, it can be handled locally.

That's all I got.