From DevOps to Git -- any gotchas?

[John Johann]

Hi,
I'm looking into migrating my passively snyched H&M projects to Git.
I know this is a very wide question, but is there anything I should pay particular attention to?
For example, the style repository and skins are currently separate and linked to Versions A,B,C ... of the help. Is that still possible or do I have to have individual repositories and skins for each branch version?
Thanks

[Tim Green]

Hi John,

When you are using a style repository you have two different projects: The Help+Manual project that everyone is working on and the style repository project, which only the project administrator should have access to, by definition. The version control copy of users' local working copies of the Help+Manual project doesn't include the style repository, because they don't have access to the project.

So how should this be handled? This depends on whether you are using the repository for styles only, or for both styles and topics as a source of snippets. Generally, I would recommend a repository with only styles if your users are in different locations, and the inclusion of snippets in the repository only if all users are on the same local network. (Users elsewhere would just see "Cannot find snippet" error messages in all the snippet locations.)

The repository project should not be included in the normal version control, since only the administrator can edit it. When the administrator edits the styles in the repository, the changes are reflected in his/her local working copy of the project, and these propagate to the users when the administrator synchronizes his project. That's simple and clear. If you want to manage the repository in a separate git folder for backup and rollbacks that's OK, but it wouldn't involve the regular users.

The situation is more complicated if you are also using the repository (or any other projects) as a source of snippets linked to the main project. Then the local users need access to it, because linked snippets are loaded live from the repository during editing, and the reference to the repository in the project is an absolute path. That is not a problem if all users are on the same local network: Then the repository can be stored on a network share to which all regular users have read-only access via the same path.

Things are different when users are in different geographic locations and the version control synchronizes over the Internet. Then including a local working copy of the repository for all users on the same local path as part of the version control would be theoretically possible, but exactly the same path would have to be used for the repository project on every user's computer, and the users would all have access to the repository. Or your version control would have to manage a folder that would be read-only for the local users, further adding to the complexity. A potentially better solution would be to have the repository in an online folder that is mapped to a local path with a drive letter and exactly the same path on every user's computer, including the administrator's.

[John Johann]

Hi Tim,
Thanks for the answer.
The repository only contains styles and is separate from the individual branches. Templates/skins are also separate.

I'd like to avoid branching the styles with each version A, B, C of the documentation but had been told different so wanted to check.

[Tim Green]

That's fine then, you can leave the repository out of the equation. The style changes made by the admin will propagate to the local copies when he/she synchronizes their copy.