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:
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 | | |___ | | | |___ | |___