Subversion. An open source version control system. W. Miah escience Rutherford Appleton Laboratory

Transcription

1 Subversion An open source version control system W. Miah escience Rutherford Appleton Laboratory

2 Agenda for today Need for source control; Subversion concepts; Working/local copy of a repository; Object history; Branching and merging; Repository administration; Server configuration; escience Subversion service.

3 Why version control? 1. Standard software engineering practice; 2. Aids managing of large projects; 3. Centralised repository instead of many copies scattered everywhere. Easier to back up; 4. Help manage change (new versions, bug fixes, new features); 5. Ability to roll back to previous (working) versions of code.

4 What can be version controlled? 1. Source code (C++, Java and shell scripts); 2. Documentation; 3. Configuration files; 4. Binaries and data files. Not recommended as they can be re-produced by source code and configuration files; 5. MS Word documents using TortoiseSVN.

5 Architecture of Subversion 1. User has a local copy of the repository; 2. This is accessed via http(s), svnserve or file://; 3. For security, it is important to use a secure protocol (e.g. https or ssh); 4. Before changing the local copy, it is important to synchronise with the main repository to avoid working with out of date files.

6 Local copy of repository Subversion uses URLs to identify files and directories. To check out a repository: $ svn co A calc/makefile A calc/integer.c A calc/button.c Checked out revision 56. The A indicates that it has added a file.

7 Local copy of repository The files can then be changed. To obtain the status of the current directory: $ svn st M integer.c The M indicates the file has been modified. The command svn diff will print what has changed. To synchronise the change with the main repository: $ svn ci -m bug #234 fixed Sending integer.c Transmitting file data Committed revision 5. Commits are atomic all or nothing.

8 Local copy of repository Another user can then obtain the change: $ svn up U integer.c Updated to revision 5. Subversion knew that integer.c had been changed no need to specify file name. Can be applied to directories and sub-directories. Revision numbers are global even if a single file has changed, so revision 1 of calc.c may be the same as revision 3 of calc.c

9 Local copy of repository A versioned file can have the following status: 1. Unchanged and current; 2. Locally changed and current (svn ci); 3. Unchanged and out of date (svn up); 4. Locally changed and out of date (svn revert). Before making changes, always update svn up Subversion will merge. To get a status of the current directory, use svn st

10 Local copy of repository To get an un-versioned copy of a directory, use the export option: $ svn export Additional commands: $ svn add newfile.sh $ svn rm oldfile.c #removed from head version $ svn cp oldfile.c new.c $ svn mv parse.pl xml_parse.pl

11 Multiple copies of repositories can cause conflicts: $ svn up C bar.c Update to revision 21. Object conflicts The C implies conflict. Svn then creates three files: filename.mine your changes filename.r{oldrev} without your changes filename.r{newrev} version from latest revision

12 filename highlights the conflicting parts: <<<<<<<.mine my changes ======= her changes >>>>>>>.r2 Once conflict has been resolved, use: $ svn resolved filename $ svn ci -m resolved conflict Or to discard your changes: $ svn revert filename Object conflicts

13 Examining history To show log message: $ svn log [-r <revision>] To show difference: $ svn diff Display contents of certain revision: $ svn cat [-r <revision>] file List contents of certain revision: $ svn list [-r <revision>]

14 Branching and merging Branches are created for forking projects this allows different versions of the project to evolve in parallel. Typical versioned directory structure: Tags allow the creation of snapshots of projects useful to snapshot a working version or release.

15 Branches Simply copy the trunk into a new directory: $ svn cp \ -m version snapshot Committed revision 12. This copies the version history as well as the files. Then check it out to create working copy: $ svn co A my-calc-branch/makefile A my-calc-branch/integer.c

16 Branches To include changes from the trunk to your branch, use the merge command: $ svn merge \ branches/v1.2 U branches/v1.2/integer.c $ svn ci -m ported change from trunk

17 Branches Once work on branch is completed, changes can then be merged into trunk; However, work has also been carried out on trunk, so we do not want to remove these changes we only want to merge work in branch since its creation; Assume revision 120 is traced to the creation of branch, and assume revision 150 of the current trunk; Then to merge the branch into trunk, we use:

18 Branches $ svn merge -r 120:150 \ This will update files in the main trunk. Commit if changes are valid and revert if not (assuming current working directory is trunk).

19 Repository administration The repository itself stores the versioned data and is accessed via a number of protocols. This is of interest to administrators and not users, but that doesn t mean you can leave right now! Decide whether you want to create repositories for projects, departments or groups. If a number of projects are contained within a repository, it is easier to share data. It is recommended that the repository be hosted on a local file system and not on NFS and be accessed via the methods available.

20 Repository administration Feature Sensitive to interruptions Usable over network FS Disk usage Directories with many files Large commits Maturity Large check out Berkeley DB Very No Larger Slower Slower Mature Faster FSFS Not very Yes Smaller Faster Faster Not so Slower

21 Repository administration To create a repository: # svnadmin create /var/svn/repos This creates: conf/ - configuration files to set ACLs dav/ - used by mod_dav_svn Apache module db/ - data store for versioned files format version number of repository layout hooks/ - scripts that are triggered during events locks/ - store for lock files

22 Server administration Repository needs to be served to clients as a local one is not very useful. Can use a number of well established protocols. svnserve; svnserve tunnelled over SSH; HTTP; HTTPs;

23 Server administration svnserve -Network protocol is stateful and no need to create accounts; -Traffic is not encrypted; -Password is stored in clear text and no logging of any kind. Summary: not very good.

24 Server administration svnserve tunnelled over SSH -Use existing UNIX accounts; -All traffic is obviously encrypted; -No logging of any kind; -Only one choice of authentication (asymmetric encryption SSH keys); Summary: reasonable.

25 Server administration Apache HTTPs -A number of authentication methods (certificate, username/password, WebAuth Kerberos cookie); -No need to create system accounts; -Full Apache logging; -Traffic obviously encrypted; -Repository browsing using the web browser; Summary: slower than svnserve, but ideal when configured with WebAuth (Kerberos)

26 escience Subversion service We are offering a Subversion service to members of escience. Further information can be found at: Repositories are served using svnserve tunnelled over SSH. Will need ssh public key can be generated using puttygen and secure using pass phrase! - important; to me and confirm fingerprint over the telephone or in person; Run putty or ssh agent with private key loaded; Authentication via certificates is planned for the future.