Hi Mark
On Thu, Jul 3, 2014 at 5:50 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Jul 3, 2014 at 12:43 PM, Notes Jonny <jongmob_at_gmail.com> wrote:
>>
>> Hi Stefan
>>
>>
>> On Thu, Jul 3, 2014 at 4:47 PM, Stefan Sperling <stsp_at_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
Received on 2014-07-03 21:01:52 CEST