Re: svn checkout --set-depth ignores externals
On Thu, Jul 3, 2014 at 8:02 AM, Daniel Becroft wrote: > On Thu, Jul 3, 2014 at 4:01 PM, Daniel Becroft wrote: >> >> Hi, >> >> In the root of our trunk, we have a 'build_tools' folder which is defined >> as an external. >> >> For example >> /trunk >> /build_tools (external) >> /alpha >> /A >> /beta >> /gamma >> build.xml >> build.properties >> >> If we checkout using 'svn checkout --depth immediates', this folder is >> ignored, but I continue to get alpha/beta/gamma folders (empty). I can't >> seem to get it back without checking out the entirety of trunk. >> >> Any ideas? Is this intended behaviour? > > > Sorry, using 1.8.8 (r1568071). I haven't checked in detail, but there are a couple of known issues around externals and depth behavior, so perhaps it's related to one of these: - http://subversion.tigris.org/issues/show_bug.cgi?id=3311 (externals are not created unless depth=infinity) - http://subversion.tigris.org/issues/show_bug.cgi?id=3216 (externals with --depth) - http://subversion.tigris.org/issues/show_bug.cgi?id=4381 (Update of sparse WC fails at externals definitions) -- Johan
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
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 -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
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
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 > Do GIT repos suffer these same problems? No, they don't. And neither do Subversion repositories (i.e on the the server-side), which are fully backwards compatible. SVN working copies correspond more to the "git working tree" rather than the git repository. SVN working copies are not backwards compatible (yet) and thus clients sharing working copies need to be updated in lock-step. We know that this is problematic for some users, however for now that's the situation. SVNKit-based Subversion clients should be able to use older working copy formats. Most Java-based clinets use SVNKit instead of Subversion (SVNkit is a separate implementation written in Java, see http://svnkit.com/). IIRC Jenkins uses SVNKit, so it should be able to work with working copies in older formats.
RE: Extend E155021 message to include supported format version
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: 03 July 2014 16:48 > To: Notes Jonny > Cc: Branko Čibej; users@subversion.apache.org > Subject: Re: Extend E155021 message to include supported > format version > > 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 > > > Do GIT repos suffer these same problems? > > No, they don't. And neither do Subversion repositories (i.e > on the the server-side), which are fully backwards compatible. > SVN working copies correspond more to the "git working tree" > rather than the git repository. > > SVN working copies are not backwards compatible (yet) and > thus clients sharing working copies need to be updated in > lock-step. We know that this is problematic for some users, > however for now that's the situation. > > SVNKit-based Subversion clients should be able to use older > working copy formats. Most Java-based clinets use SVNKit > instead of Subversion (SVNkit is a separate implementation > written in Java, see http://svnkit.com/). > IIRC Jenkins uses SVNKit, so it should be able to work with > working copies in older formats. This is correct. > > __ > This email has been scanned by the Symantec Email > Security.cloud service. > For more information please visit > http://www.symanteccloud.com > __ > > - > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4592 / Virus Database: 3986/7774 - Release > Date: 07/01/14 __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
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
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. 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? 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. -- Thanks Mark Phippard http://markphip.blogspot.com/
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: Recreate SVN DB
Hi Stefan, Thank you for your reply, however at this time I think we're just going to go ahead with the data I was able to recover and take extra caution as far as backups are concerned. Thanks again! Saurabh On Wed, Jul 2, 2014 at 3:05 PM, Stefan Sperling wrote: > On Wed, Jul 02, 2014 at 07:11:36AM +, Markus Schaber wrote: > > There are companies which offer commercial support including hex-editing > broken repositories. > > I'm not sure this is a good answer in general for questions asked > on the users@ list, which is a free best effort support forum. > > Loss of data is tragic, and it seems in this case that several revision > files (817-824) have been lost. It might still be possible to extract > a full text if any of the files in the 825-891 range were saved as full > texts, rather than deltas. This is the case for representations which > begin with a line saying > "DELTA\n" > instead of > "DELTA \n" > > Saurabh, are there any revision files among the 825-891 range which > contains contain lines saying just "DELTA"? > > > Hello, > > > > I really need some help!! I accidentally deleted my Repository folder. I > have a backup of it from last year, and have a incremental backup of it as > well. Unfortunately my backup system had problems and so the only thing I > could retrieve from the most recent backup was the "db" folder which has > the revprops and rev folder and current file. Under the revprops and rev > folders, I notice the files in there are from 825-891. My backup from last > year has files from 0-816. So I'm missing files 817-824. Now I can open my > last year's backup just fine using Repo-Browser, but can't seem to open the > most recent backup as it only has the db folder. Is there a way I can merge > all these files together without the missing files? I use Tortoise SVN > 1.7. Please help. Any help or advice is really appreciated. > > > > Thank you, > > -S >
Re: Extend E155021 message to include supported format version
On 03.07.2014 21:01, Notes Jonny wrote: > 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.. I'm not going to comment on (D), but you absolutely do not want to do (E) in the sandbox used by your automatic build setup. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Extend E155021 message to include supported format version
> On Jul 3, 2014, at 3:01 PM, Notes Jonny wrote: > > 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.. That can't be true. All 1.7 clients use identical formats. > > >>> 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 Can't Jenkins do D? Mark
Re: Extend E155021 message to include supported format version
> 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
