[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
Besides of the packages that are installed by dependencies when you install svn-buildpackage, you may need ssh and the obligatory tool chain: dpkg-dev, build-essential and all the packages they pull into the system.
Here is a quick guide for those who wish to build an existing package using an existing, public available SVN repository. To create own repositories, skip this section and look for more details below.
svn co <svn://server/path/to/trunk> package
mkdir tarballs
cp dir-where-you-keep-the-source/package_version.orig.tar.gz tarballs/
NOTE: you need the upstream source tarballs, stored under a usual dpkg-source-compatible filename in tarballs/
cd package
svn-buildpackage -us -uc -rfakeroot
You need only few commands to start using svn with svn-buildpackage scripts.
If you wish to learn more about it, read parts of the the Subversion Book
. The
most used commands are:
add -- put new files unto the revision contol
rm -- remove the files from the repository
mv -- move files around, leting revision control system know about it
commit -- commit your changes to the repository
resolved -- tell svn that you have resolved a conflict
diff -- creates a "diff -u" between two versions, specified by file revision number or by date. See the diff --help output.
cat -r Revision -- useful to browse in some previous revision of the file
If you are familiar with CVS you will probably know almost all you need.
The main Subversion repository is easily created with:
svnadmin create repo-directory
For our example, we choose the name svn-deb-repo and put it in /home/user.
If you plan to keep many packages in the one repository including upstream tarballs, consider to put it on a hard disk with much free space and good performance (especially short disk access times) since the repository will grow and the filesystem may become fragmented over time.
Multiple developers with local access to the repository may share it using a common group. To do so, create a new group and add all developers to it. Run "chgrp -R sharedGroup repdir ; chmod -R g+s repdir" for the shared group and the repository directory. Now, on local access to this repository everybody will create files with the appropriate group setting. However, the developers will need to set a liberal umask before using svn (like "0022").
If somebody resists to do so, there is still a brute-force solution: fix the
permissions with a post-commit script. However, this is an "unsound"
solution and may lead to ALL KINDS OF PROBLEMS. MAKE SURE THAT YOU ARE AWARE
OF THE POSSIBLE CONSEQUENCES BEFORE YOU OPEN THE PANDORA BOX. See Debian
BTS
for details. When you damage your repository, don't blame me
and remember that there is "svnadmin recover".
#!/bin/sh # POST-COMMIT HOOK # The following corrects the permissions of the repository files REPOS="$1" REV="$2" chgrp -R sharedGroup $REPOS # replace sharedGroup with your group chmod -R g+r $REPOS chmod -R g+w $REPOS
To run Subversion over SSH, you basically need a shell on the target system and a subversion repository located there which is created following the description above. The repository must be configured for access by the system users of the remote system.
Assuming that your user name on the client system is the same as on the server side, there is not much to configure. Just change the protocol specificaton from file:// to svn+ssh://remoteusername@server-hostname in all examples showed in this manual.
Note that during svn-buildpackage tools actions a lot of SSH calls can be made
and so the user is asked for his login data. The regular method to deal with
that is using an SSH key authentication method together with ssh-agent and
ssh-add to cache the passphrase in memory. Another approach, which also brings
a significant speed boost, is using a cached SSH connection. This can be done
with a new feature of OpenSSH (see GCC SSH connection
caching howto
) or a third-party tool like fsh.
If you wish to use fsh over ssh you could specify a custom transport method in subversions's configuration. To do so, edit the file ~/.subversion/config and add the section [tunnels] to it, following by your custom transport definition. Example:
# personal subversion config with custom ssh tunnel command [tunnels] # SSH account on svn.d.o # compression is enabled in the ssh config deb = fsh -l blade # SSH account for NQ intranet, set fix username nq = ssh -C -l zomb
You can use the new defined tunnels in a similar ways as described above but replace svn+ssh with svn+tunnelname, so the final URL looks like:
svn+deb://svn.debian.org/svn/myproject/ourpackage/trunk
.
You can allow outsiders to have anonymous (read-only) access using the svnserve program, as described in the Subversion documentation.
Another method is using HTTP/WebDAV with Apache2. More about a such setup can
be found in the Subversion Book and the SubversionApache2SSL
Howto
. svn.debian.org
is an example site
granting anonymous access to some selected projects hosted there.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
svn-buildpackage - maintaining Debian packages with Subversion
$LastChangedDate: 2005-09-23 16:17:33 +0200 (Fr, 23 Sep 2005) $