MadCap Software Forums

Up to this point, we've not had a need to branch Flare projects. We've only had the equivalent of a "trunk" and would simply add fixes in a cumulative fashion to the trunk. We've never had to maintain parallel branches and merge branches at some future date, but this may be on the horizon.

Do any of you branch and merge Flare projects? If so, what tools do you use?

We are currently using SubVersion, but the branching/merging features of this tool are really oriented to textual code--not Flare projects that contain images and videos.

Any ideas about tools?

Thanks,

Rob

Yes, we've done branching and merging for our Flare projects, which like yours are controlled in Subversion, but those tasks cannot be performed directly by Flare. We use TortoiseSVN.

Just last week using TortoiseSVN, I merged a very large set of changes from a branch that was created more than a year ago (I know; a bad practice to let a branch get that far removed from the trunk) back to the trunk and it all worked beautifully.

Then, just to feel extra secure that I was working with the trunk again, I created a new Flare project by importing from the trunk, as I would no longer be doing any development in the working copy of the Flare project that was bound to the branch.

Nita,

We also use TortoiseSVN, but it's not really geared up for doing merges of topics with images, right? Did you have any problems where Tortoise didn't know how to resolve conflicts with images?

Thanks,

Rob

We weren't concerned about knowing the diffs in images and with doing "merges" as one might do for a text-based file. Rather, we just wanted to have all the images that were in the branch get copied over to the trunk. If an image in the trunk was overwritten with an image of the same name from the branch, that was just fine, on the theory that what was in the branch was more up-to-date. Our trunk actually had very little action in it during the time we were working in the branch, so we didn't have any conflicts (to not use the term technically, source-control wise) with images.

> Did you have any problems where Tortoise didn't know how to resolve conflicts with images?
At the risk of stating the obvious.... the problem is that the images are binary files, and there's no good way to diff binaries. We have the same issue in our legacy FrameMaker source, in our Flare source, and in our software code source, where images are used as icons in our UI. While it's possible to diff binaries, and svn can provide some basic level of support for it (if you were to fiddle with MIME types), what you'd be dealing with is diffing binary. And while I've known developers with that kind of skill, I can't imagine it's typically the best choice.

When merging, we always take the most recent image; we then test that we've got the right version by manually reviewing the files.

Thanks,

Kristen

Hi,

I've been trying to branch/tag my Flare project with Tortoise and I'm not having any luck. It seems that--after creating the branch/tag using Tortoise--you should modify the project's .flprj to point to the tag/branch folder on Subversion. Maybe I'm barking up the wrong tree.

In any case, could someone post the basic steps for branching/tagging in SVN and then switching a Flare project to the branch/tag?

Thanks much,
Mark

I confess to being completely confused by the SVN branching/tagging feature. We have been using SVN with the Tortoise interface, for about a year now, and are just coming to the point of needing to branch off for a version release. We were about to make the switch to TFS, because it's branching structure is much simpler, but Flare does not support that feature in TFS (which completely baffles me, since they say it is one of their natively supported source control tools - how could they not support one of the most important features???)

At any rate, though I haven't actually tried the setup yet, in theory, I get how one is supposed to create a branch from a given topic, but nothing in the Tortoise help offers any information about the process of making changes to a version that needs to be pushed to other versions.

So, for example, we've just released v3.07 of our software, and I need to branch that off so I can start making changes for our next release, v3.08.

Working with tiny test projects, I have tried making changes to the trunk and pushing them to the branch, I've tried making changes to the branch, and pushing those to the trunk. Nothing, nothing, nothing seems to work.

Is it recommended that changes always be made in the trunk file, and then merged to the branch, or vice versa?

What are the rules around folder and filenames? You have to be able to change one or the other (best case: both) in order to distinguish them, and I am getting either error messages (and) failed merges, or SVN tells me the merge is complete, but when I look in the branched project, nothing has changed.

Does the Global Linking feature in Flare have anything to do with versioning?

