 Hello, I'm Chris and I'm here today with my friend James James is very into C and he also worked for a web design company for a while and Today I'd just like to ask you a little bit about when you're working for that company over the last couple of years What did you guys do for commits as far as large group of people working on one project? And also, what did you guys do for backups? How often did you back up every time you committed? Did you back something up somewhere? It was like a daily thing so just a little bit of detail on that and As we're talking before we started this interview. He's gonna touch on this lightly in this interview But in the future he's probably gonna go into more detail and more technical aspect of it in future talks Sure. So You know what we did at this company is we used a versioning software called subversion. It's a very popular software. It's been around for a very long time It is for you for to use. I believe it's open source But actually I I you probably should check that and maybe put it somewhere now subversion. I think I heard you mentioned CVN is that the same thing or is that something SVN SVN SVN subversion subversion I think it's a technical name SVN is just like the command and I think people like the shorthand for it Okay, so so SVN is very similar to get There are some differences SVN is before get the I believe in the history if I understand correct You know, there were versioning softwares, but Torvo Linus Linus was looking for a Versioning software that was more democratic and didn't really focus on a single Authoritative source and so that's when they came up with get but it's it's still very similar With subversion you're able to collaboratively work with with multiple people just like in get and Essentially what you're doing is You're you were in in SVN at least you're you're downloading the project to your computer And there are files to store the state of the project you downloaded And as you edit the file it knows because it can basically diff and find the differences and see what updates you've made to those those files and Once you've edited those files you can then recommit them back to the project you're working on So now when you make a commitment I'm assuming your guys are running your own personal servers Because there's a private project. Yes When you guys committed something did it automatically back up the last changes somewhere or once you commit something It overwrote the last thing and you guys periodically did back up. Yeah It's it's a really neat how subversion works and and the more you use it I think the more you kind of understand How the background of subversion works Because you know essentially it's it's easier to think about Instead of thinking about every time you commit something that it stores what you what what you have your final product A better way to think about it is is what it really does is it is it stores the differences between the last time it was committed to what you're committed so What what what that means is which you're When you're When you're committing something it gets a version number And you can always roll back actually to to any of those version numbers and as a matter of fact There's special types of merges you can do where you can say we'll take all the changes I made from commit number 20 to commit number 30 and reapply them to this file Or take all the commits I've done on this section of files and then apply those changes to this section of files Okay, so now you've worked with that for a couple of years with the company You're working for have you worked at all with get like are you familiar? I know obviously you're probably more familiar with subversion, but have you worked with get yes I work with get quite a bit and and again It's very similar, but I think get is more the mindset and that's an interesting thing in programming is it's It's not just about the technical details What's even more important is the concepts the way to think about something and so get is is a little more Democratic in when you're using get the better way to think about it is There is no source You become a source and and and you can merge throughout the different sources You know so that's the main difference. Yeah, because I just recently with the projects I've been currently working on Just really started using github and the get command and I know the basics and so far my projects I have worked on with myself, right? I haven't really had other people help me it because they're just kind of starting out before I go out and ask for help I want to have something complete so I don't look just like someone begging for help So I'm still very curious about how it all works and I'm learning as I go along Yeah, so like if I'm gonna set up a subversion what I'm gonna do if we're working on a project together It's probably gonna be on a server that that I'm gonna set up access to it and you and yourself and myself We're gonna have a username and a password and I'm gonna give you permissions to work on that project And I might even say well Chris Chris can only edit The the trunk he can't add it or maybe I can say Chris can only edit his own special branch And then I can see what you're doing on the branch and I can I can merge your changes in as a sort of thing I need to learn with github as I start getting help hopefully getting help from other people I was like do I get to say? Approval to this person or do they have to work on the project completely separate and then I add in the codes I assumed it wasn't that but I something I need to learn and we'll probably get on in more into future trail with subversion Yeah, and then the other thing is with with When you're developing a project with virgining software What you tend to do is you come up with with versions, you know You have numbered versions and you try to think about major revisions minor revisions tags and branches and so you know typically You're gonna work with a trunk, which is your main source Your your I mean it's the trunk of your tree and then you have branches the branches are sort of Derivative works, okay points and times that break off that you might want to re-merge back in okay So they kind of become separate projects that later on could be they're like a clone of the project at one point in time That you can edit and commit to separately with a separate timeline that you can then decide to merge back in Or maybe it doesn't or maybe it merges back from the trunk and and we can get a more detail about that later it's kind of like a Long lines of when people complain about certain open-source projects that don't commit things back upstream Right. Yeah, it's kind of like that sort of thing to have their own thing going on But they don't actually give back. Yeah, it's a long downside and then and a and a subversion project you typically have a Tagging mechanism, which is just sort of like freezing it So the branch is something you can you can kind of go off of the trunk You can decide to murder you can make changes on it independently You can decide to merge back a tag is supposed to be like this is locked No one's going to make any changes to this tag. If there's a bug in this tag, we're gonna make a new tag We're not going to edit this tag now, you know, it does Not everybody works that way and and there's different philosophies, but that's typically what you mean by a tag when your tag You're gonna freeze it and the way a subversion works actually is there really isn't any such thing as a as a branch or a tag inherent into in the software But the way you set up a project is you basically set the permissions up that no one can write to a tag And you basically, you know, I said you can you can copy a set of changes from one directory to another Well, all branches is just another directory where you've copied all the changes from your trunk to another directory So basically the the the tools of SVN have allowed you to create this idea of branching and tagging That you can use for this philosophy But since they're just tools you can have any philosophy you want sure and like you said people have different ways to do And different things and and you briefly mentioned like version numbers There's no standard on how people do version numbers on software. It's kind of like your person has their own way So the best way I've heard though and and and I think this is a good philosophy This is what we try to adopt is the first number Is the version and you only change that number if you rewrite the software from scratch, okay? Okay, the second number is major revisions when you say the first number you mean like you got two one dots Yeah, okay, so the one means that maybe there was a zero and they rewrote that that was the prototype and they rewrote the code So now it's a one so I always thought of my head like like once you get to a whole number And this is my my way of thinking of my small little projects working on my own is It's like one. Okay. I just hit a stable point Yeah, and then like now I start making big changes and once those big changes are stable now To yeah, and that's kind of how I think of it Well, that's and then typically the second number is I would say is more for that. So that's called the major Major revisions that that number typically again. This is all just different people do with different ways Right, but the second number is major revisions. So you probably should roll out maybe new Maybe new features and that number or maybe even if you have a major change in an interface You should definitely keep them for those You know if the function is no longer valid for you to use if you know You probably have already announced is deprecated and you've said hey There's a major revision coming up where that's going to be un Unusable and then finally the third number and some people have been go to fourth or even farther But the third number is the minor revisions and those are the bug fixes. Okay So when you hear 8.2.0 comes out and then it's a point you you keep downloading updates to get a point 8.2.1 8.2.2 8.2 those are like little revisions that or the little bug fixes usually that that the developers have made new tags That that have just fixed those bugs But when somebody's working on new functionality, they've kept that separate from that project in a way so that they don't have to roll out accidentally roll out those functions During the next tag they can they can develop on a separate little branch until they're done Merge it in and wait till the next major revision come out So that's that's the major point of subversion great well James I thank you for joining me today and Definitely have you on many times in the future because you're very knowledgeable on aspects that I am not knowledgeable on I think we compliment each other very well. Yeah, um, so thank you again And I thank you all for watching and I hope you join me again in the next talk Which will probably be with James as well. Have a great day If you enjoy my tutorials and would like to see more Please think about contributing to my patreon account at patreon.com forward slash metal x 1000