[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.5 repository/client compatibility

From: <petesea_at_bigfoot.com>
Date: Tue, 10 Feb 2009 15:34:51 -0800 (PST)

On Mon, 2 Feb 2009, Andy Levy wrote:

> On Mon, Feb 2, 2009 at 20:03, <petesea_at_bigfoot.com> wrote:
.
>> I was hoping someone could clarify a question with regards to
>> compatibility...
>>
>> According to the 1.5 release notes:
>>
>> ... merge-tracking is not supported unless you upgrade the repository
>> as well as the server
>>
>> OK..., but then later, with regards to "sharding", there's this:
>>
>> ... These repositories will only be compatible with other Subversion
>> 1.5 clients...
>
> I think you may have taken this quote out of context. Repository
> sharding is transparent to the client, only the server libraries will
> ever see the sharded directories.

I don't believe I took it out of context... here's the exact quote from
the release notes:

     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.

and the link to that same text:

   http://subversion.tigris.org/svn_1.5_releasenotes.html#fsfs-sharding

It clearly says "only be compatible with other 1.5 clients"... which means
(at least to me), that ANY client, regardless of the access method must be
1.5 in order to access a sharded repository. That seems very odd and
more likely I'm not quite understanding what the release note really
means.

Is it an error in the release notes? Should it say:

     ...
     These repositories will only be compatible with other Subversion 1.5
     servers ...

or... perhaps your next comment is what the release note was referring
to...

> If you're using file:/// access, then the client is also the server, so
> you'll need matching version numbers in that case.

Perhaps "... compatible with other Subversion 1.5 clients..." only means
clients using the file:/// access method?

>> Sooo... I read this to mean that in order to support the new
>> merge-tracking features we need to upgrade the server and the
>> repository. .. OK, that's fine. But I also read it to mean that if ANY
>> user wants to use the new merge-tracking features, ALL users will need
>> to upgrade their clients to 1.5... even the users that don't care about
>> the new 1.5 features?
>
> All 1.x clients are compatible with all 1.x servers. When one is older
> than the other, the newer features will be disabled for the operations
> being performed. If you have some people doing merges with 1.5 clients
> and your 1.5 server, and others doing merges with 1.4 clients and your
> 1.4 server, things could get a little messy.

We'll be using the same server (1.5) for all repositories, and in order to
support the new merge-tracking features we'll need to upgrade (at least
some repositories) to 1.5... but there will be a variety of client
versions using either the http://, https:// or svn+ssh:// access methods.
Any file:// access will be for admin purposes only and will of course be
using the same 1.5 version as the server.

Sooo... can you explain a but more what you mean my "things could get a
little messy"? Could this "messyness" cause corruption of the repository
itself?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1136360

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-11 00:39:01 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.