[TYPO3-dam] fileversioning in DAM - a scheme for inspiration?

[Troels Kjær Rasmussen]

Is a scheme for fileversioning already set up?

I suppose a simple chain of db and filestructure versions would do the 
job and would be a fine implementation of versioning in the T3DAM.But 
his weekend I had a glimpse of what i thought to be a brilliant inhouse 
DAM tool for a danish game-developing company, where they handle a lot 
of versioned graphics, multilingual docs a.s.o. Below is my "translated" 
model for how this could be for T3DAM - it´s just a quick idea, but 
maybe René and others could find inspiration for the versioning scheme 
of T3DAM and if not, im perfectly in understanding with this.

The essence for them was that they had to have multi-strain versioning 
of files - 1 strain for ordinary versioning (v1, v2, v3) but also they 
had format versioning (orig psd, gif copyversion,PNG copyversion / orig 
OpenOffice file, pdf copyversion, word copyversion) and finally also 
language versions af those files - all broken down in shadow directories 
like the following.

They used Openoffice and Graphicsmagick for most CLI automated format 
versioning.

Main repository
	- subfolder1 of main repository
		- actual wordfile(s)
		- actual giffile(s)
		- sub pdffolder of subfolder1 (hidden)  - files occur as versioned 
files in parentdir
			- pdfcopy of subfolder1 wordfile(s)
		- sub jpgfolder of repository (hidden) - files occur as versioned 
files in parentdir
			- jpgcopy of actual wordfile(s)
		-i10n folder (hidden)
			- german
			- danish
				- danish copy of wordfile(s)
				- danish copy giffile(s)
				- sub danish pdffolder of subfolder1 (hidden)  - files occur as 
versioned files in parentdir
					- danish pdfcopy of subfolder1 wordfile(s)
	- subfolder2 of main repository
		....

So this structure wasn´t "real" versioning, but it opens the possibility 
of the linguistic and format related "versioning" of all files and 
folders. The cool thing was that the (hidden language and format folders 
didn´t appear as folders, but where all listed under the same main 
record in the db in the parentfolder - so files that had been translated 
and exported to different fomats where just listed like this.

documentname 	- document description  	-  orgsize  	- orginal format	 - 
original language 	- language overlays	 - format overlays
Myfile.doc		blablabla	    500kb	    word/doc               english		 
german, danish	      pdf, sxw

I found this pretty cool - But why couldn´t the formatversion not just 
be generated on the fly? - because all the above had another real 
versioning system like descriped below...

Main repository (version 2)
	- subfolder1 of main repository
		- actual wordfile(s)
		- actual giffile(s)
		- sub pdffolder of subfolder1 (hidden)  - files occur as versioned 
files in parentdir
			- pdfcopy of subfolder1 wordfile(s)
		- sub jpgfolder of repository (hidden) - files occur as versioned 
files in parentdir
			- jpgcopy of actual wordfile(s)
		-i10n folder (hidden)
			- german
			- danish
				- danish copy of wordfile(s)
				- danish copy giffile(s)
				- sub danish pdffolder of subfolder1 (hidden)  - files occur as 
versioned files in parentdir
					- danish pdfcopy of subfolder1 wordfile(s)
	- subfolder2 of main repository

Main repository (version 3)
	- subfolder1 of main repository
		- actual wordfile(s)
		- actual giffile(s)
		- sub pdffolder of subfolder1 (hidden)  - files occur as versioned 
files in parentdir
			- pdfcopy of subfolder1 wordfile(s)
		- sub jpgfolder of repository (hidden) - files occur as versioned 
files in parentdir
			- jpgcopy of actual wordfile(s)
		-i10n folder (hidden)
			- german
			- danish
				- danish copy of wordfile(s)
				- danish copy giffile(s)
				- sub danish pdffolder of subfolder1 (hidden)  - files occur as 
versioned files in parentdir
					- danish pdfcopy of subfolder1 wordfile(s)
	- subfolder2 of main repository

a.s.o

This meant that when a new real version was created of a file or folder 
all formats and language "versions" where copied out to the 
versionbranch exactly as they where at a given time.

I find this way of versioning very cool and usable- would this be a way 
for fileversioning for T3DAM? Of course the expected and normal thing to 
do would be to just implement versions of the default files and then let 
language and formatversioning be up to the user - but implementing a 
system as described above would definately bring T3DAM in a pole 
position regarding webbased DAM.

comments please... and please don´t flame me it´s only a ball I kicked 
in the air for inspiration.

regards

Troels Kjær Rasmussen