Version control
From Deptford.TV
1. step install subversion on client machine
2. define folder to be under subversion control
3. sync with subversion & the server (see subversion howto bellow)
4. start to edit in cinerra
5. but very important: the project file & all the media assets need to be in the subfolder of the folder you have under version control titeled something like xml-versions (or edits)
6. do again svn update
7. if you want to work on a different project you can simply download a tarfile from deptford.tv which inlcudes all the media assets, a log file & the project file
8. to do so go to http://svn.southspace.org/subversion/dtvtest follow the trunk... & choose the version you want to download (remarque lisa: if you use getarchive a lot, let me know and i will go into the right place and clean up the big directories that are created. when i have little time i'l write a nightly cron job to do this.)
9. copy paste the link into http://watch.deptford.tv/tests/getarchive.php
10. download the tar
11. unpack it in the folder & ther in the subfolder you have under version control
& off we go :-)
[edit] subversion howto
you can browse it on the web at: https://svn.southspace.org/
you will need to accept the certificate, and log in with the following: get user name & pw from sys admin
our repro is called dtv test,
the url via subversion client is: https://svn.southspace.org/subversion/dtvtest/trunk
its really easy to start using: see my quickstart guide below ;) . lets play. we can't break anything ;)
maybe someone can commit some sample xml files/edl files as we discussed.
quickstart guide (if needed...)
1. make a new directory on your local computer and cd to it. 2. checkout the repro to your local machine with: svn checkout https://svn.southspace.org/subversion/dtvtest/trunk . this makes a "working copy" you might need to accept the certificate adn give the username and pass as above. 3. do what you like with existing files or make new ones... 4. if you have created new files and dirs within your local copy add them to svn with svn add <filename or directory name> 5. when you are ready to send your files to the repro to a commit like this: svn commit -m "a short log message explaining what you've done"
you don't need the url again.
6. update your working copy with: svn update
this command will also bring down new/modufied files that other people have committed.
you can also update to a particular revision, ie. roll back to an earlier revision.
read the manual! http://svnbook.red-bean.com/en/1.0/
[edit] version control with GIT
I spent some time with the git manual today.
I think i conclude like this:
Git is really flexible and clever, but i think that using it will make too much heavy demand on our users. Each user would have to maintain their own repro and branches. We probably don't need all its features and I am worried that it will be a barrier to people getting started.
The provisos on this conclusion is: need to research the git/drupal api and if this is useful for us. Need to read one more time on how to set git up in a more CVS-type way, and see if there are advantages in starting off like this. Need to think about how much we would rely on commits going through a web form to save users having to keep a working copy on thier own machine.
We are going to try to use git, rather than the more straightforward subversion.
Git is more complicated it seems to me, because you can use it in lots of different ways. More work to work it out at the beginning but hopefully more possibilities as we go along...
So far I did this: Set up git on watch.deptford.tv using debian packages git-core, gitweb
Set up a virtual host for git.deptford.tv (which is broken right now, but you can use http://dtvgit.southspace.org/ for now. it points to the same place, with document root /home/lisa/public_html/git
Configured gitweb to be able to look for git repros in the doc root ie. /home/lisa/public_html/git. ie. so you can view repros over the web. created a new repro with a test file. you can see it on the web. you can also access the files directly with http://dtvgit.southspace.org/dtv_versions
Next set up webDav so that anybody can download repositories and (if authenticated) can upload new commits over http. ie. enabled mod_dav, dav_fs and dav_lock for apache.
Tested the webDav setup with a script called litmus. from the results, i think its going to work ok.
Now its time to test out the client-server relationship. downloaded the binaries for mac os x; got errors with a git-clone. however, i think this is to do with the repro not properly set up. now there is a big learning curve for how to use git properly ;)
Anyway: when this is worked out, we should be able to pull/push new files to the repro via git clients over http, but now only the "central" repro, you would be able to connect and merge directly with your collaborators too. Thats a big difference from svn.
Remember we still have svn to play with: https://svn.southspace.org
References:
http://kaeso.wordpress.com/2008/02/02/git-repository-with-apache-via-webdav-and-gitweb/ http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
and all the official git docs.
next this one looks useful: http://toolmantim.com/article/2007/12/5/setting_up_a_new_remote_git_repository
--lisa
[edit] Editing XmlFormats
Now added the actual assets to the archive. Need to set their location inside the xmlParser class (need to re-name this).
According to the manual, the cinelerra xml file will give a relative path to the assets (media files) ONLY if they are placed in the same directory as the xml project file. Therefore i hand edited the symphony.xml file to reflect this, and the archiver places everything in one directory as cinelerra would like.
NOTE: if people download an archive using this script, ie, outside of svn, how do they upload their new version? maybe we make a little web form for that and manage the commit on the server (though then, how to maintain the proper "blame"?.
NEXT JOB (a nice one)
Look further into the xml file, see if we can use it to create a "story board", esp. using the clip descriptions. Ask doma how to get a still clip from the .mp4 file.
STILL TO SOLVE
Logging and metadata. How do we store the logging information? How is it linked (or not) to the in-file metadata information? Once we establish this we can pull the logging info into the tar archive with the xml and clips.
-- lisa 3 july 2008
So far, our we have a script that:
* gets the xml file with curl ie. downloads it from a given remote location. copies to temp local location as will need later for making the archive * gets the links to the assets. for now just adds the names to a text file in the same location as the xml file, called assets.txt but will do a lot more later ;) * makes a tar.gz of xml file + text file assets.txt. later, we will add all the clips, metadata from the files and db, and any "external" metadata.
To expand the metadata idea:
we could ceate new text files?xml format? with "extended" metadata - it could be any text format. the file name should be the md5 hash of the clip. therefore the external metadata file can always be associated with the clip file.
code is at:
https://svn.southspace.org/listing.php?repname=dtvtest&path=%2Ftrunk%2F&rev=0&sc=0
--lisa 1 july
this one gives info on the final cut pro xml format, including a dtd (but no schema...?)
need to find similar information on cinelerra or other systems we might use. use xslt (or just php script) to transform one to the other on serverside? should be prefectly possible but writing the xslt likely to be fiddly.
lisa 9 april
SimpleXML will probably be all the tool we need for first experiments at xml project file manipulation. we will always know the structure of the file so, should be straightforward... ;)
http://www.onlamp.com/pub/a/php/2004/01/15/simplexml.html
lisa 27 june