What's the difference between tagging and branching? You don't actually see any menu options that have anything specifically to do with updating or merging to or from tagged projects.

I'm sure I have other questions, but my brain hurts too much right now.

Thanks,
Henry

docudramaqueen wrote:So, for example, we've just released v3.07 of our software, and I need to branch that off so I can start making changes for our next release, v3.08. How does one manage subsequent changes that need to made in both files? That is the piece I just don't get.

Based on the experience I have with source code you load the project from each branch and make the change in each branch. Typically, you make the changes in the development branch first to get things worked out, then copy and paste into the release branch. That may be low tech, but otherwise you need to sort through a ton of things that are not to be merged in. From what I hear from developers, branching is not a problem, but merging usually does not work out as well as expected.
No matter how you port changes, you do want to keep the number of active branches to a minimum. Not sure how your support model is, but we tend to support only the current release and one before, but the previous release for code changes only and update builds (patches) do not come with new docs. If a customer wants up to date docs they have to go with the current release. That all depends on what your customers expect and what you can get away with.

Henry, I'm not sure this will help you, but someone in the LinkedIn group "Users of MadCap Flare" posted a question about branching that I replied: http://www.linkedin.com/groups/How-can- ... Egmr_86373

And yes, you can merge in either direction. So say your main line of development is in the trunk and you've got one or more branches. You can use TortoiseSVN to merge changes from each branch back into the trunk. Likewise, you can merge changes from the trunk into any or all of the branches (each one, a separate operation).

I agree with Ramon that you should keep the number of active branches to a minimum. You should also avoid letting a branch deviate for too long from the trunk, although I once merged changes from a branch that was almost a year old (very bad practice!!!) into the trunk and had absolutely no hitches. A miracle!

We use SVN, but do all our SVN work outside of Flare. Not sure if that's a sensible approach, but it works, after a fashion. And we'll be doing branching rather than just working on the trunk some time during the year, so this thread is very interesting. I know I'm not adding anything to the discussion, but wanted to say thanks folks.

