Git

From OrbSWARM
(Redirected from Subversion)
Jump to: navigation, search


In October 2014 the software repository was moved from Subversion (http://svn.lee.org/swarm) to Git (https://github.com/mct/orbswarm-svn).

The rest of this page is thus obsolete.


For New Users

If you are new to the project and want write-access to Subversion, please sign up for the mailing list and introduce yourself briefly. We'll be happy to give you the password to commit changes

Introduction

To track our source code, we have a Subversion server at .

Tools to help you with Subversion


SVN Hints from Luka

do emphasize/remember the need to update before commit, as it is an important part of what makes subversion work well, and a common answer to "what went wrong?" questions.

also if we're editing across different platforms (pretty safe assumption these days), be aware of end-of-line conversion policies. svn actually has some pretty good automatic heuristics for dealing well, and most users will never need to think about it, but whoever is admin'ing should try to learn the details and be ready to deal with the occasional trouble case.

and still think twice about *why* you are checking in binaries if you do so, as it is often best to keep "generated" code out of the tree, and true binary source data (e.g. pictures) segregated. why is this important to mention? svn will not eat your lunch nearly as or nor as often as other systems, but it 1. encourages bad habits by being "safer" and 2. will still eat it sometimes.

having a public-ish readonly user and commit access only for named authorized users is a good plan.

Cheatsheet from Matt

SETUP

- install svn client

(see above)

- checkout your local copy (only need to do this the first use)

svn co --username swarm http://svn.lee.org/swarm/trunk



DAY TO DAY

before you start:

- svn update

add a file or directory:

- svn add <file/directory>

delete a file:

- svn delete <file>

see what you've changed:

- svn status

- svn diff

rollback unwanted local changes:

- svn revert <file>

check it in:

- svn update <- always update before commit

- svn commit --username swarm -m "I changed foo and added bar" <-- note "-m" for update message (required)

this will prompt you for a password, which can be found on the private wiki here


How Lee does a backup of SVN

  • log into SSH as swarm
  • svnadmin hotcopy /home/swarm/svn/swarm /home/swarm/svnbackup-6-4-08
  • tar -czvf svnbackup-6-4-08.tgz svnbackup-6-4-08/
  • (then FTP it locally)




How to backup SVN by Ion

> It would be good if we made occational backups of the Subversion  
> repository.
> If someone could walk me through it, I'd be glad to undertake regular
> backups. I'm sure it's not too hard but I'd rather have someone  
> tell me how
> (or point me to valid instructions) rather than me take the time to  
> DIY.
>
> Lee

An initial backup can be made on the server where the repository  
resides with:

	svnadmin hotcopy <repository path> <backup path>

To make future backup you run the above again -- with a different  
backup path.  You can manage multiple backups with a script that  
comes with Subversion sources: tools/hot-backup.py.  This handles  
keeping several iterations of the backup around.  It takes the same  
parameters as svnadmin hotcopy:

	python hot-backup.py <repository path> <backup path>

You will probably prefer the script to the straight command.

The above is easy.  If space for backups is not an issue, use it.   
The downside of it is that each backup takes up as much space as the  
full repository.  If space is an issue it's slightly more complex  
(and needs SVN v 1.4).

Create a mirror repository:

	svnadmin create <backup path>

Tie the backup repository to the original repository.  Note that the  
arguments are the full URLs, not the local paths, and that <backup>  
is the first parameter unlike svnadmin.

	svnsync init <backup URL> <repository URL>

Periodically you synchronize the backup from the main repository like  
so.  Note that you only need <backup URL>.

	svnsync sync <backup URL>

This will keep the backup copy in sync with the original, and not do  
a full copy.  I think, though I'm not certain, that it might be  
slower than a hotcopy, but it can be run without needing to be logged  
into the server, and can work from one machine to another.

lurkingly,
Ion