Extend E155021 message to include supported format version
Hello I raised this ticket. Ben Reser suggested to discuss on here in the first instance http://subversion.tigris.org/issues/show_bug.cgi?id=4511 Extend E155021 message to include supported format version svn, version 1.7.5 (r1336830) Could error message E155021 be extended please to include the format code that is supported. svn: E155021: This client is too old to work with the working copy at '/cygdrive/c/ws/shared_ws/dev_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 e.g. could it be changed to: svn: E155021: This client supports (format 28) and is therefore too old to work with the working copy at '/cygdrive/c/ws/shared_ws/dev_code' (format 31). This is useful to know, because we have various different applications which checkout in svn format (cygwin svn, Hudson, Jenkins, TortoiseSVN) and are suffering from incompatibility. Of course, what would be even better if client formats were backwards compatible, and tools forward compatible. Like audio codecs are. As my local soltuion, I found a computer that had old Cygwin installed, and copied that folder so that I could get an old version of svn.exe svn, version 1.7.5 (r1336830) compiled Jun 27 2012, 15:27:52 I have seen similar messages from SVN.exe when the checked out repository is in an new format than svn.exe (e.g. svn.exe supports up to format 29, but checked out copy by TortoiseSVN is in format 31) Is there a published list of the format numbers and what versions they change? I'm still a little confused. Regards, Jon What is your opinion on this change?
Re: Extend E155021 message to include supported format version
Hi Bert That is good. I will close the ticket Regards, jon On Wed, Jul 2, 2014 at 11:30 AM, Bert Huijben wrote: > > >> -Original Message----- >> From: Notes Jonny [mailto:jong...@gmail.com] >> Sent: woensdag 2 juli 2014 11:45 >> To: users@subversion.apache.org >> Subject: Extend E155021 message to include supported format version >> >> Hello >> >> I raised this ticket. Ben Reser suggested to discuss on here in the >> first instance >> >> http://subversion.tigris.org/issues/show_bug.cgi?id=4511 >> Extend E155021 message to include supported format version >> >> svn, version 1.7.5 (r1336830) >> >> Could error message E155021 be extended please to include the format code >> that >> is supported. >> >> svn: E155021: This client is too old to work with the working copy at >> '/cygdrive/c/ws/shared_ws/dev_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 > > This is already implemented in the current code > > You just need the newer version to see the updated message. > (We don't have a time machine to update your older version to include the > message there) > > Bert >
Re: Extend E155021 message to include supported format version
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. Regards, Jon On Wed, Jul 2, 2014 at 2:21 PM, Notes Jonny wrote: > Hi Bert > > That is good. I will close the ticket > Regards, jon > > On Wed, Jul 2, 2014 at 11:30 AM, Bert Huijben wrote: >> >> >>> -Original Message- >>> From: Notes Jonny [mailto:jong...@gmail.com] >>> Sent: woensdag 2 juli 2014 11:45 >>> To: users@subversion.apache.org >>> Subject: Extend E155021 message to include supported format version >>> >>> Hello >>> >>> I raised this ticket. Ben Reser suggested to discuss on here in the >>> first instance >>> >>> http://subversion.tigris.org/issues/show_bug.cgi?id=4511 >>> Extend E155021 message to include supported format version >>> >>> svn, version 1.7.5 (r1336830) >>> >>> Could error message E155021 be extended please to include the format code >>> that >>> is supported. >>> >>> svn: E155021: This client is too old to work with the working copy at >>> '/cygdrive/c/ws/shared_ws/dev_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 >> >> This is already implemented in the current code >> >> You just need the newer version to see the updated message. >> (We don't have a time machine to update your older version to include the >> message there) >> >> Bert >>
Re: Extend E155021 message to include supported format version
Hi Brane On Thu, Jul 3, 2014 at 10:43 AM, Branko Čibej 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
Re: Extend E155021 message to include supported format version
Hi Stefan On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling wrote: > On Thu, Jul 03, 2014 at 10:58:35AM +0100, Notes Jonny wrote: >> 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.. > > The 1.8 format added support for local move tracking, for instance. > http://subversion.apache.org/docs/release-notes/1.8.html#moves Many thanks for your reply. I'm still suffering the version collisions. I was going to join tortoise svn users list, but I thought as I am already discussing here I will ask you. I've installed TortoiseSVN 1.7.7 (which uses svn 1.7.5) and it can't access the checkout from Jenkins (which is supposed to be "1.7" format). Actually Tortoise is offering to upgrade to "1.7". I am a bit surprised as it is already a 1.7x release. = Upgrade working copy This will upgrade your working copy to the new 1.7 format and make it unusable for older clients etc etc [Upgrade the working copy to the new 1.7 format] [Cancel keep the current format] The workspace was successfuly acessed by cygwin client svn, version 1.7.5 (r1336830) compiled Jun 27 2012, 15:27:52 I'm a bit confused why TortoiseSVN can't handle. I will probably go back as a binary search to find a TortoiseSVN that works.. this is such a high cost on users (already a large amount of money/development time used up. I'd happy donate an amount of money to get a fixed .svn standard format for the next decade..) Thank you for any tips Regards, Jon
Re: Extend E155021 message to include supported format version
Hi Mark On Thu, Jul 3, 2014 at 5:50 PM, Mark Phippard wrote: > On Thu, Jul 3, 2014 at 12:43 PM, Notes Jonny wrote: >> >> Hi Stefan >> >> >> On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling wrote: >> > On Thu, Jul 03, 2014 at 10:58:35AM +0100, Notes Jonny wrote: >> >> 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.. >> > >> > The 1.8 format added support for local move tracking, for instance. >> > http://subversion.apache.org/docs/release-notes/1.8.html#moves >> >> >> Many thanks for your reply. >> >> I'm still suffering the version collisions. I was going to join >> tortoise svn users list, but I thought as I am already discussing here >> I will ask you. >> >> >> I've installed TortoiseSVN 1.7.7 (which uses svn 1.7.5) and it can't >> access the checkout from Jenkins (which is supposed to be "1.7" >> format). Actually Tortoise is offering to upgrade to "1.7". I am a bit >> surprised as it is already a 1.7x release. > > > Note that Jenkins uses SVNKit, not the Subversion libraries and it has a > global preference that indicates which working copy format it will create. > I believe it defaults to 1.4, but it can be changed to 1.7 if you are on an > updated version of the plugin. Interesting. I have set it as 1.7 in the "Manage Jenkins", which means it works with 1.7.5 cygwin svn client. But not 1.7.7 TortoiseSVN.. >> I'm a bit confused why TortoiseSVN can't handle. I will probably go >> back as a binary search to find a TortoiseSVN that works.. this is >> such a high cost on users (already a large amount of money/development >> time used up. I'd happy donate an amount of money to get a fixed .svn >> standard format for the next decade..) > > > Why do you need to access the working copies of your continuous integration > server with TortoiseSVN? On Jenkins machine it has some steps: A) Jenkins SVN checkout B) Jenkins Triggers build C) Jenkins Triggers automated testing of the build. D) Build checks in the results to SVN E) Developer fixes code, and commits files using TortoiseSVN. (D) is compulsory. (E) is Nice to have.. > This issue has existed in every Subversion version and I have personally > never found it that difficult to manage. Typically on a developer machine > it means you either want to upgrade all your SVN clients (command line, > TortoiseSVN, IDE integration) together or you just do not try to mix the > clients on the same working copy. I'm stuck on why TortoiseSVN 1.7.7 (which appears to use svn 1.7.5) is incompatible with the Jenkins 1.7 checkout.. Unfortunately the output from TortoiseSVN is not clear about what version of TortoiseSVN I would need to install to for it to be compatible with the checkout from Jenkins. So it appears I will need to gradually try older versions until I get one that works. I've already asked Jenkins to move to latest svn format.. but they have not replied yet. Thanks for any suggestions. Regards, Jon
Re: Extend E155021 message to include supported format version
Hi Mark You are right that I did have 1.8.x installed. Which I downgraded to this version: TortoiseSVN 1.7.7, Build 22907 - 32 Bit , 2012/05/15 12:16:05 Subversion 1.7.5, apr 1.4.6 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.1c 10 May 2012 zlib 1.2.7 NB. I don't know why tortoise is called 1.7.7 and subversion uses 1.7.5 - would be simpler if they matched. However.. I rebooted the machine and it is now working (that part anyway). I hadn't realised that was compulsory (although I know the un-installer indicates that a reboot is essential) Thank you for the help. Regards, Jon On Thu, Jul 3, 2014 at 11:08 PM, Mark Phippard wrote: > >> Interesting. I have set it as 1.7 in the "Manage Jenkins", which means >> it works with 1.7.5 cygwin svn client. But not 1.7.7 TortoiseSVN.. > > I think you have TortoiseSVN 1.8.7 installed. That would make sense since it > is current version and it would explain your problems. That would be SVN 1.8 > working copy format (31) which you showed in an earlier error message. > > Uninstall it and download and install TortoiseSVN 1.7.14 and you should be > all set. > > http://sourceforge.net/projects/tortoisesvn/files/ > > Mark
Adding [svn users] to subject
Hi Guys Have you thought about adding [svn users] to prefix the subject of emails? It would make my mailbox simpler to prioritise all emails.. Currently I need to read the subjects.. or implement some complex filtering to folder of svn users emails.. Thanks for considering this. Regards Jon
Re: Adding [svn users] to subject
On Mon, Jul 7, 2014 at 2:32 PM, Branko Čibej wrote: > On 07.07.2014 15:23, Notes Jonny wrote: >> Hi Guys >> Have you thought about adding [svn users] to prefix the subject of emails? > > Yes, and we shied away from the idea in sheer terror. > >> It would make my mailbox simpler to prioritise all emails.. Currently >> I need to read the subjects.. or implement some complex filtering to >> folder of svn users emails.. > > All messages sent to this list contain the standard list identification > header: > > List-Id: > > Most mail clients can create filters based on that. Hi Brane Yes, I thought it would have been discussed. As far as I am aware, my client GMail can't add [svn users] to the subject of such emails.
Re: Extend E155021 message to include supported format version
On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy wrote: > On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny wrote: >> Hi Mark >> >> You are right that I did have 1.8.x installed. Which I downgraded to >> this version: >> >> TortoiseSVN 1.7.7, Build 22907 - 32 Bit , 2012/05/15 12:16:05 >> Subversion 1.7.5, >> apr 1.4.6 >> apr-utils 1.3.12 >> neon 0.29.6 >> OpenSSL 1.0.1c 10 May 2012 >> zlib 1.2.7 >> >> NB. I don't know why tortoise is called 1.7.7 and subversion uses >> 1.7.5 - would be simpler if they matched. > > TortoiseSVN release 1.7.7 is built on Subversion version 1.7.5. > Because there may be bugs in TSVN that aren't present in the > Subversion libraries, there may be multiple TSVN releases for a given > version of the Subversion libraries. > > For example, TSVN 1.7.2, 1.7.3 & 1.7.4 were all built on Subversion > 1.7.2; TSVN 1.7.2 had some nasty bugs that needed to be resolved > quickly (and 1.7.3 had one more). From the release announcement for > 1.7.3[1]: > > Due to some nasty bugs in TortoiseSVN 1.7.2 which in some specific > situations could make it crash, we're releasing this version out of sync > with SVN releases. > > 1.7.4 had another bug that needed quick resolution[2]. > > The alternatives I can think of offhand are: > > 1) Only release TSVN in lock-step with Subversion releases, leaving > TSVN bugs hanging in the wild unnecessarily long > 2) Don't publish the library versions used in TSVN. This makes > debugging & error reporting tougher > 3) Don't bump the TSVN version number. This makes support tougher - > are we using the first release of 1.7.5 or the second one? > 4) Add yet another level to the version number scheme? 1.7.5.0, 1.7.5.1, etc.? > > The current scheme is fine IMHO. > > [1]: > http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2894038 > [2]: > http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2908607 Hello Many thanks for the replies. It sounds like the TortoseSVN team want to keep things roughly "lock step", I think better to be "completely lock step". I would go with: TortoiseSVN_1.7.5_Build001 Just increment the Build number when they make an updated delivery of TortiseSVN that uses svn1.7.5 Its more confusing to use a similar but different numbering scheme (1.7.7 and 1.7.5) in my view. Best regards, Jon
Re: Adding [svn users] to subject
On Wed, Jul 9, 2014 at 9:10 PM, Ben Reser wrote: > On 7/7/14 6:23 AM, Notes Jonny wrote: >> Have you thought about adding [svn users] to prefix the subject of emails? >> >> It would make my mailbox simpler to prioritise all emails.. Currently >> I need to read the subjects.. or implement some complex filtering to >> folder of svn users emails.. > > Modifying mail going to mailing lists is a very bad idea these days. It's > becoming increasingly common for mail providers to sign mail and then publish > DNS records that tell receivers that they can reject mail that is not properly > signed. Modifying the mail then means these signatures no longer validate and > the mail may be rejected. > > Yahoo changed their DMARC settings in April of this year to tell receivers > that > they should start rejecting mail that was not signed. This caused many > mailing > lists that are doing exactly what you suggest to start dropping mail coming > from Yahoo users. > > The solutions for this as outlined here are not great: > http://www.dmarc.org/faq.html#s_3 > http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail > > It basically comes down to: > > 1) Don't modify mail. > > 2) Start modifying the mail in more intrusive ways. > > At the Apache Software Foundation for lists that don't follow the first option > they've adopted the .invalid option: > http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Add_fixed_string_such_as_.invalid_to_addresses > > Which means for domains where DMARC configuration would break the mail the > sender mail is changed to have a .invalid postfix on the sender's address. > For > example in the case of Yahoo u...@yahoo.com.invalid > > This would be particularly problematic for our users@ list because often we > have posters who are not subscribed to the list and would like to receive the > responses back. Responders would have to pay attention to the addresses and > fix them manually in all these cases. > > I don't think munging the email subject is worth dealing with that. Hi Ben Thank you for making these points. Unfortunately I agree that it is no longer possible to do what I feel is the ideal solution (add an [subversion-users] to subject). Thanks again for providing the links Jon
