ahaha Im stuck now… anyway I can roll back to before this error?
Before I did all this I copied and pasted the entire project folder to another one on my desktop as a backup. Am I able to just copy and paste this backup version overwriting everything in the original one to go back?
Should be possible. If you right click on a commit you can choose revert to this commit.
If your copy contains the git commit history, that should be possible. Just copy the whole project folder back, close wappler, reopen and refresh the git history. git stores all its history commits with all code changes localy in your project, unlesse you push to your remote repository.
Okay so copy and paste went fine but error keeps showing up
Hmm, no clue what that could be. .DS_Store is apple specific. I’ve never worked with one.
Your error just says, that on your desktop copy this isn’t a directory…
I created a new repo…pushed to new repo… error remains. aaagh
Thats not a problem of git, push or repo. There has to be a problem in the local project. If you try to revert to a old commit, and discard all never commits (you should get asked if you click revert to commit) do you get also an error?
Really wierd… I created a new .DS_Store file in github, pulled it in wappler, then deleted in git, pulled again in wappler… error is now gone!
Also… whats difference between reset and revert?
Revert does usually creates a new commit, that undoes the changes of the reverted commit. So it extends your git history with a new commit, to undo, usually the last commit (it will keep the old commit, that you want to revere)
Reset modifies the whole git history. It jumps back to the specific commit, activate this one as “life” and discards all commits after that point.
My old teacher said ones, only use reset if you completly messed up the shit 
Use revert if you can find the error and fix it. It’s more about, that you can take a look on old code if the same error comes up again.
Eventually the file got corrupted while copying. Perfect if it’s working 
Hi @daves88,
To effectively handle multiple tenants, I suggest you restructure your app to use tenant specific data or configuration from the database. This way you avoid dealing with all the git merge issues or other configuration problems.
I assume that each tenant will have a separate database but all share the same source code. The source code can be for all tenants and can be pulled automatically from one master branch on GitHub when you apply any changes to your application.
Because the tenant specific data or configuration is from the their own database, they can all have the changes made to the source code but still maintain their individual configurations such as brand name, brand color, logo, etc.
So the styling of your application has to be from the database using dynamic attributes if you want it to be applied for all tenants. Using the css file will not work in this scenario.
Tenant data such as brand name also has to come from the database.
At the end you will deploy all tenants with a copy of the default database and the source code linked to the master branch on GitHub. When they make changes to their own application, they are modifying their own database.
I hope this helps.
Thanks Kenneth. This is the best way forward.
-
Create an admin file that stores brand specific details for a tenant that gets saved to their database. So when a new tenant is forked they logon and update these details so edit their skin (colors logos font type etc),
-
Only work on the master repo when creating new features. Never on the forked tenant. This way no conflicts can occur.
-
When I need to create a new feature only specific to a particular tenant, I still create this feature in Master but I need to figure out a way to only enable it for that specific tenant only, and to be ignore by all other tenants.
What do you think?
Database implementation is the ideal way. New features are developed on the master branch. However, access to those features are controlled from the database.
Let’s say I developed a schedule calendar module as a new feature. In the database, I would have a table for features/modules. I would also have a table for user/tenant subscriptions where it details what features or modules each tenant has access to.
In the front end, I would set conditions to the modules/features to only be accessible to tenants if they are permitted to. So if tenant 1 is permitted to use the schedule calendar module they will automatically have access to it.
All tenants should be able to use the same source code from the master branch.
Except in a situation where a tenant requires a specific feature in their application that will never be used by other tenants. So you have to just create a different branch for that tenant and manage it separately.
1 Like