Subversion - Revision history

imported>Huston: No more redmine

2018-02-23T16:43:26Z

No more redmine

← Older revision		Revision as of 16:43, 23 February 2018
Line 21:		Line 21:
	--tunnel-user=collaborator-username",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AA....		--tunnel-user=collaborator-username",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AA....
	Of course that should all be on one line, as all SSH keys are. This will let that user login, and tell Subversion who they are (even though the Unix account they'd all be using would appear the same). Then checkin histories will be tagged with the collaborator's name, even though there's only one Unix account accessing the actual repository.		Of course that should all be on one line, as all SSH keys are. This will let that user login, and tell Subversion who they are (even though the Unix account they'd all be using would appear the same). Then checkin histories will be tagged with the collaborator's name, even though there's only one Unix account accessing the actual repository.

	~~A newer, simpler method is to use [[Redmine]].~~

	[[Category:Software]]		[[Category:Software]]

imported>Huston: Redmine link, fsfs, update URL

2010-02-19T19:17:39Z

Redmine link, fsfs, update URL

← Older revision		Revision as of 19:17, 19 February 2010
Line 4:		Line 4:

	== Introduction ==		== Introduction ==
	Subversion is still a fairly young system, though it's now in widespread use in many places (including [http://www.sourceforge.net SourceForge]). It is itself an open source project, and you can find information about it on the Subversion website: http://subversion.~~tigris~~.org. An excellent source of information is the Subversion book, which can be viewed at http://svnbook.red-bean.com or purchased from O'Reilly or their resellers.		Subversion is still a fairly young system, though it's now in widespread use in many places (including [http://www.sourceforge.net SourceForge]). It is itself an open source project, and you can find information about it on the Subversion website: http://subversion.apache.org. An excellent source of information is the Subversion book, which can be viewed at http://svnbook.red-bean.com or purchased from O'Reilly or their resellers.


Line 12:		Line 12:

	=== Setting up a repository ===		=== Setting up a repository ===
	You can setup a repository on any machine that has Subversion installed. Please note that unless you're using 'fsfs' for the back-end, it is considered unsafe to store the repository on NFS due to the way locking is handled with Berkeley DB. Therefore, the repository should either live on a local scratch disk (and you'll have to back it up manually) or use a newer server which has 'fsfs' capabilities and use that as the back-end.		You can setup a repository on any machine that has Subversion installed. Please note that unless you're using 'fsfs' for the back-end, it is considered unsafe to store the repository on NFS due to the way locking is handled with Berkeley DB. Therefore, the repository should either live on a local scratch disk (and you'll have to back it up manually) or use a newer server which has 'fsfs' capabilities and use that as the back-end. Most hosts have a newer Subversion install already, which defaults to the 'fsfs' backend, so you can safely create repositories in your home directory.


	== FAQ ==		== FAQ ==
	=== How can I have a repository for a bunch of off-site collaborators? ===		=== How can I have a repository for a bunch of off-site collaborators? ===
	The ~~simplest~~ way to do this is to setup a single account for the repository or project, and use SSH+SVN. You configure the repository under that account, and have your collaborators mail you their SSH pubkeys. Then edit the file and add it to the account's ~/.ssh/authorized_keys file:		The old way to do this is to setup a single account for the repository or project, and use SSH+SVN. You configure the repository under that account, and have your collaborators mail you their SSH pubkeys. Then edit the file and add it to the account's ~/.ssh/authorized_keys file:
	command="/usr/bin/svnserve -r <repository location> -t		command="/usr/bin/svnserve -r <repository location> -t
	--tunnel-user=collaborator-username",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AA....		--tunnel-user=collaborator-username",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AA....
	Of course that should all be on one line, as all SSH keys are. This will let that user login, and tell Subversion who they are (even though the Unix account they'd all be using would appear the same). Then checkin histories will be tagged with the collaborator's name, even though there's only one Unix account accessing the actual repository.		Of course that should all be on one line, as all SSH keys are. This will let that user login, and tell Subversion who they are (even though the Unix account they'd all be using would appear the same). Then checkin histories will be tagged with the collaborator's name, even though there's only one Unix account accessing the actual repository.

			A newer, simpler method is to use [[Redmine]].

	[[Category:Software]]		[[Category:Software]]

imported>Huston: Overview of SVN, including some details for single-account multi-collab

2007-07-26T19:11:38Z

Overview of SVN, including some details for single-account multi-collab

New page

Subversion is a version control system which has gained in popularity lately as a replacement for the aging CVS. It incorporates most (if not all) of the good things about CVS, and fixes most (if not all) of the bad things about it.
{{stub}}

== Introduction ==
Subversion is still a fairly young system, though it's now in widespread use in many places (including [http://www.sourceforge.net SourceForge]). It is itself an open source project, and you can find information about it on the Subversion website: http://subversion.tigris.org. An excellent source of information is the Subversion book, which can be viewed at http://svnbook.red-bean.com or purchased from O'Reilly or their resellers.

== Using Subversion ==
Subversion should be installed by default on all Peyton machines, so you should be able to use it anywhere. Some machines have newer versions of the program than others (which is usually more important in terms of the repository itself, not the client accessing the repository).

=== Setting up a repository ===
You can setup a repository on any machine that has Subversion installed. Please note that unless you're using 'fsfs' for the back-end, it is considered unsafe to store the repository on NFS due to the way locking is handled with Berkeley DB. Therefore, the repository should either live on a local scratch disk (and you'll have to back it up manually) or use a newer server which has 'fsfs' capabilities and use that as the back-end.

== FAQ ==
=== How can I have a repository for a bunch of off-site collaborators? ===
The simplest way to do this is to setup a single account for the repository or project, and use SSH+SVN. You configure the repository under that account, and have your collaborators mail you their SSH pubkeys. Then edit the file and add it to the account's ~/.ssh/authorized_keys file:
command="/usr/bin/svnserve -r <repository location> -t
--tunnel-user=collaborator-username",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AA....
Of course that should all be on one line, as all SSH keys are. This will let that user login, and tell Subversion who they are (even though the Unix account they'd all be using would appear the same). Then checkin histories will be tagged with the collaborator's name, even though there's only one Unix account accessing the actual repository.

[[Category:Software]]