Tortoise SVN 1.7.1.22161 is incompatible with Flare 7.2.0

[crdmerge]

Do not upgrade to SVN 1.7.1.22161 if you're binding Flare 7.2.0 and SVN! (Not sure if there are any issues if using SVN standalone.) This bug has been verified by the Flare developers and Bug # 46996 has been submitted.

THE GOOD
With projects bound to SVN 1.6.12.20536, the .svn folder appeared under all subfolders (Contents, Resources, etc.), and projects opened and closed with no problems.

THE BAD
After upgrading to SVN 1.7.1.22161, only one .svn folder appeared: at the project root. Attempting to open a project resulted in this error message: “Content is not a valid working folder.” We were fortunate in reverting back to SVN 1.6.12.20536 and undoing the damage.

THE UGLY
I would have felt more reassured if this sentence in the support reply started with When instead of If. ("If a fix is released for this issue, we'll send you an e-mail mentioning this bug report number.") Sigh...


Leon

[RamonS]

Thanks for posting the warning.
What was the motivation to upgrade? Did you try it on a test system first?

THE UGLY
I would have felt more reassured if this sentence in the support reply started with When instead of If. ("If a fix is released for this issue, we'll send you an e-mail mentioning this bug report number.") Sigh...

My assumption is that MadCap (and I further assume you refer to their support email) gets dozens if not hundreds of bug reports each week. They all have merit, otherwise the customer would have not gone through the trouble of reporting it, but there is always a process applied that needs to determine
- if the described behavior is by design
- if it is by design, is the design correct
- if the design is correct, is there any way to remedy the problem
- is fixing the problem causing new problems
- is fixing the problem worth the time and effort with time and effort being limited resources
- is this a bug that needs to be acknowledged, but will not get fixed now, because a redesign of that feature is already in the works or planned near future
- is this a bug that needs to be acknowledged, but there is a simple workaround

I am sure there are more thoughts going into this, but suggesting before this evaluation took place that a fix will be provided is just dishonest. And even if the message states "when" it will not help you when the "when" is five years from now.

[Nita Beck]

Thanks for alerting us to this.

FWIW, I have only recently started using TortoiseSVN and started with 1.7.1.22161. I see the .svn folders throughout my bound Flare projects, in the root folder and all subfolders. I get no errors when I open any bound project in Flare 7.2.0.

Perhaps the problem you are experiencing is limited to those who started with a prior version of TortoiseSVN, in which case the title of your post is correct for some circumstances but not for others.

[crdmerge]

Ramon, the motivation was this: after several months of these ubiquitous update alerts, my boss decided to test the upgrade on a project copy (actually merged project). Had Madcap made any form of announcement that admitted they hadn't tested this upgrade themselves, he would have been saved quite a bit of time.

Nita, You could very well be correct. I'll reply to Madcap with that possibility.


Leon

[RamonS]

Had Madcap made any form of announcement that admitted they hadn't tested this upgrade themselves, he would have been saved quite a bit of time.

Why would that be MadCap's responsibility? MadCap does not provide Subversion. Aside from that, any update needs to be tested on a test system before applying it to a production system. That is what IT departments spend a lot of time on, especially in weeks like this one when Patch Tuesday is. I guess in your case it worked out in the end as the downgrade was possible.

[crdmerge]

Ramon, on the Madcap announcement page for V7 (http://www.madcapsoftware.com/products/ ... troduction, they tout the following feature:

"Native Source Control Integration for Apache Subversion, Team Foundation Server and Visual SourceSafe: Native source control support means you no longer need any third-party plug-in to take advantage of integrated source control within Flare."

Call me crazy, but "Native source control support" certainly implies a level of responsibility on Madcap's part towards their users.

In addition, Ramon, I find your statement "any update needs to be tested on a test system before applying it to a production system," to be rather disingenuous, if not outright patronizing. Yes, of course, we tested it on a test system! That is, a test system replicating our 40-project merged WebHelp with 3K topics, 15K hyperlinks, 16K images. Therefore, preparing the test bed, preparing the SVN infrastructure, binding the projects to SVN, researching why projects cannot be opened, and, finally, determining the causes for the aforementioned error message -- was no easy task. A task, as I said earlier, that would have been unnecessary had Madcap thought to alert their users about this incompatibility. Were they unaware of the version mismatch, or simply unconcerned? Either scenario is disappointing, don't you think?


Leon

[RamonS]

You original post suggested that you installed the update to a production system, which is why I asked if you tried it on a test system first.
As far as MadCap's responsibility is concerned, I still don't see it. Especially since SVN 1.7 was released AFTER Flare 7.2 came out (11 October 2011 for SVN vs 7 September 2011 for Flare). As far as the client side is concerned, that part apparently works fine as you confirmed with SVN 1.6. If the folks at Apache put out a new version of Subversion that works differently and therefore breaks clients that worked fine before it is a matter of determining if Subversion has a bug or if the change was intentional, in which case the client (in this case Flare) needs a change. My guess is that the many API changes in Subversion in the 1.7 branch may cause the problems, something that can be noticed only after the release of 1.7, not before. A bug report is filed with MadCap and it now is up to developers to sort out if the client (Flare) or the server (Subversion) is at fault and what needs to change. Demanding that this gets done a month before the problem occurs is unrealistic.

[benjimenez]

Thanks for this thread. Had same issue as original poster.

[Stefaans]

Same problem here. I would appreciate if MadCap could release a patch that would make Flare 7.2 work with SVN 1.7.2. I accept that this issue is not MadCap's fault, but the solution still lies with them.

[Mont Rothstein]

Add me to the list of wanting to see an update to fix this. We just starting using Flare and were already on Tortoise SVN 1.7. Now we have to look at downgrading out clients.

[owilkes]

Adding myself to this list as well.

As syncing with SVN through flare takes approx 15 times longer than through Tortoise (and makes x number of additional calls) - any large project needs to work with Tortoise.

Oh, and we have the problem in Flare 8 as well, in case anyone was hoping....

I'd rather they fixed the problem inside flare of the additional, unneeded calls - but one step at a time.

[MarinaMichaels]

I had the same problem with Flare 7 and Tortoise. I was able to revert to an earlier version of Tortoise and then just checked all the files out again to a new location (the old one was dead and unrecoverable). I am now on Flare 8 and had been hoping this had been fixed, but apparently not.

It might not be a Tortoise/Flare problem; it could be Tortoise/SVN, as our developers had problems with Tortoise and SVN last fall, so none of us have updated to the latest Tortoise.