Difference between revisions of "Subversion"

From SME Server
Jump to navigationJump to search
 
(23 intermediate revisions by 3 users not shown)
Line 10: Line 10:
  
 
=== Description ===
 
=== Description ===
This contrib provides subversion over http and https for SME Server, it won't provide other means of subversion like the svn protocol or the ssh+svn protocol. It will install a panel in the server-manager to administer your subversion repositories. Subversion a is version control system for all kind of files with a central storage on the SME server. Subversion is mostly used for smaller workgroups. If you have a lot of users please consider to use [http://wiki.contribs.org/Git Git]. Subversion is by many seen as more simple and easy to understand. If you need more information please read the [http://svnbook.red-bean.com SVN manual]
+
This contrib provides subversion over http and https for SME Server, it won't provide other means of subversion like the svn protocol or the ssh+svn protocol. It will install a panel in the server-manager to administer your subversion repositories. Subversion a is full-featured version control system for all kind of files with a central storage on the SME server. Subversion is mostly used for smaller workgroups. If you have a lot of users please consider to use [[Git|Git]]. Subversion is by many seen as more easy to understand. Subversion is also partly a DeltaV server as it under WebDAV can support auto-versioning. Subversion is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users. Version control is an important element of the modern software development process. Cooperating developers commit their changes incrementally to a common source repository, which allows them to collaborate on code without resorting to crude file-sharing techniques (shared drives, email). Source control tools track all prior versions of all files, allowing developers to "time travel" backward and forward in their software to determine when and where bugs are introduced. These tools also identify conflicting simultaneous modfications made by two (poorly-communicating) team members, forcing them to work out the correct solution (rather than blindly overwriting one or the other original submission).<br>
 +
