Hi Brane On Thu, Jul 3, 2014 at 10:43 AM, Branko Čibej <br...@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
