Svn exercises
Jump to navigation
Jump to search
SVN for users
Copyright Notice
Copyright © 2004-2023 by NobleProg Limited All rights reserved.
This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.
1. Prepare 'slideshow' project in subversion repository:
a) create proper catalogs and move files (trunk, tags, branches)
b) create catalog 'repos' for all repositories
(svnadmin create [user-home-folder-path]/repos, svn import ... file:///[user-home-folder-path]/repos/slideshow)
c) export 'slideshow' to working copy and name it 'wc1'
(svn checkout)
d) list content in repo
(svn list)
2. Create another copy of 'slideshow' repo and call it 'wc2'.
3. In 'wc1':
a) manage files in catalogs:
- pictures (pic)
- java script (js)
b) check 'wc1' status (svn status, svn diff)
c) send changes to repository (svn commit)
d) check 'wc1' status
e) add new file "logo5.html", copy from 'logo.html'
and change types of pictures rotation
f) check 'wc1' status again
g) push changes to repo
h) check 'wc1' status
4. Make 'wc2' actual and analyze messages (svn update)
5. In 'wc2':
a) create new empty folder "html" (svn mkdir):
- check 'wc2' status and analyze messages
- push changes to repo
- check status
b) place all '.html' files in folder "html"
- check status, but don't push changes yet
c) add new file "logo_jq2.js", copy from "logo_jq1.js"
and change values of parameters (delay, speed, timeout)
for rotation type 'slideY'
- check 'wc2' status and analyze messages
- push changes to repo
- check status
6. Change 'wc1':
a) cut 'css' code from 'logo.html' into new file "logo.css" and link it:
- check 'wc1' status and analyze messages
- push changes to repo and analyze messages
b) refresh 'wc1' and analyze messages
c) solve any problems (svn resolve, svn revert)
7. Change 'wc2' (update it first):
a) remove file "logo5.html"
- check 'wc2' status and analyze messages
- push changes to repo
b) refresh 'wc2' and analyze messages
c) change look of table, in "logo.css" add solid border
- check 'wc2' status and analyze messages
- push changes to repo
- check status
8. Apply changes:
a) in 'wc1':
- update it
- in "logo.css" add dashed border
- check status
- push changes to repo
- check status
b) in 'wc2':
- DO NOT update it yet
- check status
- in "logo.css" add dotted border
- push changes to repo and analyze the situation
- check status
- what can we do now?
8.1. Make binary conflict with file 'logo.png', postpone it and resolve it.
9. Check the difference between versions of file "logo.css" (svn diff)
a) for one revision
b) between revisions 6 and 8
10. Check who and when added file "logo.css" (svn annotate, svn blame, svn praise, svn log)
11. Copy file "logo3.html"(use svn cp), name it "new_logo3.html". Check status.
Next move "logo3.html"(svn mv) and change the name to "old_logo3.html".
Again check the status. Compare the results.
12. Check what has changed in "logo_jq1.js" (svn log)
a) globally
b) between 2 revisions, for example 4 and 7
13. Check info about file "logo.css" from logs (svn cat)
a) globally
b) just revision number 6
14. Modify our project, add more pictures:
a) in 'wc2':
- in file "logo_jq1.js" in row 6 add the line from below:
$('div').append('<img src="../pic/Frog.png"/>');
- push changes to repo
b) in 'wc1':
- DO NOT update yet
- in file "logo_jq1.js" in row 6 add the line from below:
$('div').append('<img src="../pic/Duck_svn.png"/>');
- push changes to repo
15. Build(deploy) new version of project (svn export)
16. Use our time machine and go back to version 4. Check the status.
Go back to the future and check status again (-:
17. Create new branch with name 'wc3_branch1' (svn copy, svn checkout)
a) in 'wc3_branch1' change files:
- logo1.html
- push changes to repo
- logo.css
- push changes to repo
- check logs
b) in 'wc1' change file:
- logo.css
- push changes to repo
- check logs
18. Merge changes from trunk into 'wc3_branch1' (pwd, svn merge)
19. Merge 'wc3_branch1' back to trunk (svn merge)
20. Resurrect file "logo5.html" in 'wc1' (svn revert?, svn update?, svn checkout?)
21. Create tag with name 'v1.0' (svn copy)
22. Use GUI to make changes:
a) add new file to repo
b) move existing file in different folder
c) remove file from repo
d) make a conflict and solve it
SVN advanced and for admins
1. Configure authorized acces to repository via 'svn://' protocol a) prepare catalog 'tempor' - with structure of folders: trunk, branches, tags - in trunk: component1, component2, common - add files in each project(module) - component1/co1, component2/co2, common/co/co3 b) prepare connection via 'svn://' protocol: - sudo svnadmin create /home/reactions_svn - configure all related files (authz, passwd, svnserve.conf) - start 'svnserve' daemon c) prepare users and permissions: - sudo addgroup svnreactions - sudo adduser james - sudo adduser neil - sudo chmod g+rwx -R /home/reactions_svn - sudo chown :svnreactions -R /home/reactions_svn - apply 'svnreactions' group to james and neil: -- sudo mcedit /etc/group d) import project to server: - svn import ~/tempor svn://localhost/components -m "initial commit" - test the connection as james and neil
2. Restrict access: a) to tags: allow only James to make and modify release tags (use '~' negation) b) on file path (co1), James read and write, but Neil only read c) allow James and Neil to read and write trunk
3. Changing log message by svnadmin admin.ppt https://training-course-material.com/training/Subversion_for_Administrators#changing_log_messages_.E2.8C.98
4. Create changelog in 'html' file with changes: - between revisions 11 and 14, - include actions and revision number, - group by day, - put text 'Breaking changes' in title tag, - find and apply 'css' file provided by command suggested below (svn2cl)
5. Make xml file with list of repo files in 'wc2', but only from subdir 'html' - save it as 'repolist.xml' (svn list)
6. Add html comment "Ignore me completely" to 'logo.html'. - Don't commit yet, but look at the repo with advanced revision specifiers (keywords, dates) (svn diff, svn log) - verify revisions from 3 to 8 for the whole repo (svnadmin)
7. Create a conflicted path in 'wc1' - during 'svn update' postpone the conflict - solve it with changes from 'wc1' (svn resolve)
8. Look at the repository in 6th rev in 2 ways: - use 'svn up' - use 'svn cat' What is the difference? When would you like to use which one?
9. 10. Hooks admin.ppt https://training-course-material.com/training/Subversion_for_Administrators#Exercises_.E2.8C.98 11. Set up 'meld' as a diff tool for merges and conflict resolution (svn option) - test it with conflicted path and 'svn up'
12. Properties - versioned for dirs and files, not versioned for revisions svn propset, svn propedit(better, we can see old value), svn propdel, svn proplist -v, svn propget, svn commit (...) --with-revprop "test-results=all passing" a) set property on 'logo1.png' file in 'pic/' (use 'svn propedit'): - copyright '(c) NobleProg Ltd' - find it via 'svn proplist' b) set property on folder 'js' (use 'svn propset'): - 'internalTaskID:issue1234' - find it via 'svn propget' c) 'svn:externals' - allow to checkout diffferent pieces of repo in one go: - create at least 3 revisions for all projects in /home/repos_svn - as harry set property 'svn:externals' on project 'component2' with 'svn propedit': common/co1 svn://localhost/common common/co2 -r3 svn://localhost/common common/co/co3 -r2 svn://localhost/common/co - as sally do 'svn up' and 'svn checkout' into new 'wc_component2'
13. Branch exercise - Common Branching Patterns
13.1. Release Branches (life cycle: code, test, release, repeat)
I. Commit all new work to the trunk: new features, bug fixes, etc.
II. Copy trunk to a 1.0 release branch. ( /trunk to /branches/1.0 )
III. Continue to work in parallel. One team tests the release branch,
another team continues new work on /trunk. Port bug fixes back and forth as necessary.
IV. Tag and release. After tests copy /branches/1.0 to /tags/1.0.0, and give it to customers.
V. Maintain branch over time. More bug fixes can become a 1.0.1 release: /branches/1.0 to /tags/1.0.1
New 2.0 release branch can be created, tested, tagged, and released.
After some time, we have a number of release branches in “maintenance” mode,
and a number of tags representing final shipped versions.
13.2. Future Branches (exercises 17-19 from above)
13.3. Vendor Branches - maintain custom modifications to third-party code in your own version control system.
Vendor branch - directory tree in our own version control system that contains
information provided by a third-party entity (or vendor).
Vendor drop - each version of the vendor's data that we decide to absorb into our project.
Benefits:
- members of our project never need to question whether they have the right version of the vendor's data
- we can store our custom changes to it in-place-we have no more need of an automated (or worse, manual)
method for swapping in our customizations
svn import /path/to/libcomplex-1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
-m "importing initial 1.0 vendor drop"
svn copy http://svn.example.com/repos/vendor/libcomplex/current \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
-m "tagging libcomplex-1.0"
svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/calc/libcomplex \
-m "bringing libcomplex-1.0 into the main branch"
HINTS:
Create a branch or tag ( svn copy URL1 URL2 )
Switch a working copy to a branch or tag ( svn switch URL )
Synchronize a branch with trunk ( svn merge trunkURL; svn commit )
See merge history or eligible changesets ( svn mergeinfo SOURCE TARGET )
Merge a branch back into trunk ( svn merge --reintegrate branchURL; svn commit )
Merge one specific change ( svn merge -c REV URL; svn commit )
Merge a range of changes ( svn merge -r REV1:REV2 URL; svn commit )
Block a change from automatic merging ( svn merge -c REV --record-only URL; svn commit )
Preview a merge ( svn merge URL --dry-run )
Abandon merge results ( svn revert -R . )
Resurrect something from history ( svn copy URL@REV localPATH )
Undo a committed change ( svn merge -c -REV URL; svn commit )
Examine merge-sensitive history ( svn log -g; svn blame -g )
Create a tag from a working copy ( svn copy . tagURL )
Rearrange a branch or tag ( svn move URL1 URL2 )
Remove a branch or tag ( svn delete URL )
14. (EXPERIMENTAL feature) Can we "git stash" in subversion? Yes, we can (-; 14.1. As 'wc1' change 1 file (logo2.html) at the top of it. Make the revision. 14.2. As 'wc2' don't "svn up". Change 2 different files (logo.html, logo2.html) and make sure you've changed 'logo2.html' at the very end of it. Don't commit yet, do "svn st -uv". Hide local changes temporarily (svn x-shelve) and do "svn up". Bring shelved changes back (svn x-unshelve) and make a revision.
15. Do "cherry-pick" on new feature branch. Branch should have 3 revisions. We want only the middle one (2nd).
SVN Admins additional exercises
1.0. New svn version (source: http://tecadmin.net/install-subversion-1-9-on-ubuntu/# ) 1.0.1. Add new resource in ubuntu sudo sh -c 'echo "deb http://opensource.wandisco.com/ubuntu `lsb_release -cs` svn19" >> /etc/apt/sources.list.d/subversion19.list' sudo wget -q http://opensource.wandisco.com/wandisco-debian.gpg -O- | sudo apt-key add - sudo apt-get update 1.0.2. Remove old and install new sudo apt-get remove subversion sudo apt-get install subversion 1.1. Fix the wc cd wc1 - check status of repo svn st -- fix it svn upgrade - check history of repo svn log, svn list -- fix it svn info svn relocate - prep bash script to similarly fix automaticaly wc2 and wc3 1.2. Fix wc2 with local uncommited changes cd wc2 - add html comment tag in file 'logo2.html' ( <!-- comment --> ) - check status of repo -- fix it -- do status again -- what can be done? how to fix it? (svn up)
