Continuous version control

Question

I haven't seen a continuous version control system - one that would save changes in your code as you developed them, rather than waiting for an official check in. The changes would be saved as 'not checked in' of course, but they would be saved away for backup, and viewing by others before you actually did the official check in.

I haven't seen this, and wonder if it, or something like it, exists, and the reasons why it might or might not be a good idea.

Right now programmers think of source code control as integrating packets of code, but why not make those packets smaller and integrate continuously?

Answer 1

You could commit every line, or character with a DVCS like git if you wanted. Generally, I think it is a great idea to commit as often as possible, when using a DVCS, to make it easy to hunt down problems with tools like git bisect. If you wanted the effect you describe, you could script your editor of choice to commit on every save... In practice though I would think that would be a bit much.

Answer 2

You mean something like Subversion autoversioning?

Disclaimer: I'm not saying autoversioning is a good idea for development, or that I would personally do it, but the technology exists.

Answer 3

Some people would setup a development branch for this purpose and have the developers commit their changes as they work before merging it into a quality assurance level branch. You could even have a developer doing major changes work in his/her own branch before committing and merging those changes into the main development branch. So, branching can address this.

Answer 4

I think Eclipse does, or used to do something like this at every save. It's saved me a few times when my code ended up being hacked to pieces while trying to identify a bug.

Answer 5

You don't want to check in every change. You want to check in atomic sets of changes that can work together. You don't want to add a parameter to a method and save, having it checked in (and a CI build run), then have the build break because you haven't yet updated the calls to the method.

Answer 6

Eclipse has a feature called 'local history' that does exactly that. It will keep a copy of your source files between saves. It even keeps track of deleted folders for you. It saved my butt a number of times. You can see Local History as low-level version control that only happens on your local machine. Downside of this is of course when you work on a different machine, you will have a different local history.

Answer 7

The job of constant autosaving is not a task for a version system, but for the editor. When you see a new version in the version system, it should represent a meaningful change from the other versions, not every halftyped word.

Answer 8

Right now programmers think of source code control as integrating packets of code, but why not make those packets smaller and integrate continuously?

I would say DVCS are already basically doing this now, not because they are decentralised, but because commiting is so much quicker.. With git I commit far more often than with SVN.. It also makes it simple to commit "chunks" or specific of code (using git add -i or git gui), and is generally much more focused on tracking lines of code, rather than complete files (as "traditional" VCS' like Subversion)

Also, the way git inherently works means, as you said, "the changes would be saved as 'not checked in' of course".. When you commit, the changes are local, then you push them to the remote machine with a separate command.. You could commit every time you save, then rebase them into a single commit if you wished.

As for a tool that does "continuous version control", you could do this quite simply with a shell script, something like..

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

There is a script, CACM (github), which does something similar

[CACM] watches a specific directory, and commits all the changes to a standalone Git repository.

To use just do:

cacm --repo dir_of_git_repo --watch dir_to_watch

I'm not sure why you'd want to do so.. I find one of the most useful things about using a VCS is the diff of what I've changed (since the last commit). It seems like having constant/automated commits would just be noise..

Also, the "e" Text Editor has an interesting feature, it visualises the undo history, with branching. There is a blog-post on it with screenshots.

Answer 9

you can use a distribute version control system, like bazaar, git, Mercurial. then you can commit locally.

Answer 10

Having more than few years of experience of programming in Java, I still remember (with nostalgia) novel approach that Visual Age brought to the development process. Visual Age had a non-file approach to source code. Code was stored in relational database. You’d generally work on a view showing a single method. You also had a full file view, but you wouldn’t use it that much.

Regarding version control, it would generate a version with each save. You could explicitly checkpoint a method, class/interface, package or entire project with a version number/name. It also permitted a more fine grained control of your source on method level. Once I started working with Eclipse, while it inherited many features from Visual Age, and today has History feature that saves locally all “saves” of your code, I couldn’t help feeling I made a step back.

Answer 11

I've seen some inotify based plugins for various DVCS, however those can only be but so smart. Really, the ideal thing to do is store the repository on a copy-on-write file system, so that these frequent granular (and immutable) versions of files are kept outside of the DVCS.

Like others have said, I prefer to make many small commitments. With a DVCS, you don't have to worry about breaking the trunk or master branch, push only after you're done .. no worries about toxic revisions as you edit files.

On Linux, I use ext3cow to store my HG/Git repositories. This gives me the kind of functionality that you describe. Sad to say, I don't know of anything like it that is portable beyond Linux. Maybe some crazy team will come up with one in Python.

This question has come up several times before (though each in a different context), so surely the need for something like ext3cow (but portable) is obvious. Yet, I would not want that bloat in a DVCS itself, especially on huge trees.

I think you really need to ask for this from the file system, not the DVCS.

Answer 12

As Dan mentioned, the IBM Visual Age IDE kept every version you saved of a source code file. This approach isn't limited to IDEs, however; the DEC VMS operating system took a similar approach with its versioned file system. In VMS, the full name of each file included a version number, and each time you saved a file, a new copy was created with a version number one higher than the previously highest number.

Neither approach quite matches version control as we know it today, in that both lack branching (or, for that matter, any features designed especially to facilitate multiple people working on the same source file). But, they both serve the purpose of backup against human error, which for me is the most useful aspect of version control.

Answer 13

Rational ClearCase has the concept of a dynamic view. On windows, your development view shows as a mapped drive, but your code changes are stored server side as soon as you hit save. Is that what you are looking for?

There are, as you'd expect, trade offs with working this way, so like Si's answer above, this is not a recommendation...

Answer 14

Here is a different approach. Almost every day I run in to situations where something stops working and I don't know why. I rewind a couple of minutes and check what changes have been made and to which files. So I agree on the need for continouos version control.

At the same time it is true that you don't want to checkin thousands of small changes every day into your repository.

Ok, so this is what you do. You use both but don't mix them. Your source control should be used by the whole team and you check in to that every now and then. At the same time you run some local personal file version software that saves every small change and makes it easy for you to actually use the information.

That's it. I use History Explorer since I helped develop it, but there are others out there also.

Answer 15

How about VESTA?

http://www.vestasys.org/