Best Practices for Flare, Subversion, and Copying a Project

This forum is for all Flare issues not related to any of the other categories.
Post Reply
Mishou6779
Propeller Head
Posts: 57
Joined: Mon Jun 01, 2009 9:19 am

Best Practices for Flare, Subversion, and Copying a Project

Post by Mishou6779 »

Hi all,

Backstory: I work at a software company, I am a lone writer, I use Flare 2018, and just recently started using Subversion for source control.

I have always "cut" one help build from the last. When I got here we were on 4, from 4 I cut 5, from 5 I cut 6, and so on. That was before we used source control.

Our current version of our main product is numbered 7, and within the last couple of months we started using Subversion, so help build 7 is in Subversion. At the end of the year we will launch version number 8. Our Dev team has already been coding 8 for a couple of months now. Our product is huge and the help contains many files (upwards of 1,400). Before we sunset version 7, there will be some overlap between 7 and 8. So I might have a file with one name but it's in two different flare projects, one for version 7 and one for version 8. The stinker is that when we have a support pack or a hot fix release it's very likely that if we had to fix something in 7 then we have to fix it in 8 too. So then I will have two different places to go to update the online help accordingly. This will increase the possibility of mistakes getting published.

So I'm wondering if anyone out there who uses Flare with source control wants to share best practices. I'm not at all sure how to use 7 to create 8 now that it's in Subversion but will of course read the Flare user guide on source control. I'm also not sure whether to add the new version 8 content to the version 7 help and condition it out of 7 and then condition it back in to 8 once I create 8. Could I create a file folder under the Content folder in the Content Explorer in Flare for the new version 8 help pages and just condition that folder out? I could run a test of that but don't want to mess with it now that it's in Subversion.

If the folder thing even worked, then once I create the version 8 help I would need to move the version 8-specific help pages back into the main Content folder in Flare and that seems like a lot of work now that Subversion is involved. I will probably add as many as 150 files and make changes to around 300. Since my version 7 Flare project runs so much more slowly now that Subversion is involved, I'm worried that adding, deleting and checking out and back in that many files (and all the image files, snippet files, etc.) would make it crash. Or be messy. Or both. It already crashes on a fairly regular basis.

Would love to hear what others have learned, regarding any aspect of this task.

Thank you!
Michelle
bunnycat
Propeller Head
Posts: 70
Joined: Tue Nov 03, 2015 6:44 am

Re: Best Practices for Flare, Subversion, and Copying a Proj

Post by bunnycat »

You should always default to your source control and team's branching strategy, but some practices that are good.
[*]Maintain separate branches for different release branches - I found that previous writers either didn't "trust" source control, or didn't know how to use it - so had brand new files mixed in with legacy files, or had things conditionalized like crazy within each major branch. It was a mess to take up as the new writer, and left me with a multi-week project to analyse and pull out the implicit branches blended into the main release Flare project. My previous writer also left what looked to me like random subfolders around per minor/minor/sustaining release, and it was just really confusing without a lot of context.

[*]model your source control branches on what development is doing for their branches. If they are doing work in 'main' or 'trunk' (different descriptions for mainline dev) - model yours similarly. And then when you release the version for main, create a branch with an explicit version number using the Branch/Tag feature in source control. If Dev explicitly numbers their mainline dev branch, do similar.
[*] Branch/tag in source control - use your SVN features to branch it and tag a release. It will leave you with a known quantity of a clean branch. This will also help if older branch needs post-release sustaining work. As you will only have a small amount of changes to make.
[*]Decide when to branch. I usually branch my source around RTM or GA day, or earlier at feature complete because at feature complete time, I should be down to adjusting release notes and such, not adding lots of new topics to a release about to go out the door. If you wait to GA day - you may have to do some smaller content merges, but it should be manageable with a diffing application (Kdiff is wonderful for that).
[*] Diffing applications are your friend - I use them all the time to compare branches.
Mishou6779
Propeller Head
Posts: 57
Joined: Mon Jun 01, 2009 9:19 am

Re: Best Practices for Flare, Subversion, and Copying a Proj

Post by Mishou6779 »

bunnycat,

Thank you for the reply. I really appreciate it! I'm definitely going to check out the branch / tag feature!

Thanks again!

Sincerely,
Michelle
Post Reply