Prskavčí blog

Pokud máte strukturu repository podobnou této:

/repository/project1/trunk
/repository/project1/branches
/repository/project1/tags
/repository/project2/trunk
/repository/project2/branches
/repository/project2/tags

a chtěli jste dělat nějakou akci pro jednotlivé projekty nebo jen pro některé je potřeba si trochu pohrát s post-commitem. Zde uvádím příklad na posílání mailu jen pro projekty, které začínají „php_“.

#!/bin/sh
# POST-COMMIT HOOK
REPOS="$1"
REV="$2"
REPNAME="${1##*/}"
SVNLOOK="/usr/bin/svnlook"
AWK="/usr/bin/awk"
GREP="/bin/egrep"
ERR="/tmp/errors"  

TEST=1

CHANGED=`$SVNLOOK changed  -r "$REV" "$REPOS" | $AWK '{print $2}' | $GREP ^php_`
for FILE in $CHANGED
do
	# echo $FILE >> $ERR
	TEST=0
done 

if [ $TEST = 0 ]; then
	/srv/svn/tools/commit-email.pl "$REPOS" "$REV" adresat@email.com -h svn.hostname.cz -s "SVN: $REPNAME" > /tmp/postcommit-log 2>&1
	# echo "Send mail" >> $ERR
	exit 0
fi

Post commit je upraven tak, že pomocí svnlook si zjistí provedené změny a podle nich se zachová, tak se dá řídit celá logika akce, kterou chcete vykonat.

Já osobně jsem začal pracovat s někde kolem roku 2000 se systémem CVS z kterého jsem nebyl vůbec nadšený, hned jak jsem se pokusil něco přejmenovat. Později jsem přešel na Subversion, který mě v té době nadechl a to mi celkem vydrželo po dlouhou dobu než jsem před několika lety začal koketovat s distribuovanými systémy a teď asi rok už aktivně používám Git a pře ním jsem si hrál s Bazaar a Mercurialem. Na Subversion jsem, ale nijak nezanevřel a stále ho používáme ve firmě jako jediný verzovací systém v poměrně slušném nasazení (asi 100 repositářů, několik desítek GB místa). Znám limity Subversion a podle toho s ním zacházím.

Verzovací systémy jsou tu už 38 let, první verzovací systém SCCS vznikal v Bellových laboratořích v roce 1972. Dodnes existuje na mnoha unixových systémech v GNU variantě.

Protože SCCS to byl proprietární verzovací systém, vytvořil na Walter F. Tichy  na Pordue University open source variantu tohoto software pojmenovanou RCS. RCS se dodnes používá například v Twiki pro uchovávání historie stránek.

Následovali další jako CVS, PRCS (Project Revision Control systém). CVS byla původně jen nadstavba na RCS, sada skriptů, které používali příkazy RCS. Většinu vlastností CVS má poděděnou od RCS.

Subversion vznikl nový verzovací systém, který odstraní chyby co lidem vadili v CVS a byl napsán úplně znova i když filozoficky se hodně držel původního CVS, ale byl tree oriented, což přineslo některé výhody, ale i nevýhody.

Protože řada vývojářů nebyla s CVS spokojená vznikali další systémy a za některými stál i Microsoft, který přišel se svým verzovacím systémem Delta v roce 1994. Tento systém dlouho nevydržel, protože MS udělal výhodou akvizici a koupil firmu SourceSafe a další rok už vydal nový verzovací systém VSS. Tento systém měl mnoho nevýhod a pokud někdo s ním pracoval určitě mi dá za pravdu, že to nebylo jednoduché. Problémy se zamykáním souborů, přenos přes sdílené disky apod. V roce 2005 naštěstí MS představil moderní centralizovaný systém, který je součásti TFS, který jako datové úložiště používá MS SQL.

Larry McVoy je klíčová osobnost návrhu verzovacích systémů. Stál u vývoje verzovacího systému  Sun TeamWare, který vedl Evan Adams a potom na základě těchto zkušeností vytvořil BitKeeper. To jsou první distribuované verzovací systémy. TeamWare byl postavený na základech SCCS, přesto přinesl spoustu nových věcí, které dali později vzniknou dnešním systémům. Implementace TeamWare začala v roce 1991, to můžeme považovat za datum vzniku distribuovaných systémů.

TeamWare to začal, ale BitKeeper může za vznik Gitu a Mercurialu, kteří patří dnes mezi nejznámější distribuované verzovací systémy. Společnost BitKeeper se na základě událostí v roce 2005 rozhodla odebrat (reverse enginnering na linux konferenci pomoci telnetu) volné použití linuxové komunitě, která BitKeeper používala k vývoji jádra.

To vedlo ke vzniku Gitu (Linus Torvald) a Mercurial (Matt Mackall) v roce 2005. Git je inspirován BitKeeperem a Monotone (sha1 hash), také velkou část práce na něm udělal Petr Baudiš, který stojí například za frontendem Cogito  a příklad git-filter-branch.

