[TYPO3-dev] Local Development with Subversion

[christian reiter]

Hi,

I have been using both CVS in the past and more recently SVN to manage the
greatest part of some TYPO3 projects due to client requierements.

In general you should think first about what you want to achieve with
versioning. For your own extensions, this is obvious. For extensions from
the TER, it may be useful to version them if you find you have to modify
them frequently. The same is true for the core files if you need to hack
anything (like adding new hooks). Also, versioning helps keeping track of
security patches.

Versioning your typoscripts, any CSS, HTML/XML files, javascripts etc that
belong to your wbsite implementation is also helpful, there is often a lot
of work contained especially in the TS and CSS.

Another question is the versioning of assets - the images and PDFs that you
use on your website. This makes sense if your workflow or the contract with
the client requires this but you have to be aware of the limitations
(experiences follow). In some situations it is important that you can roll
back the state of all file assets, document for the client what the
delivered state of a file was on some exact date, etc. Typo3 does not make
this very easy by default, and the existing system of workspace and
versioning extension does not deal with this issue (that is not a bug, it is
simply not intended to do so).

All files that are regularly changed/dynamically downloaded/created of
course need to be kept out of SVN (typo3temp, localconf.PHP ,
typo3conf/*CACHED* files, typo3conf/l10n, ... etc). In case of the
localconf, you can of course regularly check in a copy of it that reflects a
working state at a certain timepoint if you are afraid it might get lost. ie
have a versioned "localconf.OK.php" and if the real one gets trashed, copy
it over. Anything that is "temp" or dynamic caching never belongs in the
version control system.

In general you will always get into trouble if files can be changed both by
checking them out from SVN or by altering them through the web interface of
TYPO3 itself.

Where TYPO3 absolutely needs to write, keep SVN away. (e.g.
typo3temp,localconf,fileadmin/_temp_)

Where Typo3 write access is optional, disable it.
For instance typo3conf/ext should not be accessed via typo3 backend, but
check out your versioned extensions there. Of course if you have several
installations of typo3 you should use only one SVN repository for the
extensions instead of adding the same code over and over. Take care, some
extensions still come with traces of versioning sandboxes (ie you find CVS
subfolders), these of course you *must*  delete if you use CVS; if you drag
them into SVN it is merely annoying.

You should put as much typoscript and TSConfig as possible into external
files and manage these with SVN also. Trivial extension templates of course
can remain as they are in the Typo3 backend textarea.
Having TS in versioned files is very helpful. Especially together with
typoscript supporting editors, the best of which today is in probably
"SweeTS" editor http://typo3.area42.de/. If you have any sensitive
information in your typoscripts, just give them a standard extension or
always store them in certain paths like fileadmin/template/{websitename}/t3s
and configure your Apache to deny all access to these files/paths.

You could put the contents of fileadmin/ into subversion but then you should
make fileadmin not writable for the filemanagement in the typo3 web backend,
unless you adapt the file management to add newly uploaded files to the
repository, and to catch all renames/moves/overwrites and carry out the
appropriate SVN command first (see
http://subversion.tigris.org/faq.html#wc-change-detection) - ie, you
implement a low-end subversion web client via hooks in the file functions.

Using the SVN postcommit hook you can have any file that is checked into SVN
automatically appear in fileadmin, ths means that editors who are allowed to
add new files must be able to use an SVN client on their machine to do this
(which was in fact required in my case) and the Filelist module in Typo3 is
basically not used anymore.

The problem with this is that it is not terribly useful for controlling what
is on the website because in the normal behaviour of typo3 all fileadmin
elements that are used anywhere in content elements are copied in multiple
instances to uploads/pics, uploads/media etc.

i.e. you might have a PDF in versioned shape within fileadmin/pdfs/ but what
is offered in a filelink element on the page will not distribute the
versioned PDF but a copy from uploads/, so when you update the SVN sandbox
and check out a new versioned copy to fileadmin, your filelinks across the
website will NOT change to reflect this automatically. Even after deleting
all cache. Because the reference in the filelink element simply does not
point to the original from fileadmin/pdfs, but to a copy that will only
reflect the state of the file at that point when the content element was
created. In our case, it was a contractual obligation to the client that
such scenarios must be avoided.

If you use DAM/reference mode you will be able to distribute versioned files
(PDFs etc) through your website for those elements that support direct
references, but as far as I know installing DAM and enabling references does
not automagically apply to any and all extensions - the extension needs to
have DAM support. Another way, especially before DAM was available, was to
suppress the copying in the first place (which happened in our projects) by
xclassing or hacking the appropriate parts of the source code. This would
then apply to any and all extensions.

In this case, the only files that appear in uploads/ would be RTEmagic
images which of course again fall into the category of files that should not
be versioned; honestly from a content-control perspective they should not be
used in the first place.

you will also run into a few harmless quirks with a number of extensions,
when your fileadmin is versioned - in general, any extension that displays
lists of directories directly on the frontend (ie goof_fotoboek) will
usually tend to also display the ".svn" folders.

Also consider that subversion sandboxes are larger by a considerable factor
than an unversioned file system - much more so than with CVS which only
added a subfolder with three text files. If you are working on shared or
limited webspace you can run into trouble with disk space. Subversion 1.4
has improved this somewhat.

Of course one can ask, why use typo3 in such a situation,instead of a CMS
that supports file versioning in the first place. In our case the client had
already lost significant resources with expensive CMS that had some
versioning but couldn´t build the websites they needed. Typo3 passed the
tests for building their websites with better score than all the competition
so they gave it a try.

Greetings,

Christian Reiter

"Ronald Renfro" <rr at dreimorgen.com> schrieb im Newsbeitrag
news:mailman.25316.1161250698.20124.typo3-dev at lists.netfielders.de...
> Hello,
>
> I would like to use subversion to control my local typo3 installation
> and for extension programming.
> In the past I have been able to use svn for single extensions
> programming and it works great - but at the moment I do not know how
> to set forth at using subversion for a complete typo3 installation
> with database, temp files, ext dirs and so forth.
>
> If someone could share a little insight and experience on this
> subject or point me in the right direction... I would be grateful.
>
> Thanks and have a nice day.
> Ronald Renfro