Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Most of the version control systems I have used have a lot of similar functionallity for source code files: they work on their text content, diff using well known diff algorithms, the changes contain deleted and inserted lines of text, the whole workflow is based on some form of commits, branches and merging of branches.

Several days ago I found and I started playing with Darcs, a version control system created by the Haskell community based on Patch theory. I wonder if there are any other, more esoteric version control systems based on different concepts(e.g. different kind of commits, working on code structure, etc)

share|improve this question

closed as too broad by GlenH7, MichaelT, Thomas Owens Jul 26 '14 at 12:50

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Subversion and CVS are pretty different, I suppose. – Casey Jul 25 '14 at 14:52
the FTP version control system works very different, every user has the access to the same files and hopefully they don't overwrite each other's work. – Matthew Jul 25 '14 at 15:01
Well, I don't consider ftp as version control system(or at least I can't find something called "ftp vcs" in google) – Alexander Ivanov Jul 25 '14 at 15:21
@AlexanderIvanov Matthew's FTP comment was most probably a joke - just dump your files on a common server and hope for the best. – metacubed Jul 25 '14 at 17:23

I think you'll find all SCMs are roughly the same, though you could consider Visual Sourcesafe as an esoteric outlier :-)

Nearly all work on diff deltas between commits, SVN for example has the same kind of diff+patch approach darcs does, only it doesn't try to pull in more revision history than you ask it to when merging (I'm not sure if Darcs trying to reduce conflicts by pulling in more revisions is a good or a bad thing, probably both at the same time).

Git, Mercurial, Bzr, Clearcase, TFS, all do things pretty much the same way.. the differences are in how they present these differences to the user and allow you to manipulate the commits.

For example, Fossil is a newer one that works to auto sync your changes with an upstream origin if it can to give you the kind of DVCS flexibility whilst giving a CVCS style 'commit to server' as well. But again, it still works on diffs the same way, just gives the user some slightly different way of working.

share|improve this answer

Image-based systems such as most Smalltalks, LISPs, but also the Intentional Domain Workbench and similar tools have VCSs that aren't based on text. In those systems, programs aren't text files, they are semantic graphs of rich objects. In image-based systems, "programming" actually means "mutating the live running program while it is executing". Their VCSs work based on semantic transformation of the semantic graph.

Traditional VCSs basically have three operations: add line, remove line, replace line. Semantic VCSs have operations like add class, rename class, add method, rename method, extract method etc. (similar to refactorings but slightly lower level).

share|improve this answer

Fossil and Veracity are two VCSs that are not just VCSs, they are full project management systems. In addition to VCS functionality, they also include bug tracking and documentation, among other things.

Veracity specifically is based around the idea that there are two general "shapes" of data in project management: "file shape" (a tree of unstructured, untyped text streams) and "record shape" (a graph of structured, typed key-value documents, similar to, e.g. SQL tables related by keys, or a graph of linked JSON documents). While traditional VCSs can only record the file-shaped data, Veracity can also version and record record-shaped data. In fact, Veracity is very general in that schemas (i.e. "types") for the records are records themselves and thus can also be versioned, so that Veracity doesn't actually know anything about "bugs" or "users" or "permissions", but can handle them anyway.

[Actually, that version control mechanism is so general, that Veracity is no longer being developed, because the company realized that they had accidentally developed a cloud-syncing service that could survive long network disconnections with many clients (basically branching and merging) and is now concentrating on that.]

share|improve this answer

Actually, git is rather different from the concept you described. In a nutshell, this is how it works:

It's repository stores compressed copies of entire files that have changed, as determined by the SHA-1 hash of the file, rather than some form of a diff patch. But if the hash for a file is already anywhere in the repository, even if found on some unrelated branch for a file with a different name, then git knows that it can use the compressed version of that file. This is because the SHA-1 uniquely identifies the contents of a file, like a fingerprint or DNA match. It means that git does not have to reconstruct some particular version of a file by applying some sequence of diff patches. It simply looks up what the SHA-1 of a file was at a given commit point, and unzips the contents stored under that SHA-1 identifier.

Once git has unzipped version(s) of a file, then it can perform a diff to indicate the "changes". This might mislead some to think it was the diff patch(es) that git stored.

share|improve this answer
sure, but it doesn't matter what gets stored, or how it does it. You could use a SQLServer record, or a file, or a heap of files... a diff is still generated and applied. There's plenty of implementation differences, I meant the concepts are fundamentally the same. incidentally, git will have to open 2 versions of the file - or it cannot create the diff that the developer made between checkins. Its probably easier just to store the diff. – gbjbaanb Jul 26 '14 at 13:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.