 Online simulation and more for nanotechnology. In the process of publishing our tool, I mentioned once or twice that you get into a workspace and you use Subversion or you check out your code. I don't know if you guys have used Subversion or any source code control system yet, but let me explain to you how that works. Alright, so first of all what is this Subversion thing? Subversion is like a program called CVS, but it works a lot better. CVS is the concurrent versioning system in Linux. If you're kind of older you might have heard of it before or even used it. And I put that reference there because there are a lot of people that are like, oh CVS, I know that. It was created by some people at CloudNet a long time ago, a decade ago. It's been in production for a while so it's pretty stable. It has an open source license so you're free to use it and a lot of people use it on Linux especially, although it also works on Win32 and a bunch of other platforms. And basically it's a way of managing the source code that you create for your tool. So what you can do is take all the source code for your tool and upload it into Subversion into what Subversion calls a repository where it stores your code and then you can check out or download your code anywhere else that you want to work on it. So it works with a client server model. In our case the server is NanoHub and then let's say this is your your machine here in the lab and maybe this is your laptop which you use at home. So you can check out your code onto any computer, work on it and send the changes back. You can go to a completely different computer and pull down the latest version of the code, work on it and check in your changes. So that's what it's for. It's for keeping track of your source code. So here we are with some code. We're going to upload it into the repository and then I can download and check it out onto a completely different client like at home or something like that. So think of it as a way of storing your source code. Now you guys may say that sounds cool in everything but I don't need that. A lot of people tell me like I don't need that and it used to be that we would tell people well okay but I think you're making a mistake now we just say no you're gonna use Subversion whether you like it or not because I'm I'm tired of these problems. So imagine this. Imagine you have a version of a program that's all working, version x1 of your program. You spent a lot of time on it. You worked a little bit more, you've got x version x2, you fixed a few bugs, you added a feature and you took it over to a machine and you installed it on some machine. I like nowadays we used to have a machine called Hamlet but nowadays there's coats and Rossman, all these machines that produce right. So you need to get your code onto that machine and kind of get it built and compiled and as you're doing that there's actually problems but your make file is wrong or something there's a bug in the code or you forgot to declare something double so oh yeah you fix that over there on that machine to make it work on that machine. And then you take that code and you put it on to another machine like at the National Center for Supercomputing Applications, right? You copy the latest version there and in the process there's probably a problem there too. So okay well I fixed the make file a little bit more and now it works on everything supposedly. Now in the meantime you've been working on some other stuff and you copied the working version of your code to test. You kind of forgot about all the changes you made on Hamlet and NCSA but you copied your latest code from your home machine to test and you made some more changes and you sent that code to email via email to someone right because they said hey send me a copy of your code. So you're like okay here it is and then they start making changes and then they want to send you the changes back right. And at this point now there's like five versions of the code floating around and there's a problem because in the latest version when I take this very latest code and I compare it to my version X2 it's almost right it's just a little bit off right. Like instead of 3.125 I'm now getting 3.12498 that's probably good enough isn't it? It's probably just rounding isn't it? I triple E or something and instead of 9.987 I'm getting 9.9901. So now that's like only two significant figures now and the third significant digit it's starting to get dicey but it's probably okay right because I really want to be done and graduate right? So like you remember with scientific code there's a good chance that you just goofed up something small and that this should not be different at all probably should not be different at all you should at least be getting like six significant figures come on like machines nowadays compute 16 significant digits right so out of 16 significant digits I think you can get at least three right so if you're seeing stuff like this is pretty scary it probably means your code is poorly written or there's a bug somewhere so the other thing that's interesting is that when you run this code the original version took 420 seconds the new version takes 340 seconds hmm is it optimized? Did you optimize your code or did you forget to call a certain routine right? Maybe somehow you're not calling a routine to generate the right model values and that's why it runs a lot faster now but it's also a whole lot less accurate let's say well of course I don't know which is right so stuff like this happens and it just drives you crazy you have no idea which version of the code you should trust is this the version or is that the version which version is correct and really the only way you can know for sure is by going back and running your Rapture regression tester or by checking values against the literature or by having someone else run the code and maybe double check everything for you so there's there's a lot of work there that needs to be done all right now if I haven't scared you already into using Subversion I hope I did let me tell you another reason number one if you're already using CVS you should use Subversion instead because it's better you might be using Git in which case Git might be the best of all nowadays so if you're using Git I won't give you any argument on Linux but Subversion is a lot better than CVS because it uses secure transport and a whole bunch of other things so when you connect with Subversion to Nano Hub it uses HTTPS sends your code over secure transport and sends it into a repository so it's stored somewhere else off your machine and backed up now that's really good because like remember the story a minute ago you're like where is that latest version of the code I know I fixed the make file at some point like where did I put that fix you never have to guess with Subversion because you're going to commit all your changes and your commits will always be in the repository they'll either be in the latest code or they'll be in the history somewhere so if you're like oh yeah I remember I added that but then I deleted it and I wish I had that code again you can go back into the repository and pull out an old version you can see everything that's in there Subversion does versioning of all your code the other thing about Subversion is that it'll answer who broke the build now I don't know if you guys have run into this when you get into a team with like three people you'll work like a dog over the weekend getting everything right you come in Monday morning you're ready to show it to your advisor you show up and it's broken all of a sudden it's broken who broke it I was working this morning I had it working right and then you look in the history on Subversion and it shows you that after I checked in version six this guy Clark's M checked in two more versions but at least you can tell your advisor hey it wasn't me it wasn't me it was this guy he checked in the latest version he broke it right so there's a history there you can see like who did what and who's messing with my code so uh so there's the detail now I can go and kick Steve Clark in the pants and say what did you do the last reason is and this has happened to me more than once imagine your hard drive just died so you got right to the last second you were just fixing the copyright lines and all of a sudden you hear that clicking sound coming from the disc it sounds like kind of a geiger counter you know and and you know when you're hearing that clicking sound that your disc is like toast at that point you start thinking maybe I can keep it running just long enough to pull off one last copy no no if it's clicking it's probably gone but fortunately you put your stuff in Subversion and you've been committing all your changes so if your disc dies no big deal you'll just pull out your laptop and you'll check everything out under your laptop and you go from there or you walk in you know you go to the the lab at Purdue and check out your code and go from there so if your code is in Subversion it's always safe you can always pull it down to whatever machine you want and kind of continue on from there like that I'm back in business now two minutes later just set your laptop aside worry about that later use that new laptop instead you're all set to go all right so let me tell you a little bit about Subversion now maybe you're interested in using it if you were going to set up on your own Linux machine this afternoon maybe you guys use Linux at home or whatever if you wanted to use Subversion this is what you would do if you were starting scratch you could make a directory I'll call it initial or whatever and inside that you make three directories by convention you don't have to but but typically when people are using Subversion they do this they make three directories called trunk branches and tags you'll find out why later trunk is the one for us that's important because that's the root of all of your changes and you might take all of your source code files all your star.cs or your tool.xml or whatever and move them into that trunk directory like that so now I've got all these directories I've got trunk branches and tags and I've got all my files moved into the trunk all ready to go all right now you can type these commands to create a repository and if you're on your own Linux system this is what you have to type you have to type SVN admin create blah blah blah some repository and then SVN import initial blah blah into that repository so that'll take this this directory structure that I just created and put it into a Subversion repository and you store that repository wherever you want user local SVN repo might be a good choice but whatever you choose so on an ordinary Linux system that's what you would do now we're not on an ordinary Linux system we've already got nano hub we're all set to go nano hub simplifies a few of those steps and does all that stuff for you so when we go through the contribution process and we fill out our form and we create a project like I showed you a minute ago nano hub is going to automatically create a Subversion repository for you it will automatically create the trunk the branches and the tags and it will automatically put a bunch of stuff in the trunk it'll create a rapture directory for you it'll create a middleware directory for you it'll do all this stuff like getting your tool all ready to go so that much you don't have to worry about all you have to do once you've created a project on nano hub all you have to do is check out your code check out the initial code and add your stuff to it so you do something like this in your workspace or in your home machine or whatever wherever you are you type a command svn checkout and you give it a path like this HTTPS remember it uses secure transport so HTTPS colon slash slash nano hub dot org slash tools slash and where it says your tool use your tool name if you made a tool called Spyro you say Spyro there if you make a tool called Q dot you say Q dot there so whatever your tool name is you put that in there and then svn for Subversion and trunk because that's where all the good stuff is and then you make the same directory name usually the same as your tool whatever your tool name is Spyro or Q dot so if you do that what that does is it takes the code from nano hub downloads it to your local machine and checks it out so you can work on it so it takes that skeleton empty directory structure that nano hub creates for your project and brings it down to your machine you can see it gives you a rapture directory a doc directory source directory middleware examples all that stuff and it tells you you're at version one okay now you want to add some files because you got some stuff now that you're going to add so you can make durr example slash ex one for example and you can edit a file called read me and add some stuff in there so now i've got a directory and a file and i can tell Subversion to keep track of that to use that so i say svn add example slash ex one and what that will do is add that directory and everything in it to my repository so from now on that's part of the repository it's not just a weird file on my file system a junk file it's like part of my tool so i do svn add now and it's a good idea to go way back up to the top to the very top of your tool and then you can look at the status if you do svn status it'll show you every all the changes that you've made that are pending that aren't quite solid yet but think of them as proposed changes right so i've got examples ex one examples ex one read me it says a next to it a means add and then there's a question mark next to a dot out um the question mark next to a dot out says that uh it doesn't know what that file is remember a dot out is probably what you get from the compiler it's like some garbage file i don't want to add that i just want to add examples ex one and examples ex one read me those are the ones i want to add right so so that that looks correct to me some things you want to add some things you don't if i want to make that change permanent i can type svn commit when i say svn commit it says okay i'm going to add ex one and ex one read me i can it'll usually pop up like vi or emacs or whatever and i can type in some commands created the ex one directory and added the read me file and then as soon as i save that it'll commit the change and from now on that's a permanent part of my tool so when i when i'm done with svn commit you'll see it saying adding adding and then it'll say it's committed revision two so now i have two versions of my tool and if you look you'll actually see it there too um if you look in the change history you'll see the original version created by root and then you'll see revision two created by me on such and such a date and all of that what's checked in all right now you guys might say well i don't use linux i i use windows and all that i like windows well that's fine because there's a version of svn called tortoise svn that you can use on windows and when you add this package to your windows installation you'll get a right menu click you can right click on any folder and say svn checkout it'll add that option onto the menu the right menu and um so and you can check out your code you'll get a directory with a green check mark on it that lets you know it's being controlled by subversion and you could right click on that and you can do things like svn update and svn commit and all that kind of stuff so there's an equivalent windows way of doing all this stuff if you prefer windows when it asks you about committing um it'll give you dialogue boxes instead of typing command line options it'll prompt you with the dialogue boxes for all this stuff uh and then it'll show you basically the same stuff it'll show you added all this stuff and then at revision two and so um so it's all the same it's the windows version of it all right now that's adding so you can add stuff in what about moving and removing and changing things around suppose i get in here into my examples ex one and people are complaining because i made that file called read me and the windows users don't like it because it doesn't know what file type it is so i want to change read me to read me dot text normally you just say mv move read me to read me dot text with subversion you have to tell subversion about those changes so we say svn move read me to read me dot text that way subversion knows you're trying to rename the file and what it will do is basically add a new read me dot text and delete the old read me file in the version history so you can see it kind of echoing those commands back at you i may go up a couple of levels in my project and i may say i don't need that doc directory so i can say svn delete doc and it will delete again i don't just remove the folder myself i should tell svn to delete the directory and it will delete the directory and then keep track of the fact that it needs to be deleted all right now if i say svn status i can see what's pending these are the pending changes i can see that doc will be deleted when i commit and then it's going to add read me dot text and it's going to delete the old read me so those are the changes that are coming up now if i want to make those permanent i can say svn commit and it'll prompt me again it'll show me what changes i'm about to make and it'll prompt me and i can type in my message move some files around right and then again now i'm at revision three and you'll see on the change log revision three mmc move some files around so you can always keep track of who's making changes and it's really a good idea to put those comments there because when people commit stuff without comments it's like what do they do i have no idea i have to look at all the diffs now to figure out what they changed i'd rather know conceptually what they're changing you know i changed this part i changed that part i added notes to my spy row whatever that way you kind of know you can tell which version has what all right now all this gobbledygook over here the d and the a and the plus and this and that there's actually a link in the notes here that'll take you to the documentation there are a bunch of simple ones like the ones i'll show you and then there are more complicated ones that you can find that you only need once in a blue moon so i just kind of i put in just a pointer in the notes here if you're curious you can follow the link here where it says this page and it'll pop up the the doc all right now suppose you guys are all trained in using subversion you've committed some changes to the repository very good and suppose i do a check out now and i check out the code to one machine and i do a check out now and i check out the code to another machine so i've got the code in a few different places now that's good suppose i make a change to the make file over here i'm editing the make file and i'm going to make a small change for this machine instead of gcc-g i want it optimized so i'm going to say gcc-o to have it optimize the code and then i'll commit that change back to the repository right so i've made a change now when i'm working on the other machine i may want to get those changes so over here i can say svn update and it will bring down the latest version of that code so it'll always bring in the latest it'll bring you up to date on whatever machine you're on you can say svn update it'll suck down the latest changes so my message to you is don't copy code around you remember in the beginning where i said well you take that code and you copy it onto this machine you change it you copy it onto this machine you change it don't do that always put your code in subversion always check out and commit because then wherever you want the code you just do an svn checkout or update and it'll always update to the latest version it's a lot safer a lot cleaner than copying code around because you'll get really confused if you're copying code around you don't know which version of what and whether you had that fix or not and it's all a mess so don't copy code around instead you move codes with svn checkout and you do things like svn commit and svn update to move the changes around trust me it's worth it it really is like you're looking at me like you're so skeptical trust me you're gonna love it once you get used to it all right so suppose i have modified a file if i do svn status i'm looking at my file and it says source hello dot c and my gosh sometimes i can only remember things for about a week at a time you know let's say let's say there was a bar mitzvah last week and i just can't remember anything like before that in history i too many brain cells gone or something so you can do svn diff and it will show you what you were working on maybe it was a week ago maybe it was six months ago i'm thinking why did i what was i changing svn diff shows me that there's a diff here pending that i haven't committed yet this is a a change that i've made locally that i haven't yet committed and i can remember oh yeah i remember um i was changing the hello world program i got rid of the world the fine uh the line that says hello world you see there's a minus next to it and i added two lines that say say hello to everyone in hello universe so now that's what the difference is that sitting on my local machine and i can ask myself do i want to commit that change or am i ready to go with that is that good or not if i don't like the change if i think wow what was i smoking that was like crazy i should never have done that you can always do svn revert and it will it will move that file back a version back to what it should be from the repository so if you say svn revert it'll take changes that you've made locally but you haven't committed yet and it will get rid of them and it's almost like a reverse update it's taking you back to the last safe version of the code all right you can also revert changes with directories and stuff too by the way if you delete a directory and then you decide oh i shouldn't do that you can actually revert as long as you haven't committed that change all right now one last interesting thing suppose i'm over here on a machine and i'm editing the make file and the make file i'm going to add a clean target i'm going to add rm minus f start out o and a dot out so i've i've edited the make file and over here on this machine i've edited the make file maybe my teammate maybe it's someone else someone else working on the team checked out the code and they edited the make file too although they added cc equals gcc and dollar cc dash o hello dot c right so we've both been working on the same make file whoever checks in first has got the easy job so you always want to check in early although not so early that you break the build because then someone like me comes after you and spanks you and says why did you break the build but when you're happy with your changes check them in because the sooner you check in the fewer problems you have so over on this side i'll do an svn commit and my make file changes get committed to the repository over on the other side the other person when they go to commit they won't be able to it'll tell them you're not up to date there's something wrong so on the other side before you can commit you're going to have to do an update in the process of doing an update it'll bring those changes down and it'll show me okay i have my changes cc equals gcc and dollar cc but it'll add in clean the clean target that's good right because i made the change over there it gets pulled over here i did the merge everything's good so now that i've updated my code then i'm okay then i can do svn commit and now the make file looks like this with all of our changes in it so it really helps you work together as a team integrate changes and get them all committed all right now there can be problems suppose that i'm working on the make file over here and not only did i add the clean target but i added dash oh hello and at the same time over here my teammate added cc equals gcc and the dollar cc there so we're both working on the make file at the same time and at this point we actually made a we both made a change these this each of these lines here we both changed them so again i repeat whoever checks in first has no problem check in early check in often not so often you break the build but often so if you do svn commit that make file goes up no problem the next guy when he tries to do his commit he won't be able to do it he'll have to do svn update and when he does the svn update it'll suck the changes down and it will tell you oh i always hate this when i see the c usually tells you all the stuff it's updated and when it shows you a c like that it means there's a conflict in that file so it means you're going to have to figure something out it doesn't just merge neatly together there's a problem if you try to svn commit it'll tell you it failed won't let you do it and it'll remind you that there's a problem there's a conflict you got to fix it won't let you change it all right and if you look svn status will tell you by the way i've got some junky stuff sitting around and then i've got this make file look at the junky stuff the make file is in conflict and subversion actually leaves around some different versions it'll leave around revision five revision six and something it calls make file dot mine so make file dot mine is my version of the make file before i started all this mess and make file right now has got the best guess of everything merged together subversion takes its best guess and tries to fit it all together and then the revision five and revision six i can look at those if i have questions about older versions so now it's my job i have to figure out which one of these is right or what how to fix it so the make file is the best guess that's usually the good starting point to start there so if i look in that make file here's what i see it'll look like this subversion puts in the less than less than less than dot mine and then it shows you the line from your file and then the equal equal equal equal and then the rest of the stuff from the other file and then the greater than greater than greater than dot r6 so it what it's showing me when you see that less than less than equally quick greater greater greater that's an area where i have to figure out which is right so i look is it the top part that's right or is it the bottom part that's right or is it some combination in this case it's some combination of the two right because the top part mine isn't quite right the other guy added the dash o or but at the same time my their part isn't quite right because i added the dollar cc so we actually have to mix up you have to make both of those changes you know i need to get i need to get the cc here but i also need the dash o hello so this line i have to fix to have both of those parts so what i can do then is put it all together in my editor nothing fancy just in the editor you delete the less than less than you delete the equals and the greater greater and you build everything all back together the way it really should be so i i put everything together onto one line with the dollar cc and the dash o hello and put it all together and that's the way i want it and so i save that file out and then i tell svn that it's okay it's cool now say svn resolved make file and svn knows okay i'm blessing that that make file is in good shape now don't do that unless you got rid of all those equal equal equal and less than less than or else you broke the build right next time somebody tries to make makes going to lose its mind because of all that less than less than less than equal equal equal burp and you'll be like who did that why didn't you fix the conflict so go in fix everything up and then say svn resolved all right and then once you've cleaned up all the conflicts you can say svn commit and it will go ahead and commit now i've got everything all put back together right that's the hardest part of using svn when two people edit the same file at the same time and change the same line then all of a sudden it's like you're stepping on each other's toes and you got to work it out usually that doesn't happen because usually we'll work on a project i'll work on one file you'll work on another file or i'll work on one file you're working on the same file but we do the top and i do the bottom or whatever usually the changes don't conflict but when you actually both change the same line subversions like come on are you kidding me how do we fix it so it's up to you to fix it all right there are a few other things that are kind of handy to know if you want to get an old version of your tool there's a flag there dash r3 you can give a revision number so if i say dash r3 it'll check out revision three of my code sometimes you say oh i know back in revision 12 i had that cool thing but i deleted it so you can check out that revision and go back to the old version you can also say i wonder what the old make file looked like you can say svn cat dash r5 make file and it'll find that make file find revision five and print it out to the screen so that's a quick way not checking out the whole revision but just getting one file getting an old version you can save that too by the way onto a new file and or in this case i guess overwrite your current file you can also say svn log and svn log will tell you like the revision history so if i say svn log make file it'll tell me all the different revisions of that file what's changed you can also say svn log not for make file but just in general it'll tell you all the revisions about a particular repository current directory i guess all right now subversion has some pretty good defaults usually does the right thing if i take a jpeg and i copy it into my examples directory and then if i say svn add you notice it says add and it says bin it recognizes that that's a binary file so subversion usually is pretty good about recognizing binary files and that's good because it treats them differently binary files don't get merged the same way as ascii files right so the bin there doesn't it doesn't do any funny translation carriage returns the line feeds and it doesn't try to merge versions so it's good to for subversion to know about binary files when you commit it you'll see it's a binary file again adding bin examples slash diagram dot jpeg if for some reason you had a file called demo dot dat and you know it's a binary file and you add it and if for some reason subversion doesn't get it like here it just says add it doesn't say anything about bin binary file you're ding you can fix it there's this all this gobbledygook that you can say if you dig down into the subversion documentation you can set a property uh you can do prop set and say it's octet stream on this file and you can change the eo line style and all of that stuff so if you need to you can set these properties but usually subversion does the right thing i'm just mentioning that because it is possible not likely but possible excuse me to put a binary file into a repository and then have it get corrupted because if if subversion thinks that it's an ascii file it's going to automatically convert character turns and line feeds and do merges and weird stuff so with a with something like a jpeg or a mp4 video that that wreaks havoc on the whole thing i mentioned way at the beginning about branches and tags and i'll just mention quickly about that here um you can think of the whole source code repository as a tree and so far we've been dealing with the trunk the trunk of the tree trunk is sort of the main line of where all the code is and as time goes on you get more and more revisions on the trunk now at some point you may say well i'm going to do something so crazy with my code i don't want to mess up the rest of my team i want to create a separate version of that kind of a different they call it a branch if you think of it as copying your code to a different directory and you can work on it separately where you don't mess anybody up and then later on maybe you'll merge it back into the main line after you've worked it all out so they call that a branch and you can create a branch in um uh in subversion by doing something like this um you can do a checkout and you notice in this case when i when i did the checkout i didn't say svn trunk i just said svn that'll check out the whole svn directory including the trunk and the branches and the tags and everything that we originally set up so i can check that out into a directory and i can go in there and then i can say i'll see the trunk and the branches and the tags and all that i can say svn copy that trunk directory to a new branch branches mclennan and that'll act as though i've created a complete brand new copy of everything as if i picked up the whole directory and copied it now it's more efficient than that you might say well my gosh i've got 10 megabytes of stuff and i don't want it to copy 10 megabytes of stuff well subversion is really smart about that all the files that haven't changed it won't copy but the ones that change it keeps track of all the differences so that's the other smart thing about subversion it's not just copying code it actually keeps track of all the differences it's very efficient all right and then i once i've copied my trunk to a new branch mclennan then i can commit that and that'll go ahead and create that private branch and then i can check it out and again instead of saying svn trunk i can say svn branches mclennan and it'll take that directory and check it out into a different whatever directory name i give it here instead of i didn't want to confuse myself so instead of just saying your tool i said your tool all up there and i said your tool mcl here just to remind myself that's a branch so so that's basically how you do it what i'm telling you is it's really weird with subversion when you create branches and tags and things in subversion you just copy them as directories and you just do it with subversion you do an svn copy of one directory to another and in this case there's nothing special we just started everything by saying we have a directory called trunk and branches and tags and i can copy from one to the other so all i'm doing is copying directories basically and i can work on this whole copy of my tool all by myself and i won't mess anybody up and i can change everything and plumb the guts of everything and i'll put it back later when it's all settled down now similarly i can copy the trunk to something called tags release 1.0 tags is typically a practice in computer science software engineering where you you're just about to release your tool you want to tag it and if anybody ever asks you hey can you pull up version 1.0 again you're like oh my gosh what's version 1.0 i don't know it was somewhere back in july or something right if you do this if you do svn copy the trunk to tags release 1.0 from now on you'll have a copy of that just as it was in version 1.0 and that's really good too by the way because you can go on and make changes and change your tool and now maybe i'm at release 10 and then someone will say hey i found a bug in release 1.0 and well normally you'd say just get the latest release right but if you wanted to fix 1.0 if you were in a company let's say and the company actually has paying customers and the paying customers say i want 1.0 fixed you can go back to this tagged version and you can fix files in that release and then put out a new release of 1.0 1.0.1 or whatever so it's a really great idea when you're about to release a tool to do a copy like this to tag it you can think of that as if you're applying a tag onto the tree and from then on when i want to see exactly what was in release 1.0 i can just check out tags slash release 1.0 and i'll get everything checked out i have a comment in here when you do this branching stuff if you have many people on your team creating branches and all that kind of thing and then later on you want to take a branch and merge it back in it's it's a really a big pain and the comment here says to use svk i would say nowadays don't use subversion if you're going to do weird complicated merging and branching don't use svn or svk at all use git there's a new thing nowadays that people use called git which is probably far superior to this it's a little more complicated if you already know git stick with it if you don't know git subversion is a little easier might be easier for you to get started so we still have people using subversion in nano hub and it works well for small projects but all this branching and well the tagging is pretty simple but the branching stuff if you start doing a lot of branches you're not going to like subversion anymore all right one last thing mention that there's a lot of good pointers out there there's orally books on subversion you can find the orally books on the web you can a lot of documentation online and all the stuff if you want to check out tortoise svn and all the different flavors for windows and all that so you you can find all that stuff online and one last thing i wanted you guys to try before we head out today is using subversion for your development teams i hope you guys still remember your team if not i guess you can look in the wiki find your name because you put your name in the wiki right so what i want you to do is i want you to to get into a workspace and i want you to check out the code for your development team and i want you to actually you can check out the whole code i suppose but i want you to check out the code for your development team go into the directory for your your development team add your name on the list and then commit it and again whoever checks in first has the easy job because everybody after that has to deal with all the merge conflicts right so if we go back to our boot camp remember we were working in where was it slash tools slash boot camp oh slash wiki i have to do that all right so here's our wiki page right um and here's lab assignment number 12 right on the wiki page instructions are right in the wiki so you can start up a workspace and use subversion to check out the source code and it says follow these instructions and there you go every project on nano hub has a little briefing on subversion so if you're ever wondering how do i check out the code for this project there are always instructions on the project and then they actually show you the svn checkout command you see right here there's there's a command here that says svn checkout and it tells you exactly what to type https nano hub dot org tools boot camp svn trunk boot camp that's what i want you to do get into your workspace and check out the code then i want you to find your directory dev team one dev team two and i want you to go in there and edit the stuff we good back there all right all right so here's my solution to the lab assignment i wanted you guys to get into the boot camp problem project and check out the code and make some changes so oops in my workspace i'm going to get in my workspace here and i'm going to do svn checkout http colon or https colon slash slash nano hub dot org tools boot camp and if you're wondering dang i wonder what was that path again i can't remember um on every project there's always instructions about how to do the uh... subversion checkout and in this particular project we linked it right here we said check out the source code for this project and follow these instructions and this shows you the svn checkout path here so it's tools boot camp svn trunk and i want to check it out to my own directory so tools boot camp svn trunk and i'm going to check it out to my own i'll call it bc 2012 you can call it whatever you want whatever directory name you want to call it at the end so that does the checkout and it tells me that i'm at version 180 and if you watch you'll just see this counter go up and up as you guys are committing things everybody's checking things in the revision count keeps going up and up and up so i'm going to go into boot camp 2012 into dev team one and take a look there's a read me and oh look my name is there uh terrific i'll remove it for posterity all right so now i fixed it if i do svn status it shows me i've modified that if i go up a couple of levels and look around at all the files i can look at svn status over the whole thing i can actually edit more than one at a time let me um edit dev team uh three two whoops the read me file um and i like this but i'm gonna get rid of all the blank lines and squish it all together somebody out there's put a lot of time in putting the blank lines in they're probably mad at me but anyway so now if i do svn status it shows me i've modified both of those files and i can always look at the diff so i can say svn diff dev team one read me and it'll show me all the changes i've made and if i want to back out i can revert that file svn revert dev team one read me and it put it back the way it is now if i look at all the changes i didn't change that file anymore and if i look at dev team one read me it's the old one with my name there so at some point i've checked everything out i've got it the way i want it i do maybe one last update to make sure i'm up to date good now i do svn commit and it'll prompt me it'll show me all the things i've changed and i'm about to commit and i can add my comment um which is removed extra blank lines and there you go now sometimes you get to that point and you find out uh oh had a conflict somebody else check something in the meantime while i was messing around and then you got to go and resolve the conflict so then you go and you you do your update you update your code svn update you get the latest code you edit the file you get rid of all the conflicting files you tell svn you've resolved the conflict and then you commit that's all there is to it i know you guys kind of worked through some of that too so if you get in the habit of using this svn it'll really help you out we hit the worst case today because all you guys were editing the same file in the same spot at the same time you're hitting tons of conflicts which is why we do the lab assignment which is good um in real life you won't hit conflicts that often because not everybody will be editing the same file in the same time but it's a really great way of helping emerge the changes work together in small teams you may find yourself working with two or three other students this summer working on a tool you can check out the code you can all work on it together get it committed and get it published on nano hub