Výhody Gitu vidím v těchto vlastnostech:

• pružnost (moderní různá worklow)
• lokální větve
• jednoduchý a rychlý merge
• rychlost a offline commit
• vysoký failover, díky lokálním kompletním kopiím

Tak proč všichni nepoužívají Git, ale Subversion? Je proto několik důvodů.

1. ne všichni považují tyto výhody za důležité, priority mají jinde
2. pro SVN mluví vysoká rozšířenost, snadná dostupnost v mnoha IDE
3. vynikající TortoiseSVN, který pomáhá více než by se na první pohled mohlo zdát
4. dostupný placený support včetně tvoření balíků pro linux, windows (CollabNet)
5. http, apache pro snadné začlenění do každé sítě
6. napojeni ldap, active diretory nastavení práv až na úrověň každého adresáře
7. znalost

Proto více než 80% firem dnes používá Subversion.

Dnes je důležité používat určitě aktuální verzi Subversion, vůbec nedoporučuji pracovat s verzemi 1.4 a nižší, které nepodporovali mergeinfo. Subversion má desetileté výročí. Ale stále je to malé dítě, které potřebuje dospět. Už jsou pryč dětské nemoci, ale některé problémy přetrvávají.

Subversion byl začleněn pod Apache Foudation do toho doufám, že se trochu akceleruje vývoj Subversion k následujícím verzím. Tým kolem SVN si je dobře vědom věcí, které SVN scházejí a dobře vědí, že to není jednoduché je odstranit. Proto existuje tato roadmapa.

Je to roadmapa přibližně na 4 roky dopředu, klíčový bude letošek a uvidíme jak se podaří vývoj verze 1.7 o které budu teď. K ostatním verzím se vrátím později.

Verze 1.7 by měla obsahovat tyto novinky

• httpv2
• wc-ng
• svn patch

Nová verze HTTPv2 by měla přinést větší rychlost při zachování všech výhod http protokolu.

Pracovní kopie nové generace je důležitá součást nutná pro další následné změny, které odstraní dnešní problémy (tree conflict, rename tracking). Bude to sqlite databáze v jednom adresáři .svn, kde budou všechny potřebná metadata o repository.

Svn patch jen umožní to co umí příkaz patch v linux, drobnost, která v svn chyběla.

Ve verzi 1.8, která by měla být za rok bychom se snad díky nové WC-NG mohli již dočkat sledování přejmenovaných souborů napříč historii. Nastavení pro jednotlivé repository ne jen globálně a vylepšení problémů s tree conflicty.

Co bude v dalších verzích uvidíme, autoři slibují nový FS, nový editor a další vylepšení. Uvidíme zda se do budoucna dočkáme třeba i offline commitů.

Na závěr bych chtěl shrnout co by jste si měli odnést těchto 4 věci:

• pokud máte subversion, ujistěte se že používáte poslední verze
• pokud chcete přejít na DVCS mějte pro to dobré zdůvodnění nedělejte to je kvůli módě
• na subversion se stále pracuje
• existují distribuované verzovací systémy a přinášejí něco nového

Tento článek je přepis mojí přednášky na Teched 2010.

Po několika dnech když jsem dával dohromady synchronizaci firemního mirroru s naším dodavatelem, vznikla nová kapitola do knihy Subversion pro každého.
Nastavit mirror a pustit synchronizaci to najdete i v manuálu, ale přidal jsem tam také řešení možných problémů se kterými se můžete, ale také nemusíte setkat.

Pokud se vám někdy stane, že pracujete na projektu a máte vzdálený SVN server dejme tomu např. s 500 revizemi.

Teď ale jedete někam pryč kde nemáte připojení k internetu nebo má server výpadek. Pracovat na projektu musíte, tak např. pomocí TSVN uděláte lokální repozitory a importujete working copy a pracujete dál, uděláte 50 revizí a server zase začne fungovat.

Co teď? Máte podle mne tyto možnosti.

1. Můžete vzít zase svoji WC a tu naimportovat do původního repozitory
2. Nebo zahodit staré SVN a udělat dump nového a to naimportovat místo starého.
3. Nebo mít na serveru obě repozitory.
4. Spojení obou repozitory

SVN Merge

Já jsem pro spojení obou repozitory, to se dá udělat také různě. Napadají mě dvě možnosti jak to provést.

1. Vygenerovat diff patche pro jednotlivé revize v nové repozitory a ty aplikovat postupně na WC ze původního repozitory.
2. Udělat dump repozitory pomocí svnadmin dump a potom použít příkaz svnadmin load  s nastavením --parent-dir a import provést do jiné branche.
3. Udělat dump pomocí svnadmin dump s parametrem --incremental a se stejným parametrem jej i importovat. Tento postup uvádějí v manuálu, ale nemám ho zatím odzkoušený.
4. můžete také použít svndumptool a udělat merge na úrovni dump souborů, to mi přijde nejlepší řešení pokud požadujete jednu větev vývoje.

