Andrei Costescu:
Anyway, I would recommend in this case (if I got right what you were doing) that you set “startAsTeamProvider=false” for your developer and use the application server as a Servoy Team provider instead of “localhost” - just use the IP address/hostname of your app server. (127.0.0.1 if it is also running on the local machine, but separately started).
This way team commits would affect the app server directly, not indirectly through the repository database.
I tried that, using the IP of the app server and set “startAsTeamProvider=false” in my developer, but when I checkout a solution I receive an error: “Invalid thread access”.
The Invalid thread access exception has been fixed in 4.1. Anyway, this appears if for some reason the solution list from the given app server is not accessible. So in fact it is only hiding the real - more useful error message.
In order to be able to use the remote app. server as team provider you have to set “startAsTeamProvider=true” on the application server. So “startAsTeamProvider=true” for the app server and “startAsTeamProvider=false” for the developer. Also supply a valid user/passwd for the remote app server.
Another reason why this could fail is that the IP/hostname is not reacheable via the network…
Let me see if I get this right: you have Servoy Developer 4 running with admin setting “startAsTeamProvider=true”. You use Servoy team provider that points to “localhost” for your solution projects and resources projects. You also have another Servoy app server that runs separately based on the same repository database as Servoy localhost team provider does.
It’s OK!
In this case, after you modify something in security, if you want it visible on the app server, you need to commit the changes (using Team → Commit or Team → Sychronize then commit on your Security node or Resource project). This way, the security changes that you changed locally in Eclipse will be pushed into the repository database. After this restart the app server to reload the security settings from your repository database.
I think I’m doing something wrong, because I active the tracking for all secutiry groups, I do what you say (commit changes, restart app server) and I do not see any records in the log
Andrei Costescu:
Are you sure the app server uses the same repository database and log table?
In my developer I have 2 Database Servers: repository_server (pointing to “DBServer/Servoy”) and log_server (pointing to “DBServer/Servoy_log”). And in the app server I have 2 database servers: repository_server (pointing to “DBServer/Servoy”) and log_server (pointing to “DBServer/Servoy_log”).
Ok. I think I know what happened. I told you to Commit/Synchronize on your Security node… But that only synchronizes the users/groups (on file from the resources project), not the form/table security settings (that are kept in the solution project/other folders in the resources project). Sorry about that.
You will have to commit/synchronize on the “Resources” node for table security (and on the solution node for form security - if you use it). The best way to go - to make sure everything is in sync with the team provider is to sync on the active solution while the following Window-Preferences-Servoy-Team options are checked (as they are by default) - “Synchronize/commit/update solution, also do it on resources” and “Synchronize/commit/update solution, also do it on modules”.
Hmm. Even if you do synchronize and you see a sec file as outgoing change, choosing commit on the sec file will not really commit it; commit will not commit - this is a problem that we must solve. All sec files should be commitable individually / together with the resources project or with a folder that contains them.
So the only way you can currently really commit sec files (with Servoy team provider) is to choose “Commit” on the entire “Database Servers” node (in case of table security) and on the entire solution (for form security).
Andrei Costescu:
Hmm. Even if you do synchronize and you see a sec file as outgoing change, choosing commit on the sec file will not really commit it; commit will not commit - this is a problem that we must solve. All sec files should be commitable individually / together with the resources project or with a folder that contains them.
So the only way you can currently really commit sec files (with Servoy team provider) is to choose “Commit” on the entire “Database Servers” node (in case of table security) and on the entire solution (for form security).
It works! I had to commit on the database servers and the table security settings are now in the app server. Thanks!
I have read this thread and Paul’s very helpful posting called ‘TIPS: Team Support Basics’ (found here: http://forum.servoy.com/viewtopic.php?f … &sk=t&sd=a). Thank you all for the info. I have a couple more questions about the workspace/repository relationship. I am a standalone developer - no team.
1 - I’m confused about the ‘HEAD’ which you see in the repository when checking out a solution. What’s the difference between HEAD and the most recent release? If I check out the HEAD and then do a commit, am I updating the most recent release or the HEAD? At ServoyWorld I believe we were told that checking out the head was the same as checking out the most recent release but I’d like confirmation of that.
2 - Under 3.x, if I checked out a release that was not the most recent release, I was not allowed to save my changes to the repository. What about under 4.x? If I check out something other than the most recent release will I be allowed to commit? If so, which release is updated? The release I checked out? The most recent release? The HEAD?
3 - If I already have release 5 of a solution checked out and I decide I want to look at release 4, I have taken to first deleting the solution from my workspace first by right-clicking on the solution under the ‘solutions’ node and selecting ‘Delete’. It’s probably not necessary but it seems like the prudent thing to do. When I do this I am asked if I “also want to delete contents under workspace MY WORKSPACE DIRECTORY\solution_name”. I find this question confusing. If I’m deleting the solution from my workspace, why would I want to leave the files in my workspace?
4 - When I commit, I am often told that I have conflicts with .dbi and .obj files that I don’t remember touching. From reading other threads I know how to resolve these “conflicts” but I’m wondering why this keeps happening?
1 - I’m confused about the ‘HEAD’ which you see in the repository when checking out a solution. What’s the difference between HEAD and the most recent release? If I check out the HEAD and then do a commit, am I updating the most recent release or the HEAD? At ServoyWorld I believe we were told that checking out the head was the same as checking out the most recent release but I’d like confirmation of that.
HEAD means the most recent release, but this is used not only on checkout but on all the future team operations, this is why it is not the
same if you checkout HEAD or latest release, as latest release is a fixed release number.
2 - Under 3.x, if I checked out a release that was not the most recent release, I was not allowed to save my changes to the repository. What about under 4.x? If I check out something other than the most recent release will I be allowed to commit? If so, which release is updated? The release I checked out? The most recent release? The HEAD?
you can only update the latest release, as HEAD will always means latest release, it can always be updated
3 - If I already have release 5 of a solution checked out and I decide I want to look at release 4, I have taken to first deleting the solution from my workspace first by right-clicking on the solution under the ‘solutions’ node and selecting ‘Delete’. It’s probably not necessary but it seems like the prudent thing to do. When I do this I am asked if I “also want to delete contents under workspace MY WORKSPACE DIRECTORY\solution_name”. I find this question confusing. If I’m deleting the solution from my workspace, why would I want to leave the files in my workspace?
this is usefull if you don’t want do delete the solution’s files, only hide them from eclipse, and maybe later import it again
4 - When I commit, I am often told that I have conflicts with .dbi and .obj files that I don’t remember touching. From reading other threads I know how to resolve these “conflicts” but I’m wondering why this keeps happening?
it is possible that you did operations that also touched that files; even if there content remained the same, if there timestamp has changed, they will appear as changed
What I am finding is that after a commit, it makes no difference whether I check out the most recent release or the HEAD - either way I get my most recent version. So I don’t really see any difference between most recent release and head. But I am a lone developer - perhaps HEAD has more relevance in a true team environment.
What DID surprise me is that if I check out an earlier release without first deleting that solution from my workspace, I don’t get the earlier version. It seems you have to delete before checking out earlier versions.
I need help committing my sec files. They will commit but will automatically come back as an update when I sync my solution. All help would be appreciated.
Andrei Costescu:
Hmm. Even if you do synchronize and you see a sec file as outgoing change, choosing commit on the sec file will not really commit it; commit will not commit - this is a problem that we must solve. All sec files should be commitable individually / together with the resources project or with a folder that contains them.
So the only way you can currently really commit sec files (with Servoy team provider) is to choose “Commit” on the entire “Database Servers” node (in case of table security) and on the entire solution (for form security).
It works! I had to commit on the database servers and the table security settings are now in the app server. Thanks!
I have the same problem, again… I’ve changed the security of a form, I’ve commited the .sec file, the entire solution, but the file isn’t commited. When I try to sync the solution, I see the .sec file as ingoing change
can you please create screenshots with the
team synchronizing perspective, when all the files
are in-synch, then after you changed the security setting,
and finally after you did the commit, and put them into a case
in our support system ?