SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Bug reports.
RanoTester
Posts: 19
Joined: Mon Jan 14, 2013 7:16 pm

SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by RanoTester » Mon Nov 03, 2014 8:13 pm

PROBLEM LOCATION: Within Ranorex Studio, with the existing Solution open, at the top go to Tools > Options > Tools > Subversion Options. The below-stated problem is in regard to the "SharpSvn Version" selection process for customers that need to select a "SharpSvn Version" other than the default value, i.e, which is currently Read-Only / Non-Editable "SharpSvn Version 1.8" in Ranorex 5.1.0 and 5.2.0.

PROBLEM SUMMARY: Companies such as the one I work for need to continue using "SharpSvn Version 1.6" due to a number of factors, but are unable to in Ranorex versions 5.1.0 and beyond. Why? Due to the above-stated "SharpSvn Version" selection process. See Request below - That would resolve the problem.

Compare the two attachments. You see that in Ranorex 5.0.5, this ability to select "SharpSvn Version 1.6" via the DDDW was in fact there. However, in Ranorex 5.1.0 and 5.2.0, this ability has been lost - It defaults to a Read-Only "SharpSvn Version 1.8".

Given our Subversion infrastructure is "SharpSvn Version 1.6", i.e., we are on Tortoise SVN 1.6.10, if were to compile our existing Ranorex scripts under "SharpSvn Version 1.8", the result would be corruption on a Ranorex / SVN server level. Therefore, for the time being, until this problem is resolved, my company will be unable to upgrade to a new Ranorex version (i.e, 5.1.0 or 5.2).

REQUEST: Please re-enable the "SharpSvn Version" DDDW seen in Ranorex 5.0.5 and prior (See attachment) so customers can select "SharpSvn Version 1.6" if that is their need. If this is not done, i.e., and the "SharpSvn Version" selection process continues to be something the customer has no control over, such customers may have no other option than to NOT upgrade to new Ranorex versions (i.e., Ranorex 5.1.0 and beyond) specifically due to the inability to select the "SharpSvn Version" of their choice.

SYSTEM INFO:
Ranorex Studio Version 5.0.5.19738
Internet Explorer 10 Version 10.0.9200.17089
Java Version 7 Update 71 (build 1.7.0_71-b14)
Flash Player Adobe Flash Player 14.0.0.176
Windows 7 Ultimate N Service Pack 1 64-bit Operating System - Installed Memory: 4.00 GB - Processor - Intel(R) Core(TM @ 2.67GHz)
You do not have the required permissions to view the files attached to this post.

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by krstcs » Mon Nov 03, 2014 8:39 pm

This is not a bug, but a feature change purposefully made by the Ranorex team because SVN 1.6 is out of support. You can't really expect Ranorex to continue to include support for it in new product releases at this point.

You either need to update your subversion install or stick with Ranorex 5.0.x or earlier.
Shortcuts usually aren't...

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by Support Team » Mon Nov 03, 2014 10:41 pm

Actually, we are still supporting Subversion 1.6. However, the used SharpSvn version cannot be selected anymore in Ranorex Studio, simply because that does not make sense. Ranorex Studio chooses the SharpSvn version that matches the installed TortoiseSvn version, which is a prerequisite of the SVN integration within Ranorex Studio. Before Ranorex 5.1, you had to choose the correct SharpSvn library version yourself. This is now done automatically.

Which version of TortoiseSvn do you have installed?

Regards,
Alex
Ranorex Team

RanoTester
Posts: 19
Joined: Mon Jan 14, 2013 7:16 pm

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by RanoTester » Wed Nov 05, 2014 12:27 am

Thank you for the quick reply.

Your question - Which version of TortoiseSvn do we have installed? The answer - Our Ranorex playback / development machines are both on TortoiseSVN 1.6.10, Build 19898 - 64 Bit. See Figure 3 for details.