Pokud máte nějaké jiné zkušenosti se spojováním repozitory doufám, že to uvedete v komentářích. Ozvěte se také pokud by byl zájem, můžu uvést nějaký příklad s tím jak se to dělá pomocí příkazového řádku, krok za krokem.

Pokud jste si někdz hráli s nastavením SVN pod Apachem tak jste narazili na directivu SVNIndexXSLT. Pokud se vám nelíbí obvyklý styl jak to zobrazuje SVN. Pokud použijete XSL ze stránek Subversion tools bude výsledek jako je obrázku. Je to lepší ale žádný zázrak.

Pokud chcete aby výsledek byl lepší a nepoužijete ViewVC, kde styly ujdou až tak od verze 1.1 a ještě by je to chtělo taky vylepšit tak doporučuji navštívit ReposStyle, kde autor vytvořil pěkný styl, který se dá hned použít.

Není problém si vytvořit vlastní styl a nebo případně upravit ten co vám vyhovuje. Doporučuji se podívat na https://labs.repos.se/data/style/trunk/ kde je vidět ReposStyle v akci.

Dneska za mnou přišel kolega, že mu vadí na SVN, že neumí exportovat poslední revizi s plnou cestou. Potřebuje to na server kde nemá shell aby mohl spustit patch, který si můžeme vygenerovat pomocí svn diff. A nechce všechny soubory jak to standardně dělá svn export, ale jen ty které se změnili.

Trochu jsem se na to díval a myslím si, že řešení přímo jen pomocí SVN není, pokud někdo ví jak to udělat elegantně ať mi dá vědět. Já jsem na to napsal jednoduchý shell skript, který to řeší, třeba to bude někomu také ku prospěchu.

EXPORTPATH=/tmp/testexport/
REPOS=file:///home/prskavecl/repos/project/
REPOSPATH=/home/prskavecl/repos/project/
REV="$( svnlook youngest $REPOSPATH )"

