Horror stories about Flare SVN integration

[wpqs0]

I haven't used Flare for some time, but in older versions support for version control was so poor that I had given-up trying to use it from within Flare. Instead I used TortoiseSVN (Subversion client) and a hosted server, putting-up with the inconvenience of manually dealing with the new files and file renames resulting from changes made by Flare as I worked on my project.

I've now got some new work in the pipeline involving Flare, so recently upgraded to v10.2.2 and decided to try the integrated support for SVN. Frankly, it seems a bit flaky and not the sort of thing I would recommend for production work. I've also noted a few horror stories about people corrupting their repository after Flare crashes, etc. What's the community view on this? Should I continue using TortoiseSVN to version control my Flare project files from Windows Explorer, or persevere with the integrated support provided from within Flare?

My experience this morning hasn't been very encouraging. After creating a repository for my old Flare project files in a hosted SVN, I then imported the project into Flare and started work. Unfortunately, I soon hit an access violation problem with RecentLinks.xml whenever I opened the Hyperlink edit dialog (forcing me to abend Flare using Task Manager). The problem seems to be related to SVN locks as adding a lock to this file resolved the issue, but created a new one when I tried to check-in my changes. It's very frustrating! I also noted that Flare had added a number of Content.* files in the pending checking dialog, but "Check-in all" didn't add them to my repository. Has anyone had similar issues? I am concerned that the time saved by letting Flare handle new files / file rename will be quickly lost by having to deal with bugs in the SVN integration. I need some reassurance that I'm just experiencing a few teething problems here rather something more fundamental.

[Nita Beck]

Welcome to the forums.

Sorry you're having difficulties.

I just did a quick search for RecentLinks.xml and I see that it's in the Project\users folder. That folder, along with the Analyzer and Output folders, should never have been added to source control to begin with. Those folders hold temp files that will constantly change as one works on a Flare project.

I've only ever bound my Flare projects to SVN from within Flare, and Flare has been programmed never to add those temp folders to the repo. I've never put a Flare project into SVN using TortoiseSVN, but had I, I would have set up some kind of "ignore" operation so that TortoiseSVN would ignore those folders and therefore not put them into the repo.

I've been using Flare with SVN (and TortoiseSVN for those operations that Flare is not programmed to do, such as branching and merging) for several years now with very few problems.

In short, I think you've got stuff in your repo that doesn't belong there, regardless of whether you stick with using TortoiseSVN exclusively to manage source control operations or whether you use Flare's sc operations.

[wpqs0]

I'm surprised that Flare didn't set these folders as "ignore" when importing the project from SVN, preferably with some sort of warning message. Certainly, the current approach of importing everything found in the Flare project root directory (and its subdirectories) needs to be changed, as does the response when Flare encounters a file unexpectedly found in version control - it enters an endless loop of dialog box and error message which can only be broken by terminating the program from Task Manager (with a loss of all changes since the last save all).

Is there a definitive list of the Flare folders / files that should NOT be added to source control? I couldn't find one in the Help documentation. It would be great to have some basic documentation about using SVN with Flare, as I suspect there are all sorts of gotchas in terms of things that you shouldn't do with SVN clients (like Tortoise) on a working directory / repository bound to a Flare project. For example, using Tortoise to lock files seems like a bad idea. Granted, this would mean putting technical information into the Help documentation; something that MapCap marketing seem to have banned

I'm glad to hear that you recommend using the SVN tools integrated with Flare. I'll give it another go. I guess my confidence in Flare has been dented by encountering a succession of bugs and poor quality programming in V10.2.2.

Thanks for your advice

Will

[Nita Beck]

Is there a definitive list of the Flare folders / files that should NOT be added to source control? I couldn't find one in the Help documentation.

The Flare 10 help system does discuss what files and folders should (rather than should NOT) be added to source control if not using Flare to do the binding: http://webhelp.madcapsoftware.com/flare ... ontrol.htm

Under "Which Files Can Be Included in the Integrated Source Control" section, there's a subsection "If including files manually in your source control client".