Project Properties Dialog

In most situations, you will have one TOC that you use for a particular output (target). In that case, you simply associate the appropriate TOC with the target. If you have multiple TOCs that you want to include in the same project or output target, the TOC that you associate with the project or target serves as the primary TOC. In your primary TOC, you have the option of creating links to the other TOC that you want to include in the output. If you do not select a TOC, Flare will use the first one in the project (if there is more than one). If you have specified a primary TOC at the project level and another at a target level, the TOC at the target will take precedence. Click in the field and select a table of contents (TOC) from your project to use as the primary one. If you click the Edit button, the selected TOC opens in the TOC Editor. See Associating a Primary TOC With a Project.

After you create a page layout and configure its frames and settings as necessary, you need to associate the page layout with the appropriate content. In most cases, you will probably want to associate different page layouts with various entries in your outline TOC (so that different page layouts can be used for different parts or chapters in a manual). Otherwise, you would associate a single "primary" page layout with an entire target or project; in that case, the same page layout will be applied to all topics in that target or project. You can associate a page layout with an outline TOC entry with or without creating a chapter break at the same time. Click in the field and select a page layout from your project to use as the primary one. If you click the Edit button, the selected page layout opens in the Page Layout Editor. See Associating Primary Page Layouts With Projects.

The branding stylesheet (Branding.css) specifically identifies values for branding elements for your project. When you add a new branding file to a project it will not include all the necessary connections for instant results, but it will tie the stylesheet to a project if you select it as your primary branding stylesheet. (The branding stylesheet can also be associated at the Target level.) If you click the Edit button, the selected stylesheet opens in the Branding Editor. See Associating a Branding Stylesheet at the Project Level.

If you have a Flare project open—and bind detection in the Options dialog is disabled, or if you don't already have a repository in the folder—you will see a button that lets you bind (i.e., connect) it to a source control application (see Binding a Project to Source Control). Binding a project to source control lets you take advantage of the many multi-author features available through source control integration. This includes automatic check-in, check-out; viewing differences between source control and local copies of the project files; and more. If the bind detection option is enabled in the Options dialog and you already have a repository in the folder, which Flare locates, the project will automatically become bound to it. See Source Control.

You can remove the connection between the Flare project and a source control provider. You can also disable a provider so that the Flare interface is not available for source control tasks for that provider. See Unbinding or Disabling a Source Control Provider From a Project.

When you are finished editing files, you can check them in to source control. Checking in a file overwrites the old copy of the file in the database with the new one from your local machine. Even if others are not working on a file, it is a good idea to periodically check in files for a backup in source control. You will see this option if your project is bound to Microsoft Team Foundation Server. See Checking In, Committing, and Submitting Source Control Files.

When you are finished editing files, you can commit them to source control. If you are working with Git, committing a file adds your changes to the local database. When you are ready to add your local commits to the remote repository, you can push these files to the remote. If you are working with Subversion, committing a file overwrites the old copy of the file in the source control database with the new one from your local machine. You will see this option if your project is bound to Git or Subversion. See Checking In, Committing, and Submitting Source Control Files.

When you are finished editing files, you can submit them to source control. Submitting a file overwrites the old copy of the file in the source control database with the new one from your local machine. So even if others will not be working on that file, it is a good idea to periodically submit files so that you have a backup in source control. You will see this option if your project is bound to Perforce Helix Core. See Checking In, Committing, and Submitting Source Control Files.

When you need to work on any of the Flare project files, you can check them out. Checking out files means to copy the latest source control files to your local Flare project and remove the "Read Only" designation from them so that you can edit the files. A red check mark is displayed next to each file that is checked out. You will see this option if your project is bound to Microsoft Team Foundation Server or Perforce Helix Core. See Checking Out Source Control Files.

When you are working, you may want to lock the files you have modified. Locking a file does not prevent other users from modifying the file. However, no one else can commit a file that you have locked until you unlock the file. If your project is bound to Subversion, you can steal a lock from another user if you need to commit a locked file while they are working on it. Likewise, another user can steal a lock on a file you have locked. You will see this option if your project is bound to Perforce Helix Core or Subversion. See Locking Files.

If you have locked a file, you should unlock it when you are done modifying it. Other users can modify the file while you have it locked, but they cannot submit a locked file until you unlock it. To help prevent file conflicts and make sure that everyone on your team has the most current version of the file, you should unlock and submit the file when you are finished working on it. You will see this option if your project is bound to Perforce Helix Core or Subversion. See Unlocking Files.

After you bind a Flare project to a source control application, you can get the latest version of any of the source control files. When you do this, you are copying the most current files stored in the source control application to your local Flare project without necessarily checking out the files. This means that the "Read Only" designation will remain associated with the files until you check them out. You will see this option if your project is bound to Microsoft Team Foundation Server or Perforce Helix Core. See Updating or Getting the Latest Version of Source Control Files.

After you bind a Flare project to Subversion, you can update any of the source control files. When you do this, you are copying the most current files stored in Subversion to your local Flare project. When working with other authors, it is a good idea to do this frequently (e.g., at the beginning of each day) in order to ensure you have the latest changes that those authors have made, and that they have the latest changes you've made. You will see this option if your project is bound to Subversion. See Updating or Getting the Latest Version of Source Control Files.

If you have files checked out from source control but do not want them checked out anymore, you can use the "Undo Check Out" option instead of checking in the files. You will see this option if your project is bound to Microsoft Team Foundation Server. See Reverting or Undoing a Checkout of Source Control Files.

If you have modified files from source control but do not want to keep your modifications, use the "Revert" option instead of committing the files. While committing the file would save changes to source control, reverting a file returns it to its previously committed state and does not commit any of your new changes to source control. When reverting changes made in Git, you only revert changes to the file on the branch you are currently editing. If you have a file that resides on multiple branches, copies of the file on other branches are preserved. You will see this option if your project is bound to Git, Perforce Helix Core, or Subversion. See Reverting or Undoing a Checkout of Source Control Files.

One of the benefits of Flare's integrated source control is that you can view the history and differences for a particular file. You will see this option for all source control providers. See Viewing Differences in Source Control Files.

One of the benefits of Flare's integrated source control is that you can view the history for a particular file, including who checked in the file and when it was checked in. You can also view differences between different versions of the file and roll back to an older version if necessary. You will see this option for all source control providers. See Viewing the History of Source Control Files.