An optimal way to store forum in git

[sashabe]

I'm looking for an advice on a best way to keep a git repo on production in order. The installation is 2.0.11.
When working with other CMS I usually store only theme files and custom modules/plugins in Git. Everything else — other people's plugins and core files — is omitted from repository to allow those plugins and core to be updated without messing up the git state.
We know that SMF is extendable by packages in its own way - the packages, when being installed, look for specific lines in the core or theme files' source code and overwrite it with its own code.
Therefore, if a forum admin (unrelated to me) would like to update/install/disable a mod from the forum interface, then chances are it would change files in the current theme directory and make the git state "dirty" on production.
Is there any solution/workflow for a situation like this? Have anybody tried to deal with this peculiarity of SMF mod system? I understand that we may create hooked mods but it seems that on 2.0.x there might not be enough hooks for the whole range of features we need.

[live627]

This seems like a wonderful idea to easily keep track of code changes. I'm thinking that a cron job would work for this. Write a shell script to grab a dump of the files, and commit if git reports changes.

[sashabe]

Thanks live627 for your reply and an interesting suggestion!
Committing every time files change may not have much sense though — because you can't know what was that commit about. Was it core update, or specific plugin installed, removed, or updated?...  I'm also not sure that updates should belong (ideally) to the development flow — only files that are worked on by developers should be there, I think. But that's in an ideal situation, may not work well in case of SMF.
This is probably not a idea, but rather more of asking advice how people use their SMF in conjunction with Git or other version control system to control the development.

[Arantor]

People generally don't, simple as that.

Me personally, I keep repos for each plugin and for the theme since I try to go for hooks wherever possible and frequently what I end up doing is making a plugin that is "the site" changes.

Depends on the situation.

[sashabe]

Thanks Arantor. I'm not sure yet if we'll be able to keep all the plugins hook-only, but if yes, then the problem is solved. It's just there's about 10 features to be implemented, and I'm not sure we will be able to use hooks only for all of them.
We're thinking of gitignoreing everything, except for our custom packages (their name may begin from a certain word, say custom_ that will be put as a regex into .gitignore) and our copy of default theme. That way:

1. Admins will be able to update core files on their own without messing up the repo state — because Sources folder, default theme and root files are not in the git;
2. Admins will be freely able to update external non-hook packages and the changes done by them will not make the repo dirty — because everything is ignored in the Packages folder (along with those folders above) except for subfolders in Packages that begin from custom_;
3. We just need to make sure that changes done by a custom package are committed in the same commit with the changes in the package files itself - to track correctly which change belongs where.

But it's just theoretical for now, I'm still unsure if that's gonna work correctly. What do you say? Are there any shortfalls in this scheme?

[Arantor]

In which case I'd still be inclined to make the plugins their own repo, though whether that's one repo per plugin or one huge repo for 'the mod package that contains everything' is entirely what works for you.

Your approach sounds like it would work for you but speaking as someone that's written many, many mods, I'm not sure how maintainable it will actually be because I'm not sure you really need to track the interim state of forum beyond the mod packages.

[sashabe]

Thanks for the reply. Yeah, I should actually test it and see if it works. But the idea is now that we don't want to track anything apart from our plugins and custom theme (it's gonna be built from scratch with completely different markup etc.) Regarding one/many repos for plugins problem, it's the internal structure of our git — one repo per site project — that forces us to place mods inside the site repo.

[Suki]

I have tried both, to use branches and make separate repos even a combination of both.

I use branches when the modifications focuses on file edits, I use separate repos when mods are mostly hook or completely hook based.

Using branches has the advantage of automatic merge (where possible anyway) and have an unlimited amount of branches (for your needs anyway)  if there are two mods that conflict with each other you can manually merge them on a different branch (call it mod Y plus mod X).  It also works wonders for small, manual hacks/edits, providing you tag/name your branches in a structured way.

[sashabe]

Thanks Suki. I may have to think about using branches for storing the site again, after seeing this article — hxxp:www.chandlerfamily.org.uk/2011/03/managing-smf-software-in-git/ [nonactive], though this seems overly complicated.

Another question — I'm trying to actually implement the system described earlier in this thread, but in a bit different way for now, symlinking custom theme and Packages folder from git folder (that would contain only those two) to the web root folder where all the other stuff like Sources, attachments etc is. But it seems SMF doesn't pick up symlinked folders — neither Packages nor Themes — for some reason.

Have somebody ever tried to symlink parts of SMF installation? That's a usual thing we do with Drupal/Wordpress.

[Suki]

It seems complicated indeed but I suppose it largely depends on your needs, for example, is this for you or a team?

I don't have that much experience with symlinks, sorry.

[sashabe]

Thanks Suki. It is supposed to work with a team of devs, yes, that's why it needs to be planned so thoroughly.

I finally found what the problem was — it was not SMF fault but the Vagrant box' that I use. So SMF supports symlinks very well. The problem was that in a Vagrant environment symlinks should be created from inside the virtual machine (vagrant ssh), not from the local machine, otherwise naturally the web server inside the virtual machine will be unable to follow the absolute path which doesn't exist in it (say, in a box it'd be /var/www/smf and on local /Users/user/sites/smf, and the latter doesn't exist inside the machine which is why the link is not being followed).

[Suki]

I use the combo vagrant/puppet/puphpet  for SMF test environments and so far it has worked pretty well