Revision Control II. - svn

Size: px

Start display at page:

Download "Revision Control II. - svn"

Thomas Andrews
6 years ago
Views:

1 Revision Control II. - svn Tomáš Kalibera, Peter Libič Department of Distributed and Dependable Systems CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics

2 Subversion Whole source tree is versioned Version numbers are integers (1,2,3, ) They version state of the whole source tree both files and directories using this single number But revisions can be mixed in working copy There are no branches and no tags Directories are used instead, employing copy-on-write repository storage mechanism This has also some drawbacks, i.e. branch merges cannot be fully recorded

3 Versioning Single version per repository Support for mixed versions Different files (and directories) in a working copy may come from different repository versions This happens naturally by committing changes (commit of a file does not mean update of whole repository) push and pull operations are separate This also can be forced by retrieving a file/directory of some earlier repository version Revision and other information can be obtained by 'svn info' command

4 Demo I

5 Subversion There is support for binary files Including binary diff for efficient storage of successive versions in the repository Saving network bandwidth For some extra disk space The working copy includes vanilla versions of latest repository files Disconnected operations: status (see what is modified), diff, revert, info Sending deltas on check-in

6 Subversion Commits are atomic Repository administration support for Backup hotcopy (repository copy) Migrating dump,load

7 Starting repository and working copy Create new repository svnadmin create Populate it with directories and files svn import New project only the default layout Create working copy svn checkout Metadata in.svn directories

8 Demo II

9 Branches and tags are ordinary directories No special support, just ordinary directories Typical repository layout /trunk /branches /tags /project1/trunk /project1/branches /project1/tags /project2/trunk /project2/branches /project2/tags

10 Work cycle Update working copy svn update Make changes, test Edit files svn add, svn delete, svn copy, svn move, svn mkdir Review changes svn diff, svn status Undo changes svn revert Merge others changes, resolve conflicts svn update, svn resolved Commit changes svn commit

11 Demo III

12 Tags Repository version (numeric) is in principle a tag, but does not have a human readable name Creating a tag with human readable name ( svn copy ) logically creates a copy of the files to be tagged From repository version (i.e. assigning a human readable name to a repository version), specified by repository URLs, fast From working copy (i.e. tagging a tree of files and directories with mixed versions), has to be committed

13 Branches Branches are again copies of files and directories They differ from tags only in the way developers use (and comment) them Created using svn copy like tags It is though highly recommended to start branches only from tags or trunk or branches The copy operation preserves history In the branch, file history goes beyond the branch root (time when the copy was created) Modifications done on the branch are however only visible there ( svn log v )

14 Branches check-out / traversal Normal mode branch is like a directory We have to remember to make changes only in particular directory To switch to another branch, we can check it out as usual Switching working copy Switching working copy to reflect different directory ( svn switch ) SVN will make the required branch appear in the current directory More efficient SVN can use diffs instead of copying all files

15 Diff and merge Diff (2-way) svn diff Compares two directory trees (including file addition, removal, etc) Merge svn merge Applies diff of two versions to the working copy Correspondence to what it means for branch merging is left to user The result is not committed automatically the user should resolve conflicts and commit, or svn revert

16 Diff and merge consequences for branching Flexibility Can merge only some changes at a time Can merge changes even from arbitrary branches (common root not required) Danger We must not merge same changes twice We must keep track of what we merge where Good place for this are commit messages

17 Branch merging best practices 1. Start with up-to-date working copy (no local modifications, ideally of assigned tag) 2. Check what would happen if merged ( svn diff or svn merge dry-run ) 3. Merge 4. Revert if needed svn revert recursive 5. Resolve conflicts 6. Commit changes with informative message (i.e. Merged changes r120:140 into the trunk )

18 Merging branches with renamed files Renaming happens (refactoring) Subversion does not support it svn move is just svn copy and svn delete The new file ancestry is lost Merging can now lead to loosing changes On the first branch, a file is modified On the second, it is renamed and kept old Merging the second branch to the first causes the changes to be lost (they remain in the history, but one has to detect it)