@Nita,
Thanks so much for the guidance. I was doing most of what you described, with two, apparently, critical differences. I was not closing Flare (or at the very least the project) when trying to perform the merge, and I had put the working copies of both the trunk and the branch in the same Explorer folder. Had no idea that would complicate things so much. Now my question is, can I rename the branch project? I renamed the branch folder (to reflect the s/w version release #), but want to change the project name as well, so that you can easily distinguish them on the Flare start page.

Also, I'm still not clear exactly when one would use tags instead of branching. Our company supports the current release, the one prior to that, and of course, I will always be working on the "next" (my trunk) release, and the current and next will always overlap.

Thanks so much! If you're ever in Oregon, let me take you out for coffee, tea, or a local microbrew!

docudramaqueen wrote:Also, I'm still not clear exactly when one would use tags instead of branching. Our company supports the current release, the one prior to that, and of course, I will always be working on the "next" (my trunk) release, and the current and next will always overlap.

If you have the option to branch and it works out for you I strongly recommend using that approach. The tags require you to properly apply, change, and remove them without a system keeping track of things. It is doable and may come in handy of the one off cases, but I think using source control is the more robust and reliable solution.

Ramon, I think the question was about Subversion tags not Flare condition tags. (And I know you know the stuff I'm about to write; my goal is to enlighten others.)

A Subversion tag is a named snapshot of the trunk at a particular point in time.

I create a tag in Subversion at some major milestone. Say I have completed V1.0 of a Help system to go out the door with V1.0 of a software product. I create a tag in Subversion that marks the Flare project as V1.0. If I ever needed to reconstitute the Flare project at that particular point in time, I could do so by (using TortoiseSVN to open the Subversion repository and) copying the URL of that tag. I'd then use Flare to create a new project by importing from source control, and tell Flare to find the project's files at that URL in the repository.

I always create a Subversion tag at the end of a release cycle, period, even if I were using branching and merging.

Nita Beck wrote:Ramon, I think the question was about Subversion tags not Flare condition tags. (And I know you know the stuff I'm about to write; my goal is to enlighten others.)

Aha! No, did not know that....lack of time does not allow me to play around with Subversion....

Once again, thanks Nita!

@Ramon, ah, I must be confusing you with another MVP who gave me a lot of advice about SVN when I was just starting out.

@Henry, my pleasure. Someday pay it forward!

Hi,

I'm using Flare and SVN, and I have the TortoiseSVN client. I'm investigating branching/tagging as a means of creating a version of a project at a particular point, with the idea of being able to recreate the Flare project at that point and update it at some future time.

I've a query with my setup. In the past, I've created projects locally, in Flare's default location, worked on them, then bound them to a folder in SVN, and continued updating them there. Everything seems to work fine, in terms of checking topics in and out, comparing history and so on, using Flare' Source Control menu. But when it comes to the branching or tagging operations I know that I have to use the functionality in TortoiseSVN. The thing is that my local, or working folder, is not actually "TortoiseSVN-ised". I mean that if I right click on the local folder that contains a project that I want to branch/tag, I don't get that list of operations. Do I need to do an SVN check out in that local folder? I'd

Thanks.

@Spectre, I suspect you are not seeing the full menu for TortoiseSVN because it and Flare, as SVN clients, are not compatible, that is, they support different versions of the SVN database structure.

Check what version of TortoiseSVN you're using and then make sure it's compatible with the version of Flare you're using.

-- Flare 10 = TortoiseSVN 1.8.x
-- Flare 9 = TortoiseSVN 1.7.x
-- Flare 8 = TortoiseSVN 1.6.x
-- Flare 7 = TortoiseSVN 1.5.x

HTH

Nita,

Many thanks for your reply. Yes, I'm on Flare 9, and TortoiseSVN 1.8. It was pleading with me to upgrade and I weakened.

Can I confirm something you've said earlier in this thread:

I create a tag in Subversion at some major milestone. Say I have completed V1.0 of a Help system to go out the door with V1.0 of a software product. I create a tag in Subversion that marks the Flare project as V1.0. If I ever needed to reconstitute the Flare project at that particular point in time, I could do so by (using TortoiseSVN to open the Subversion repository and) copying the URL of that tag. I'd then use Flare to create a new project by importing from source control, and tell Flare to find the project's files at that URL in the repository.

By reconstitute, you mean that from the tag you're able to recreate the Flare project as it was at V1.0, BUT, your current working version of the project is unchanged? That is, you're not reverting your project to V1.0, you're just building a version of it, as it was at V1.0? And that works okay in your experience?

Thanks

Spectre wrote:By reconstitute, you mean that from the tag you're able to recreate the Flare project as it was at V1.0, BUT, your current working version of the project is unchanged? That is, you're not reverting your project to V1.0, you're just building a version of it, as it was at V1.0? And that works okay in your experience?

Yes, as you will have two completely separate working copies of the Flare project on your computer, with each one pointing to a different place in the SVN repository. And if you make a change in that older version that you want to pull forward into the most current version, you can do a merge from the tag to the trunk (assuming you've got the most current project bound to the trunk).

Once again, thanks very much.

We use TortoiseSVN and have not bound Flare to SVN.
We have always used different branches for different versions of our set of Help files, and the working copies of these different versions are in separate folders on the local computers. This has worked fine, but admittedly, there is a lot of disk space being used, and as we are importing a large set of shared files into all the projects, there is quite a bit of work to make the individual projects fit for the new branch every time we branch off.
Now one of our developers has suggested to me that it would be much easier to use just one local SVN folder, and then use TortoiseSVN - Switch to simply switch to another branch to do your work in that branch.
Now in light of the number of Flare files that are not in SVN (and should not be), has anyone got experience with this SVN function with Flare projects? Does it work, can it work, or does it not? For example, would I lose my Output folders every time I use Switch? Before trying it out myself and losing stuff, has anyone tried to use SVN Switch with Flare projects in different branches?