MadCap Software Forums

Hi,

I am investigating if it is feasible to use Global Project Linking across different repos in Azure DevOps.

The general idea is to have a parent Flare project containing just the Page Layouts which will include different branding to be used by our different teams, this will be in one repo and accessed and maintained by Marketing for example. We will then have multiple separate repos containing Flare projects which will be maintained by different teams. These projects would ideally import the Page Layouts from the parent repo.

We have got one of the intended child Flare projects in Azure DevOps so are comfortable with source control on the projects from a standalone perspective.

My assumption is that this is probably technically possible, but not a clean way of working. Would I be correct in saying that all 'child teams' will need access to the Parent Flare project/repo and they will have to manually load this and synchronise any changes that have been made to the Page Layouts? The child project would then pick up these changes from the users locally synchronised files of the parent project or something?

Ideally of course the child teams wouldn't have any kind of write access to the parent repo and any changes to the parent would be automatically synchronised either when a change to the parent is made or when a child project is opened.

Has anyone got any experience with this sort of distributed way of working where a separate team is maintaining the branding in a parent project in a different repo?

Ultimately we are going to set up a couple of test projects and repos and play around with it, but any advice or guidance you can provide is greatly appreciated.

Did you continue playing with this idea and have anything to report on this experience? I'm considering something similar, and the only answer I've seen is to commit our templates to a repository and link new projects to the local repository of the template. Here's that post. viewtopic.php?f=13&t=31329

I'm using TFS rather than Azure DevOps, but you'll get the same problems with project imports (GPL) whatever source control you use.

Most of the problems we had were down to two reasons:

(1) When you set up a project import (GPL) in Flare, you can only set it up to import files from somewhere in the Windows filesystem (a local or network drive)- but not from the actual files in source control itself.

This means that everyone that runs the project import must use an identical folder structure (path) for the project you're importing - which most people probably won't be using.
We solved this by getting everyone to map a drive letter to the project folder on their PC (e.g P:/ = c:/whatever/projects/), and set up the project import relative to the mapped drive letter P:/ (not their C:/ drive).

(2) When you run a reimport, it will decide what files to import based on the timestamp of your local copy of the file, which is not the same thing as comparing the file version from source control.

By default, when you reimport files it will only include files marked "source is newer" (green), and doesn't import files if the "local is newer" (red). However, these file date comparisons depend on when you last got the local copies of both projects from source control. So you can get different results depending on the order you get files from source control and run the import. Also, these dates are also being compared to the dates saved from the last project import, so if that was run by a different person (or PC) their local copies of files will have different dates to yours.

Anyway, this caused problems for us because genuinely new files were not getting reimported, because the import didn't think they were new from the source. So when you reimport you must select to overwrite "local is newer" (red) files too, which ensures you import any file that is different.