As of the 1. This will cause traffic on port to be redirected to port Subversion Edge configures the server using a self-signed certificate that we provide with the software. Since the certificate is self-signed users will receive warnings in most browsers when accessing the site.
Individual users can install the certificate to their browser if they want to no longer see the warnings. If you want to solve this for all users, then you must purchase, install and configure an official SSL certificate from a trusted Certificate Authority.
You may decide you want to purchase an official SSL certificate or use an existing SSL certificate that you already use internally.
This is relatively easy to do. The first step, possibly the most difficult, is that you need to have your SSL Certificate as well as the private key and any necessary intermediate certificates loaded into a Java keystore. If you purchased a certificate from a vendor and followed their instructions, it is possible that you already have this in a keystore.
More often, you will have the certificate and key in OpenSSL format for use for your Apache server see below. You can use this same certificate for the Jetty server, but you must first import the certificate and key into a keystore. For some reason, the Java keytool command does not provide an option to do this. Once you have your certificate and key in a keystore, you simply need to edit the file named svnedge-ssl.
This is what the file looks like as shipped:. Just replace the Keystore and truststore values with the path to your keystore and the passwords with the password you used to protect the keystore. The next section explains how to generate an obfuscated password so that it is not exposed in plain text. If you edit the Jetty SSL configuration you may find yourself needing to supply Jetty with an obfuscated version of the password you used for your keystore and certificate. Jetty provides a tool to generate an obfuscated password that you can enter in its configuration files.
You need to use that tool to generate an obfuscated version of your password. Navigate to the appserver folder and run the following command:. When this is done, we install an initial self-signed certificate provided with Subversion Edge. This matches the self-signed certificate that the console uses so that a user only needs to accept the certificate one time. The following directives are added to the Apache configuration to use these certificates:.
If you have purchased a certificate from a vendor, you may receive an intermediate certificate in addition to these two files. If they reference this directive, then you will need to copy this file so that we add the directive.
It is fairly common to protect a private key with a passphrase, however in order to be able to start the Apache server from anything other than a Terminal window you must remove the passphrase from the private key file. This can be accomplished using OpenSSL as follows:. Refer to the documentation of this directive in the Apache documentation. Migration to Subversion Edge from an existing Subversion installation is fairly straightforward. The steps below should apply to any flavor of Subversion, whether it is CollabNet Subversion, open-source Subversion or some other Subversion server product.
However, there are a lot of different ways that Subversion could be deployed so we have not attempted to provide an automated upgrade or migration. Please be mindful of these limitations of Subversion Edge before beginning a migration. These are not temporary limitations, but core choices made in the design for Subversion Edge.
Generally, you will want to install Subversion Edge on the server as your first step and then migrate your repositories and configuration. Some things to look out for:. This is the easiest step. Just configure Subversion Edge to serve repositories from their existing location by pointing the Repository Parent Directory to the old location. Alternatively, you can use the new location for repositories and manually move the existing repositories to this folder Subversion Edge does not automate this.
On Unix systems, the repositories need to be owned by the user under which the Subversion Edge server will run. New repositories created under Subversion Edge will have the correct permissions. If you are currently using LDAP, then this process is pretty simple. See the next section. NOTE: Apache passwords are a one-way hash for security reasons, so there is no way to extract the current password and create a Subversion Edge user account.
Finally, if you are using some other user account system, then you either need to switch to the ones we provide in Subversion Edge or customize the Apache Configuration. Subversion Edge manages and writes the Apache configuration, but it supports only a subset of directives, since it is assumed that this Apache instance will only be used for SVN. However, if you require additional Apache customizations in order to run Subversion, let us know about them so we can add support to a future release.
Subversion Edge only writes the main Apache httpd. This main file pulls in the sections generated by Subversion Edge via Include, so after we write the httpd. For complete control of the Apache configuration, you can disable the Include directives and replace with your own code. Do not edit the Subversion Edge-managed include files as they will be overwritten the next time the Subversion Edge configuration is changed or the server started.
If you need to edit the content of those files, then remove the Include, copy and paste the content into the main httpd. Subversion Edge generates an initial self-signed certificate when SSL is requested. We expect users to replace this with their own server certificate. Here are some example scenarios of complicated configurations and how they might be handled with Subversion Edge.
This should be as simple as editing the httpd. We are writing defaults for some of these directives based on feedback and experience. The feedback we got for Linux was that the Apache defaults were pretty ideal for most users so we left those defaults in place. We should do so in the future if we learn of any settings that improve performance and reliability.
We support configuring LDAP authentication, but not authorization. There are some Subversion users that seem to like to write fairly complicated Apache configuration where they do the path-based authorization using rules within the Apache configuration. This allows them to tie the authorization more easily to groups in their LDAP system. We do not have any UI to support this, so the user would need to edit httpd. The installer will add two Windows services set to start automatically when the system starts.
CollabNet Subversion Server - the actual Apache Subversion server that the management console manages for you, and that your Subversion users will access. You must login to the CollabNet Subversion Edge browser-based management console and configure the Apache server before it can be run for the first time. The UI of the management console writes the needed Apache configuration files based on the information you provide.
This will open your browser to a local page that will detect when the server has finished starting. This will cause attempts to access the site via plain HTTP on port to be redirected to the secure port on Updates CollabNet Subversion Edge includes a built-in mechanism for discovering and installing updates. You should use this facility to install updates. The update mechanism will require you to restart the servers at the end of the process, but it will do it for you.
As of the 2. For the upgrade from the 1. To fix this problem: 1. Reboot so that your Apache service can pick up the change. About Subversion and CollabNet CollabNet launched the Subversion project in in response to the demand for an open standard for Web-based software configuration management that could support distributed development. CollabNet also provides the most widely used collaborative development environment in the world.
More than 1,, developers and IT projects managers collaborate online through CollabNet. The company is transforming the way software is developed by enabling organizations to leverage global development talents to deliver better products and innovate faster. Subversion is a registered trademark of the Apache Software Foundation. License - Subversion Edge 5. Subversion 1. Includes all Subversion command-line binaries. Requirements - Subversion 1.
Readme - Subversion 1. Platform and configuration 2. Installation notes 3. Support for CollabNet Subversion 4. Installation notes If you have an existing version of Subversion installed, examine the PATH environment variable after installation to make sure it points to the version of Subversion you want to use.
If you have previously installed the bit version of the command line client you will need to uninstall that version separately. License - Subversion 1.
Free Trial Subversion Hosting. Add-ons and Integrations for CollabNet Subversion. CollabNet Subversion Edge is known to work on virtually all Linux distributions and is informally tested on others such as Ubuntu and Fedora. When testing on bit Linux we have used the bit JVM. There are separate downloads for bit and bit Linux. Download the appropriate version for your distribution and kernel. Many recent Linux distributions include the shared libraries in an optional packages named "python-libs" or something similar.
This package needs to be installed. In addition, some Linux distributions may package some Python modules in optional packages, such as "python-xml". You may need some of these modules installed, particularly if you connect your Subversion Edge server to CollabNet TeamForge. In the preceding example, 3.
A tag is important for future work that might be necessary for patch creation or bug-fix releases. Another importance of a release tag is to facilitate investigation regarding issues in the associated release. If a patch or subsequent change of a tag is considered necessary, then you must create a branch. A branch is a copy of a location elsewhere in the repository and does not differ in composition from a tag. After a copy of the tag is made under the branches directory, you can check out the code and modify it as necessary.
When changes are complete, the new release is made from the branch and a corresponding tag is created. The current version developing under the trunk directory is version 2. The three previous releases of Project-A are 1. A problem is discovered in version 1.
The release build can then be made from the tag. For more information on directory structure conventions, see the section about the recommended repository layout in Version Control with Subversion at the following URL:. If you have existing projects that you want to manage in your repository, you can import them using the SVN client's import command:.
Make changes. Use the svn add , svn delete , svn copy , and svn move commands as needed to edit your files. Review changes through the svn status and svn diff commands.
Fix mistakes. You can revert and abandon changes using the svn revert command. Resolve conflicts. When they are resolved, mark them using the svn resolve command. Commit changes using the svn commit or svn ci command.
In a continuous integration development process, this workflow remains largely unchanged. Committed change sets tend to be smaller and occur more frequently than in a noncontinuous integration process. You must commit the active trunk or branch code for the target release so that the continuous integration system can perform an integration build. Avoid creating a personal branch with the intention of merging back to the main-line code base in the future.
0コメント