The plan is to get one single script in the parent repository to synchronize all content, including the submodules.
Working solution by #26, still some issues for later dev, all submodule synchronised with same variables (in script)
CURRENT Plan 2020-11-18
One script in the parent
One config file (text) in the parent, contains also variables for submodules.
get first version using the current gin-cli.
future: use datalad? update gin-cli with submodules capacities?
Questions:
update system for synchronisation scripts (i.e. scripts and config files)?
variables will depend on the computer:
config file should not synchronise
how to handle variables for parent and variables for submodules ?
We probably need to think about different use cases to answer this.
The plan is to get one single script in the parent repository to synchronize all content, including the submodules.
## Working solution by #26, still some issues for later dev, all submodule synchronised with same variables (in script)
CURRENT Plan 2020-11-18
- One script in the parent
- One config file (text) in the parent, contains also variables for submodules.
- get first version using the current gin-cli.
- future: use datalad? update gin-cli with submodules capacities?
Questions:
- update system for synchronisation scripts (i.e. scripts and config files)?
- variables will depend on the computer:
- config file should not synchronise
- how to handle variables for parent and variables for submodules ?
We probably need to think about different use cases to answer this.
One idea could be to have a sync script in each submodule, and the script in the parent would look for them and run them in the correct folder.
This way we could also deal with submodules in submodules, submodules coming from gitlab (i.e. not using gin) ?
It would then need to give an warning if one submodule was not updated.
?
One idea could be to have a `sync` script in each submodule, and the script in the parent would look for them and run them in the correct folder.
This way we could also deal with submodules in submodules, submodules coming from gitlab (i.e. not using `gin`) ?
It would then need to give an warning if one submodule was not updated.
?
One idea could be to have a sync script in each submodule, and the script in the parent would look for them and run them in the correct folder.
This is very interesting. Hadn't considered it but it's a pretty good solution, I think. Submodule syncing can be done individually when required. This might put things out of sync, but it also might be a feature if users want to work on a submodule separately (e.g., light tweaking of scripts without cloning entire repository structure).
It would then need to give an warning if one submodule was not updated.
Sounds reasonable. We could do this, yes.
> One idea could be to have a sync script in each submodule, and the script in the parent would look for them and run them in the correct folder.
This is very interesting. Hadn't considered it but it's a pretty good solution, I think. Submodule syncing can be done individually when required. This might put things out of sync, but it also might be a feature if users want to work on a submodule separately (e.g., light tweaking of scripts without cloning entire repository structure).
> It would then need to give an warning if one submodule was not updated.
Sounds reasonable. We could do this, yes.
I was thinking about having the script in a submodule and calling them from the parent, so that the script would update when we update the script repository.
This does not work with the idea to have each submodule to have its own script ?
Maybe submodules could have a specific file (script-variable.yml ?) that would tell the main script what to do there, but keep the "what to do" information in this script submodule ?
What do you think ?
About the possibility to update scripts later on:
I was thinking about having the script in a submodule and calling them from the parent, so that the script would update when we update the script repository.
This does not work with the idea to have each submodule to have its own script ?
Maybe submodules could have a specific file (script-variable.yml ?) that would tell the main script what to do there, but keep the "what to do" information in this script submodule ?
What do you think ?
Another way to go would be to have a special function in the script, and make updates in the gin-cli:
Script would be:
cd to the right folder
read a metadata file (.gintonic)
run gin tonic
Inside .gintonic, I would see (my current ideas):
upload_changes: yes
ask_for_commit_message: no
download_gitannex_content: no
The gin tonic command would:
look for .gitmodules
if found, run gin tonicin each module folder, one after the other.
if not found, or if all sub-modules were done:
pull new changes
if download_gitannex_content == yes, download content
if ask_for_commit_message == yes:
ask for message
give commit message
if upload_changes: yes, git commit and push
What do you think? The logic should be worked a bit (upload_changes: no
ask_for_commit_message: yes, would make problems), but I do not want to think to much about this before we talk about the principle.
what about use with gitlab repositories?
how to ensure we have the latest version of the gin tonic command?
Another way to go would be to have a special function in the script, and make updates in the gin-cli:
Script would be:
- cd to the right folder
- read a metadata file (.gintonic)
- run `gin tonic`
Inside `.gintonic`, I would see (my current ideas):
```
upload_changes: yes
ask_for_commit_message: no
download_gitannex_content: no
```
The gin tonic command would:
- look for .gitmodules
- if found, run `gin tonic`in each module folder, one after the other.
- if not found, or if all sub-modules were done:
- pull new changes
- if download_gitannex_content == yes, download content
- if ask_for_commit_message == yes:
- ask for message
- give commit message
- if upload_changes: yes, git commit and push
What do you think? The logic should be worked a bit (upload_changes: no
ask_for_commit_message: yes, would make problems), but I do not want to think to much about this before we talk about the principle.
- what about use with gitlab repositories?
- how to ensure we have the latest version of the gin tonic command?
I'm not sure about adding config files that are specific to these kinds of use cases. I think that adds unnecessary complexity to the client (reading configuration files to perform actions) that can best be served by just running a set of commands (like in a script).
I'm not sure about adding config files that are specific to these kinds of use cases. I think that adds unnecessary complexity to the client (reading configuration files to perform actions) that can best be served by just running a set of commands (like in a script).
I looked like the simplest solution for me to get:
double-click one unique file to synchronise all submodules
give the user the possibility to switch synchronisation off for specific submodules (easily)
possibility to update scripts once the repo were created.
Would you propose another strategy ? Or would you like to forget about part 2 for the MVP and implement that later?
(maybe we could have just a warning message for the first version:
"You are about to synchronise all changes with the GIN server, no commit message will be added to it.") or have the possibility to ask for a commit message ?
I looked like the simplest solution for me to get:
1. double-click one unique file to synchronise all submodules
2. give the user the possibility to switch synchronisation off for specific submodules (easily)
3. possibility to update scripts once the repo were created.
Would you propose another strategy ? Or would you like to forget about part 2 for the MVP and implement that later?
(maybe we could have just a warning message for the first version:
"You are about to synchronise all changes with the GIN server, no commit message will be added to it.") or have the possibility to ask for a commit message ?
The plan is to get one single script in the parent repository to synchronize all content, including the submodules.
Working solution by #26, still some issues for later dev, all submodule synchronised with same variables (in script)
CURRENT Plan 2020-11-18
Questions:
We probably need to think about different use cases to answer this.
One idea could be to have a
syncscript in each submodule, and the script in the parent would look for them and run them in the correct folder.This way we could also deal with submodules in submodules, submodules coming from gitlab (i.e. not using
gin) ?It would then need to give an warning if one submodule was not updated.
?
This is very interesting. Hadn't considered it but it's a pretty good solution, I think. Submodule syncing can be done individually when required. This might put things out of sync, but it also might be a feature if users want to work on a submodule separately (e.g., light tweaking of scripts without cloning entire repository structure).
Sounds reasonable. We could do this, yes.
Add code before the sync itself:
Note: synchronise repositories from the bottom up (deepest first).
About the possibility to update scripts later on:
I was thinking about having the script in a submodule and calling them from the parent, so that the script would update when we update the script repository.
This does not work with the idea to have each submodule to have its own script ?
Maybe submodules could have a specific file (script-variable.yml ?) that would tell the main script what to do there, but keep the "what to do" information in this script submodule ?
What do you think ?
That's a good idea. I'll have to think about it a bit, but on first consideration I don't see any issues.
Another way to go would be to have a special function in the script, and make updates in the gin-cli:
Script would be:
gin tonicInside
.gintonic, I would see (my current ideas):The gin tonic command would:
gin tonicin each module folder, one after the other.What do you think? The logic should be worked a bit (upload_changes: no ask_for_commit_message: yes, would make problems), but I do not want to think to much about this before we talk about the principle.
I'm not sure about adding config files that are specific to these kinds of use cases. I think that adds unnecessary complexity to the client (reading configuration files to perform actions) that can best be served by just running a set of commands (like in a script).
I looked like the simplest solution for me to get:
Would you propose another strategy ? Or would you like to forget about part 2 for the MVP and implement that later?
(maybe we could have just a warning message for the first version: "You are about to synchronise all changes with the GIN server, no commit message will be added to it.") or have the possibility to ask for a commit message ?