Subversion Administration: Difference between revisions

From Elvanör's Technical Wiki
Jump to navigation Jump to search
Line 3: Line 3:
== Design choice: repository setup ==
== Design choice: repository setup ==


You can choose to have one repository per project, or only one single repository containing each project in a separate directory. The single repository setup is easier, but the inconvenient is that the revision number will go up for some projects that did not undergo any changes (if some other projects are updated).
* You can choose to have one repository per project, or only one single repository containing each project in a separate directory. The single repository setup is easier, but the inconvenient is that the revision number will go up for some projects that did not undergo any changes (if some other projects are updated).
 
* Note that if you choose to use the svnserve method rather the Apache one, you won't be able to use name based (DNS) "virtual hosting" if you have several repositories. At least it seems to be MUCH more complicated to set up.


== Importing projects ==
== Importing projects ==

Revision as of 09:34, 9 May 2007

This article is a tutorial to Subversion repository administration.

Design choice: repository setup

  • You can choose to have one repository per project, or only one single repository containing each project in a separate directory. The single repository setup is easier, but the inconvenient is that the revision number will go up for some projects that did not undergo any changes (if some other projects are updated).
  • Note that if you choose to use the svnserve method rather the Apache one, you won't be able to use name based (DNS) "virtual hosting" if you have several repositories. At least it seems to be MUCH more complicated to set up.

Importing projects

While doing the initial import, remember that if you specify a path, only its contents will be added, thus, if you want to actually add the directory, remember to do a svn mkdir first.

This is not the case when you do an initial checkout of a project.

Tips & Hints

  • Subversion does password caching by default, so don't be surprised if you are not asked for a password after the first time.
  • There is a list of patterns (for example, *.o files) that are automatically ignored by svn. This is done client-side and can be modified by the client configuration files.
  • Ignore patterns can be specified by running svn propedit svn:ignore directory. Note that this does NOT affect items already put under version control (eg, this makes sense only for items not under version control).
  • Ignore patterns can be set recursively by adding the -R option to the command svn propset, for example. However I don't know if it is possible to add ignore patterns recursively, since propset erases the previous information.
  • The bottom line is that files that need to be ignored on *every* platform (.o files, for example) should be set using the svn:ignore property. What is dependent of the development platform (eg, .directory files that seem to appear with KDE/KDEsvn) should be set by the client.
  • On UNIX, the client configuration file is at ~/.subversion/config. The line to change is global-ignores, set for example to:
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store .directory
  • The fact that a file has the executable bit turned on (on UNIX systems) is controled by the property svn:executable. To set this property:
svn propset svn:executable myprogram

To unset it:

svn propdel svn:executable myplainfile

Note that if you work under Windows some files seem to get this property wrongly set (thus forcing you on UNIX to correct this).

Issues

If you are using the command line SVN client (on Linux for example), there is a bug associated with operations on the root directory of an svn+ssh:// server. For example, svn list ssh+svn://svnusername@svn.elvanor.net will not work as expected. This is due to a bug in the parsing system of svn; it does not happen when dealing with another directory (eg , svn list ssh+svn://svnusername@svn.elvanor.net/doc/ works fine) and it also does not appear when using GUIs (KDEsvn or TortoiseSVN).

A workaround is to not use the user@server syntax, but directly server. So add the following lines to your SSH config (on Linux, ~/.ssh/config):

Host svn.elvanor.net
User svnusername

Then you can use svn like this: svn list ssh+svn://svn.elvanor.net/.

Useful links

Subversion book