Writing my own file versioning program

Question

There is what seems to be a plethora of version control systems. Therefore, to draw a bad conclusion, it must be easy to write one.

What are some issues that must be considered in order to write a simple file versioning system? (What are the minimum necessary functions?)

Is it a feasible task for one person?

Answer 1

A good place to learn about version control is Eric Sink's Weblog. His most recent article is Time and Space Tradeoffs in Version Control Storage, for one example.

Another good example is his series of articles Source Control HOWTO. Yes, it's all about how to use source control, but it has a lot of information about the decisions and tradeoffs developers have to make when designing the system. The best example of this is probably his article on Repositories, where he explains different methods of storing versions. I really learned a lot from this series.

Answer 2

How simple?

You could arguably write a version control system with a single-line shell script, upversion.sh:

cp $WORKING_COPY $REPO/$(date +"%s")

For large binary assets, that is basically all you need! It could be improved quite easily, say by making the version folders read-only, perhaps recording metadata with each version (you could have a text file at $REPO/$(date...).meta for example)

That sounds like a huge simplification, but it's not far of the asset-management-systems many film post-production facilities use (for example)

You really need to know what you wish to version, and why..

With large-binary assets (video, say), you need to focus on tools to visually compare versions. You also probably need to deal with dependancies ("I need image123.jpg and video321.avi to generate this image")

With code, you need to focus on things like making diff's between any two versions really easy. Also since edits to source-code are usually small (a few characters from a project with many thousands of lines), it would be horribly inefficient to copy the entire project for each version - so you only store the differences between each version (delta encoding).

To version a database, you probably want to store information on the schema, tracking new tables, or columns, or adjustments to existing ones (rather than calculating deltas of the database files, or making copies like the previous two systems)

There's no perfect way to version everything, you have to focus on doing one thing well.. Git is great for text, but not for binary files. Adobe Version Cue is great with binary files (images), but useless for text..

I suppose the things to consider can be summarised as..

• What do you want to version?
• Why can I not use (or extend/modify) an existing system?
• How will I track differences between versions? (entire files? deltas?)
• What other data do I need to attach to versions? (Author? Time-stamp? Dependancies?)
• What tasks would a user commonly need to do (diff'ing? reverting specific files?)

Answer 3

Have a look in the question "core concepts" about (D)VCS.
In short, writing a VCS would involve making a decisions about each of these core concepts (Central vs. Distributed, linear vs. DAG, file centric vs. repository centric, ...)

Not a "quick" project, I believe ;)

Answer 4

If you're Linus Torvalds, you can write something like Git in a month.

But "a version control system" is such a vague and stretchable concept, that your question is really unanswerable.

I'd consider asking yourself what you want to achieve (learn about VCS, learn a language, ...) and then define some clear goal. It's good to have a project, but it's also good to have a reachable goal in a small amount of time. Small successes are good for your morale.