19 Side effects & what is good to know Commands operating on repository URL involve commit svn mkdir, svn copy, svn move, svn delete (when used with repository URL) Use svn status to see what we have modified Does not update anything svn revert reverts anything Not just file changes, but also deletion, creation, etc. But only uncommitted changes

20 Side effects & what is good to know svn cat Prints file of a given version (does not change the working copy) svn list Directory listing (does not change the working copy) Directory is relative to repository root svn cleanup Finishing interrupted transactions (based on metadata in.svn directories) Removes working copy locks ( svn status shows them as L ) NOT user created locks

21 Properties Files, directories, and revision may have properties Property is name-value pair of strings File and directory properties are versioned Revision properties are not SVN internal properties start with svn:, i.e. svn:log, svn:keywords, svn:executable, svn:mime-type, svn:eol-style, svn:needs-lock Property setting svn propedit, svn propset Internal properties guessed automatically Property querying svn propget very inefficient (linear search)

22 Locks Still needed to work with binary files Concurrent modifications on binary files cannot be merged (images, audio, slides) Locking svn lock Locks a file/directory Others then cannot commit changes Unlocking svn commit (unlocks automatically) svn unlock

23 Locks (2) Examining locks svn status o svn info Administrator options svnadmin lslocks svnadmin rmlocks Breaking locks by users (not lock owners) svn unlock force Stealing locks by users svn lock force

24 Locks (3) Aiding users to lock certain files svn:needs-lock File is updated as read-only A stricter locking policy can however be set-up by an administrator Hook scripts ( pre-lock, pre-unlock ) Actions can be triggered based on lock actions Good use is sending notifications by Hook scripts ( post-lock, post-unlock )

25 Authentication SVN server pulls authentication requests Based on issued svn command and on configuration (no authentication needed for publicly available repository) User credentials are cached by clients On the disk In systems that support it, they re encrypted using user s system password (Windows, MAC OS/X) Caching can be disabled

26 Local access to SVN repository Does not require specialized server Users need privileges for direct read/write access to repository Security issues File permission issues (UNIX) requires a dedicated group, correct umask, SGID (the same as cvs) Does not require administrator privileges on target machine

27 Remote access to SVN repository svnserve Separate user accounts, per-path privileges Unencrypted communication svnserver over SSH System user accounts, per-repository privileges SSH encryption Requires users access to repository (same issues as for local access) Apache + mod_dav_svn Separate user accounts, per-path privileges Apache authentication and encryption (HTTPS, SSL) Partially supports WebDAV/DeltaV HTTP extension Slower (stateless)

28 Repository data storage implementations BerkeleyDB Based on Berkeley DB engine (relational database) Platform dependent Its use in SVN has robustness issues (crashes of svn server, file system permissions changes) Should only be used when single user (Apache or svnserve without ssh) accesses the repository FSFS (native implementation) File-system based Atomicity achieved using file-system operations (rename/move) Bugs in earlier versions have lead to data loss, currently however assumed stable

29 Repository data storage implementations BerkeleyDB Based on Berkeley DB engine (relational database) Platform dependent Its use in SVN has robustness issues (crashes of svn server, file system permissions changes) Should only be used when single user (Apache or svnserve without ssh) accesses the repository FSFS (native implementation) File-system based Atomicity achieved using file-system operations (rename/move) Bugs in earlier versions have lead to data loss, currently however assumed stable

30 Repository directory structure Orthogonal to repository content Only partially editable by humans Configuration files Hook scripts shell scripts, templates with informative comments are contained in default installation /conf /hooks /db /format /locks /dav

31 Demo IV

32 Revision keywords Textual representation of a revision which can be used instead of revision number HEAD Latest revision in the repository BASE Revision number in working copy (before modifications) COMMITTED The latest revision in which the item changed and was committed (no larger than BASE) PREV COMMITTED-1 (before the last committed)

33 Tools/ GUI Tortoise SVN kdesvn svnx

34 Links SVN Book

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

Subversion. An open source version control system. W. Miah escience Rutherford Appleton Laboratory Subversion An open source version control system W. Miah (w.miah@rl.ac.uk) escience Rutherford Appleton Laboratory Agenda for today Need for source control; Subversion concepts; Working/local copy of a