Ignoring certain files (especially hidden ones) in Flare

[Eric Lachance]

After using TamTamCVS with Flare for a while (something we'll stop doing soon in favor of external tools, switching to SVN and TortoiseSVN soon), I've encountered an annoyance that really makes me twitch .

Flare has absolutely no idea how to ignore hidden files such as the "CVS" folder where the source control plugin does it's local backup while files are checked out. What this means is that if I made a modification to, say, a master page or a stylesheet, Flare will show two entries in the drop-down menu with no indication as to their location. It's happened a fair number of times that I selected the wrong one in the drop down; when that happens, the building process either doesn't work because it can't find the file (because hidden files are ignored when generating output, obviously ) or it'll output but this output will be damaged in some ways (because it refers to a file in the CVS/BASE folder, which doesn't exist in the output)

Even if we leave CVS and go with subversion instead, it'll still leave some hidden folders (completely normal and expected) and I'll have the same issue.

Does anyone have any experience with this and know how to fix it? I've looked in the flare manual and can't find any way for Flare to ignore hidden files from the interface.

[lacastle]

i had a problem with hidden files a few years ago and i think it was fixed with one of the new versions of flare (v4 maybe?). i'm at a different job now so i don't have the emails from support in front of me, but they could probably explain the issue if you don't get any response here.

[Eric Lachance]

I have version 6.1 so it could be a given that "past" issues were fixed, but I've actually seen other posts in regards with issues that came back between v5 and v6, so this may be one of them. I think I'll submit a bug report.

[Paul Griffiths]

Eric, you say you intend to switch to SVN and the TortoiseSVN client. Am I right in thinking that this means abandoning Flare's internal source control inerface? We too are looking at using Flare and TortoiseSVN, but being new to SVN I'm worried about how to handle file renames/moves (which of course must be done in Flare to preserve the links).

[Eric Lachance]

Hi Paul,

Yes, that's the plan. Flare's support for source control systems other than Microsoft is very marginal and I've suffered from a lot of issues (granted, they were all small when taken individually) that annoyed me regularly. For example, creating a new topic will regularly give you a title that says "Topic Title" in H1 instead of what you typed in the dialog and put the same title in the ToC. There's a horrible overhead when doing any actions on the source control (a couple of seconds, multiplied by hundreds of daily actions... you get the picture) and I've had instances where the binding simply broke and I got errors - I even lost some topics while fixing that. Plus, Flare's support for source control is limited to what it knows - forget about branching and merging, for example. Note that in my case I was using PushOK at the moment, TamTam was even worse.

Don't worry about changing links and such. You're still going to be working in Flare to change your project, only the checkout/checkin/commit system is external. Not precisely sure how SVN does it (haven't had a chance to actually try it yet) but if it's anything like my test with GIT, whenever you submit your changes TortoiseSVN (or whatever you use) will have no problem detecting filename changes, moves and deletions done from Flare.

[AndrewW]

whenever you submit your changes TortoiseSVN (or whatever you use) will have no problem detecting filename changes, moves and deletions done from Flare

Unfortunately, I think the opposite is true. If your project is not bound to source control in Flare, Flare will only rename, move, and delete the local files. The files in the repository on your Subversion server will remain unchanged.

[Eric Lachance]

Andrew,

I haven't had the chance to actually try TortoiseSVN yet because our Subversion server isn't ready, but I'm fairly certain that TortoiseSVN knows which files have changed and will modify the server version. The source control binding is absent in Flare, but you still need to actually do it externally. I think though that renaming a file means that Tortoise would do a delete of the old file and add the new one, not a "rename" action, meaning you lose the history.

This now becomes a moot point however - before we got the chance to implement the new subversion server with TortoiseSVN locally, Madcap released version 7.0 which integrates Subversion support. This means no more plugin and, I assume, no more confusion between source control files and actual files (hopefully). As soon as we've tested it, I'll let you know - updating to version 7 may be a good idea regardless, it's awesome

[AndrewW]

Good luck with your testing of Flare 7. I have also been looking at this, and I found that I was able to rename and move files successfully. I found a small problem with deleting files though. Although Flare deletes the files on your computer and everything looks okay, the deletion does not normally get committed to the Subversion server. Therefore, if you later check out another working copy of the project elsewhere, you find that the files that you wanted to delete are still present. I submitted a bug report about that, and was informed that you can get Flare to commit the deletion be adding a new file to your project, and committing the addition.

If you're not using Flare 7's Subversion integration though, I would stand by my original comment. When you make changes to the contents of your files using Flare, TortoiseSVN will indeed detect those changes, and enable you to commit them to the server. However, if you rename, move, or delete a file using Flare, you are not able to commit those changes to the server using TortoiseSVN. TortoiseSVN requires you to rename, move, and delete files using the functionality that it provides (e.g. TortoiseSVN menu items).

[Eric Lachance]

Ah, I guess I was thinking GIT then, not Subversion. The different features of all the source control systems are sometimes confusing.