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?

-Adam

Answer 1

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 2

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 3

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.