You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Notes Jonny <jo...@gmail.com> on 2014/07/02 11:44:53 UTC
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
Posted by Tony Sweeney <ts...@omnifone.com>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@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
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jul 7, 2014 at 9:40 AM, Notes Jonny <jo...@gmail.com> wrote:
> On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy <an...@gmail.com> wrote:
>> On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny <jo...@gmail.com> 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.
I personally see nothing wrong or confusing about the system the TSVN
folks have settled on. If anything, I think your suggestion would lead
to more confusion, having to ask people *which* 1.7.5 they're using.
What do you mean, 1.7.5 doesn't always mean the same thing?
If you'd like to lobby for a change, you'll need to take it to the
TSVN mailing list; how TortoiseSVN is managed seems to be quite
off-topic on the SVN Users mailing list.
Re: Extend E155021 message to include supported format version
Posted by Notes Jonny <jo...@gmail.com>.
On Fri, Jul 4, 2014 at 4:51 PM, Andy Levy <an...@gmail.com> wrote:
> On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny <jo...@gmail.com> 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: Extend E155021 message to include supported format version
Posted by Andy Levy <an...@gmail.com>.
On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny <jo...@gmail.com> 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
Re: Extend E155021 message to include supported format version
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jul 4, 2014 at 11:16 AM, Notes Jonny <jo...@gmail.com> 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 is its own product with own features and bugs to fix. So it
needs its own release schedule and numbering. The significant part of any
Subversion release is the major.minor part. So 1.7. All 1.7.x releases
are compatible both at binary/API level but also formats such as working
copy. So your TortoiseSVN version is 1.7.7 and it is using version 1.7.5
of the Subversion libraries.
Given all the security fixes in Subversion and OpenSSL since the versions
you have I would recommend updating TortoiseSVN to the latest 1.7.x version
I recall it was 1.7.14. This would still be fully compatible with your
Jenkins and Cygwin versions.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Extend E155021 message to include supported format version
Posted by Notes Jonny <jo...@gmail.com>.
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 <ma...@gmail.com> 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
Re: Extend E155021 message to include supported format version
Posted by Mark Phippard <ma...@gmail.com>.
> 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
Re: Extend E155021 message to include supported format version
Posted by Mark Phippard <ma...@gmail.com>.
> On Jul 3, 2014, at 3:01 PM, Notes Jonny <jo...@gmail.com> wrote:
>
> Hi Mark
>
>> On Thu, Jul 3, 2014 at 5:50 PM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Thu, Jul 3, 2014 at 12:43 PM, Notes Jonny <jo...@gmail.com> wrote:
>>>
>>> Hi Stefan
>>>
>>>
>>>> On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling <st...@elego.de> 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
Posted by Branko Čibej <br...@wandisco.com>.
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. brane@wandisco.com
Re: Extend E155021 message to include supported format version
Posted by Notes Jonny <jo...@gmail.com>.
Hi Mark
On Thu, Jul 3, 2014 at 5:50 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Jul 3, 2014 at 12:43 PM, Notes Jonny <jo...@gmail.com> wrote:
>>
>> Hi Stefan
>>
>>
>> On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling <st...@elego.de> 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
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 3, 2014 at 12:43 PM, Notes Jonny <jo...@gmail.com> wrote:
> Hi Stefan
>
>
> On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling <st...@elego.de> 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
Posted by Notes Jonny <jo...@gmail.com>.
Hi Stefan
On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling <st...@elego.de> 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
Posted by Stefan Sperling <st...@elego.de>.
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
Posted by Notes Jonny <jo...@gmail.com>.
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
Re: Extend E155021 message to include supported format version
Posted by Branko Čibej <br...@wandisco.com>.
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. brane@wandisco.com
Re: Extend E155021 message to include supported format version
Posted by Notes Jonny <jo...@gmail.com>.
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 <jo...@gmail.com> wrote:
> Hi Bert
>
> That is good. I will close the ticket
> Regards, jon
>
> On Wed, Jul 2, 2014 at 11:30 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Notes Jonny [mailto:jongmob@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
Posted by Notes Jonny <jo...@gmail.com>.
Hi Bert
That is good. I will close the ticket
Regards, jon
On Wed, Jul 2, 2014 at 11:30 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Notes Jonny [mailto:jongmob@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
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Notes Jonny [mailto:jongmob@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