Version 1.4 | Version 1.5 | Version 1.6 |
svnsync, a new repository mirroring tool | Merge tracking | Repository root relative URLs |
| Sparse checkouts | |
| Detection of tree conflicts | |
| Filesystem storage improvements | |
Improved interactive conflict resolution | ||
Logging support for svnserve | ||
New public HTTP URI syntax for examining history |
NOTE: Support till version 1.4 stopped
Svnsync
This tool provides the ability to replicate history from one repository to another. The replication can happen all at once, or can be done incrementally through repeated 'sync' operations. Because the tool uses the abstract network (RA) API, the source and destination repositories can be local, remote, or any combination.
Binary Delta Encoding Improvements (client and server)
Subversion uses the xdelta algorithm to compute differences between strings of bytes. The output of this algorithm is stored in a custom format called 'svndiff'. svndiff data is what's stored in the repository to represent the difference between successive versions of files, and svndiff data is also transmitted over the wire between client and server (e.g. during updates and commits.)
New subcommand switches(1.4)
svn blame --force
Displays the output of blame, even if the file is binary.
svn merge/blame -x
Merge and blame commands can now pass options to an external diff3 program.
svn diff/merge -c/--change
You can now simply write -c N to view or merge a single revision, instead of the cumbersome -r N-1:N.
svn diff --summarize
Prints only the list of changed files, in the output format of 'svn status'. This lets you retrieve summaries of changes directly from a repository, whereas 'svn status' operates only on the local changes of your working copy.
svn diff -x [-u | -b | -w | --ignore-eol-style]
The diff engine internal to Subversion can now ignore whitespace and eol-style when computing the diff.
Merge tracking (foundational) (client and server)
Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.
Sparse checkouts (client and server)
Many users have very large trees of which they only want to checkout certain parts. In previous versions of Subversion, checkout -N was not really up to this task. Subversion 1.5 introduces the --depth option to the checkout, switch, and update subcommands. This option replaces -N, and allows users to construct working copies containing just what's needed, leaving out everything else.
Depth overview
Each directory now understands the notion of depth, which has four possible values: empty, files, immediates, infinity. The values are defined as follows:
empty | Updates will not pull in any files or subdirectories not already present. |
files | Updates will pull in any files not already present, but not subdirectories. |
immediates | Updates will pull in any files or subdirectories not already present; the new subdirectories will have depth-empty. |
infinity | Updates will pull in any files or subdirectories not already present; the new subdirectories will have depth-infinity. Equivalent to today's default update behavior. |
The --depth option sets depth values as it updates the working copy, tweaking new subdirectories' depth values as described above.
Affected commands:
checkout
switch
update
status
info
Interactive Conflict Resolution (client)
Conflict resolution is now done interactively by the command-line client for the update/switch/merge subcommands, and the client library offers a callback function so other clients can do similarly.
Here's an example using the command-line client:
$ svn up
U contrib/client-side/svnmerge/svnmerge_test.py
Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: s
(p) postpone - mark the conflict to be resolved later
(df) diff-full - show all changes made to merged file
(e) edit - change merged file in an editor
(r) resolved - accept merged version of file
(mf) mine-full - accept my version of entire file (ignore their changes)
(tf) theirs-full - accept their version of entire file (lose my changes)
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: tf
G contrib/client-side/svnmerge/svnmerge.py
Updated to revision 25685.
Changelist support (client)
The Subversion client now contains the notion of a changelist: a group of files which are associated with a chosen name. This becomes especially useful when working on several different set of files within the same working copy. Instead of having to remember each file in each set, Subversion 1.5 will allow you to associate a changelist with each set of files. Most commands which take a set of files as targets will now also accept the --changelist option, which filters those targets based upon the members of the changelist. Changelist membership can be edited using the newchangelist subcommand.
Copy/move-related improvements (client and server)
A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.
Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to 'foo', and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file 'bar', and unversion the file 'foo' (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally's point of view, her changes seem to be lost; the newly added 'bar' file has the older content, and the file 'foo' has been taken out of version control.
In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn't send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally's 'foo' file is copied to 'bar' (with local edits intact!).
In theory, this is the best-case scenario. There are a few caveats: this "proper copying" of existing working-copy resources only works on files, not (yet) on directories. Also, if an incoming move-operation deletes 'foo' before it attempts to copy it to 'bar', then the copy will fail, and the client reverts to the old behavior of fetching a pristine copy of the file from the repository.
Command-line client improvements (1.5 )
New "resolve" subcommand replaces "resolved"
A new resolve subcommand replaces the "resolved" subcommand (the latter is deprecated, but still present for compatibility). The new subcommand takes a --accept=orig|mine|repo option to select which version of a file to retain (which means Subversion now supports batch-style conflict resolution).
Create intermediate directories if asked
Add, mkdir, copy, and move take a new --parents option, which makes intermediate directories as necessary to create the destination path.
New --keep-local option retains path after delete.
Delete (remove) now takes a --keep-local option to retain its targets locally, so paths will not be removed even if unmodified.
Commit now takes a --with-revprop option.
Commit now takes a --with-revprop option allowing one to set revision properties
Repository root relative URLs (client)
$ svn SUBCOMMAND ^/
$ svn SUBCOMMAND ^/PATH
Detection of tree conflicts (client)
Subversion 1.6 recognizes a new kind of conflict, known as a "tree conflict". Such conflicts manifest at the level of directory structure, rather than file content.
Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved.
Note that Subversion is still treating renames as a "copy+delete" operation, so file renames causing tree conflicts can only be detected in terms of file additions and deletions. Because of this, false positives during tree conflict detection are possible.
To facilitate tree conflict detection, attempting to commit the deletion of a file which has already been deleted in the HEAD revision now causes an error. In Subversion 1.5, this was treated as a no-op, potentially resulting in "empty" revisions which contained no changes.
Filesystem Storage Improvements
Subversion 1.6 contains several improvements to both the Berkeley DB and FSFS backends. These are designed to improve storage space, and can result in drastically smaller repositories. These changes include:
Improved interactive conflict resolution (client)
Interactive conflict resolution supports new display-conflict, mine-conflict and theirs-conflict options.
Here's an example using the command-line client:
$ svn update
U Makefile.in
Conflict discovered in 'configure.ac'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: mc
G configure.ac
Updated to revision 36666.
$
Sparse directory exclusion
In Subversion 1.6, the --set-depth parameter to svn update has grown a new value—exclude. This value tells Subversion to exclude the target from the working copy, immediately and until further notice. Prior to Subversion 1.6, if a directory could not easily be removed from a working copy. If it was deleted without the help of Subversion, it would return on the next svn update. If it was deleted with svn delete, the directory remained as a local modification forever. (Unless, of course, it was accidentally committed.) The new exclusion mechanism in Subversion 1.6 fixes both these problems.
Note that if you exclude a versioned directory that has some unversioned files in it, or some files with local modifications, Subversion handles this situation gracefully. All the files that aren't safe to delete, Subversion leaves around, and of course leaves any intermediate directories required to reach those files, too.
Logging support for svnserve (server)
svnserve now accepts the --log-file option which allows to specify the file used for logging.
New public 'historical' HTTP URI syntax for mod_dav_svn (server)
mod_dav_svn now supports a new public URI syntax for examining older versions of files or directories. The intent here is to allow users to examine history without the use of an svn client, and to make it easier for 3rd-party tools (e.g. code-review services) to work directly against repositories without using svn libraries.
http://host/repos/path?[p=PEG][&r=REV]
The new syntax works similarly to the way URIs work with the svn commandline client. Simply requesting http://host/repos/path fetches "path" in the HEAD revision. Adding a "p" query argument specifies a different peg revision instead, so that:
http://host/repos/path?p=38
...is similar to specifying "path@38" on the commandline. Adding a "r" query argument is like specifying "-r" on the commandline, causing the repository to follow history backwards from the peg revision to the older operative revision:
http://host/repos/path?p=38&r=20
As with the commandline, the peg revision defaults to HEAD if unspecified, and the operative revision defaults to the peg revision
Command-line client improvements (client)
There are far too many enhancements and new options to the command-line client to list them all here. Aside from all the ones mentioned already in these release notes, below are a few more that we consider important
log can take multiple revisions
The svn log command can now take multiple revision arguments in one invocation. Both the -c and -r arguments are supported.
$ svn log -r36169 -r36171 http://svn.collab.net/repos/svn/
------------------------------------------------------------------------
r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
...log message omitted...
------------------------------------------------------------------------
r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
...log message omitted...
$ svn log -c36169,36171 http://svn.collab.net/repos/svn/
------------------------------------------------------------------------
r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
...log message omitted...
------------------------------------------------------------------------
r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
...log message omitted...
--trust-server-cert option
Option added to svn and svnsync, so that non-interactive operations can work with self-signed certificates not backed by a known trust authority.
with this option:
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk --trust-server-cert --non-interactive
------------------------------------------------------------------------
r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
...log message omitted...
------------------------------------------------------------------------
without this option:
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk
Error validating server certificate for 'https://svn.collab.net':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: svn.collab.net
- Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT
- Issuer: sv, CollabNet, Brisbane, California, US
(hostname@collab.net)
- Fingerprint:
AA:5B:74:B1:E2:7F:38:B3:2B:C2:B1:60:6E:01:BB:F5:7C:37:98:46
(R)eject, accept (t)emporarily or accept (p)ermanently? t
------------------------------------------------------------------------
r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
...log message omitted...
Posts
No comments:
Post a Comment