# function to list and export file by file
pathexport() # $1
{
mkdir -p $EXPORTPATH${2%/*}
svn export --force $1$2 $EXPORTPATH$2
}

# make export path
mkdir -p $EXPORTPATH
# list all changed files
for i in $( svnlook changed -r $REV $REPOSPATH ); do
if [ "${#i}" -gt "2" ]
then pathexport $REPOS $i
fi
done

Na začátku skriptu se nastaví proměnné s cestami. Před svnlook si skript zjistí poslední revizi a projde všechny soubory, které se v revizi změnili. K nim vytvoří příslušné adresáře a vyexportuje jednotlivé soubory. Neměl by být problém napsat obdobný skript i pro windows.

Více o exportu také najdete na svn.prskavec.net.

Protože jsem v češtině nenašel žádnou knihu, kterou bych mohl strčit do ruky někomu kdo se mě ptá jak začít pracovat se Subversion a návody na webu nejsou zcela ucelené, tak jsem se rozhodl napsat takovou příručku pro každého kdo chce se Subversion pracovat.

Nesnažím se o překlad SVN book i když ten by této knize výrazně pomohl, ale snažím se shrnout postupy a praxe co nejjednodušeji, aby to začátečník pochopil. Já už se SVN, ale dělám delší čas a nemám potřebný odstup a proto budu vděčný za zpětnou vazbu co týká obsahu, co přidat a co je zbytečné a případných chyb.

Ke psaní jsem použil Docbook a jako editor XMLmind, PSPad a SciTE. Do html převádím docbook za pomoci PHP tímto jednoduchým skriptem.

<?php
$xml_filename="svn-kniha.xml";
$xsl_filename="c:\Program Files\XMLmind_XML_Editor\addon\config\docbook\xsl\xhtml\docbook.xsl";

$doc = new DOMDocument();
$xsl = new XSLTProcessor();

$doc->load($xsl_filename);
$xsl->importStyleSheet($doc);

$doc->load($xml_filename);

file_put_contents("index.html",str_replace("</head>","><link href='default.css' type='text/css' rel='stylesheet' />
</head>",$xsl->transformToXML($doc)));

?>

AnkhSVN je SVN klient pro Visual Studio,  verze 2.0 přináší kromě řady vylepšení podporu Subversion 1.5. Vyžaduje VS2005 a vyšší. Myslím, že to je dobrá správa pro všechny kdo VS a SVN používají.

Před časem, jsem přešel z Eclipse PDT na NetBeans IDE Early Access for PHP a to hlavně z důvodu, že projektový adresář je umístněný libovolně mimo zdrojové kódy a také pro lepší práci se subversion než mi poskytoval Subclipse. Když vyšel nový Subversion 1.5 měl jsem obavy, že budu muset čekat na novou verzi pluginu pro Subversion jako je to u PDT.

Subclipse 1.4.x pro Eclipse je už venku, tak to naštěstí u PDT není problém. Ale jak to je u NetBeans, čekám na říjen kdy má být verze 6.5 s podporou PHP, ale dosavadní funkčnost mi celkem vyhovuje, asi je to tím, že stejně edituji nejvíce v PsPadu a SciTE.

NetBeans, ale s Subversion 1.5 fungují bez problémů a to proto, že potřebují ke svému běhu jen binární soubory Subversion,  používají totiž běžného řádkového klienta. Tak pokud odinstalujete starou verzi Subversion a nainstalujete novou, stačí potom nastavit cestu do $PATH, případně se vás NetBeans zeptají kde Subversion najdou. Jednoduché a geniální.

Samozřejmě to má i svoje nevýhody, podporují se základní funkčnosti a až v dalších verzích budou, doufám, k dispozici funkce, které jsou v klientu nové (changelisty, merge tracking atd.). Klient v NetBeansech nemá implementovány i další vlastnosti jako nemožnost propojení s Issue trackerem jak je možné v Subclipsu nebo TSVN. Já primárně používám TSVN a proto mi tyto necnosti příliš nevadí s spíše se mi líbí diff přímo při editaci, ukázání anotací apod. Náhled na používání Subversion v NetBeans je na obrázku.

Jak jsou na tom ostatní prostředí Komodo IDE, Zend? Těším se na komentáře.

Phing obsahuje ve verzi 2.3 tyto Tasky pro práci se Subversion.

• SvnCheckoutTask
• SvnExportTask
• SvnLastRevisionTask
• SvnUpdateTask

To se hodí a také ve svém buildu používám tento postup:

1. udělám export HEAD revision (SvnExportTask)
2. načtu si číslo HEAD revision (SvnLastRevisionTask)
3. potom vygeneruju SVN Log (SvnLogTask)
4. vygeneruju API dokumentaci pro build (PhpDocumentorTask)
5. všechno zakomprimuji do souboru s dokumentací a se zdrojáky a uložím kam potřebuju (ZipTask)

V postupu je něco co není standardní součástí Phingu i když si myslím, že se to tam objeví. Phing pro práci se SVN používá VersionControl_SVN 0.3.1 alpha. Bohužel neexistuje zatím stable verze této PEAR knihovny což je škoda, protože funguje celkem dobře a má implementováno vše co potřebuji. Když používáte VersionControl_SVN dá se pracovat s několika návratovými typy:

• VERSIONCONTROL_SVN_FETCHMODE_ASSOC,
• VERSIONCONTROL_SVN_FETCHMODE_OBJECT,
• VERSIONCONTROL_SVN_FETCHMODE_XML,
• VERSIONCONTROL_SVN_FETCHMODE_RAW,
• VERSIONCONTROL_SVN_FETCHMODE_ALL,
• VERSIONCONTROL_SVN_FETCHMODE_ARRAY

V Phingu se používá, ale výhradně VERSIONCONTROL_SVN_FETCHMODE_ASSOC což není někdy úplně vhodné. V případě, že máte totiž zapnutý přepínač pro výpis v XML je lepší návratový typ VERSIONCONTROL_SVN_FETCHMODE_XML. Proto jsem musel upravit phing\tasks\ext\svn\SvnBaseTask.php.

Tuto část

$options = array('fetchmode' => VERSIONCONTROL_SVN_FETCHMODE_ASSOC, 'svn_path' => $this->getSvnPath());

jsem nahradil tímto kódem

		// Set up runtime options. Will be passed to all
		// subclasses.
		if ($mode=="log")
		{
		$options = array('fetchmode' => VERSIONCONTROL_SVN_FETCHMODE_XML, 'svn_path' => $this->getSvnPath());
		}
		else
		{
		$options = array('fetchmode' => VERSIONCONTROL_SVN_FETCHMODE_ASSOC, 'svn_path' => $this->getSvnPath());
		}

Po této úpravě, která jistě by šla udělat lépe. Jsem se dal do psaní vlastního tasku SvnLogTask.php. Task vrátí log z repozitory v XML formátu. Pokud chceme plain text, tak to prožene XSLT transformací a potom ještě vymaže whitespaces z celého dokumentu.

require_once 'phing/Task.php';
require_once 'phing/tasks/ext/svn/SvnBaseTask.php';

class SvnLogTask extends SvnBaseTask
{
    private $name = 'log.xml';
    private $xml = true;
    private $verbose = false;
    /**
     * The setter for the attribute "name"
     */
    public function setName($str) {
        $this->name = $str;
    }
    /**
     * The setter for the attribute "xml"
     */
    public function setXML($str) {
        $this->xml = $str;
    }
    /**
     * The setter for the attribute "verbose"
     */
    public function setVerbose($str) {
        $this->verbose = $str;
    }
	/**
	 * The main entry point
	 *
	 * @throws BuildException
	 */
	function main()
	{
		$this->setup('log');
		$this->log("Log SVN"); 

         $switches = array('verbose' => $this->verbose);
         $output=$this->run(array(), $switches);

        $doc = new DOMDocument();
        $doc->formatOutput = true;
        $doc->loadXML($output);
        // output format 

        if ($this->xml=="true")
        {
          $doc->save($this->getToDir()."/".$this->name);
        }
        else
        {
         // print in plain
         $xsl = new DOMDocument;
         $xsl->load(dirname(__FILE__).'\LogTxt.xsl');
         $proc = new XSLTProcessor;
         $proc->importStyleSheet($xsl); // attach the xsl rules
         $output=$proc->transformToDoc($doc)->firstChild->wholeText;

         $pat[0] = "/^\s+/";
         $pat[1] = "/\s{2,}/";
         $pat[2] = "/\s+\$/";
         $rep[0] = "";
         $rep[1] = " ";
         $rep[2] = "";
         $after=preg_replace($pat, $rep, $output);
         $str=str_replace("\\n ","\n", $after);
         file_put_contents($this->getToDir()."/".$this->name,$str);
        }
    }
}

Potom se to dá už použít v build.xml.

        <taskdef name="svnlog" classname="phing.tasks.ext.svn.SvnLogTask" />
        <svnlog
           svnpath="${svnpath}"
           repositoryurl="${rep}"
           name="CHANGELOG"
           xml="true"
           verbose="true"
           todir="${tmp}\log"/>

Moje vlastní XSLT transformace (phing\tasks\ext\svn\LogTxt.xsl) na plain text není přiliš vhodná pro nějaké systémové řešení. Lepší je parametr nechat zapnutý. Vzít XML a pomocí XsltFilter aplikovat vlastní transformaci.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="log">
			CHANGELOG\n
			<xsl:apply-templates select='logentry'/>
</xsl:template>

<xsl:template match="logentry">
			\n R<xsl:apply-templates select='@revision'/>\n
			<xsl:apply-templates select='date' /> - <xsl:apply-templates select='author'/>\n
			<xsl:apply-templates select='msg'/>\n
</xsl:template>

</xsl:stylesheet>

Nakonec přidám ještě moje build.propeties a buid.xml jednoho moje projektu pro ilustraci.

# Property files contain key/value pairs
# key=value
tmp = c:\tmp
svnpath = c:\apps\svn\bin\svn.exe
rep = file:///rootwww/rep_cvut/akce/trunk
wc =  c:\rootwww\wc_cvut\akce

Tady v build.propeties si všimněte jen jediného detailu, ale ten vás může stát hodně času. Cesty k svn a k repozitory neobsahují mezery, pokud máte Subversion např. v Program Files může to nadělat více problémů než užitku a chyby se projevují různě a ne zcela systémově. Doporučuji se tomu předem vyhnout, ušetříte si čas a nervy.

<?xml version="1.0" ?>
<project name="akce2" basedir="." default="main">

    <!-- Sets the DSTAMP, TSTAMP and TODAY properties -->
    <tstamp/>  

    <!-- Load our configuration -->
    <property file="./build.properties" />
    <taskdef name="svnlog" classname="phing.tasks.ext.svn.SvnLogTask" />

    <property name="package"  value="${phing.project.name}" override="true" />
    <property name="builddir" value="${tmp}/build/${phing.project.name}" override="true" />
    <property name="srcdir"   value="${project.basedir}" override="true" />

    <target name="svn" description="SVN executes">
         <!-- Export HEAD copy do /tmp/ -->
       <svnexport
       svnpath="${svnpath}"
       repositoryurl="${rep}"
       force="yes"
       todir="${tmp}\export\${phing.project.name}"/>
        <!-- Získání čísla HEAD -->
        <svnlastrevision
           svnpath="${svnpath}"
           workingcopy="${wc}"
           propertyname="svn.lastrevision"/>
        <!-- Vygenerování aktuálního logu -->
        <svnlog
           svnpath="${svnpath}"
           repositoryurl="${rep}"
           name="CHANGELOG"
           xml="false"
           verbose="true"
           todir="${tmp}\export\${phing.project.name}"/>
    </target>

    <target name="phpdoc" description="API Documentation" depends="svn">
        <!-- Generování phpdoc dokumentace -->
        <phpdoc title="Akce2008 API Documentation"
          destdir="${builddir}/apidocs"
          sourcecode="yes"
          defaultpackagename="Akce2008"
          output="HTML:default:default">
           <fileset dir="${tmp}/export/${phing.project.name}">
              <include name="*/*.php" />
              <exclude name="inc/phpmailer/**" />
              <exclude name="build/**" />
           </fileset>
            <projdocfileset dir=".">
                  <include name="CHANGELOG" />
             </projdocfileset>
        </phpdoc>
      </target>

        <!-- Fileset for all files -->
        <fileset dir="${tmp}/export/${phing.project.name}" id="allfiles">
            <include name="**" />
            <exclude name="build.xml" />
            <exclude name="build.properties" />
        </fileset>

    <!-- Main Target -->
    <target name="main" description="main target" depends="phpdoc">
        <!-- Zdrojové kódy pro příslušnou revizi -->
        <zip destfile="${builddir}/${phing.project.name}-R${svn.lastrevision}-${DSTAMP}${TSTAMP}.zip" basedir="${tmp}/export/${phing.project.name}" />
        <!-- Vygenerovanou dokumentaci přesunu do ZIP s číslem příslušné revize -->
        <zip destfile="${builddir}/${phing.project.name}-apidocs-R${svn.lastrevision}-${DSTAMP}${TSTAMP}.zip" basedir="${builddir}/apidocs" />
        <!-- Smazaní temp adresáře -->
        <delete dir="${builddir}/apidocs" includeemptydirs="true" verbose="true" failonerror="true" />

    </target>
</project>

Vlastní build se pustí pomocí phing z příkazové řádky tam kde máte build.xml uložený. Pokud se nedaří Phing nainstalovat a nakonfigurovat pro chod např. s PHPDoc, tak doporučuji postup ze stránek Phingu.

pear channel-discover pear.phing.info
pear install -a phing/phing
pear install channel://pear.php.net/VersionControl_SVN-0.3.1

Doufám, že někomu rady budou k užitku, Phing je skvělý produkt i když většina asi dá za přednost Antu pokud nedělají čistě PHP.

Hlavní novinky jsem představil už v TortoiseSVN 1.5.0-beta1 a podrobně s tím seznámím postupně jak s tím budu také delší dobu pracovat. Originální release notes je k dispozici na stránkách projektu.

Pro windows je k dispozici kromě zdojových kódů v této podobě, officiální binárky zatím k dispozici nejsou:

• VisualSVN Server 1.5
• TortoiseSVN 1.5
• New Merge Clients for Eclipse

AnkhSVN 2.0 pro Visual Studio se chystá v co nekratší době, stejně jako officální binárky pro Windows, které mají bý hotovy v tomto týdnu, certifikace je plánovaná na 24.6.2008. Pro Red Hat jsou již dnes k dispozici. Pro Solaris se v zápětí 26.6. 2008.

Pokud hledáte free hosting pro svůj projekt a není to opensource na které se hodí Sourceforge nebo Google Code, tak je několik alternativ např. OpenSVN a Assembla. Já jsem si vybral Assembla, ve free variantě vám umožní hostovat projekty do 500MB což mě zatím stačí a pro ty na kterých aktuálně dělám také bude stačit. Tak není nic jednodušího než si založit projekt a potom vyexportovat repozitory u sebe ze SVN.

svnadmin dump path_to_rep >file.dump

Pokud máte toho víc, možná užijete tento export.bat, aby to bylo jednodušší pro celé repository, také se to hodí na zálohování.

dir path_to_rep\rep_dir /b /O /AD >dir1.txt

FOR /F  %%M IN (dir1.txt) DO (
  ECHO  %%M
  svnadmin dump path_to_rep/rep_dir/%%M  --incremental >%%M.dmp
  zip -m -9 -g %%M.dmp.zip %%M.dmp
)

Jednotlivé dump soubory potom naimportujete do Assembla. Hlavní výhodou je to, že je k dispozici celý systém třeba jen pro vás a nejste nikde k nalezení pokud zrovna nechcete. Samozřejmě těžko můžu dát ruku do ohně za spolehlivost a důvěryhodnost firmy, která to provozuje, ale jejich filozifie se mi líbí. Samozřejmě bych uvítal třeba firmu, která by to poskytovala u nás, ale myslím si že to už dnes není potřeba. Na http://www.assembla.com/tour najdete porovnání Free varianty s těmi komerčními. Commercial mi přijde při ceně kolem $150 (cca 2400 Kč) za rok celkem dobrá, myslím že provoz a údržba vlastního stroje na podobný účel musí přijít i malého soukromníka na mnohem větší peníze.

Aktualizace 17.12.2008

Už firma svoji politiku změnila a nemůžete si svůj projekt mít jako privátní zdarma, je to škoda, použitelné to ale zůstává pro otevřené projekty

Pokud pracujete s TSVN nebo přímo s repozitory pod Windows časem přijdete na to, že potřebujete občas nějakou operaci před commitem nebo commitem k tomu slouží hook skripty. Hook je program, který je spuštěn nějakým triggrem, každé repozitory obsahuje předdefinované skripty. Nutnou podmínkou je mít samozřejmě nainstalovaný i Subversion ne jenom TSVN.
Adresář repozitory: \path-to-repozitory\project-name
[conf] [dav] [hooks] [locks] format README.TXT
v adresáři hooks jsou skripty:

post-commit.tmpl
post-lock.tmpl
post-revprop-change.tmpl
post-unlock.tmpl
pre-commit.tmpl
pre-lock.tmpl
pre-revprop-change.tmpl
pre-unlock.tmpl
start-commit.tmpl

tyto skripty vám určují možné spouštěče, kdy se který skript vykoná. Já osobně používám jen post-commit a to tak, že jsem vytvořil post-commit.bat, který obsahuje tento kód, který přegeneruje changelog.

"c:\Program Files\Subversion\bin\svn.exe" log -v --xml svn://localhost/rep_testing/start_page/trunk >c:\rootwww\wc_testing\startpage_changelog.xml

ještě mě napadlo, že můžete např. udělat automatický export pro deploy na jiný stroj:
"c:\Program Files\Subversion\bin\svn.exe" export --force file:///rootwww/rep_cvut/akce/trunk c:/tmp/export/akce
a k němu vygenerovat příslušný textový changelog:
"c:\Program Files\Subversion\bin\svn.exe" log file:///rootwww/rep_cvut/akce/trunk >c:/tmp/export/akce/changelog.txt
Ty skripty samozřejmě mohou dělat mnohem více.

Generovat můžete diff soubory pro jednotlivé revize a někam je ukládat:
svn diff path-to-working-copy -c revision_number --no-diff-deleted >diff_revision_number.txt
Pokud potřebujete např. provést update a potom poslat mail doporučuju článek SVN post-commit for Windows, kde autor ve stejné době jako já řešil něco obdobného i když z jiného důvodu.

Stefan Küng vytvořil tuto šikovnou utilitu, která monituruje commity na repozitory, kde si nastavíte. Je to velmi užitečné pokud pracujete na více projektech a krásně se vám to zobrazí v taskbaru.

Náhled obrazovky monitoru.

Zobrazní v taskbaru potom co je detekován nový commit.

Nastavení repozitory, Commit Monitor (CM) používá SVNParentPath directivu z Apache a také dovoluje nastavit repozitory pomocí svnrobots.txt, kde můžete určit jak často se CM může připojovat k repozitory.

Takto vypádá svnrobots.txt, hledá se automaticky v web rootu, v repozitory root a trunk. První nalezený se použije.

# this is an example svnrobots.txt file
#
# the checkinterval line sets the minimum interval in minutes between
# update checks:
checkinterval = 90
# the disallowautodiff line if it's present forces the check apps
# to *not* do automatic diffs:
disallowautodiff

Doufám, že v další verzi přidá možnost spuštění po commitu nějakého batch souboru. Užil bych to pro aktualizaci logů ze SVN, které provádím zatím přes batch file.

V nové verzi jsou toto hlavní novinky:

• Merge Tracking
• Cyrus SASL support for svnserve
• Sparse checkouts
• Changelist support
• Log message caching
• Repository browser
• Revision graph
• Client side hook scripts
• TortoiseMerge

Pro Cyrus SASL support for svnserve a Merge tracking bude potřeba i vlastní Subversion 1.5 pokud ho používate a nemáte TSVN zcela samostatně. Bude možný také opakovaný merge (Repeated Merge) a rozšíří se informace o každé Merge.

Sparse checkouts umožní checkout jen na část repozitory, což bude u velkých projektů hodně užitečné. K dipozici budou parametry podle kterých se provede volba.

• Fully recursive
• Immediate children, including folders
• Only file children
• Only this item

Changelist support mi docela chyběl, pokud pracujete na více problémech součastně a chcete je při commitu rozdělit do více části, které spolu souvisí, aby se dalo zpětně vysledovat, která změna patří ke které.

TSVN bude v nové verzi lokálně uchovávat kopii zpráv (Log message caching), u vetších repository dojde i urychlení načítání.

Repository browser starý

Repository browser v nové verzi, přibyl levý panel a umožňuje drag a drop operace.

Další věci mi nepřijdou tak důležité, vylepšený je TortoiseMerge, práce s konci řádek včetně MAC OS, Undo funkce se také hodí a možnost přímé editace není k zahození.

Revision Graph by měl vypadat lépe a mít nové možnosti, zatím jsem to netestoval. Jako dobé vylepšení jsou Client-side hook scripts. Ty umožnují na straně klienta provádět operace Start, Pre a Post u Commit a Update.

Ještě bych chtěl upozorňit na to, že verze 1.5 provádí upgrade formátu Working Copy, tak pozor při testování a nepřecházejte ukvapeně.

Nedávno jsem si tu stěžoval, že sháním něco co dává náhled na práci se SVN, sám jsem si naprogoramoval malý jednoduchý tool, který zobrazuje aktuální working copy (wc) u mě na disku a k tomu příslušné changelogy, které se generují skriptem. Rozhodně jsem si nemyslel, že by něco takového nenapdalo nikoho před tím. Časem jsem narazil na dva produkty, které zhruba splňují co jsem od toho čekal.

První je StatSVN a druhý FishEYE. Nevýhodou FishEYE je jenom cena $1200 pro 10 uživatelů není pro organizaci moc, ale pro mě ano.

FishEYE je webová aplikace běžící pod Tomcatem napsaná v Javě. Umožňuje skvělý náhled na changelog v repository, krásně zobrazuje diffy mezi verzemi, příslušnou historii, ukazuje i smazané adresáře v předchozích revizích. Náhled na to jak se rozrůstá projekt ukazuje Line history, při nějaké stagnaci nebo prudké změně se dá lehce najít co se dělo. K dispozici máte kompletní informace na jednom místě a vlastní repository mohou být klidně na různých serverech a FishEYE si dělá vlastní index a po přidání celého většího repository to chvíli trvá než si ho zaindexuje.

StatSVN je opensource projekt, poskytuje podobné informace. Je také napsán v Javě, ale funguje jako řádkový interpretr, který pošlete na log exportovaný ze SVN. Funguje to trochu méně komfortně, ale výsledky jsou podobné.

Nejdříve potřebujete wc vašeho projektu ze SVN. Typický příkaz na řádce vypá takto:

svn co svn://server/repo/trunk/modulename

Samozřejmě můžete checkout udělat třeba pomocí TSVN. Potom je potřeba udělat log ve formátu XML. To bohužel TSVN pokud vím zatím neumí a na to potřebujete příkaz:

svn log -v --xml > logfile.log

Potom už můžete spustit StatSVN a pohnat ho na log.

java -jar /path/to/statsvn.jar /path/to/module/logfile.log /path/to/module

StatSVN vytvoří HTML report v aktuálním adresáři (ukázka takového reportu).

• Homepage StatSVN http://www.statsvn.org/
• Homepage FishEYE http://www.atlassian.com/software/fisheye/

Minule jsem psal o tom jak jsem potřeboval doinstalovat server SVN jako service pod Windows a to pro moji startovací stránku (kus vidíte na obrázku). Stránka načítá moje working copy z adresářů a umožňuje mě na ně se přímo prokliknout, pomocí exportu, která jsem dodělal vidím poslední záznam z Logu a můžu prokliknout na kompletní Log, který se zobrazí po jediném kliknutí. Jediné co zatím nefunguje je parsování napojení Bug/Issue tracker, který v práci používáme. V logu Eclipse nebo TSVN je textem Ticket odkaz, který vede přímo do našeho helpdesku.

Někdo se mi zmiňoval, že viděl podobný systém jako nějaký open source projekt, pokud někdo víte o nějkém dobrém tak mi dejte vědět. Díky

Pokud jste vývojáři a používáte Subversion (SVN) pod Windows máte několik možností jak to dělat. Donedávna jsem používal jen klienta buď Subclipse nebo Tortoisesvn (TSVN) a tím jsem to řešil. Buď jsem se vzdáleně připojil na SVN server nebo jsem používal lokální repozitory, které umí TSVN vytvořit a zpracovat. Pro vývoj je vcelku jedno které řešení používáte, pokud máte stálé připojení k internetu, musíte používat stejně centrální repozitory. Pro některé moje projekty, ale vlastní repozitory server nemám a hostuji to jen lokálně a celé repozitory jen zálohuji jako soubory.

Pár let co používám SVN to bylo v pořádku, pro vývoj to stačí. Pokud jsem používal Linux, tak to bylo o to jednoduší, měl jsem tak plný SVN server (1.4.6 aktuálně) a lokální nebo vzdálená administrace je totéž. Podobně se můžete zachovat i na Windows pokud k tomu máte motivaci, kterou jsem donedávna neměl. K instalaci na windows dopoučiji balíček TortoiseSVN-1.4.8.12137-win32-svn-1.4.6.msi a aby vám fungoval server jako service je dobré to doplňit o svnservice-1.0.0.msi. Po jednoduché instalaci těchto balíčků a nastavení SVNROOT můžete ve svém klientovi přistupovat přes svn protokol a používat všechny běžné příkazy.

Já jsem měl v motivaci ve vytváření changelogu pro deploy pomoci svn.exe log –xml svn://localhost/rep_name což přes klienta TSVN nějak rozumně nešlo a při exportu přes schránku jsem měl problém s exportem češtiny ve výsledném dokumentu. Takto to jednoduše obejdu a můj jednoduchý skript udělá pro každý projekt aktuální changelog.