Subversion Repository: HOWTO

Introduction

Terminology

1. Checkout - downloads a copy for the first time
2. Update - downloads your copy with any changes in the repository
3. Commit - uploads any changes you made in your copy to the repository
4. Import - upload - can be replaced by a combination of update/commit

repo - repository

depo - your copy

Windows Walkthrough

http://tortoisesvn.tigris.org/

This is a minimal but totally functional how to checkout from, and commit to, gpl.openqm in Windows using the Tortoise Windows Explorer shell extension. Think of Tortoise as a folder sync tool which pops up reconciliation screens where conflicts occur between people's edits.

The interesting bits of source code management jump out at you later when two people work on the same file at the same time.

• You commit a file which has also committed by someone else AFTER you checked it out
• You update your depo from repo and someone has committed changes to a file that you have already locally changed.

In these cases you get presented with opportunity to compare and reconcile the two edits in a neat side by side window.

Other tools

Visual Studio - http://ankhsvn.open.collab.net/

Eclipse - http://subclipse.tigris.org/

Netbeans supports it natively now too. <Diccon> Bean a life saver. (Can we have a few hints, Diccon?)

HELLO SUBVERSION in Windows

Installation

http://tortoisesvn.net/downloads

Might need a reboot

Checking Out

Right click on your desktop and choose SVN CHECKOUT

Fill in the details

URL? https://gpl.openqm.com/svn/qmvdb

Checkout Folder? D:\Documents and settings\steve\Desktop\TESTIT

Click OK

Do you want to create the directory? Yes

Do you want to accept the unsigned certificate? Yes

Wait while it downloads the whole repository

Finished: OK

After you click on the folder or refresh desktop with F5, the new folder TESTIT should have a big green tick over it indicating all synced with the repo

Subversion puts a hidden folder called .svn in any folder it is managing

Acquiring rights to commit

To commit you must have a username and password which is given by an admin with root perms on gpl.openqm.com with the following command where xxxxxxx is the username

htpasswd /etc/subversion/passwd xxxxxxxxx

Committing

1. Open the folder TESTIT
2. Create a file called testing.txt anywhere in the folder structure
3. Close the folder and notice that it has a big red ! on it showing that something is commitable
4. Right click on the TESTIT folder (or indeed any subfolder)
5. Choose SVN Commit
6. It shows a long list of files that it thinks could be committed - in your case just the testing.txt file - you have to check all files that you want uploaded or check Select All
7. It helps to add a message explaining why you are committing
8. Click OK
9. Enter your committers username and password
10. Screen showing upload progress
11. Click OK when finished and note that the red ! has changed back into a green tick

Committing Binary Files like VOC/ERRMSG

To subversion, VOC/ERRMSG (and other files? which?) are deemed to be "binary" rather like image files. Unlike ordinary source/text files, parallel edits on binary files from two people cannot (or rather should not) be merged. Conflicts, due to simultaneous edits outside of the repository, can only be resolved by picking one or the other person's file.

The tempting solution is to make these into directory files but this doesnt work - probably because a) the default file type isnt directory and b) performance.

The proper solution would be that these files are represented as ordinary directory files in the source code repository and that the required binary files are built thereof during the QM build process. Since only QM can build these files, the build process will first have to build QM and then use QM to build these files.

If you do not do follow one of the procedures below then when you finally come to UPDATE or COMMIT and someone else has also worked on the file in the meantime then you will be presented with the unpleasant choice of either losing your changes or trashing someone elses - on the all or nothing principle for binary files. Depending on how much work you have dont this could be mildly irritating or extremely inconvenient.

PRACTICAL SOLUTION FOR NOW

Do SVN UPDATE just before editing these files and do SVN COMMIT immediately afterwards.

1. Get a lock on the file (or more likely folder) that you want to edit
2. SVN UPDATE
3. Edit the file
4. SVN COMMIT
5. Release the lock on the file

There might be a combined LOCK&UPDATE command and a COMMIT&RELEASE command but I dont know it.

Command line

svn lock files -m "Reason for locking these files"

Tortoise