Subversion 1.5 is a superset of all previous Subversion releases, +and is 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://
compatibilityAll 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 propogated, 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.
+ +A great many bugs have been fixed. See the 1.5.0 section in the CHANGES file +for details.
+ +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).
+ +