Additional Info:
1. There is only one instance of TortoiseSVN.dll on each of the above-mentioned Ranorex machines (as seen when searching the C:\ root and entire machine), and it corresponds to above-stated TortoiseSVN 1.6.10.19898.

2. The upgrade process using one of these machines, performed last week, was from Ranorex 5.0.4.1882 to Ranorex 5.2.0.20272. At that time, we observed what is seen Figure 1 where the SVN Selection process is now automatic / that SVN 1.8 is now automatically selected and read-only in Ranorex v5.2.0.

3. Our Ranorex SVN process is incompatible with SVN 1.8; it must be SVN 1.6 due to the nature of the SVN version on both the local machine and the Ranorex - SVN Server we use . . . . Which is compatible with SVN 1.6, but not 1.8.

4. So, in lieu of this, we un-installed Ranorex 5.2.0.20272, reviewed the Ranorex Release notes more closely, observed that Ranorex v5.1.0 was where the SVN Selection process was changed from DDDW to automatic, and proceeded with installing Ranorex 5.0.5.19738 which is where we are now . . . . Which allows our organization to still select SVN 1.6 via DDDW in Ranorex Studio > Tools > Subversion Options.
You do not have the required permissions to view the files attached to this post.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by Support Team » Thu Nov 06, 2014 3:42 pm

Hi RanoTester,

As workaround you can try to remove the SharpSvn1.8 and the SharpSvn1.7 folder from the "<Ranorex Install Folder>\RanorexStudio\AddIns\AddIns\Misc\SubversionAddin" directory. After doing so Ranorex should use the "SharpSvn: 1.6" plugin.

Regards,
Bernhard

RanoTester
Posts: 19
Joined: Mon Jan 14, 2013 7:16 pm

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by RanoTester » Fri Nov 07, 2014 6:23 pm

Confirmed Resolved - The workaround you provided was perfect! It worked.

The workaround may be something appropriate for the Ranorex User Guide in a section for customers that need to continue using SVN 1.6 or SVN 1.7. We'll continue to use this workaround in future Ranorex upgrades, as necessary, to achieve the same result, i.e., to see the appropriate SharpSvn number in Tools > Subversion Options.

Notes:
1. Using the workaround, we were able to use to successfully upgrade from Ranorex 5.0.5.19738 to Ranorex 5.2.0.20272 and continue to be able to use SVN 1.6.

2. Since doing this, we have no problems to report. We have been able to succesfully perform SVN Commits and SVN Updates in Ranorex 5.2.0.20272 given we see SVN 1.6 selected in Figure 4.

3. When we first installed Ranorex 5.2.0.20272 yesterday, we observed the SVN 1.7 and SVN 1.8 Add-Ins in the Ranorex 5.2 Installation Path (Figure 5).

4. When we then opened our existing project in Ranorex 5.2.0.20272, we observed the orignal problem of only SVN 1.8 appearing in the Subversion Options.

5. So, we closed Ranorex Studio and performed the Workaround of deleting the SVN 1.7 and SVN 1.8 Add-Ins (Figure 5) via Windows Explorer with the result being that the SVN Add-In was SVN 1.6 (Figure 6).

6. We then re-opened our existing project in Ranorex 5.2.0.20272 and correctly saw that SVN 1.6 was displaying and Read-Only. This is perfect.

7. We then Re-Build Solution and are in the process of manually updating, saving, and SVN Committing the appropriate files, i.e., .rxrec, .cs, .rxrep, etc., under the new Ranorex version (5.2.0.20272). Thus far, no problems.
You do not have the required permissions to view the files attached to this post.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: SVN Selection Process in 5.1.0 negates SVN 1.6 Selection

Post by Support Team » Tue Nov 11, 2014 2:57 pm

Hello RanoTester,

Thank you for the information and the detailed description. I am glad that the workaround helps solving the problem. We will discuss internally if we add the workaround to the user guide.

Regards,
Bernhard