If you need more information please read the [http://svnbook.red-bean.com SVN manual]
  
 
=== Installation ===
 
=== Installation ===
This contrib can be found in the [http://mirror.contribs.org/smeserver/releases/7/smecontribs/i386/repodata/index.html SME Contribs] repository (available on SME Servers as of smeserver-yum-1.2.0-41).
+
<tabs container><tab name="For SME 10">
 +
yum install smeserver-subversion --enablerepo=smecontribs
 +
</tab><tab name="For SME 9">
 
To install this contrib get shell access as root user and issue the following command:
 
To install this contrib get shell access as root user and issue the following command:
 
  yum install smeserver-subversion --enablerepo=smecontribs
 
  yum install smeserver-subversion --enablerepo=smecontribs
 
After yum has finished make sure to issue the following commands:
 
After yum has finished make sure to issue the following commands:
  signal-event post-upgrade
+
  signal-event post-upgrade ; signal-event reboot
signal-event reboot
+
or if you don't want to restart your server
 
+
  config set UnsavedChanges no
==== '''For SME 9''' ====
 
You have to enable the '''[[stephdl]]''' repository, see '''[[bugzilla:8998]]'''
 
  yum install --enablerepo=stephdl --enablerepo=epel smeserver-subversion
 
 
 
After yum has finished make sure to issue the following commands:
 
signal-event post-upgrade
 
signal-event reboot
 
  
 +
</tab><tab name="For SME 8">
 
==== Updating the subversion 'core' ====
 
==== Updating the subversion 'core' ====
 +
* only for sme8
 
The smeserver-subversion contrib does not contain the subversion package itself, as this removes the need of releasing a new contrib every time a new subversion version is released.
 
The smeserver-subversion contrib does not contain the subversion package itself, as this removes the need of releasing a new contrib every time a new subversion version is released.
  
 
This contrib is meant to tie it in to SME Server. The command in the installation section will install the latest subversion version yum can find in the enabled repositories. the SME Contribs repository should contain the latest release of subversion. You can install or update like this
 
This contrib is meant to tie it in to SME Server. The command in the installation section will install the latest subversion version yum can find in the enabled repositories. the SME Contribs repository should contain the latest release of subversion. You can install or update like this
 
  yum update subversion --enablerepo=smecontribs
 
  yum update subversion --enablerepo=smecontribs
 +
</tab>
 +
</tabs>
  
 
=== Removal ===
 
=== Removal ===
 
To remove this contribution issue the following command:
 
To remove this contribution issue the following command:
 
  yum remove smeserver-subversion
 
  yum remove smeserver-subversion
After yum has finished make sure to issue the following commands:
+
After yum has finished make sure to issue the following commands for SME9 and previous versions:
 
  signal-event post-upgrade
 
  signal-event post-upgrade
 
  signal-event reboot
 
  signal-event reboot
Line 45: Line 45:
 
After installation you have to create a repository in the server-manager under the subversion menu by pressing the button "Add repository".
 
After installation you have to create a repository in the server-manager under the subversion menu by pressing the button "Add repository".
  
Next procedure is to create the recommended folder structure in your repository with this command in a terminal
+
* When Subversion auto-versioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is automatically generated and attached to each revision (this can result a lot of automatically committed revisions).
 +
* If you don't want to remember to set it manually on every file you add, you can enable the "automatic MIME type" feature. This can automatically set the line ending (for text files) or MIME type (for binary files) based on file extensions.
 +
* Be careful when setting permissions for reading and writing to a repository. When no selections are made in both the "read-only access" lists, or both the "full access" lists, they will default to 'Everyone'. To completely restrict access to specific groups and users, you must make a selection from both the "read-only access" and the "full access" lists, for either one or more groups, or one or more users.
 +
<br>
 +
Next procedure is to create the recommended folder structure in your repository with this command in a terminal (just a recommendation and not nessesary)
 
  <nowiki>svn mkdir https://server-name/repository-name/{branches,tags,trunk} -m "Recommended structure"</nowiki>
 
  <nowiki>svn mkdir https://server-name/repository-name/{branches,tags,trunk} -m "Recommended structure"</nowiki>
  
Line 56: Line 60:
 
'''Branches'''
 
'''Branches'''
  
There are different types of branches. With the branches directory you can create paths for you code to travel to more specific goals like an upcoming release. The branches directory contains copies of your trunk at various stages of development.
+
There are different types of branches. With the branches directory you can create paths for you code to travel to more specific goals like an upcoming release. The branches directory contains copies of your trunk at various stages of development. The stages can for example be a bug fix branche that address the more serious bugs found in the trunk. The bugs are of such a magnitude that you can’t fix them by yourself in a single commit. So, in order to focus on the problem of fixing this bug you should create a new branch for this purpose. This allows development in the trunk to continue, and you won’t disturb them with new bugs or tests that break the current code. Bug fix branches can be named after the ID they are assigned in your bugtracking tool. Another branch is an experimental branch that mainly support introduction of new technologies. You don’t want to bet your entire project on it. Imagine that you want to change from PHP 5 to PHP 6 for your web application. How long would it take you to convert your entire project? Do you want your entire code base (trunk) to be useless until you have converted all of your code? Then use a branch for it!
  
''Release Branches'' - When the trunk reaches the stage that it’s ready to be released (or when you want to freeze the addition of new features) you create a release branch. This release branch is just a copy of your current trunk code.
+
'''Tags'''
 
 
''Bug fix branches'' - Branches may also be used to address the more serious bugs found in the trunk or a release branch. The bugs are of such a magnitute that you can’t fix them by yourself in a single commit. So, in order to focus on the problem of fixing this bug you should create a new branch for this purpose. This allows development in the trunk or your release branch to continue, and you won’t disturb them with new bugs or tests that break the current code. Bug fix branches are named after the ID they are assigned in your bugtracking tool.
 
  
''Experimental branches'' - Something that also happens a lot is the introduction of new technologies. This is fine, of course, but you don’t want to bet your entire project on it. Imagine that you want to change from PHP 5 to PHP 6 for your web application. How long would it take you to convert your entire project? Do you want your entire code base (trunk) to be useless until you have converted all of your code? Probably not!
+
Tags are, like branches, copies of your code. Tags, however, are not to be used for active development. They mark (tag) a certain state your code is in - for example when you release your code.
 
+
<br><br>
'''Tags'''
+
The essential Subversion life cycle is the following:
  
Tags are, like branches, copies of your code. Tags, however, are not to be used for active development. They mark (tag) a certain state your code is in for exampel when you release your code.
+
# Check out a project (a directory path) from a repository.
 +
# In that project directory, create or edit files and subdirectories.
 +
# Update your local copy from the repository, picking up changes your team members may have made since your last update.
 +
# Go to step 2. If you're ready to commit your changes, go to step 5.
 +
# Commit your changes to the repository. Go to step 2.
 +
<br>
 +
To work with your repository you need to use a client like TortoiseSVN for Windows or RabbitVCS for Linux. ALso possible to use the command line with the svn command. You just import your code to <nowiki>https://server-name/repository-name/trunk</nowiki><br>
  
 
=== Additional information ===
 
=== Additional information ===
 
* Each SVN repository is stored on the server under /home/e-smith/files/repositories/{repository-name}
 
* Each SVN repository is stored on the server under /home/e-smith/files/repositories/{repository-name}
 
* The URL for a repository is <nowiki>http://{server-name}/{repository-name}</nowiki> (or <nowiki>https://{server-name}/{repository-name}</nowiki>). Care must be taken with the naming of subversion repositories as they share the same web namespace as the i-bays
 
* The URL for a repository is <nowiki>http://{server-name}/{repository-name}</nowiki> (or <nowiki>https://{server-name}/{repository-name}</nowiki>). Care must be taken with the naming of subversion repositories as they share the same web namespace as the i-bays
* In the admin panel, be careful when setting permissions for reading and writing to a repository. When no selections are made in both the "read-only access" lists, or both the "full access" lists, they will default to 'Everyone'. To completely restrict access to specific groups and users, you must make a selection from ''both'' the "read-only access" and the "full access" lists, for either one or more groups, or one or more users.
 
  
 
=== Bugs ===
 
=== Bugs ===

Latest revision as of 20:18, 1 August 2022


PythonIcon.png Skill level: Easy
The instructions on this page can be followed by a beginner.


Maintainer

Jonathan Martens

stephdl Stéphane de Labrusse AKA Stephdl

Version

Devel 10:
Contrib 10:
Contrib 9:
smeserver-subversion
The latest version of smeserver-subversion is available in the SME Contribs repository, click on the version number(s) for more information.


Description

This contrib provides subversion over http and https for SME Server, it won't provide other means of subversion like the svn protocol or the ssh+svn protocol. It will install a panel in the server-manager to administer your subversion repositories. Subversion a is full-featured version control system for all kind of files with a central storage on the SME server. Subversion is mostly used for smaller workgroups. If you have a lot of users please consider to use Git. Subversion is by many seen as more easy to understand. Subversion is also partly a DeltaV server as it under WebDAV can support auto-versioning. Subversion is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users. Version control is an important element of the modern software development process. Cooperating developers commit their changes incrementally to a common source repository, which allows them to collaborate on code without resorting to crude file-sharing techniques (shared drives, email). Source control tools track all prior versions of all files, allowing developers to "time travel" backward and forward in their software to determine when and where bugs are introduced. These tools also identify conflicting simultaneous modfications made by two (poorly-communicating) team members, forcing them to work out the correct solution (rather than blindly overwriting one or the other original submission).
If you need more information please read the SVN manual

Installation

yum install smeserver-subversion --enablerepo=smecontribs

To install this contrib get shell access as root user and issue the following command:

yum install smeserver-subversion --enablerepo=smecontribs

After yum has finished make sure to issue the following commands:

signal-event post-upgrade ; signal-event reboot

or if you don't want to restart your server

config set UnsavedChanges no

Updating the subversion 'core'

  • only for sme8

The smeserver-subversion contrib does not contain the subversion package itself, as this removes the need of releasing a new contrib every time a new subversion version is released.

This contrib is meant to tie it in to SME Server. The command in the installation section will install the latest subversion version yum can find in the enabled repositories. the SME Contribs repository should contain the latest release of subversion. You can install or update like this

yum update subversion --enablerepo=smecontribs

Removal

To remove this contribution issue the following command:

yum remove smeserver-subversion

After yum has finished make sure to issue the following commands for SME9 and previous versions:

signal-event post-upgrade
signal-event reboot

Usage

After installation you have to create a repository in the server-manager under the subversion menu by pressing the button "Add repository".

  • When Subversion auto-versioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is automatically generated and attached to each revision (this can result a lot of automatically committed revisions).
  • If you don't want to remember to set it manually on every file you add, you can enable the "automatic MIME type" feature. This can automatically set the line ending (for text files) or MIME type (for binary files) based on file extensions.
  • Be careful when setting permissions for reading and writing to a repository. When no selections are made in both the "read-only access" lists, or both the "full access" lists, they will default to 'Everyone'. To completely restrict access to specific groups and users, you must make a selection from both the "read-only access" and the "full access" lists, for either one or more groups, or one or more users.


Next procedure is to create the recommended folder structure in your repository with this command in a terminal (just a recommendation and not nessesary)

svn mkdir https://server-name/repository-name/{branches,tags,trunk} -m "Recommended structure"

This will create 3 sub folders under your repository - branches, tags and trunk. These will be used for your development.

Trunk

The trunk contains the most current development code at all times. This is where you work up to your next major release of code.

Branches

There are different types of branches. With the branches directory you can create paths for you code to travel to more specific goals like an upcoming release. The branches directory contains copies of your trunk at various stages of development. The stages can for example be a bug fix branche that address the more serious bugs found in the trunk. The bugs are of such a magnitude that you can’t fix them by yourself in a single commit. So, in order to focus on the problem of fixing this bug you should create a new branch for this purpose. This allows development in the trunk to continue, and you won’t disturb them with new bugs or tests that break the current code. Bug fix branches can be named after the ID they are assigned in your bugtracking tool. Another branch is an experimental branch that mainly support introduction of new technologies. You don’t want to bet your entire project on it. Imagine that you want to change from PHP 5 to PHP 6 for your web application. How long would it take you to convert your entire project? Do you want your entire code base (trunk) to be useless until you have converted all of your code? Then use a branch for it!

Tags

Tags are, like branches, copies of your code. Tags, however, are not to be used for active development. They mark (tag) a certain state your code is in - for example when you release your code.

The essential Subversion life cycle is the following:

  1. Check out a project (a directory path) from a repository.
  2. In that project directory, create or edit files and subdirectories.
  3. Update your local copy from the repository, picking up changes your team members may have made since your last update.
  4. Go to step 2. If you're ready to commit your changes, go to step 5.
  5. Commit your changes to the repository. Go to step 2.


To work with your repository you need to use a client like TortoiseSVN for Windows or RabbitVCS for Linux. ALso possible to use the command line with the svn command. You just import your code to https://server-name/repository-name/trunk

Additional information

  • Each SVN repository is stored on the server under /home/e-smith/files/repositories/{repository-name}
  • The URL for a repository is http://{server-name}/{repository-name} (or https://{server-name}/{repository-name}). Care must be taken with the naming of subversion repositories as they share the same web namespace as the i-bays

Bugs

Please raise bugs under the SME-Contribs section in bugzilla and select the smeserver-subversion component or use this link .

Below is an overview of the current issues for this contrib:

IDProductVersionStatusSummary
2967SME Contribs7.1CONFIRMEDAbility to select which domains svn is available on & create subdomains