How to code a simple versioning system?

Question

I want to do a simple versioning system but i don\'t have ideas on how to structure my datas, and my code.

Here is a short example:

1. User logs in
2. U

Answer 1

Start from an existing content management system, done in PHP and MySQL if those are your requirements, such as eZ Publish, or Knowledgetree. For rapid testing of these applications, Bitnami provides quick-to-install "stacks" of these as well (WAMP-stacks on steroids).

Then you can tailor these applications to your organizations needs, and stay up-to-date with the changes upstream.

Answer 2

For a database schema, you likely need two sets of information, files and file versions. When a new file is stored an initial version is created as well. The latest approved version would have to be stored explicitly, while the newest version can be selected from the versions table (either by finding the highest version related to the file, or the newest date if you store when they are created)

files(id,name,approved_version)
file_versions(id,fileId)

file versions could then be stored using their ids (eg., '/fileId/versionId' or '/fileId/versionId_fileName') on the server, with their original name stored in the database.

Answer 3

It's not as simple as it looks. Read this article by Eric Sink on the implications of storage of storing these files.

Perhaps a better question would be what sort of files are being loaded, and do they lend themselves well to versioning (like text files)

Answer 4

Might an existing version-control solution work better than rolling your own? Subversion can be made to do most of what you want, and it's right there.

Answer 5

As an alternative to my previous post, if you think a hierarchical structure would be best, you may want to use flat-file storage, and expose an API through a Web service.

The server would have its data root directory, and you can store groups (of files) in folders, with a root meta-data entry in each folder. (XML perhaps?)

Then you can use an existing revision control tool wrapped in an API, or roll your own, keeping revisions of files in a revisions folder underneath the item in the folder. Check for revisions, and do file I/O with file I/O commands. Expose the API to the Web application, or other client application, and let the server determine file permissions and user mapping through the XML files.

Migrate servers? Zip and copy. Cross platform? Zip and copy. Backup? Zip and copy.

It's the flat-file back-end that I love about Mercurial DVCS, for example.

Of course, in this little example, the .rev files, could have dates, times, compression, etc, etc, defined in the revisions.xml file. When you want to access one of these revisions, you expose an AccessFile() method, which your server application will look at the revisions.xml, and determine how to open that file, whether access is granted, etc.

So you have

DATA
| + ROOT
| | . metadata.xml
| | |
| | + REVISIONS
| | | . revisionsdata.xml
| | | . documenta.doc.00.rev
| | | . documenta.doc.01.rev
| | | . documentb.ppt.00.rev
| | | . documentb.ppt.03.rev
| | |___
| | |
| | . documenta.doc
| | . documentb.ppt
| | |
| | + GROUP_A
| | | . metadata.xml
| | | |
| | | + REVISIONS
| | | | . revisionsdata.xml
| | | | . documentc.doc.00.rev
| | | | . documentc.doc.01.rev
| | | | . documentd.ppt.00.rev
| | | | . documentd.ppt.03.rev
| | | |___
| | |
| | | . documentc.doc
| | | . documentd.ppt
| | |___
| | |
| | + GROUP_B
| | | . metadata.xml
| | |___
| |
| |___
|
|___

Answer 6

I recently built a simple versioning system for some static data entities. The requirement was to have an 'Active' version and 0 or 1 'pending' versions.

In the end, my versioned entity had the following attributes relevant to versioning.

VersionNumber (int/long) ActiveVersionFlag (boolean)

Where:-

• only 1 entity can be ActiveVersionFlag = 'Y'
• only 1 entity can be Version number > the 'Active' version (i.e. the 'pending' version)

The kind of operations I allowed were

Clone current version.

• Fail if there is already a version > the Versionnumber of the 'Active' version
• Copy all of the data to the new version
• increment the version number by one

Activate Pending Version

• Fail if the specified version is not the 'Active' version + 1
• find the 'Active' version and set its ActiveVersionFlag to 'N'
• set the ActiveVersionFlag of the 'pending' version to 'Y'

Delete Pending Version

• Delete the Pending Entity

This was reasonably successfull and my users now clone and activate all the time :)

Michael