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

Pascal Voitot pascal.voitot at free.fr
Mon Aug 21 14:57:54 CEST 2006 

yes for sure :)
the "head" version is important and also a way to search for "tagged" version
and optionally a way to search among all existing versions !

Is a workflow mechanism foreseen for the DAM? such as: a way to put a "checkout"
notification on the document so that nobody can commit a new version while you
are working on it and when you finish, you commit your new version and the
document is released for other pple...

Pascal

Quoting Troels Kjær Rasmussen <troels at linkfactory.dk>:

> 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
> _______________________________________________
> 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

More information about the TYPO3-project-dam mailing list