subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Notes Jonny <jong...@gmail.com>
Subject Re: Extend E155021 message to include supported format version
Date Thu, 03 Jul 2014 09:58:35 GMT
Hi Brane

On Thu, Jul 3, 2014 at 10:43 AM, Branko ─îibej <brane@wandisco.com> wrote:
> On 03.07.2014 11:37, Notes Jonny wrote:
>
> Hi Bert
>
> Could I ask, would it be possible to standardise the .svn format to
> avoid the problems I see?
>
>
> svn: E155021: This client is too old to work with the working copy at
> '/cygdrive/c/jenkins/_code' (format 31).
> You need to get a newer Subversion client. For more details, see
>   http://subversion.apache.org/faq.html#working-copy-format-change
>
>
> Like the way FLAC or MP3 bitstream is standardised, if .svn folder
> could be standardised, and not change from format 29 -> 31, it would
> make my life simpler (I have cygwin svn.exe, TortoiseSVN and also
> Jenkins SVN) because Jenkins SVN is lagging behind, I have to manually
> find old versions of other tools.  That is the workaround. However, if
> svn was backwards and forwards compatible to work gracefully with
> checkouts that would be great.
>
>
> It's definitely not trivial. We want to do that eventually, but due to
> hysterical raisins, it's going to take a fair amount of work.
>
> -- Brane

Hi Brane

Many thanks for your reply

I guess the other idea is to promise to only allow ".svn format"
updates every 5 years? I can't think that I've noticed any
improvements since I've been using new formats..  Do GIT repos suffer
these same problems?

I suffer this .svn dependency hell every time I need to build a new
automated build server (most places don't even publish old packages
any-more).

Jon

Mime
View raw message