Add Missing Files Recursively

svn status | grep "^\?" | awk '{print $2}' | xargs svn add

Delete or Filter Revisions

The generic procedure is the following:

  • dump the svn repository with svnadmin dump.
  • filter the dump file with svndumpfilter.
  • create a new repository.
  • load the modified dump file.

Delete Revisions

In order to delete revisions by number, say 1 through 500, the procedure is as follows:

  • dump the svn repository and select the revisions that you want to keep:
svnadmin dump /path/to/repo -r1:500 > repo.dump
  • create a new repository:
svnadmin create /path/to/newrepo 
  • import the dump:
svnadmin load /path/to/newrepo < repo.dump

Delete a Range of Revisions

Deleting a range of revisions involves dumping the exclusion set around those revisions and then importing both dumps. Suppose we wanted to delete revision 500 from a total of 1000 revisions, then we would:

  • dump revision 1 to 499 to a file dump_1.
  • dump revision 501 to 1000 by passing the –incremental option to the svnadmin dump command to a file dump_2.
  • create a new repository.
  • first load the first dump file dump_1 and then load the second dump file dump_2.

Note that removing intermediary revisions will fail if new files have been added in the revisions to be deleted and then altered in following revisions because svnadmin would, in that case, attempt to load changes to files that have not been created in the first place.

Filter Dump Files

In order to delete unwanted files or folders from a subversion repository, the svndumpfilter command is used that can pattern-match files or folders in a dump file and create a new dump with those files or folders excluded or included.

  • dump the repository:
svnadmin dump /path/to/repo > repo.dump
  • now we can exclude or include files that will be either removed, respectively kept in the new dump file.

Excluding can be performed by:

svndumpfilter exclude somefile < repo.dump > newrepo.dump

Including can be done by:

svndumpfilter include somefile < repo.dump > newrepo.dump

Both inclusion and exclusion can be performed by pattern matching, for example, to exclude pdf files:

svndumpfilter exclude --pattern '*.pdf' < repo.dump > newrepo.dump
  • now create the new repository:
svnadmin create /path/to/newrepo
  • and load the filtered dump:
svnadmin load /path/to/newrepo < newrepo.dump

Checkout Repository and Overwrite Files

Subversion can be made to checkout a repository on top of an existing directory structure that may contain files in the repository to be checked out. If the checkout is executed without any flags, then Subversion will throw errors such as An obstructing working copy was found.

To merge the copy being checked out with the local existing files, you would first clean all .svn folders from the directory structure and then issue:

svn --force co http://svn.server.tld/project

which, from the documentation, will check out the repository on top of existing files and consider the local files to be local changes, marking them as modified. However, we want to overwrite the local files with the files from the repository and we thus need to chuck away any local "modifications". In order to do that, issue:

svn revert -R project 

and the local files will be overwritten by the files from the repository.

Exporting Contents of Subversion Directory to Current Directory

Suppose that you have some configuration files in a Subversion repository:

/configuration-templates/samba/3/standalone/smb.conf
/configuration-templates/samba/3/standalone/smb.conf.local
/configuration-templates/samba/3/standalone/smb.conf.share

and that you wish to tell Subversion to download those files to /etc/samba but without creating the standalone directory and without creating a .svn directory (that is, without keeping them under version control).

In such cases, you can use the export feature of Subversion. Change to the destination directory:

cd /etc/samba/

and now export the Subversion directory:

svn export http://svn.grimore.org/configuration-templates/samba/3/standalone --force .

where:

  • –force will allow Subversion to overwrite any files in the current directory - this is necessary, otherwise Subversion will say that the current directory already exists - which is obviously the case since we are in /etc/samba/.
  • the dot . at the end of the command will export the contents of the standalone directory (ie: without ending up with /etc/samba/standalone) - thus, it will only pull the configuration files.

Remove all Local Changes and Additional Files

To remove all local changes recursively:

svn revert -R .
svn status --no-ignore | grep -E '(^\?)|(^\I)' | sed -e 's/^. *//' | sed -e 's/\(.*\)/"\1"/' | xargs rm -rf
svn update --force

In case you do not wish to remove files that are not in the subversion repository, then do not issue the svn status line.

Ignore Files

The following command will globally ignore files matching the patterns *.pem, *.key and *.crt:

svn propset svn:global-ignores "
*.pem
*.key
*.crt" .

Alternatively, ignores can be set local to a current directory. Issuing the command:

svn propset svn:ignores "
*.pem
*.key
*.crt" .

within a directory will make SVN ignore the files in that directory.

Running Svnserve on Debian

The subversion package on Debian is not installed with a service to conveniently start and stop the Subversion svnservedaemon so here are some files that can be used to manage svnserve in a Debian-compliant way.

First create a user and group that svnserve should run under (in this example, a new user and group svnserve was created):

useradd svnserve

Then the service file is created at /etc/systemd/system/svnserve.service with the contents:

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
RuntimeDirectory=svnserve
PIDFile=/var/run/svnserve/svnserve.pid
EnvironmentFile=/etc/default/svnserve
ExecStart=/usr/bin/svnserve --pid-file /var/run/svnserve/svnserve.pid $DAEMON_ARGS
User=svnserve
Group=svnserve
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=svnserve.service

where:

  • User and Group has to be changed to the new user has been created.

Next, the defaults file for Debian is created at /etc/default/svnserve with the following contents:

# svnserve options
DAEMON_ARGS="--daemon --root /srv/svn --log-file /var/log/svnserve/svnserve.log"

where:

  • /srv/svn is the parent-path under which all SVN repositories are placed.

The /var/log/svnserve directory must be created:

mkdir /var/log/svnserve

and granted permission to the user and group specified in the system file:

chown -R svnserve:svnserve /var/log/svnserve

A matching logrotate file should be created at /etc/logrotate.d/svnserve (in order to rotate logs when they get too large) with the following contents:

/var/log/svnserve/*.log {
    daily
    missingok
    rotate 14
    compress
    notifempty
    create 640 svnserve svnserve
    sharedscripts
    postrotate
            if /bin/systemctl status svnserve > /dev/null ; then \
                /bin/systemctl restart svnserve > /dev/null; \
            fi;
    endscript
}

Now, systemctl is instructed to reload the daemon file with:

systemctl daemon-reload

and finally svnserve is started with:

systemctl start svnserve

Fixing Bad Gateway Responses

When attempting an SVN COPY or MOVE command, a repository running under Apache through SSL may yield:

svn: E175002: Commit failed (details follow):
svn: E175002: Unexpected HTTP status 502 'Bad Gateway' on '/check/!svn/rvr/4/src/server'

to address the issue, add to the Apache configuration file:

RequestHeader edit Destination ^https http early

and restart Apache.


fuss/subversion.txt · Last modified: 2019/07/07 14:25 by office

Access website using Tor Access website using i2p


For the copyright, license, warranty and privacy terms for the usage of this website please see the license, privacy and plagiarism pages.