Welcome to the video working in a team environment. For Servoy University, this is Scott Butler. In this video, we're going to show you how you can share your source code in a team environment. This allows you to collaborate with multiple different developers and synchronize the source code from your local machine with the source code from a centralized server. So there are two main different ways to do this with Servoix. The first out of the box way is using the Servoix team provider. The second way is using the other standardized methods like an SVN server. We're going to show you both of those and we'll point out the differences along the way. So first we're going to start with sharing to a Servoix application server using the built-in Servoix team provider. So I've got an existing solution here and I'm just going to right-click on it and choose team and we're going to share this project. My next option is the repository type. So Servoix has a built-in team sharing repository. So we'll choose next and then I'm going to enter in the address for my server. In my example here, I'm just going to use local host and then we'll enter in the username and password. I haven't set any up for this server so we're just going to leave those empty and we'll hit finish. And when the dialog closes, I can see that my solution has been shared. I also noticed that I have some extra little icons here. So I've got a little asterisk next to these. So that means that whenever you see that little black asterisk, there are changes yet to be committed. So I've shared this to the project but I still need to commit my changes. Well now what you're going to see is when I right-click on this project and I go to team, now I have a lot more options. I can choose synchronize and that'll take and synchronize my local changes in my workspace with the changes on the application server. So it'll go through and see if there are changes on either one. Update will take and update my local copy with the latest changes from the application server. Commit will take the latest changes from my local copy and update them to the application server. And then of course, I have the option to remove the share if I no longer want to share that project. Let's go through simple commit first. And so you can see those changes have been committed. And you'll also notice I have different icons. So now I have a little cylinder orange icon here. And you'll notice the icon has changed as well and I have a little orange cylinder icon. So that just lets me know that that file or directory is in sync with the application server. If I were to make a change, I would see a change back to the black icon. It is that I've shared this with my servoy application server at my local host. There is one setting that you need to make sure it's set up properly for you to be able to do that. And all the way at the bottom of your servoy admin page on the admin settings, their servoy.applicationserver.start repository as team provider. And you need to make sure that set is true. That's what allows you to use this repository server as a team provider. Next, let's take a look at how you would check the solution out. So let's say developer a has shared the solution to the server. And now one of your other developers need to check it out because they want to work on that project as well. What is simulate that, I'm just going to switch work spaces. And I'll give it a new name. So we'll be on workspace to. Now you notice since this was a new workspace, I don't have any solutions. So we'll start with checking out a new solution. We'll right click on all solutions and choose checkout from servoy repository. Again, we enter in that server address that use a name and the password. Of course, if you were using a hosted server that everybody was connected to, you could put in the host name or the IP address of that server here. And so we'll choose next. And now I get a listing of all my solutions on the server. And there's that servoy you demo that we just saw earlier. And when I expand that out, I can see all the different versions that exist on the server. So servoy allows you to do linear versioning. So you can start at version one and automatically work your way up to as many versions as you need. It's important to note that it is linear. So you can't really go backwards and make changes to older versions. You can revert back on the application server. So if you release a new version that has some bugs in it, you can roll back, but you can't actually roll back and make changes to those old release numbers. You're always working off of the latest release. And to work off the latest release, all you have to do is choose head. So head just means the latest version that exists. And so we'll choose finish. And it's going to go through and check that out. So now I've got that solution checked out. And again, we see our familiar icons here. So I could open up some solutions. And I see you have a method here. And I could make a couple of changes to this. I'm just going to put in a little comment tag. And we're going to save that. You notice my icon changed here. And so since I've made a change, I need to commit this back to the server. So that everybody else can see that change as well. Now we're going to switch workspaces back to the other user. So now we're back on that first workspace to simulate that first user. And I know that somebody else has made some changes. So I'm going to do a synchronized. And just check to see if there are any differences between my version and the server version. And it's asking me if I want to open up this perspective. So when you do a synchronized, you actually get a new perspective and Eclipse to help you synchronize your local workspace with the server. And so when I come in here, I can expand these down. And I can see that there's one change here. Down below, I also have some additional information. So I've got one incoming change, zero outgoing changes, and zero conflicting changes. I can also change my perspective up here and change how I'm going to look at these. So I can click on this icon and I can see only the incoming changes. I can click on the outgoing mode and see only outgoing changes. I can click on incoming and outgoing and see both. Now if I want to see exactly what these changes are, I can actually double click on this file. And it'll open it up and show me my local version and the remote version. And I can see the difference. So you'll notice there's a little icon on the right here. And I can click on that. It takes me right to that change. And so I have the option here that I could manually merge this file. So if you ever have a conflict that exists, you may have to do some work where you're manually merging the changes from the mobile into your local file. But in our example, it's just a very simple synchronize that we're doing here. And so the quickest way to do that is to just click this icon that says merge all non-conflicting changes. And that's going to take and ask me from sure. And it's just going to take and merge all of those changes, both incoming and outgoing together. So when I work in a team environment, I usually do the team synchronization process when I want to both sync and commit. Let's take a look at the application server side of things. So if I come back into my server and I go to solutions. I can see all those solutions that exist on my server. There's that servoy you demo that we created. And I can see I have a button here that says latest release. So whenever you're using the application server as a team provider, you'll get this new column here. And that allows you to create a new release number. So this is how you can track the changes between releases. So by default, when you commit and servoy, you're overriding whatever changes exist for that release in the server. So for example, if you only have one release on the server and you've had 10 different developers working on the server, on that same method, there's no version history that exists for that method because it's just overriding whatever is in the server or that release. If you want to track those changes, what you can do is come in here and make different releases. So what you could say is all right, we're already at a certain point where it's a stable build. Let's make a new release and then future commits will happen to that new release. And so now you have some version history. We'll be able to compare the differences between those releases. Next, let's show how to work with a SBN team provider. So the first thing we need to do is go to our local host and port 8080. And we need to make sure we set the start as team provider to false. Since we're not going to be using any sort of team provider, we want to make sure that's off, especially on our local host. So we're going to save that. And we'll close that and we'll restart servoy as well. All right. Now the first thing you need to use an SBN as a team provider is of course an SBN server. The servoy application server is not an SBN server. However, there are lots of different options for you to get one. You can either set one up yourself or you can use a hosted option. I recommend using a hosted option and I'll show you a couple of reasons why. So we're going to take and sign up to one of my favorite ones. And that is unfuddle. You can get it at unfuddle.com. The web address is right up there. And so we're actually going to start and sign up for a free account. They have a starter account that allows you to get about 500 megabytes worth of hosting with them, which are actually last year a pretty long time. So let's go ahead and sign up. And we'll do the free account. And we'll set up our new account here. And we'll go into the terms and service and hit continue. And so it automatically signs me up here. And I can see that I'm taking into a dashboard. So it's just going to show me kind of an overview about my SBN project. I also have different projects that I can create. They create a default one for you called my first project. But you can of course make a new one. If you attempt to make a new one, it does tell you that you need to upgrade your account. So we're just going to go ahead and continue to use my first project. So when I click on that, I'm now taking into a specialized view here why I see all the info about my project. I can see some messages, some milestones, tickets, notebooks, repositories, people and settings. So these are all just some features that unfuddle happens to give you. All the different SBN hosting providers that you use will offer something slightly different. But the key thing that we're looking for here is repositories. And so I currently don't have any repositories for this project. So we're going to make a new one. And we'll call it servoyu. And we'll type in the same for the abbreviation. We're going to make sure it's a subversion type repository. And we're going to go ahead and create that. It's not going to need to adjust my abbreviation here. So we'll just do servoyu all lower case. So now I can see the URL to my subversion repository. I can even click on that. And it'll give me some of the information that I need for how to check that out. And that's going to be the URL to my subversion repository. And then we're going to use that here in just a moment. So let's go back to servoy. And in order to connect to the SVN, instead of using those command line options, there is an SVN plugin for Eclipse that allows you to very easily work with a subversion server. So we're going to install that. So we'll go to help. And we will install new software. That's going to bring us an update. And from this dropdown list, servoy has included a couple here for us for convenience. And here is the Subclips project. So Subclips will allow you to communicate with an SVN server. And so I can see some of the options here that I can choose to connect with. So there's the core SVN kit. There's a couple of optional libraries which usually don't need. And if you just want to keep it simple, you can select the core and subclips. And then we'll hit next. And we'll choose next again. And we'll accept the terms and we'll click finish. And we'll go ahead and let it install. During this process, we'll get a little security warning that just wants to ask if you want to continue the installation. And of course, we want to say, OK. And we will select all and we will accept their certificate. And then finally, we'll need to choose yes to restart and save those changes. OK. So we've created our subversion repository on our free hosting account with Unfuddle. And we've installed the SVN plugin for Eclipse. So now we're ready to start working with our server. So we're going to go back to Unfuddle. And we're going to copy that URL again. And then we're going to come back to Servoy. And we're going to share this project. So we'll right click. And we'll choose team. And we'll share the project. Now you'll notice after we installed that plugin, we get this new option for SVN. And so we'll choose next. And we'll enter in the URL. So we'll just paste our URL in there. And we'll hit next again. And we get the option to use the project as the folder name. Or we get specify our own. We'll just go ahead and use the project folder. And we'll click finish. Next, we just need to enter in our username and password that we put in when we signed up for our Unfuddle account. So I'll put in mine. Now if you want to actually track changes between different developers, then you would need to go into Unfuddle and set up multiple different users. But if you don't need to track those changes, then you can just use the same username and password for all the developers. So now let's just sharing our project into the repository. And next, it wants us to open up the team synchronizing perspective again. And we get a very similar view. So we've see a listing of both incoming and outgoing changes. And I've got this button here to commit all my outgoing changes. Now you'll notice this dialog is new. So in SVM, you get the option to specify comments along with your commits. So this allows you to better handle your change tracking so I could put in some comment dealing with this particular commit. Since it's my initial import, I'll just type that in. And now my project is shared with the SVAN server. Now there is a couple more things that we need to do. So when you're sharing it, it only actually shares the single solution that we just chose to share. If I had additional modules here, I would need to share each of those as well. I also need to share the resource project. The resource project contains metadata about my database like column info, as well as styles, and the I18N keys. So we, of course, want to share that across our developers. So I need to share that one as well. I'm just walk through that same process, sharing it to the SVAN. It remembers my last connection, so I can just choose that and import it. And again, we'll go through and commit those changes. Now, although the comment box is available here, you're not required to actually type anything in. But I suggest that you do. OK, let's go back to our design perspective. Now I can see those familiar icons again. So both the resources project and our solution are shared to the SVAN. Let's go ahead and switch work spaces again to simulate a different developer. So we'll switch back to that other workspace. All right. Now we're in our different workspace. So this would be like simulating a separate developer wanting to work on your project. So what they need to do is import that project into the workspace. So we choose file, import, and underneath of SVAN, we have checkout project from SVAN. And we'll just choose to create a new repository location, and we'll paste in our URL again. And it shows me the different projects I have in there. Now it happened to automatically remember my name and passwords since I'm on the same machine. If you were developer, you'd probably get another password prompt if you're on a different machine. But I can actually choose both of these projects now in the SVAN that I want to check out. So I'll hit next, next, and finish. All right. Now that I've got that checked out, I can go under all solutions, and I can see that solution I just checked out, and we can activate it. And now it's my main solution. And again, I've got those familiar icons on all my nodes here so that I know I'm working in the SVAN. So go ahead and make another change, so I'll open up one of these. And we'll clear this out. I'll call this SVAN test one, and we'll save that. And now if I want to commit my changes, all I need to do is right-click, go to Team, and I can choose Commit. And then again, I get that comment, so I can say, fixed something, and commit that change. So now that change is gonna be there, so the next time someone else chooses to do a synchronize or an update, they'll get that change. So when I right-click on the project again and go to Team, there's the synchronize option. So if you do that, that'll do both a commit and an update. It'll essentially synchronize your local repository with what's out on the server. So I normally do that when I'm working with a team. So every morning or every evening, or while you're fixing bugs, whatever your process is, I usually do a synchronize periodically as well. One of the other advantages of using an SVAN is many of the SVAN tools Link in with some other sort of bug tracking. So let's show how to do that in unfuddle. So I can go over to Tickets and we'll make a new ticket. So this would be like some sort of bug. And we'll choose Create Ticket. And so now I have Ticket ID number three. So let's go back to Serveoy here. And we'll pretend we fixed some bug. And we'll change that. And now we'll go ahead and do another commit. And this time I'm going to type in a special message into the comment. So each of the different SVAN hosting providers out there usually have some sort of difference in text. If you take a look at unfuddle on the website, they'll have a listing of the different syntax that you can use. For example, certain syntax will mean that you are fixing a certain bug or you're just applying time on a certain bug, et cetera. So what we'll do is we'll say Resolved Number Three. So we're saying I resolved bug number three. And we'll say, okay. Now let's come back over into unfuddle and we'll refresh our tickets by going into the tickets, going into number three. And after just a second or two, we can see that it did update and the ticket status is now resolved. The other handy thing about this is if I scroll down, I can actually see all the associated changes. So all of the different changes to the code that I made in that commit will be listed here. So if your process is to fix one bug at a time and do a commit after each bug, you'll be able to see all the changes that went along with that. So I can click on this and it takes me into a repository's tab and it'll take me into a nice user friendly view of what was in the file that I changed. And so I can see that that line was removed and that line was added. If there were multiple different files changed, I would see all those listed out. So this makes it very easy if you're fixing different bugs, maybe a bug pops up again later that's similar to an old bug. You can go take a look at that old bug and see all the changes that were made to fix that. So that's a big advantage of using something like the SVM. And again, unfottle is just one example. I suggest you do some research and find a tool that's best for your needs.