• Abstract and Figures
• Public Full-text

Source Code Version Management with SVN Carla Guillen Georg Hager Code Version Management We usually have a team of developers working on a code. Problems: • Central repository is single point of failure. • Working on the repository requires a connection to the server. • All project participants need full read/write access to the server. • All commits affect the complete repository. Famous tools which helps us deal with these problems: • CVS - Very old and deficient. Not so reliable. • Subversion - CVS replacement. • Git – Fast version control system for very large projects. • Others: Mercurial, monotone, bazaar ... SVN: Introduction • SVN stands for Subversion • Link: http://subversion.apache.org/ • Free/open source version control system • Centralized version control system • Operates across networks • Source code is accessible by all developers and stored in a repository • One-time generation of a SVN "project" from original code • One repository can accommodate many projects • Available for Unix/Linux and Windows systems – Special commands for cross usage SVN: Introduction • Options for repository access: – dedicated server, – separate password database directory on arbitrary host, – access via ssh, – local directory on development machine with group access for all developers • Repository contains the full, detailed history of each source file (who has changed what and why) • Limited practicality for binary data • Uses a copy-modify-merge model instead of lock-modify-unlock • What is SVN not? – Data backup system – Generic Distribution system Functionality Single-user functionality: • Change control/mgmt in source code. • Introduction of new files / changes to existing files. • Automatic management of running version numbers on all project files. • Return to any previous revision is always possible. • Tagging of "releases", i.e. current status of a whole project. • Generation of separate branches for independent development Multi-user functionality: • Coordination of complex projects with more than one developer. • Several developers can work with the code simultaneously • No "file locking": several developers can work at the same file simultaneously. • SVN recognizes conflicts and reports them to users • SVN is no substitute for a sensible development strategy! Glossary • Repository: Database, containing the complete source code history of the project. • Revision: Current state ("snapshot") of a file or group of files in the repository. • Sandbox (working copy): Private extract of the project source code from the repository for one developer. • Check out: Request a working copy of a project from the repository. • Commit (check in): Introduce changes on files in a sandbox back into the repository (repository is changed) • Log Message: Developer's comment that is stored together with the changes of a commit. • Update: Synchronize a developer's private sandbox with the current repository (sandbox is changed). • Conflict: Two developers make changes at the same point in the same file. Must be resolved manually. • Trunk or HEAD: the up-to-date version of the SVN. (It’s usefull to call the containing directory “trunk”. Example of development process. 1 2 3 Repository checkout commit commit update commit 1 2 3 3 Sand- 1 box commit update checkout commit commit Sand- 3 1 1 1 box 1 update checkout 3 Sand- 2 box 1 SVN Options and commands • General syntax of svn commands: svn <command> <command parameters> <switches> Example of commands: add, commit, checkout, update, etc... Example of switches: --dry-run, --quiet (-q), --revision (-r). • Switches are dependent on the command. • Switches might have parameters themselves. • Important switch: -m “message” or use --message “message” • Repository administration programs svnadmin and svnlook use the same syntax Create a repository • Create the repository: svnadmin create --fs-type fsfs /path/to/repository/ • This creates a virtual directory structure svn mkdir file:///path/to/repository/trunk -m “trunk” svn ls file:///path/to/repository/ • You can manage your virtual directory using the unix- like standard commands svn mv <from> <to> -m “msg” svn cp <from> <to> -m “msg” svn rm <url path> -m “msg” Configure the repository • After creating the repository, access controls may be altered: – Open conf/svnserver.conf found inside the newly created repository folder • Common values to alter: – anon-access • access control for non authenticated users • better to set it to none (anon-access=none) – auth-access • access control for authenticated users • will need se it to “read” or “write” (auth-access=read) Importing your project • Create your dir: svn mkdir file:///path/to/repository/trunk /myproj -m “dir for my project” • Import the project files: cd /path/to/work/myproj Importing your project NOTE! Before importing a project clean all the files which should not be version-controlled, this usually include compiled code and binaries. svn import file:///path/to/repository/trunk/myproj -m “importing project” This will import your files to your newly created myproj Check what you have imported: svn list –R file:///path/to/repository/trunk/myproj Use common layout • As an advice you should use the following directory tree for your repository – repos/trunk/ – repos/branches/ – repos/tags/ • trunk will hold the main line of development • branches contains branch copies • tags contains tags copies Checkout and existing project Also to work on your files, or someone else’s files, you will need a copy. • Create your working directory mkdir /path/to/work cd /path/to/work/ • Get a working copy with URL: svn checkout https://svn.somelink.de/repository/project • SSH checkout: svn checkout svn+ssh://url/path/to/project/ • Local machine checkout (file as url): svn checkout file:///path/to/project/ • With the previous cases you copy the folder „project“: $> ls /path/to/work project • In general you can also specify a target directory: mkdir /path/to/work/project/ svn checkout <ssh or url>/path/to/project/█ /path/to/work/project/ Update your sandbox You want to get the changes your team has committed (latest revision of the code). Let‘s assume you have no conflicts to resolve (files to update have not been modifyied by you). cd /path/to/work/project/ svn update Files which have been modified in the repository will be copied into your project folder. Incoming files are listed with „U“ (Updated): U main.c Please note: your sandbox version will be overwritten, but still available on svn. You can always obtain a previous version which has been committed by typing: svn update –r 4 Commit • Before a commit, always check the status of your sandbox. It‘s not mandatory but a good practice. svn status M myfile.cpp svn commit –m “updated myfile.cpp” sending myfile.cpp … If there was a conflict svn will display at the end: svn: Out of date: “myfile.cpp” This is Okay. SVN has detected a that the file you want to commit has a change since you last updated it. Managing conflicts • Try updating the file. That means getting the changes. If the conflict does not appear on the same lines you have modified: You are done. svn update G myfile.cpp • If you open your file you will see the changes incorporated. Check if you agree with the merged version and commit again. SVN Your local file Your local file Managing conflicts • You used the svn update command, but the conflicts are on the same lines. • SVN tells you that myfile.cpp has a conflict: svn update C myfile.cpp • SVN asks for input for the user: “put back”, “full own file”, full repository file. If you choose “put back” you will not update the file but you get two additional files. myfile.cpp.r5 and myfile.cpp.r6 • You can compare the files with an editor and decide for the changes that should be committed to the repository. Managing conflicts • What are your options? – Throw your changes and update those from the colleague. – Keep you changes and dump what the colleague did. – Merge both versions into a single one. Managing conflicts • Throwing away your changes und updating your colleagues’ work: svn revert myfile.cpp This is the easiest procedure in terms of svn managing. You don’t need to commit this file. But you loose all your changes. SVN Your local file Your local file Managing conflicts • Keep your changes and throw away what the colleague did. Copy myfile.cpp.mine to myfile.cpp and then tell subversion that you have resolved the conflict. svn resolved myfile.cpp SVN • The resolved command will clean all the special files that were created. Commit your file as you SVN normally would. Your local file Managing conflicts • You have to manually merge both files. Use an editor which allows you to compare them. The merging occurs on your local myfile.cpp • Mark as resolved like in the previous slide and commit. SVN Your Your local file SVN local file Adding, Renaming and deleting a file • To add a file: svn add • Rename the file using the command svn mv. svn mv source.txt destination.txt • To delete a file svn delete • Commit! and you are done • Files in svn are not really deleted, they can be “revived” by reverting to the version they had before deletion. Advanced Topics: Release Tags File A File B File C File C File E 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 4 4 5 5 5 6 6 6 7 7 8 9 Advanced Topics: Release Tags • You have arrived to an acceptable version of your code and want to make a release. The trunk of HEAD on svn can be „tagged“ with a release tag to have these version always available. cd /path/to/project/ svn mkdir tags A tags svn copy trunk/ tags/conv-1.0 • Then simply commit this copy. svn commit -m “tagged version conv-1.0” tags/ • Internally the svn’s database doesn’t make a copy but remembers that conv-1.0 refers to the project at a given time.

Load more

  29

Copy Link