You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by pe...@bigfoot.com on 2009/02/03 01:03:51 UTC
Subversion 1.5 repository/client compatibility
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...
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?
IS that really true? In other words, a 1.4 (or earlier) client can NOT
access a 1.5 repository?
Also... with regards to upgrading repositories. Can I upgrade ANY
previous repository version with the 1.5 svnadmin upgrade command? ie, if
I have a 1.2 or 1.3 repository can those be upgraded directly to 1.5 or do
they need to first be upgraded to 1.4 (or 1.3)?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1093752
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.5 repository/client compatibility
Posted by Andy Levy <an...@gmail.com>.
On Tue, Feb 10, 2009 at 18:34, <pe...@bigfoot.com> wrote:
> On Mon, 2 Feb 2009, Andy Levy wrote:
>
>> On Mon, Feb 2, 2009 at 20:03, <pe...@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?
I am using 1.4 clients with a 1.5 server with all repositories
sharded. No problems.
Actually, now that I think about it, I might even have a 1.2 client
using one of those 1.5-served & sharded repositories.
All using HTTP - if you're using file:///, that goes out the window.
When you use file:///, the client is also the server.
>>> 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?
No, your repository won't be corrupted. If every server & client
involved in your merge scenarios is 1.5, then you'll get full merge
tracking, no problem. If you use 1.4 clients for some of your merges,
you'll lose the built-in merge tracking when you do merges with them.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1136645
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Subversion 1.5 repository/client compatibility
Posted by pe...@bigfoot.com.
On Mon, 2 Feb 2009, Andy Levy wrote:
> On Mon, Feb 2, 2009 at 20:03, <pe...@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@subversion.tigris.org].
Re: Subversion 1.5 repository/client compatibility
Posted by Andy Levy <an...@gmail.com>.
On Mon, Feb 2, 2009 at 20:03, <pe...@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. If you're using file:/// access,
then the client is also the server, so you'll need matching version
numbers in that case.
> 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.
> IS that really true? In other words, a 1.4 (or earlier) client can NOT
> access a 1.5 repository?
>
> Also... with regards to upgrading repositories. Can I upgrade ANY
> previous repository version with the 1.5 svnadmin upgrade command? ie, if
> I have a 1.2 or 1.3 repository can those be upgraded directly to 1.5 or do
> they need to first be upgraded to 1.4 (or 1.3)?
Yes, you should be able to do that upgrade. The existing revisions
will not be sharded (IIRC there's a python script that'll do it), you
won't get the improved diffing algorithm (which *may* save you a bunch
of space on the server), and you'll also need to run
svn-populate-node-origins-index per the release notes.
If you do the dump/load cycle, that will all be taken care of for you.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1094110
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].