Subversion 1.5 is a superset of all previous Subversion releases, and is as of the time of its release considered the current "best" release. Any feature or bugfix in 1.0.x through 1.4.x is also in 1.5, but 1.5 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.5 version of the free Subversion book, see svnbook.red-bean.com.
Older clients and servers interoperate transparently with 1.5 servers and clients. However, some of the new 1.5 features (e.g., merge tracking) may not be available unless both client and server are the latest version . There are also cases (e.g., sparse checkouts) where a new feature will work but will run less efficiently if the client is new and the server old.
There is no need to dump and reload your repositories. Subversion 1.5 can read repositories created by earlier versions. To upgrade an existing installation, just install the newest libraries and binaries on top of the older ones.
Subversion 1.5 maintains API/ABI compatibility with earlier releases, by only adding new functions, never removing old ones. A program written to the 1.0, 1.1, 1.2, 1.3, or 1.4 API can both compile and run using 1.5 libraries. However, a program written for 1.5 cannot necessarily compile or run against older libraries.
New Feature | Minimum Client | Minimum Server | Minimum Repository | Notes |
---|---|---|---|---|
Merge tracking | 1.5 | 1.5 | 1.5 | |
Sparse checkouts | 1.5 | any | any | |
Interactive conflict resolution | 1.5 | any | any | |
Changelist support | 1.5 | any | any | |
Relative URLs, peg revisions in svn:externals | 1.5 | any | any | |
Cyrus SASL support for ra_svn and svnserve | any*, 1.5 | any*, 1.5 | any | *Limited, see SASL and svn:// compatibility |
Improved support for large deployments on FSFS, via sharding | any*, 1.5 | 1.5 | 1.5 | *1.5 required for file:// compatibility |
Improved FSFS optimizability, via immutable file isolation | any*, 1.5 | 1.5 | 1.5 | *1.5 required for file:// compatibility |
WebDAV transparent write-through proxy | any | 1.5* | any | *Apache 2.2 server also required |
Improvements to copy and move | 1.5 | any*, 1.5 | any | *Limited, see Copy/move-related improvements |
Speed improvements, cancellation response improvements | 1.5 | any | any | |
Easier to try experimental ra_serf DAV access module | 1.5 | any | any |
The working copy format has been upgraded. This means that 1.4 and older Subversion clients will not be able to work with working copies produced by Subversion 1.5. Working copies are upgraded automatically.
Similarly, the repository format has changed, meaning that 1.4 and older versions of Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository created by Subversion 1.5. But, repositories are not upgraded automatically.
WARNING: if a Subversion 1.5 client encounters a pre-1.5 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, be careful about which version you use in which working copy, to avoid accidentally upgrading a working copy. (But note that this "auto upgrade" behavior does not occur with the repositories, only working copies.)
If you accidentally upgrade a 1.4 working copy to 1.5, and wish to
downgrade back to 1.4, use the change-svn-wc-format.py script. See this FAQ entry for details, and run the script with the
--help
option for usage instructions.
The Subversion 1.5 server works with 1.4 and older repositories,
and it will not upgrade such repositories to 1.5 unless
specifically requested to via the
svnadmin upgrade
command. This means
that some of the new 1.5 features will not become available simply by
upgrading your server: you will also have to upgrade your
repositories. (We decided not to auto-upgrade repositories because we
didn't want 1.5 to silently make repositories unusable by
1.4 — that step should be a conscious decision on the
part of the repository admin.)
After running svnadmin upgrade
,
you may wish to also run the svn-populate-node-origins-index program on the repository.
Subversion 1.5 maintains a node-origins index for each repository, and
builds the index lazily as the information is needed. But for old
repositories with lots of revisions, it's better to create the index
in one step, using the aforementioned tool, than to have live queries
be slower until the index has built itself. See issue
#3024 for details.
Although we try hard to keep output from the command line programs compatible between releases, new information sometimes has to be added. This can break scripts that rely on the exact format of the output. Unfortunately, we are not able to enumerate all of the output changes in 1.5, but one of them is that conflict markers in files now match the file's defined eol-style.
svn://
compatibility
¶
All 1.x clients, with or without Cyrus SASL support, will be able to authenticate against all 1.x servers that do not have Cyrus SASL enabled. Note that the CRAM-MD5 and ANONYMOUS mechanisms are built into Subversion, so you'll be able to use them even if the corresponding Cyrus SASL plugins are missing.
1.x clients without Cyrus SASL support will be able to authenticate against 1.5+ servers with SASL enabled, provided the server allows the CRAM-MD5 and/or ANONYMOUS mechanisms.
1.5+ clients with Cyrus SASL support will be able to authenticate against 1.5+ servers with SASL enabled, provided at least one of the mechanisms supported by the server is also supported by the client.
See this section for more information on using Cyrus SASL with Subversion.
Each revision in Subversion has a set of revision properties
associated with it; in addition to the standard log message, author,
and date, arbitrary user-defined properties can be set. These
properties are not themselves versioned, so there is no way to revert
changes to them. Because of this, you cannot modify revprops on a
committed revision without setting up a pre-revprop-change
hook on the server. Before Subversion 1.5, only the three standard
revprops could be set at commit time; administrators using hooks to
control the contents of the three standard revprops needed to check
during pre-commit and pre-revprop-change, but for
custom revprops, only pre-revprop-change appeared
relevant.
Subversion 1.5 adds a --with-revprop option to svn commit which allows users to specify revprops for revisions as they commit them. Thus, in Subversion 1.5, it is possible for revproperties to be set on revisions without any pre-revprop-change. The pre-commit hook can examine the transaction's revision properties before it is committed (just like many servers already use pre-commit to check for properly formatted log messages, e.g.).
This means that if you previously relied on pre-revprop-change to control the ability to write to revprops (as opposed to just keeping track of their history), you may want to add similar controls to pre-commit.
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.
The merge tracking support in Subversion 1.5 is "foundational": its basic functionality is implemented, but there are still parts of our original spec that remain to be done, and merging is sometimes too slow. There will be merge tracking improvements in Subversion 1.5.1 and afterwards. In the meantime:
Take a look at the list of known issues
Read "The Final Word on Merge Tracking" in the Subversion Book
Read "Understanding the internals of Subversion's merge tracking feature" by Paul Burba
Subversion's merge tracking is designed to:
Each changeset is identified by its revision number, and merged
changesets are recorded in the new
svn:mergeinfo
property (known colloquially
as "mergeinfo") set on the destination of the merge. Subversion keeps
mergeinfo up-to-date automatically, but there is also a way to record/unrecord merges manually, since
there will always be cases where a human knows something that
Subversion doesn't.
Merging changes from (say) trunk to a branch no longer requires that you specify the revision range. Instead, each time you want to sync up with trunk, you can just do:
$ cd BRANCH_WORKING_COPY $ svn merge URL_TO_TRUNK
Subversion will figure out what changes from URL_TO_TRUNK have not yet been merged and pull in just those changes. When it's time to merge the branch back to trunk, do this:
$ cd TRUNK_WORKING_COPY $ svn merge --reintegrate URL_TO_BRANCH
Below is a more formal description of all the merge-tracking-related interface changes.
The svn merge
command takes two new
options: --record-only
and
--reintegrate
.
The --record-only option works with -r and does exactly what you think it does: it marks a revision as merged (or unmerged, if using the "-" revision number negation syntax), without actually changing anything besides the mergeinfo. For example, this would be useful when someone has hand-edited a file in such a way as to effectively incorporate a change that was already made somewhere else. Rather than have the original change be ported over in the next synchronization merge, thus risking textual conflicts wherever the two versions trivially differ, you can just record the change as already merged. (See the merge-tracking requirements, and Blocking Changes in the Subversion book, for more details.)
The --reintegrate option is used when merging a branch back to trunk; it checks for some common safeguard conditions and then does the merge in a fast and efficient way. See Keeping a branch in sync in the Subversion book for more.
The new svn mergeinfo
command can
show which changesets a directory has absorbed and which changesets
it's still eligible to receive. See Mergeinfo and Previews in the Subversion book for more information.
The svn log
and
svn blame
commands take a new
-g
(--use-merge-history
) option, which tells
them to take mergeinfo into account. Without this option, they won't.
The reason for the -g option is that it is sometimes useful to ignore merge history. In blame output you sometimes want to see the person B who merged a change, though other times you want to see the person A who originally wrote the change that B later merged; use -g to get the latter information. In log output, you sometimes want to see exactly the revisions that were committed on a given line of development, though other times you want to see, as part of the same output, the original changes that were later ported as merge revisions; again, -g includes the latter information (tagged with lines that say "Merged via: " followed by the revision number in which the merge took place). See Merge-Sensitive Logs and Annotations in the Subversion book for more details.
As described earlier, merge-tracking is not supported unless you upgrade the repository as well as the server.
If you were using the svnmerge wrapper program to do merging, and now want to switch to using Subversion 1.5's native merge-tracking, then you should use the svnmerge-migrate-history.py script to convert svnmerge's custom properties to the svn:mergeinfo properties that Subversion itself now uses.
There are still known issues with merge tracking in 1.5.0. We're working on the most important ones first, which are:
merge --reintegrate
should handle
renames bettersvn mergeinfo
shows too few or too many eligible
revisions)(See also the list of merge-tracking-related open issues and the list of all merge-related open issues, though note that not all of merge-related issues are about merge-tracking and many predate it.)
Issue #3157 is particularly easy to run into, so here's a more detailed explanation of what the issue is and how to work around it:
Merge tracking information currently can include the "natural
history" of a path. One situation where this happens is when creating
a branch from trunk at a certain revision X
and later merging all changes from branch back to
trunk, without explicitly limiting the merge range and
without using the --reintegrate
option. Afterwards, the merge
tracking information on trunk will list revisions before
X. This does no harm to future merge operations, but
thereafter svn log -g
on trunk will report these
revisions from the "natural history", which is typically not expected.
This is because svn log -g
uses the merge tracking
information from previous revisions (not only from HEAD).
Note that this should not be a problem with release branches (also called "maintenance branches"), because one typically does not merge them back to trunk. Instead, recommended practice is for new changes to enter on trunk and be ported outward to the branches that need the changes. However, you could run into this problem with a feature branch, which would be merged back to trunk once, at the end of the branch's lifetime.
One workaround is to correct the merge tracking information before
committing the merged revision, by reverse merging the "natural
history" information: svn merge --record-only -rX:1
.
Another solution is to avoid this situation entirely, by explicitly
specifying merge ranges in the first place, e.g.: -rX:HEAD.
See this mail for more information.
When merging a feature branch, the best solution is to use the --reintegrate
option;
then this problem won't happen in the first place.
For more on merge-tracking in Subversion 1.5, see:
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.
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
The -N
option becomes a synonym for --depth=files
for these commands. This changes the existing -N
behavior for
these commands, but in a trivial way (see below).
checkout
without --depth
or
-N
behaves the same as it does today.
switch
and update
without
--depth
or -N
behave the same way as today
if and only if the working copy is fully depth-infinity.
switch
and update
without
--depth
or -N
will not change depth
values (exception: a missing directory specified on the command line
will be pulled in).
Thus, checkout
is identical to checkout
--depth=infinity
, but switch
and update
are
not the same as switch --depth=infinity
and update
--depth=infinity
. The former update entries according to existing depth
values, while the latter pull in everything.
To get started, run checkout
with
--depth=empty
or --depth=files
. If
additional files or directories are desired, pull them in with
update
commands using appropriate --depth
options. The svn status
command should list the ambient
depths of directories, in addition to whatever other statuses are
listed. The svn info
command also lists ambient depth,
when invoked on a directory whose depth is not the default
(depth-infinity)
Note: There is currently no deselection interface for sparse checkouts — that is, there is no command to unselect or "fold up" a subdirectory after you've brought it into a sparse working copy (although there are some fairly easy workarounds to achieve the same effect). See issue #2843 for details.
The new --depth feature naturally requires the client to be 1.5+, and will work most efficiently if the server is also 1.5+. However, the client will still behave correctly if the server is 1.4.x or lower; things will just be less efficient.
This is because older servers do not understand — and therefore ignore — what the client tells them about "depth". So when a client requests a depth shallower than depth-infinity, older servers will send back more data than the client wants. However, a 1.5+ client will know it's talking to an older server and filter out this extra data. Thus, operations may take a while, because the server sends a lot of data over the network that the client then ignores, but the final result on the client side will be the same. (Note that older servers understand a recurse flag in the network protocols, and 1.5+ clients send that flag based on the depth; this alleviates some of the extra network traffic penalty.)
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. $
This feature can be selectively disabled by using the --non-interactive option, or disabled permanently by setting '[miscellany] interactive-conflicts = no' in your run-time config file.
The API for interactive conflict resolution is exposed via a callback function and the following new data types:
svn_wc_conflict_resolver_func_t
, the callback API
itselfsvn_wc_conflict_description_t
, a description of the
conflict passed to the callbacksvn_wc_conflict_action_t
, the part of the conflict
description indicating what the merge was trying to dosvn_wc_conflict_reason_t
, the part of the conflict
description indicating the type of conflictsvn_wc_conflict_result_t
, returned by the callback
as the result of any conflict resolution attemptsvn_wc_conflict_choice_t
, an enum indicating what
course of action the user choseClients provide their callback function to Subversion's libraries
by setting it on the (new) conflict_func
field of their
svn_client_ctx_t
, and may provide additional state to the
callback via the corresponding conflict_baton
field.
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 new
changelist
subcommand.
Changelists are handled entirely by the client. They are never sent
to the server, and aren't visible to other users of the same repository.
Also, the --changelist
option is never additive; if a file
wouldn't have been included in the list of targets without
--changelist
, it will not be added to it, regardless of membership
in the changelist. Currently, a file may only be in one changelist at a
time, and directories can not be members of a changelist.
The --changelist
option is supported by the following
subcommands:
changelist
commit
diff
(only wc-wc and wc-repos cases)info
propget
proplist
propset
propdel
revert
status
update
Two additions to the svn:externals feature
Compatibility and the new syntax: For compatibility reasons, the pre-1.5 svn:externals syntax continues to not understand peg revisions. A new format has been introduced to allow peg revisions in URLs.
The old format of
foo http://example.com/repos/zig foo/bar -r 1234 http://example.com/repos/zag
does not support peg revisions, and the following externals will not work (unless there are directories named zig@HEAD and zag@HEAD):
foo http://example.com/repos/zig@HEAD foo/bar -r 1234 http://example.com/repos/zag@HEAD
The new format moves the URL first followed by the directory the external is checked out or exported into; if there is an operative (-r) revision, it precedes the URL. Here are four externals lines:
http://example.com/repos/zig foo1 -r 1234 http://example.com/repos/zag foo/bar1 http://example.com/repos/zig@HEAD foo2 -r 1234 http://example.com/repos/zag@HEAD foo/bar2
In other words, both operative ("-r") and peg ("@") revisions are allowed, but neither is required.
Prior to Subversion 1.5, the URLs in an svn:externals specification must be absolute. Now they can be relative. Four different relative externals specifications are supported. (In the following examples, assume we have two repositories: one at http://example.com/svn/repos-1 and another at http://example.com/svn/repos-2. We have a checkout of http://example.com/svn/repos-1/project1/trunk and the svn:externals property is set on trunk.)
Relative to the directory with the svn:externals property. These URLs always begin with the string ../, for example:
../../project2/trunk common/project2/trunk
This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. The external's URL is relative to the URL of the directory with the svn:externals property, not the directory where the external is written to disk.
Relative to the repository root.
^/project2/trunk common/project2/trunk
This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk.
You can also refer to other repositories easily using repository root relative URLs:
^/../repos-2/foo/trunk common/foo/trunk
This will extract http://example.com/svn/repos-2/foo/trunk into common/foo/trunk.
Relative to the scheme. This copies the scheme of the checkout or export URL into the URL in svn:externals. It is useful when the same hostname must the accessed with different schemes depending upon network location; i.e. clients in the intranet use http:// while external clients use svn+ssh://.
//example.com/svn/repos-1/project2/trunk common/project2/trunk
This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. If the working copy was checked out from svn+ssh://example.com/svn/repos-1/project1/trunk then this URL would be svn+ssh://example.com/svn/repos-1/project1/trunk.
Server root relative URLs. This copies the scheme and hostname from the checkout or export URL into the svn:externals URL.
/svn/repos-1/project2/trunk common/project2/trunk
This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. If the working copy was checked out from svn+ssh://example.com/svn/repos-1/project1/trunk then this URL would be svn+ssh://example.com/svn/repos-1/project1/trunk.
Relative URLs are still supported in the old svn:externals format (that does not support peg revisions).
When Subversion sees an svn:externals without an absolute URL, it takes the first argument as a relative URL and the second as the target directory.
See The svn:externals section of the Subversion Book.
From Wikipedia: "SASL is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL."
In practice, the server sends a list of authentication mechanisms that it supports. The client then selects one of these mechanisms based on what the client supports, and informs the server of its decision. After that, a number of messages are exchanged until either authentication succeeds or an error occurs. In the latter case, the client is allowed to restart authentication.
The svn:// protocol has always supported this type of negotiation. However, only the CRAM-MD5 and ANONYMOUS mechanisms were implemented. Cyrus SASL supports all these, and, in addition, provides a host of other mechanisms such as DIGEST-MD5, OTP (One-Time Passwords), GSSAPI (used for Kerberos authentication), NTLM (NT LAN Manager), SRP (Secure Remote Password), and others. The exact list of available mechanisms depends on how SASL was compiled, as many of them either have external dependencies, or are not built by default. Also, because each mechanism is actually a shared library that is dynamically loaded at runtime, many distributions package these mechanisms separately from the core library.
Please see the compatibility section for information regarding using a 1.5 SASL-enabled server with pre-1.5 clients. More information about Subversion's SASL support can be found in sasl.txt.
The FSFS filesystem backend stores each revision in its own file, and prior to Subversion 1.5, all of these files were stored in a common directory in the repository. Now, newly created FSFS repositories will use a two-level directory tree with up to (by default) 1000 files per directory. These repositories will only be compatible with other Subversion 1.5 clients, but of course, Subversion 1.5 will be able to continue using repositories employing the older scheme without any problem.
The primary reason for the change is to allow the revision count to grow beyond the filesystem's (efficient) directory entry limit. While modern filesystems can support millions of entries per directory, they become slower and common administrative tools (e.g. directory listings, backups) become unwieldy or fail completely.
For more information about the technical underpinnings of FSFS sharding, see this blog entry.
The shard size can by adjusted by editing the
"layout sharded
" line in "db/format" after
svnadmin create
but before populating the
repository.
The FSFS repositories never change a revision after it is written to the disk. Although this should allow the operating system to cache these files forever, certain filesystems (e.g. NFS) prohibit such caching by default. Now the FSFS repository layout has been changed such that the immutable files are confined to the subdirectories "db/revs" and "db/txn-protorevs". This allows these directories to be on a mount point where caching is enabled (on Linux look at the "nocto" option to nfs(5)).
Since commit transactions are now built up in "db/txn-protorevs" instead of "db/transactions", the latter directory no longer needs to be on the same mount point. If the repository is stored on a slower filesystem (e.g. NFS), then commit performance can be improved by moving the transactions directory to local disk (using a symbolic link). If you are using multiple svn servers behind a network load scaler, you must configure the load scaler to direct to the same server for the duration of the transaction. This is typically called "client affinity".
Subversion 1.4 introduced svnsync — a tool which provided the ability to replicate repository history from one repository to another. Though useful, svnsync could only pull revision history from a repository, not push additional commits back to the master. Subversion 1.5 adds WebDAV proxy support to mod_dav_svn, effectively allowing bidirectional revision history replication between master servers and slave servers using mod_dav_svn.
All clients interact with a slave server, but the slave transparently passes all of the write-oriented activites to the master (rewriting the content as necessary). The slaves are essentially read-only, but they do have a complete copy of the repository locally. This serves to alleviate read traffic from the master server which may be desirable in certain circumstances.
This model has several advantages to using a straight HTTP DAV-aware caching proxy, in that each slave can respond to all read-only requests without ever having to relay them to the master backend.
Participants:
Each client does:
% svn co http://slave.example.com/repos/slave/
...
% svn ci
% ...etc...
(The client can perform all operations as normal.)
Each slave has:
<Location /repos/slave>
DAV svn
SVNPath /my/local/copy/of/repos
SVNMasterURI http://master.example.com/repos/master/
</Location>
The master MUST have a post-commit hook that updates all of the slaves. An
example that does this using svnadmin dump
/svnadmin
load
and ssh is provided below. svnsync can probably do the
same thing.
Additionally, if locks are permitted on the master repository, lock databases need to kept in sync via post-lock and post-unlock hooks on the master pushing the lock state to the slaves. (Username preservation is left as an exercise to the reader. Translation: patches to these notes are most welcome.) If the lock database is not propagated, users will not be able to accurately determine whether a lock is held — but locking will still work.
A sample synchronization script may look like this:
#!/bin/sh
REPOS="$1"
REV="$2"
SLAVE_HOST=slave.example.com
SLAVE_PATH=/my/local/copy/of/repos
# Ensure svnadmin is in $PATH on both this machine and the remote server!
svnadmin dump --incremental -r$2 $1 > /tmp/$2.dump
scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH < $SLAVE_PATH/$2.dump"
ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
rm /tmp/$2.dump
Additional information about WebDAV proxy support is available in the repository.
The abilities and behavior of copy
and
move
operations are significantly improved in 1.5+.
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. We hope to address this in svn 1.6.
See issue #503 for more.
Copy and move operations now accept sources with peg ("@") revisions.
See issue #2546 for more.
Clients may now perform chained copy/move operations locally on a single object in a working copy:
svn mv path1 path2 svn mv path2 path3
See issue #756 for more.
Clients now accept multiple sources for copy and move operations, with
the ability to copy/move each of the sources to the specified directory.
This mirrors the behavior of standard command-line copy and move tools,
such as cp
and mv
. For example:
svn mkdir new_subdir svn mv foo.txt bar.txt baz.txt new_subdir
In practice, this means users can take advantage of shell globbing when doing a local copy or move:
svn cp *.c dir
Multiple source copy/move also works for all previously defined copy/move working copy and repository combinations.
See issue #747 for more.
Copy now understands the special revision "BASE" in a working copy (as in: "-rBASE").
See issue #1643 for more.
See the section on the new --parents option for more about this.
Clients operations are now significantly more responsive to cancellation (e.g. via control-c). In pre-1.5 releases, after directing an operation to stop, one sometimes had to wait for some time (e.g. while I/O occurred) before the operation would actually stop.
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, but please see the 1.5.0 section in the CHANGES file for a complete list.
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).
See issue #2784 for more.
Add, mkdir, copy, and move take a new --parents option, which makes intermediate directories as necessary to create the destination path.
See issue #1776 for more
Delete (remove) now takes a
--keep-local
option to retain its
targets locally, so paths will not be removed even if unmodified.
See issue #1976 for more.
Subversion 1.4 introduced the experimental ra_serf repository access module for accessing HTTP[S] DAV Subversion servers. This uses the serf library instead of the Neon library which the original DAV support uses. serf supports pipelined requests which may lead to better performance. However, Subversion 1.4 required you to choose which module to use for accessing DAV servers at build time, which made it difficult to find out which module performs better for your usage patterns.
Subversion 1.5 allows you to build both modules at the same time; you can choose which library to use on a global or host-by-host basis by setting the http-library variable in your run-time server configuration file (~/.subversion/servers). In recognition of the fact that both libraries are DAV clients, we have renamed ra_dav to ra_neon.
There are too many new and revised APIs in Subversion 1.5.0 to even begin to list them all here. See the Subversion API Documentation page for general API information. If you develop a 3rd-party client application that uses Subversion APIs, you should probably look at the header files for the interfaces you use and see what's changed.
One general change is that most APIs that formerly took a recurse parameter have been upgraded to accept a depth parameter instead, to enable the new sparse checkouts feature.
Language bindings have mostly been updated for the new APIs, though some may lag more than others.
The Subversion 1.3.x line is no longer supported. This doesn't mean that your 1.3 installation is doomed; if it works well and is all you need, that's fine. "No longer supported" just means we've stopped accepting bug reports against 1.3.x versions, and will not make any more 1.3.x bugfix releases, except perhaps for absolutely critical security or data-loss bugs.
APR 0.9.x and 1.x are binary-incompatible. This means if you are already using Subversion with APR 0.9.x, and then upgrade your libapr to 1.X without rebuilding Subversion, things will break. Things will also break if your Subversion server libraries are linked to one version of APR but your Apache HTTPD server is linked to a different version.
For a long time, Subversion's main source distribution included APR 0.9.x, which was the latest available at the time, along with a few other things (e.g., Neon, zlib) that weren't yet widespread on installation systems.
Today, these dependencies are no longer exotic, so our source distribution contains just Subversion itself. Those building Subversion are expected to have the necessary libraries already installed, or to be able to fetch them easily. But for convenience, we still offer a "deps" distribution: it doesn't contain Subversion, it just has source code for those third-party libraries.
Until Subversion 1.5.0, the deps distribution contained APR 0.9.x, but as of 1.5.0, we're finally upgrading it to APR 1.x. This is because by now there are very few systems that will have binary compatibility issues, and of those, few are likely to build using the "deps" dist.
If you already have a Subversion installation using APR 0.9.x, it's still possible to move to APR 1.x safely (although you are not required to, unless you use the deps dist). Just be sure to recompile Subversion, and Apache httpd if necessary, after upgrading APR.
Note that it's perfectly safe to use APR 1.x from the beginning. In fact, we recommend it. If you're building Subversion for the first time, there's no compatibility issue to worry about, so just grab the latest version of APR (or use our deps dist).