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

Re: Compatibility of Subversion 1.3 with Subversion 1.5 Repository

From: David Weintraub <qazwart_at_gmail.com>
Date: Mon, 1 Dec 2008 14:14:19 -0500

I have the latest version of Hudson, (or at least the latest as of a few
weeks ago).
It could be the state of our build machine. We really, really should not be
using it because of all sorts of issues. It is a SUSE Linux 9 version of
Linux, and I suspect there may be some other issues with it. For example, I
can't get the latest version of Python or PHP on it, and we are stuck in
Subversion 1.3 client.

Does SVNKit depend upon APR or Neon or some other Subversion dependent
library? Maybe that's the problem we're having.

The good news is that we will be getting a better infrastructure soon and
I'll be able to upgrade my build system to use the latest version of
Subversion. Then, the whole issue will be moot.

--
David Weintraub
qazwart_at_gmail.com
On Mon, Dec 1, 2008 at 1:06 PM, Chris Lieb
<chris.lieb+nospam_at_gmail.com<chris.lieb%2Bnospam_at_gmail.com>
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Well, since your server is running SVN 1.5, you shouldn't have any
> problems accessing it using SVNKit included in Hudson.  I have SVN 1.5
> repositories (FSFS) that I can access from Hudson without issue using
> both the file:// and http:// methods.
>
> What version of Hudson are you using?  Have you tried upgrading to the
> latest version?
>
> Chris Lieb
>
> David Weintraub wrote:
> >     It does not matter what version of Subversion you have installed on
> the
> >     client in this case.  Hudson uses SVNKit as its SVN client, not the
> >     Subversion client you have installed on your computer.  The latest
> >     version of Hudson (1.262) uses SVNKit 1.2.0, which implements a
> client
> >     compatible with SVN 1.5 and which advertises itself as "SVN/1.5.2
> >     SVNKit/1.2.0".
> >
> >
> > But, I had to download a Subversion plug-in to get Hudson to do the
> > build as a 1.3 build. Or at least compatible with Subversion 1.3.
> > Otherwise, the build process didn't work. I'm not 100% sure what that
> > Hudson plugin did, but without it, Hudson couldn't build with Subversion
> > on our build machine.
> >
> > I'll create another repository, make it a duplicate of our current dev
> > repository, and try that on Hudson. I am pretty sure everything should
> > be fine, but I just need to make absolutely certain.
> >
> > --
> > David Weintraub
> > qazwart_at_gmail.com <mailto:qazwart_at_gmail.com>
> >
> >
> > On Mon, Dec 1, 2008 at 11:07 AM, Chris Lieb <chris.lieb+nospam_at_gmail.com<chris.lieb%2Bnospam_at_gmail.com>
> > <mailto:chris.lieb%2Bnospam_at_gmail.com <chris.lieb%252Bnospam_at_gmail.com>>>
> wrote:
> >
> > David Weintraub wrote:
> >> I thought I had everything setup nice and clean. I have Subversion 1.5
> >> installed as my server, and finally got the last project converted
> >> over to Subversion.
> >> However, our build machine is using Subversion 1.3. It's an old SUSE
> >> Linux installation, and we simply couldn't get a more recent revision
> >> of Subversion to work on it. Not without updating Apache, APR, Neon,
> >> and who knows what else. Heck, it took us a week just to get
> >> Subversion 1.3 running, so upgrading isn't an option right now.
> >> Now, here's the problem: Everything seemed to work our nicely. Our
> >> build machine (running 1.3) is able via Hudson to checkout the code
> >> and do a build. It can do labeling via Hudson. It looks good.
> >> However, one of our developers noticed that our Server (running
> >> Subversion 1.5) has only DB format 2 on it. He tried a "svn log -g"
> >> and got the following error message:
> >
> >> svn: Querying mergeinfo requires version 3 of the FSFS filesystem
> >> schema; filesystem '/solbright/svn_repositories/dev/db' uses only
> >> version 2.
> >
> >> I can run svnadmin upgrade on the Subversion repository, and in
> >> seconds, get it to be upgraded to db format version 3. I've tried this
> >> on a back of our server with no problems.
> >
> >> The question I have are possible side effects on our build server
> >> running Subversion 1.3. I know that this build server can't do merge
> >> tracking, but I don't really need to worry about that. I simply want
> >> to know if there would be any side effect upgrading our repository to
> >> DB format version 3. All this subversion client has to do is checkout
> >> the code, work with Hudson, and do labeling. There's no real
> >> development that takes place on it.
> >
> >> From what limited testing I'm doing, it all looks okay. I just want
> >> some confirmation that I won't be blowing everything up if I do the
> >> upgrade.
> >
> >> --
> >> David Weintraub
> >> qazwart_at_gmail.com <mailto:qazwart_at_gmail.com>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> <mailto:users-unsubscribe_at_subversion.tigris.org>
> For additional commands, e-mail: users-help_at_subversion.tigris.org
> <mailto:users-help_at_subversion.tigris.org>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQEcBAEBAgAGBQJJNCe4AAoJEJWxx7fgsD+CcDUIAIlT07I63SAdAuKBPZG+FKdO
> XWWaAEzGXYb0jEq+XR7KNtE1QYrLDkyQgN5KZIWLZw1z/ihbP6ES+IsfScadczXw
> MRYDOvTvF0+/iLckuLddRMHYg64n/wM1WV9WtsYHXRzsJu8+k9YGfFJe+TXracrH
> VGfjqlRRGF90c/NyFzz/UrDry2QsGl0bPWbzAH02fW8UXjNSOzC4g32n/yLAfFg9
> ctDh5Cw7N8g9ybX2CPB1F8I/qPRVk3fci+PDDC4ryRKE+H6fiAObsyZu0K20Bf12
> ZwmFBWVN7wCTgd3/NJbK81Wv+T2EDnq0hQpxHpqqh9iEq4Yq5qNHj9QCDtcu71g=
> =d6ba
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
Received on 2008-12-01 20:14:59 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.