Hi Brane
On Thu, Jul 3, 2014 at 10:43 AM, Branko Čibej <brane_at_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
Received on 2014-07-03 12:04:33 CEST