Since 4.0 and Eclipse it seems I have a workspace and a repository and its a little confusing, as far as I know there is no documentation on the structure or inter-relationship between the two (hoping to be corrected here BTW ).
I understood in 3.5 the repository held all of the solution meta-data and was used to build the solution when it was deployed to a server (or shown in the Client on Developer etc).
Now with the workspace it appears that the same info is duplicated in both areas - Workspace directory and Repository table! Is this correct.
Is it that the workspace is there to allow multi-developers as a matter of course, and allow synchronisation?
As a single developer how does the workspace inter-react with the repository?
If the workspace is damaged will the solution be broken OR will the repository still have the solution stored?
Appreciate any feedback or links to further resources on the matter.
Hi Kahuna – As a fellow Servoy 4 beginner, I hope this answer is correct. But sometimes it helps to explain something in “beginner to beginner language”.
The repository is still the database where all the elements of your solution are stored.
When you check out your local repository to your workspace, it is written out into text files in the workspace (XML, I believe).
This allows you to make changes in your workspace that you can then simply dump, and your local repository will remain untouched. Therefore the split into “repository for solution-element storage, workspace for mucking around” can be quite valuable to the solo developer as much as the new Eclipse IDE is valuable to teams.
When teams work on a solution that is hosted on a single server:
– they would take the server repository down to their local repository
– check out the version from their local repository into their workspace
– make their changes in their workspace, then commit them back to their local repository
– synch their local repository to the team server in order to update the team server and resolve any conflicts.
I’m pretty sure that’s how it works, anyhow!
kazar
(former database guru, with emphasis on former, LOL)
kazar:
Hi Kahuna – As a fellow Servoy 4 beginner, I hope this answer is correct. But sometimes it helps to explain something in “beginner to beginner language”.
The repository is still the database where all the elements of your solution are stored.
When you check out your local repository to your workspace, it is written out into text files in the workspace (XML, I believe).
This allows you to make changes in your workspace that you can then simply dump, and your local repository will remain untouched. Therefore the split into “repository for solution-element storage, workspace for mucking around” can be quite valuable to the solo developer as much as the new Eclipse IDE is valuable to teams.
When teams work on a solution that is hosted on a single server:
– they would take the server repository down to their local repository
– check out the version from their local repository into their workspace
– make their changes in their workspace, then commit them back to their local repository
– synch their local repository to the team server in order to update the team server and resolve any conflicts.
I’m pretty sure that’s how it works, anyhow!
kazar
(former database guru, with emphasis on former, LOL)
Thanks Kazar - so if I understand you - the local workspace and the repository in my dev box are different as I move through the dev process (adding forms etc)?
So at what point does the repository get updated to what’s in my workspace? On Closing? Do I have to overtly synch or commit (even for a standalone developer)? They seem to be in synch when I push a new solution up to the server so I guess they are synched on export or something too?
As you see Kazar, truly is NooB time here with this …
When working alone using a repository is actually optional .
You can work just from your local workspace. Even running the debug rich- and webclient doesn’t require the repository.
So why use a repository in the first place ? Well for one it’s the only way to create releases that you can rollback when needed. Another reason is when you want to test with multiple clients then Servoy server needs to have that source in the repository database.
And the main reason to use a repository (Serclipse/SVN/CVS) is of course to be able to work with a team of developers on the same source.
As for when a repository gets in sync with your workspace, that is when you manually commit (send)/update (retrieve) the changes to/from the repository. And of course when you export the solution (from your workspace) and import that in a remote Servoy server.
As for when a repository gets in sync with your workspace, that is when you manually commit (send)/update (retrieve) the changes to/from the repository. And of course when you export the solution (from your workspace) and import that in a remote Servoy server.
Hope this explains things.
Yep, that ties it up thanks Robert - I assume you guys have figured this out by trial and error? Or is the some documentation on it that I missed?
Have you looked at the tutorials? You might find what you need in this one:
What’s New in Servoy 4.0 (FLASH)
The “What’s New in Servoy 4.0 Tutorial” covers these topics: The Eclipse interface; Servoy Security; Solution Checkout; Servoy Repository sharing/unsharing options; New Servoy 4.0 Form Features; and the new Servoy 4.0 Application Server settings. This tutorial is aimed at those of you already building Servoy 3.x (Servoy Classic) applications, who are interested in learning about new features/functionality in Servoy 4.0.
You’ll find a whole bunch of great material by going to the main website, clicking on Develop, then Tutorials in the left-side menu
ROCLASI:
Documentation ? Manuals ? I am a Mac user, remember? .
All joking aside. The Servoy manuals do cover the workspace in Eclipse but it doesn’t explicitly say that you don’t need a repository per se when you develop alone.
The Servoy 4.0 Developer User’s Guide does cover what the workspace contains though. See chapter 6.
I know that Marc Norman did a incredible job describing the new IDE and I know it’s very hard to cover every angle and detail. But perhaps he can cover the difference and pros/cons of the single developer/team developer approach in some more detail.
There are the manuals and there was Servoy World with presentations and 2 classes about it.
One of the presentations is done by me and I touched the workspace briefly.
One of the classes is also done by me and I touched the workspace quite extensively.
You can buy the docs. Send me an email at it2be dot com and I can give you a price for it.
The other way to go is just search for “eclipse workspace”. There you will find as much information about is as you like!
Well I have found this thread VERY useful - and feel it illustrates the great benefit of having a Forum to back up and extend the Servoy & Eclipse documentation.
Yes the information is probably covered in Mark Normans epic tomes and is available to all out on the Internet. But when someone has already discovered specialist information it helps the entire community move forward when they pass it on.
Thanks Robert - once again you answered a question I didn’t even know I should have asked
Andrei Costescu:
You should also have a look at Paul’s “Team support basics” post - might help you to better understand the workspace ↔ repository relationship. http://forum.servoy.com/viewtopic.php?f=38&t=11054
That write up by Paul really does clarify the whole workspace / repository situation, even for single developer ‘numpties’ like me! Wish I’d looked earlier .
And I didn’t even need to send Marcel any money!!! Result…
ROCLASI:
As for when a repository gets in sync with your workspace, that is when you manually commit (send)/update (retrieve) the changes to/from the repository. And of course when you export the solution (from your workspace) and import that in a remote Servoy server.
I think I understand the difference between workspace and repository, but…
My local repository is the same than the servoy server repository, so if I make changes in the solution, the clients can see theese changes (after flush it, of course). But I make changes in the security tab of a table (to activate tracking for a group), I right-click and select “Synchronize with database”, but the tracking remains disabled.
log-out:
My local repository is the same than the servoy server repository, so if I make changes in the solution, the clients can see theese changes (after flush it, of course). But I make changes in the security tab of a table (to activate tracking for a group), I right-click and select “Synchronize with database”, but the tracking remains disabled.
What’s the the proper way to do this?
Synchronizing with the database means you are synchronizing the .dbi files in your workspace with the database. So nothing is send to your repository with that command.
To send ANY changes to your repository you need to commit to your repository or import an exported solution into the repository (exported from your workspace).
I think the only exception is the administration of users and groups (when you are using the same repository as Developer) which makes sense because this is a repository object and NOT a solution object (well groups can be).
ROCLASI:
I think the only exception is the administration of users and groups (when you are using the same repository as Developer) which makes sense because this is a repository object and NOT a solution object (well groups can be).
Hope this helps.
It doesn’t
I start my developer, open (edit) a table and, in the Security tab, I check tracking for a group. Ok, I start the SmartClient from my developer and I make some changes. In the log table I see those changes. It’s Ok.
I start the Client (I connect to the Servoy Server) and I make changes, but I don’t see these changes in the log. Why?
question: where are your database connections pointing to?
In case you are using a databases on a different ip than the ones servoy application server are using (for instance: you work with local databases) you need to make sure the use of teamprovider in your local servoy-admin page should be set to ‘false’. This could be a common setup if you do a lot of remote development.
If you are in the situation described above, the database definitions will be saved to your local databases instead of being written to dbi files in order to synchronise correctly with your teamserver.
In fact 4.0 is default in ‘multi-developer’ mode which is great if you’re using the setup that way (when installing your teamserver or when you do standalone development).
I start my developer, open (edit) a table and, in the Security tab, I check tracking for a group. Ok, I start the SmartClient from my developer and I make some changes. In the log table I see those changes. It’s Ok.
I start the Client (I connect to the Servoy Server) and I make changes, but I don’t see these changes in the log. Why?
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.
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.
Tell me if I didn’t get your developer - team provider - app server setup right.
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.