On Tue, Feb 10, 2009 at 18:34, <petesea_at_bigfoot.com> wrote:
> 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
>>> 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
> and the link to that same text:
> 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
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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-11 02:17:28 CET