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

[Troels Kjær Rasmussen]

CVS approach is also VERY nice - actually I think that for the main 
versioning this is what is used. However for usability I still think 
that viewing the versions should be another interface than cvs browsing. 
  Maybe just a checkbox under "options" for "toggle cvs (versioning) 
browsing. If the user hasn´t enabled this button, the only branch 
visible should be the most recent possibly with the language and format 
"versions" visible.

more ideas! - keep em comming and give René something to work with...

regards and thank you for "inputting"
Troels Kjær Rasmussen

Pascal Voitot skrev:
> Hello,
> I'm currently studying how to use typo3+DAM as a Document Management System
> keeping the existing file structures and indexing files (with metadata and full
> text also) and allowing to manage versioning and maybe see if we could be
> compatible with future document management systems which will come with some
> future OS I won't name :)... I find lots of good points for the DAM, but lots
> of leaks also but nothing making me go away from it :)...
> 
> Anyway concerning versioning, I have also the point of view of the raw
> programmer which uses the well-known CVS-like tools.
> One very useful feature of these tools is to have 2separated versioning
> mechanisms:
> - the automatic one managed by the tool itself which takes any modification as a
> new version and keeps it in the repository with information about the
> modification(for an image or a PDF, diff as CVS does is not possible but lets
> keep in mind the concept of "modificafions")
> - the manual one managed by the users with the "TAG" feature: when the user
> wants to keep a version as a reference one, it puts a tag on it with his
> specific versioning format.
> 
> I have seen some companies which can do 10s of versions of one DOC in a day
> because they modify 2 or 3 words per iteration and they keep all versions to
> keep tracks of every modification. But sometimes, they tell:"this version is
> the reference one, lets keep it". So the DAM could manage small modifications
> in an automatic way and could provide a way of tagging one version with the
> version format the user wants.
> 
> So my idea (which is only an idea :)) is to imagine the DAM with a CVS-like
> versioning system with all the constraints multimedia can bring with them!
> 
> Finally, I agree with you Troels, the management of document format versions and
> also languages would be a real advantage for the DAM!!!
> 
> br
> pascal
> 
> 
> Selon Troels Kjær Rasmussen <troels at linkfactory.dk>:
> 
>> 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
>> _______________________________________________
>> TYPO3-project-dam mailing list
>> TYPO3-project-dam at lists.netfielders.de
>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-dam
>>
> 
> 
> --
> Pascal Voitot
> ingénieur en génie informatique de l'ISMRA ENSI de Caen