TWiki Installation based on Subversion

Once you have followed the instructions in SubversionReadme you can run a TWiki from this checkout area simply by pointing Apache at it in the normal way and running configure.

By default the checked-out TWiki won't include any of the extensions (plugins or contribs). To enable extensions in a checkout area, you must either install them the normal way, or use the pseudo-install.pl script to link-install them. On Unix/Linux this script can be used in -link mode generate soft-links from the core tree to the twikiplugins area, so you can work on your code in twikiplugins and see the impact of the changes on your live twiki without needing to do an install step. Windows doesn't support soft links, so the script can also be run in copy mode, but in this case you need to re-run it each time you change your extension. Remember you have to enable any plugins you want to test in configure.

Use pseudo-install.pl default to enable the default contribs and plugins (e.g. TwistyContrib which is relied on by PatternSkin) and pseudo-install.pl all to install the whole works.

See the header comment of the pseudo-install.pl script (top level of checkout) for options and more information.

Example of running pseudo-install

The typical situation is that you want to run a pseudo-installed TWiki checked out from the MAIN branch. And if you develop plugins you want to be able to activate also your plugin. This is the entire sequence for checking out MAIN branch from SVN and doing the pseudo-install. We assume that you want to run your Subversion based install in /var/www/twiki

We create the directory called twiki. We checkout the MAIN branch from SVN. We run the pseudo-install. On Windows you cannot create links; just omit the -link switch. Finally we change the ownership so the entire tree is owned by the user running the Apache. In this example the user name is "apache". Change the commands to fit your actual Apache user. Some commands will have to be run as root.

cd /var/www
mkdir twiki
cd twiki
svn co http://svn.twiki.org/svn/twiki/trunk .
perl pseudo-install.pl -link all
cd ..
chown -R apache:apache twiki

Now and then you will want to keep your installation in sync with the Subversion MAIN branch. The pseudo-install script is not intelligent enough to cope with all sorts of changes done in the plugin areas. So this is the idiot proof way to update. It first removes all the links. Then does the svn update. And finally does a new pseudo-install. Normally just doing the svn update will be enough.

cd /var/www/twiki
rm -f `find . -type l -print`
svn update
perl pseudo-install.pl -link all
cd ..
chown -R apache:apache twiki

See also: SoYouWantToBeATWikiDeveloper, DeveloperResponsibilities, TWikiRelease, TWikiProductionRelease

-- Contributors: CrawfordCurrie, KennethLavrsen, MartinCleaver, PeterThoeny, WillNorris

Discussion

I have an installation using DevelopBranch. I update it whenever a new beta comes out, to the beta's SVN number.

To install plugins I use develop's pseudo-install.

Thoughts? Issues?

-- MartinCleaver - 05 Nov 2005

I don't do that.

I work "as if" I were going to download a tarball. In effect I do.

• I have a machine with a SVN checkout area ~twikidev/twiki/branches/DEVELOP. Actually I have a few 'custom' and 'scratch' areas along side where I can make custom builds, but that's beside the point.
• I use the normal svn up to update it.
• I use the tools/build.pl to build a tarball. Or 'tarzball' if you prefer that nomeclature.
• The tarzball gets moved (scp) to the target machine and un-tarz'ed
• The target machine is configured with Apache
• In my case there is ~apache/twiki/datar1, ~apache/twiki/datar2, ~apache/twiki/datar3 and so on.
• I also have a version of Dakar from July, before Icons, sessions and many orher thigns were migrated to the core.
  • This allows me to do side-by-side comparisons and tests
• The machines support NFS, so I can easly run diff between not only version but also the SVN reference.
  • I also have tools that can run directory level diff, three-way diff and selectively/interactively merge two differnt revision to produce a third.

I realise this is way beyond what is needed to "just" produce a release, but it does ensure a number of things.

• Since the check-out area never 'runs' I don't get problems with TOPICINFO when I do update a topic and submit it.
• I can see more comprehensively what changes are going on and compare their impact as well as the lexical change.
• I can run different revisions side by side. I could use this for benchmarking, but I don't want to get into that argumentative area.
• I can work on different approaches.

The SVN checkout is a reference for me. It never gets 'scribbled' on so I never have to worry about subversion conflicts. I don't get G or C notifications.

My motivation at the moment is:

1. Testing. Not all the bugs go straight into the Bugs DB. I usually check with the developers first in case there is a misinterpretation.
2. Limited release for the few sites that are willing to try the betas

-- AntonAylward - 08 Nov 2005

as a developer counter point to Anton, i use an SVK based local branch that I then rsync to my web host. this way http://www.home.org.au is backed up, and in a versioning system, allowig me to tweak the code in a managed way, while still being about to svn update to the latest DEVELOP code. I don't recommend this for everyone, but if I were running from the released version, I would still be rysncing from my svk repository, so that I get the trivial change management and backup facilities. But then I am quite fond of having my /etc dir (and my $HOME, when i get back to Sydney) in my svk repos...

-- SvenDowideit - 08 Nov 2005

Ok, thanks for your observations. I think many people would use a direct SVN checkout, so although alternatives give options there are probably things we need to do to ease those running based on SVN.

The following are particular issues:

1. Conflicts - I don't want conflicts to actually get merged. I want them rejected so that updates to files like Main.TWikiAdminGroup ever get applied.
   • Perhaps I can set up a svn ignore file?

Backups: I use BackupUsingUnison and am planning to bring backup into SyncContrib.

-- MartinCleaver - 26 Nov 2005

I would appreciate any thoughts on IgnoringSvnCommits

-- MartinCleaver - 26 Nov 2005

Sven: could you please outline your SVK approach? MattWilkie and I are both interested in getting that working and I suspect it is a better approach than ignoring SVN commits.

-- MartinCleaver - 27 Nov 2005