On 20.12.2016 22:41, Todd Armstrong wrote:
>
>> On Dec 20, 2016, at 8:31 AM, "Matt Garman" <matthew.garman_at_gmail.com> wrote:
>>
>>> On Tue, Dec 20, 2016 at 1:49 AM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>>> On Mon, Dec 19, 2016 at 6:10 PM, Matt Garman <matthew.garman_at_gmail.com> wrote:
>>>> Looking at the Subversion 1.7 release notes[2], and also my own
>>>> testing, it appears that what I could do to make this easy for
>>>> everyone is to upgrade all CentOS 6 clients to subversion-1.7 (i.e.
>>>> have subversion-1.7 everywhere on the client side). Then everyone can
>>>> do an "svn upgrade" on all their working copies and go about their
>>>> business as usual. The svn server can stay CentOS 6 / subversion-1.6
>>>> for now (probably done much later in the overall upgrade process).
>>> From experience, it's that easy. There is no Subversion 1.7 in the
>>> supported repos, and Subversion 1.9 is (from personal experience)
>>> awkward to backport to CentOS 6. So it may take some work or
>>> searching. I used to publish SRPM tools over at github, but I stopped
>>> a while ago.
>> Thank you, that is very encouraging. I was able to compile svn-1.7
>> from the vanilla sources on CentOS 6, and my colleague is a pro at RPM
>> packaging. So no worries on that front!
>>
>> Thanks again,
>> Matt
> WANDisco has freely available subversion binaries for numerous subversion versions for centos 5, 6, and 7 (and lots of other operating systems.
> We are currently using one of the 1.8 versions on both centos 6 and 7 clients. Don't know if that would be 1.6 server compatible - our server is 1.8 based as well.
As a matter of policy, all Subversion clients are compatible with all
Subversion servers[1]. However clients are not compatible amongst each
other, due to changes in working copy format (except for 1.8.x and
1.9.x, which both use the same working copy format).
In other words, a 1.6 client will talk to a 1.9 server; a 1.7 client
will talk to a 1.6 server. Depending on client and server version, some
features may not be available or their implementation not be optimal,
but day-to-day checkout, update, commit, status, diff etc. will work.
Details about compatibility are documented in the Release Notes
http://subversion.apache.org/docs/release-notes/
[1] Except that, when using the file:// protocol, it is *highly
recommended* to for the client and server to be the same version. In the
case of administration tools (svnadmin, svnlook, etc.), version parity
is required. These are essentially server-side restrictions and have
little bearing on a normal setup, when clients talk to the server using
the http:// or svn:// protocol.
-- Brane
Received on 2016-12-21 11:49:00 CET