woolfg / dokuwiki-plugin-gitbacked

Plugin for DokuWiki to store/sync files and media with a git repo
GNU General Public License v2.0
71 stars 26 forks source link

Is it possible to use multple git repos? #47

Open mifritscher opened 5 years ago

mifritscher commented 5 years ago

I would like to use one git repo per "main directory" to enable fine-grained permissions on the git side.

woolfg commented 5 years ago

I think you have to change a lot for this feature. Can you elaborate more on your use case?

hmcts-jmoore commented 5 years ago

I would like to use this for editing / storing documentation in source control alongside the source code it refers to, so that both are versioned in-sync. There would be multiple independent projects, possibly stored in different Git hosting systems. To do that, I'd want something like:

woolfg commented 5 years ago

I do not know exactly how Dokuwiki organizes namespaces in the file system but if there is one folder per namespace, maybe a quick and dirty solution would be to using symlinks from one folder to the respective repo? Otherwise, the implementation might be a bit of work, but I am happy to help by reviewing and merging it to the project.

KamarajuKusumanchi commented 1 year ago

This feature would be very useful. In my case, I have multiple namespaces - some public, some private, and some shared between a handful of users.

In general, let's say a dokuwiki instance has n namespaces (N1, N2, ..., Nn). For each namespace there are two types of data - pages which is text, media which is binary. So we have 2n categories - (N1t, N1b, N2t, N2b, .... , Nnt, Nnb) where the last letter indicates whether the underlying data is text or binary.

Assuming that the user wants to track all 2n categories in github repositories, we need a configuration setting that accommodates the following.

{repo1: [N1t, N2t], repo2: [N1b, N2b], repo3: [N3t, N4t], repo4: [N3b], repo5: [N4b], ...}

Basically, we need to be able to map all the 2n categories to an arbitrary number of user specified repos.

mhoffrog commented 1 year ago

@KamarajuKusumanchi Many thanks for your comment!

Exactly this feature is already implemented on branch issues/47_multiple_repos and functional wise tested but not yet merged to master. Unfortunately I was limited in time to finalize and merge this branch, since that merging requires an appropriate update of the documentation to describe probable scenarios.

The branch implementation is backward compatible to current installations.

You can give it a try installing the plugin manually from that branch.

You can follow the descriptions of the config properties. This implementation does not need much config at all anymore, since the repo's are "auto determined" by looking up directories from the file/document changed to the next repo available in current or next parent directory. Since namespaces are managed as directories by DokuWiki this will meet your requirement.

Your feedback is more than welcome as well as a contribution to the documentation update.

handmeatowel commented 10 months ago

Any chance this will be merged soon? Anything we can do to help to expedite the process?

mhoffrog commented 10 months ago

Any chance this will be merged soon? Anything we can do to help to expedite the process?

@handmeatowel - hey this sounds promising - many thanks for your engagement! Please provide us with some testing and config comments review feedback. If you have some ideas how to extend the existing documentation to describe the new feature this is also more than welcome. You can manually install the extended plugin with DokuWiki extensions admin UI importing from 47_multiple_repos.zip. Please read through the gitbacked configuration comments and review the descriptions, if it is of help for you. Let us know what you would improve, if you stumble on the one or other item. In principle you should set the auto determining config (which is the default on that branch now) and leave the legacy explicit repo path configs empty. Then it depends on your preferred scenario how to continue - so lets say one of these scenarios:

  1. You want to separate archiving of pages from binary media by commiting changes to either separate repos or separate orphan branches in the same repo not to mix binary data with text data commit history

    • In this case you create:
      • data/pages/.git - configured vs. remote repo1 or orphan branch 'dw_pages' in your single remote repo
      • data/media/.git - configured vs. remote repo2 or orphan branch 'dw_media' in your single remote repo
  2. You want separate repos within namespaces

    • In this case you create something like:
      • data/pages/namespace1/.git - configured vs. remote repo1 or dedicated (orphan) branch dw_namespace1 in a single repo
      • data/pages/namespace2/.git - configured vs. remote repo2 or dedicated (orphan) branch dw_namespace2 in a single repo
      • data/pages - not configured for any repo
        :bulb: You should not configure .git repo paths above namespaces that contain .git repopaths, unless you configure .gitignore properly on those levels.
  3. ... based on your own creative ideas

Many thanks for your feedback in advance!