 Oh, okay. Great. Hi, everyone. I'm David new snow gravity for those of you who don't know me Which is probably most of you looking at the room So this is a boss that was supposed to be much smaller originally I can't believe the number of people who are actually really interested in this those me like 10 people and everyone was Everyone else can be like oh, I love subversion because get sucks and it's impossible to use Apparently that's changed over the past few months though with 1.5 release especially so I I'm not entirely sure What the makeup of the audience is and how to structure this talk entirely or off? So what how many people are using get right now and consider themselves fairly good with it really workable And how many people have no experience at all with get and really oh wow, okay? So that's a pretty large number. So I'm not going to try and sell you on get per se especially not against Well, I will try and tell you on it versus something like subversion because frankly it's a much better model I won't try and compare it to things like bizarre or TLA Because I don't want to talk about TLA or mercurial because those are fine systems in their own rights And they're all distributed to and most will apply to the distributed stuff as well But really what this is important what's important about get is that it's being used by core components of any links distribution now between x.org thanks to the man the yellow shirt there and the Linux kernel we have really Major pieces of our infrastructure using this revision control system And it's worth learning just for that and I think it really does scale all the way up and it scales all the way down to your private projects You can maintain your one text file with get without any troubles. It's really quite easy so just by way of an introduction so The x-strike for switch to get a few months ago when get dot demi dot org was was established Thanks to Buxy and the aliyah team for for putting that it together And we were able to put that in and we really wanted to do this because x.org had switched to get from CVS and Being a distributed vision control system all of a sudden we had this major advantage of switching to it previously We were using subversion which was maintained Not on a Debian server. It was maintained by Brandon Robinson who I'm sure most people probably know having been famous and formal DPL And we were using subversion we were happy with it it worked it was slow as can be It was hosted on a DSL line and for pretty much anything if you wanted to you know You know get the status and all this stuff You really had to you had to hit the network for a lot of things And it was really slow and you don't realize how slow it is until you're not having to hit the network every single time You have to do it in operation But we switched to get with the help of a team member who unfortunately couldn't be here theory-reading who? Is actually our company's maintainer as well, and he wrote a massive infrastructure to Convert our really horrible subversion repository, which was thanks to me and being sloppy Into get and we've maintained pretty much all the history that we had before and you can do this if you have subversion You can do this if you have CVS There are tools that come with get to do that. I'm not going to demonstrate them, but they're available so Because we had an upstream that we were working from we really wanted to do things slightly differently than Was standard with subversion what you can do what's I don't know if everyone does this. I think a lot of people do Well probably not in Debian actually because SVM bill package doesn't do this, but With subversion one thing you can do is have a vendor branch and you can check in into your vendor branch The upstream code copied over to your working master branch your trunk and then do all your work there Have all your devian packaging in there and the trunk So we wanted something sort of similar to this in theory We wanted a separate upstream branch that we would have that you could easily diff against say upstream's branch And you could also easily diff against your working branch to see what's changed if anything So we actually have that so what I've got here is just a fresh check out of our ati driver Just because it's convenient That we keep in our in on git.debian.org So what you see is when you clone when you clone to get repository initially In with 1.5 you only get one branch check out in this case It's laying you you set up to whatever it is by default its master We've set it up to be the debbie unstable branch and what you can see here Is that we have several branches that go from origin origin is a remote in this case? It's git.debian.org you can call it whatever you want. It's basically an alias And we we have git.debian.org is our origin and what we've got is the way we've set things up is we've got these Dash experimental or unstable branches and there we both have upstream and debbie inversions The upstream version is literally just a clone from the the git.freedestop.org Repositories and the way we do this is we just pull it straight in and it's very easy You just do git pull and it goes straight in and then what we do is we pull it it further into our debbie in branch And if we want to make custom changes to the debbie in packaging for example or outside the debbie packaging in the sources But we don't want to push them upstream we can keep them in that branch We keep them separate the other nice thing about this is that upstream can look directly at the upstream dash Unstable if there's a bug report that's filed in the the freedestop.org bugzilla I don't know if anyone's actually doing this in free desktop, but we provide this ability You can easily different against head at the the x.org master head and just say oh well There's a fix that was checked in that you don't have yet because you're running unstable But look in your experimental version. It's there So this makes a trivial to do this actually if you want to do this upstream might not be doing it but I I try and use it on occasion and it is nice to have this sort of flexibility and Quite frankly with subversion you can't get this because it's not really distributed So That's basically how we do things we also We've been keeping our patches in we keep our long-term patches in in using a patch system called quilt How many people are using quilts? How many people using d-patch or? Okay, all of you using d-patch. I've already lost you've really made the wrong choice Quilt is so much better. I can't even tell you Pretty much get has various add-ons that you can use quilt like versions integrated things like st git or Guilt and then there's another one that I I don't know I haven't evaluated these personally. I've heard very good things about them They don't Interact properly with git web. So you can't if you're browsing repository with with the web you can't see what's different So that's that's kind of an issue and why we keep things in in quilt still So for long-running things you can keep the stuff in git if you want to we haven't made that transition mainly because we haven't We haven't evaluated it. Are you here? You're getting maven. Are you using any of these stat patch stack things? Not yet. Is anyone using them st git or anything? What's that? Actually, I've patched quilt a lot so that it supports posick shells There is a branch of stream with my patches in it and it seems quilt is really lighter than The nested git that uses a Python a lot and it's quite slow. Okay Okay We found this this whole method works really well So, okay, if you want to do things and you want to maintain packages with git I really I think that using Quilt is a really good way to go for long if you have long-running patches that you need to keep out You know, we've got things that really should not be pushed text or org upstream and That's how we keep them out. So if anyone wants to talk about how to use quilt I can do that privately if you'd like But you know, I'd like to focus on git for a little while if possible so I'd like to open up for questions actually because I mean I can do a whole tutorial thing But in reality, I don't think I'm to be any better than a the documentation that's out there So if there are any questions about the x-strike force and how we use git or anyone if you've got general questions about git and why you Would use it and why Ian Maybe the intersection between Debian Approach and git because there's there's quite a lot of good git documentation a lot of good Debian documentation But the intersection is a bit vague right so Git actually works really well for the Debian model of doing things Just because in terms in asked about the intersection between Debian and git and documenting using this stuff So git actually works very well for the Debian model doing things because by nature. We're all very distributed It's really nice to have the ability to just pull out The repository and work on it even if it's not your own repository. It becomes your repository in a sense and I mean Where it doesn't seem to work Well is the the Linux kernel model of using git there's two real ways to use git And I haven't seen anyone besides a Linux kernel using this model where there's no central repository People kind of accept Linux's tree as the central tree But in reality there isn't one the way you do things is pull only Mercurial was actually written to use pull only that was the model They had in mind as well and the idea is that just you pull things into your tree And if people if you're Linus Torvalds you pull in who you want and then everyone gets your tree because they're interested in your tree It's not like Linus's tree is the God tree But I think everyone else that I've talked to is using this sort of centralized subversion like model We certainly do for the x-strike force where we've got Basically one xorg tree that we xorg server tree that we use for example And it's really the canonical tree We can have user trees if we want we can have user branches But in reality there's the one tree that we consider the right one and the reason for that is simply we don't have a thousand contributors Like the kernel, you know, we've got you know me me and Julian hacking on it So It's it's not a massive thing and get can scale up in that way But a lot of the docs are made For that sort of model get format patch and all this stuff, which isn't really as useful for for the Debian model So I'm not entirely sure what other sort of intersection things you might be curious about Yeah, hi, I'm Johnny to echo and I maintain deep patch using git, but there There are other tools in Debian like a git build package and like dev scripts Dev commit tools. Do you use those tools? Okay? So I've experimented with both so git build package. Has anyone use git build package put me One per two, okay, so git build package is really not built for the specific problems that the x-strike force faces if your upstream using git Using git build package will do the wrong thing every time it expects you to have a dot orage dot target dot gz That you have to import it expects that every time So if you don't have that, you know, we do have that but we like to pull directly from free desktop It makes sense So, you know, we like to we like to cherry pick individual package patches straight in then when we merge They get merged in magically, you know, git does the git does all the work So git build package will work and it does work for people It's a little finicky to use with pbuilder and stuff Which you might be aware of or at least it was a few months ago when I was actively trying to get it to work for us but For if you're upstream using Git I don't recommend git build package if they are using it. I think it's a great tool as for Dev commit I think was the other one you mentioned so I was using that as well and the problem with dev commit So Do people actually do anyone use dev commit perhaps with subversion? It's a great tool So dev commit, okay, it's only not everyone's familiar with it Dev commit will when you when you make a change to your Debbie and change log you run dev commit It will pull out the change it will take the diff from your Debbie and change log and use that as your commit message For we're committing. It's actually very nice for subversion Forget though the way git formats its log messages So you've got for example this this one line merge. I've merged friends, but here Move the files will be put into Debbie and X FBS. You don't have to worry about this means But basically there's one summary line and then what happens is that there's several other lines below it potentially if you Want to have a very long log file? You know if you've got a lot you want to explain so what happens with dev commit is that it'll use the whole thing as one Long things you have this one long master Line when this is really supposed to be much shorter So that's a problem with using dev commit with git and the other issue is that Okay, so a lot of people probably don't know git so git Exposes something called the index And this is really a sore point for a lot of people. It's really something you have kind of to wrap your brain around And it's really not that complicated Basically, you could think of it as a staging area and everything has this so subversion has an index and it's basically when you run subversion diff It compares the index which is you know It's cached version of what all the files versus, you know, what your changed file is and it gives you the diff It doesn't have to hit the network. So that's the index. It doesn't expose it But it's there git actually exposes it and makes you deal with it in a lot of ways You don't you can get it work around not using it, but it does expose it It actually becomes a powerful tool if you want to use it So for dev commit what you have to do is actually Tell you have to manually update the index for the Debian change log and only then will dev commit see the change Which is really horrendous and really the wrong way to do it So there's a couple problems with dev commit in terms of Debian right now And I'd love to see those get fixed, but I think that It's probably not the correct way to be doing things right now I think the tools are substandard for for the specific needs of git They're really written with subversion in mind or CVS any other questions comments Martin Do you use any feature branches? Use what feature branches with that? I mean yes. Yes, okay So would you would you care to explain that workflow a feature branches like if if you decide to add another Feature that may want to go upstream at one point in time Then you put that all in the branch and then later on you can merge that branch back into your tree or send it up upstream right so yeah Martin brings up really one of the key points of using distributed version control and especially Get actually because gets branching models cheaper than anything you've ever seen So version they say branches are cheap It's only cheap if you're using SVK because you have to hit the network every time you want to switch a branch SVN switch it takes forever, right? So how many people use SVN switch or have used it? It takes a while right? I mean especially for a large tree. You have to like wait for the network. So I have a new branch You know, I mean it was nothing like it just happened There was no hitting the network. There was no nothing. It just it just works so Get what this allows you to do and it really kind of encourages is these what Martin was talking about these feature branches Where anytime you want to make a change that's substantial and honestly even when it's not that substantial It's a one-line fix that you really want to test extensively or you know, whatever It's really useful to have these and then what you do is you just make it there You commit it in that feature brands that no one ever sees except for you and then you pull it back into your Into your main thing to push it to to upstream and they're really great because they're extremely cheap and you can just delete them later no one ever knows they existed but you and It's really powerful because you can have a billion feature branches around at any given time So I think that it encourages a very a better model. It's really the right way to development is to have future branches I think that subversion hopefully subversion will get proper merging. They say they will but it's really a nightmare every time We had to update the Every time I had to merge in updates for For X for example in the XORG six eight to six nine transition I had to merge a lot of updates by hand and it was just horrendous. So you don't have to do that as much of the get It just kind of works One question on the feature branches where at least I'm a bit struggling currently is If I have some version of my Debian package and says well, okay Or basically I say I want to have the upstream as a mine target and make all features I add as feature branches, which seems sensible to me. So Then I get the next version of upstream Commits a commit the changes in import the changes in my main thing and now what I do I do to feature branches and what I do to some resulting Debian package to have it all without Major pain because they're somehow struggling. Probably just need to Probably is doing a brain to accept it how it works, but Okay So you want y'all to let me try and repeat this and see if I got it, right? You want to have multiple feature branches and you want to merge it back without pain. Is that right? Okay, it works even worse. I want to have basically I said, okay I have the upstream package. I have the Debian package. Yes, and all the features that I added in the Debian package I want to have as separate so that I can see okay This feature now has this and this and that so in case upstream decides to Upstream I saw I can send them as separate to upstream and I want to keep them as feature branches Until upstream decided to merge them. So how do I do that? Especially if they're a new upstream version in between So you do that as pole only essentially no Rebates This is a new one. This is why I wanted the boss so people can teach me things. What are rebates? I have heard about the base, but I've never let it on it Successfully. All right Keith can explain rebates because I don't know this one. This is exciting Yeah, oh rebates rebates What get rebates does is it so say you have a feature branch that has one commit on it for the ease of discussion here What get rebates does is it does a diff from that feature branch back to the back to where it was branched from? Generates a patch and then applies that patch where wherever you want to rebase to and then moves the branch to the result of that Commit so it takes a diff does a patch does a commit and moves the branch to that new point so basically relinks your feature branch to a new place in the tree and So see what it does. There's a good picture there. You can see it merging It's moving you have on your topic branch You have three commits a b and c and they're originally based at e What the rebase does is it actually moves them so that they they are now based on top of the commit at g And all of your all of your changes are are integrated appropriately and the commit It's using the regular the regular get merging techniques, which are pretty darn good I use this a lot because as I do a feature branch The last thing I want to do is expose that feature branch and the and the fact that I used a feature branch and publishing my changes So I'll do a bunch of commits along a feature branch I'll rebase to master and then I'll push the results so I get a single line of development I don't get these artificial branches And that makes the that makes the resulting tree look a lot cleaner when you push it back as well But you can do this with as many branches as you want So you could you could automate pulling in a new master branch and just rebase all of your topic branches quite easily So and how do I do it if I say I have all my feature branches concentrated in one in my Debian version. So all features are imported sir I It's just as well Made a version should just come from all the seas seas seas branches So how do I do that or just is my brain just not the web up enough around it yet? I think you have to play with it. So having having rebased It's common enough for me to want to do go and do archaeology on previous versions of my package to see What it did in some circumstance It looks it looks to me like once you rebased your that's it your topic branches now the new thing Can you go back and look at what it used to be? I don't believe so. Oh, you can go back. I've never tried this Yeah, he should stand up here This is great Now the important thing here is to look at the old commits the old commits were labeled a b and c The new commits are labeled a prime b prime and c prime the old commits are still in the repository If you have a version if you have a distribution version that points to those old commits They're still valid. So you can still do diffs against so you may have rebased the topic branch But if you have some other branch name pointing to that place like a released version that old branch will still Still refer to those old commits. So you lose nothing get never throws anything away so In the back his heads end up for a while So I'm a subversion user trying to figure out You know what what this is all about because I keep hearing lots of people saying this is just the best things in sliced bread And I haven't figured I haven't gotten it yet. So I've got a bunch of Debian packages I maintain them in subversion. I use quilt for all changes to anything upstream So I basically have no modifications outside of the Debian directory How does get help me because you you say one of the big things about get is you can merge with new upstream versions? Really, but well, I have a bunch of quilt packages. I have to merge merge the quilt patches. Does guilt get help with that? So Quilt is an amazing tool. I don't think I can sell it quite enough So you might not be getting tons of benefits out of subversion if I'm sorry I've get if you have quilt inside of subversion. I mean we were doing that. It was very successful But even without that I found that get I mean number one you you save a lot of time with get it's fast you do save a lot of time just doing basic operations and So you there is a net gain there and most importantly is really the branching You can have very easy branches and you can commit anywhere you commit on the airplane You can commit when you don't have when your wireless is down You can commit anywhere without any troubles anything is equal And that's really a very nice tool to have available to you the branching truly is cheap It's not like this sort of fake. I have to hit the network every time to get it cheap Which opens up new models of development. That's almost hard to describe in a way I gotta say real quick that I think a lot of your speed problems with subversion were because you had a painfully slow Subversion server not because subversion is actually slow. I mean I do the situation you're describing with slowness of subversion I've just never experienced that we have a very I mean we were maintaining the XOR Monolith inside of subversion. It's a very large package set subversion did not scale very well to that It's it's hard Martin has oh and Pierre as well. Yeah, Pierre was Actually first I'd like to stress that it is fast and it's a thing that you cannot stress enough even if you have a views to SVN with easy over ECSH with ECSH control masters, which helps a lot and it is Hopefully faster and well once you have tried it once you just can't use anything else because it's really really fast And you can't bear the fact that it takes ages to commit a thing in SVN anymore until the end I'd like to come back to rebase a bit because David said that a gate is unused well not only but is useful especially if your upstream is Use this gate. In fact, that's not true because there is a lot and a lot of Tools to make it interact with other SCMs like SVN, but CVS also and Arch or Bezada also it works really well and With rebase on you can have all the nice features of gates working even if your upstream Is dumb enough to use this to use CVS or SVN. In fact, well, I I'm not there quite yet, but I'm trying to package a lot of things using these techniques and having my patches in gates and sending them upstream and seeing them come back through their CVS or SVN server and seem them merged Using rebase. I'm not sure this workflow works very well yet, but I'm quite sure that it will perform very well because Well, it has been returned to work like that and in fact using it that way is introducing the Distributing way distributed way because your own and it's really what David is and she reminds It's Taskforce are doing in fact. He said we have a central repository. That's not true. They have a satellite No, how to say that Their main repository is a free desktop one. You have for a secondary repository and your repository is already the distributed model and you are using it in fact Even if in the x-tax taskforce you are using this repository as a reference. In fact, it's only a second one So I think gates is a great tool because it's fast. You can work at home You can then push things later. You can work in the plane back from the company to work and You can and well, you have to try it in fact. In fact There is nothing to to persuade to To convince you more easily than using it just play around for the record I have there is an important the web of the full JLBC history from 1983 it's 150 megabytes big and you have everything and When I work with a really on the on the live scene Today, he asked me three or four times Well, when is that patch or test came up in the repository because we've get I have the answer under one second when he has to go through the view CVS thing well Maybe you know in one hour or two. He will have the answer When I get back to that question why get is so much better than SVN and quill for a package maintenance and well, if if all you do is ever pack maintain your own package in SVN with killed on top to manage patches that were submitted by the backtracking system, then I have to admit that the speed which these two guys have been really high upon is Is one of the main reasons but as soon as you start to do things like branching as soon as you actually develop Parts of the package and you use a branch to do that. You really do not want to be using SVN I'm a zopin-plone developer and zopin-plone use SVN and It's a rather big repository as well and one of the things that get does very differently from SVN is merging branches Because the way and then nobody minds if I just explain this a little the way that Things work in SVN is that basically branches are nothing other than two separate file trees So that if you merge them what you're doing is applying a patch Now imagine that you are creating One branch to do feature a Another branch to do feature B and another branch for feature C And now you fight figure out that you actually need feature a to get feature C working So you merge branch a into branch C And then you continue working on C and you continue working on B and at one point in time You decide that B and C are both right for production. So you merge them back into the trunk When there is a conflict because all the changes that are in B are or in a are Already also in C and what you'll end up with is a hundred Reject files and ORIG files and you have to tell SVN that now this conflict is resolved and now this conflict is Evolved and the way that git does that is that every single commit has a Unique string a unique identity attached to it So if you merge two branches what's happening is simply the union of the sets or a set addition And it only pulls in exactly those commits that aren't already in your local branch So it is actually very much smarter about it. So if you use branches Don't do it in subversion, right and there's there's other I mean, there's fairly common examples of needing branches that are they're just trivial But you can't do them in subversion trivially and that's really a problem like if you've got If you've got it if you got something that you're not finished with You know commit, you know some sort of commit you're not finished with a long-term commit or a long-term branch That you really just want to work on and it's not done Get you can just do a local clone very quickly and very easily with I mean you can copy it in subversion But it gets it's subversion is also really huge that the day directors are much much bigger than it get get compresses Amazingly well, and you can make it compress even better Using all sorts of all sorts of tools that it exposes that you don't have to use but it's available to you if you want them Repack and all these things so there's some very nice things that it provides that are very low-level that I don't understand yet So I won't go over them But they're available to you if you want to learn Oh, how is the format what is it the format that gets towards in the post repository is because let's say I want to set up some tiny repository to play with it manage my documents Whatever, but I want to do backups from it and then if it's all compressed as one file For example, I would need to backup it each time with each tiny modification or is it friendly to that? Oh, it's available to you. I mean it compresses internally I don't remember that the format it uses internally. It doesn't throw anything away though, but it's all available to you. I mean I'm not sure I understand. It's not like a tarball in tarball. It's one file per commute so I can Is it internally? So how friendly is it to our scene backups? That's basically the question Our scene backups basically, I didn't understand. I'm sorry my Oh our sink. Oh, it's trivial. Yeah, I've our sink several get repositories. You can do it. You can clone Cloning is I don't know if it is an r-sync But it might as well be in a lot of ways you can r-sync a directory No problem, and then you can check out if it's just a bear get director You can check it out from there as well, so appear saying that clone is a better way to synchronize the repository I've done it. It's not been a huge problem, but it you know You know you can r-sync you can certainly can if it's hosted you can pull it I don't think you can well. No, it doesn't throw anything away. So honestly don't know the answer to that And then you have to transfer the entire thing Right, right. Okay now. I understand I see so yeah, I don't know internally if that's if that's the case I think if you probably don't pack it too much, it's probably not a huge deal You can pack it at some point and it will compress into a Very it might be one file. I don't know. It's highly compressed at that point But I've never looked into it that deeply to know the answer to that. I'm sorry. So while we're on the question of r-sync I've Used buzzer a bit and I found that r-syncing buzzer repositories is a complete pain because they contain enormous numbers of files Just get suffer from this problem It doesn't need to By default Every come every file every version of every file in git is its own file So in the old in the original repository structure. Yes, there were a phenomenal number of files every time you made a change to a Single file there would be a new file created in your repository Which if you tried to r-sync that it would be a disaster However once Lien has figured out that that was probably not very scalable He came up with a technique for taking multiple files Independent of where the where the original source independent of what source file they came from you look at multiple files in the repository and pack Them all together aligning their common data data chunks Such that the that you can pull out files very rapidly from the pack packed version of the archive and then so so What you do is you run the git repack command which takes all of the unpacked files and sticks them in a single new pack file So you basically have all of the things you've done recently in your repository are now in a single file Now if you r-sync that you copy one file now you work for a week or two You make a bunch of new changes you have a bunch of individual files You pack those together into another pack file and you r-sync again and it copies one file So it's extremely efficient with r-sync because you copy only The changes that you've made since you are same last time and you own and the entire r-sync operation is a single file Now if you want to you can actually take all of if you have a thousand pack files now You can actually tell git to repack all of those into a single larger file And it will throw away all the individual pack files and at that point you are sink You are syncing the whole new file, but you can shrink your repository dramatically by that The entire six years of X repository information for the X server is like, you know 50 megabytes or something which is about the same size as a single checkout Right, that's something to bring up actually when we had our subversion So a single subversion checkout of the X server from our old subversion repository Was about twice as large as the checkout from the extra for upstream when we switch when x.org switch to git And we had the entire history in every single branch ever Whereas it was just one checkout of one branch from subversion of our of our own extra force repository I know subversion's gotten better in that regard, but in reality there's massive space savings for git just very quickly I just did an r-sync test on a git repository and Therefore haven't listened to everything that Keith said so I hope I'm not repeating something but basically a commit will result in Additional files being created, but no existing files modified. So it's friendly for backups And with the addition of that repacking, I'm sure you can get Even like archive history and then make it even better for that in fact actually You can or think a git repository, but it's quite a bad idea because a clone will get everything From your repository and in fact some better way to Backup a git repository is to clone it and if you have a bag It's exactly what I do with my git repositories I have a script that clone it on some backup servers I have and when I commit to my central repository my backups Pull a game and they pull only the changes because git Transport is efficient and does what I think will do in a better way Sorry, I'm just quickly I Don't think that our sink is the best way to duplicate the git repository because you will it's not an atomic Transaction which is what you're saying, but sometimes if you have a backup tool that runs and it is based on our sink You can't really do anything else unless you want to switch over to something called backup ninja, which is an awesome Program that you can actually tell it to first clone the directory and then our sink that because there will be no commit going on Actually one thing that I Everyone done Children Okay, so one question what I repeatedly do with other system was for example subversion can do is that I check can just check out a Sub directly right can do that with a skid and if so, how no, okay So that's the problem with get you cannot currently do that And we've actually had to sort of balkanize some of the x stuff a little bit to make that happen There's two things that get doesn't do that. I would like one is check out individual director So you wouldn't want to say put have one git repository for like all of the package GNOME stuff You know and then you can't do that you would have to have one for each You know metacity and one for Nautilus and one for you know all these things so git can't do that currently there's Work underway though to make something similar to that happen, which is called sub projects Which is what you would really want it for anyway and the idea would be to have You know Nautilus be a sub project of the GNOME Repository and as far as I know what what I've been told by Xcb maintainers is that some of that a lot of that underlying work is in place It's not hooked into the UI and it's not going to the merge support yet. So it's not fully there And then the other thing that get cannot do that subversion can do that's often demanded is The equivalent to SVN colon externals does anyone know what this is or use externals Okay, so there's a few people so it's it's it's you'd use it for some projects sort of thing It's basically you're able to pull in a Specific directory or repository into a specific part of your own subversion repository and use that externally and it's pretty seamless It works really well. We used it for shared packaging information among the X packages and the way we do it now is we just have a separate repository for that Shared packaging information and manually pull it in rather than let the revision control system deal with it So that's something git doesn't do really well yet. That's a version does do Colin You you have the same problem and other distributed revision control systems mean arch and BZR both of the same constraint and You can almost certainly just use the same if you're if you're desperate You can almost certainly just use the same tools the the arch guys route something called config manager Which is a bit of a hack, but it's just something that takes a plain text file description of the other projects that you want to incorporate basically like SVN externals and Check those out and or update them as necessary and you can probably just use the same thing Interesting. Yeah, the problem. I've heard with that and I I don't know enough about The implementation of a revision control to comment on this further But the idea is that each change is actually a change set and that it covers It's it's it's basically a change set over across the entire repository. So if you want to pull out a specific Change set you have to get the entire repository. You can't just pull out a sub directory and this seems to be an architectural issue Which is the way these things are implemented That's that's what I've heard. I don't know if anyone can comment further on that. I See we have 15 minutes Small question back to different tools. I have Requirement to pick Eric Targaze from tag not from branch head, but from tag Sources is there any devin tool which can provide it from from what sources? Take the sources. So well my Arrictor Gazette is not in herd somewhere may be in previous tagged sources. Well, I have an upstream branch Yeah, and There is upstream version 1.0 1.2 1.3 and so on I have tech for all of them and The head now is 1.3. For example, I want Arrictor Gazette for 1.1 I want to build a devin package 1.1 minus something. Yeah, so we do that So there's a limitation so yes, you can tag anything you want. We do tag our own we tag our packages to build what Well Yeah And actually get bill package will build your own orage targe easy And that's actually one of the problems I have with it It actually will build that for you out of the out of the get repository. It can be done I don't think it's the right way to do things. I think it should just You know use what's there? Yes We use his head Okay Okay, is there any way to fine tune access control? Is there what? How do I manage passwords or access to the main repository? It's via SSH So we use SSH and things like that. So for local stuff. I mean, I've never tried to do local access Restrictions, but for remote stuff, it's just it's just SSH Which means you cannot restrict someone to a specific branch or something Not that I know of does anyone know if it's possible really How do you configure that? Actually, there is some reason to to inform that but I don't think there is there will ever be very powerful to to do that because Linus explains that Basically, he doesn't he doesn't want to hide code and He just want people to clones the main repository Whatever stupid things they want in the repository But he won't give them access right access to him repository. He won't just put he will just pull from them So in fact The any access control is done because he either he pulls from people he trusts Or he reviews the patch because before he merged them also, uh, we wanted to use a distributed version control system at work and The major showstopper for us is that we have a lot of windows people Are there any GUIs that that are in the works? I don't think there's any GUIs yet I mean, there's there's I don't even know if they run because they're tk based. I assume they'll run on windows. Um There's there's the git commit tool which comes with git 1.5 and there's also A git k which is really a wonderful so as anyone see people might not have seen See if you can see in 800 by 600 I'm my slow laptop So there are visualization tools, but they're not great. They're nothing like torus svn or anything like that that are really quite nice Um, but there are really nice visualization tools for the likes of us. So if you want to see, you know changes Um, I believe busy has cloned this right busy wrestling similar to this right now What? Yeah, yeah Okay, so yeah, this has been cloned because it's a really good idea and it's really nice I don't think subversion has anything like this. Um, it's just a really nice interface to to check out changes and See how see how branches merge and this is a relatively simple branching pattern So you don't see a whole lot, but it can get complicated Are you serious? It's yeah, you you talked about it when she's in they weren't shown on the screen Sorry, I I I didn't get Keith to fix my laptop like he managed to fix martin's so Um, sorry about that. But yeah, basically it's a really nice visualization tool But um, the problem is also just getting git running at all on windows. There's a min g w port in progress I don't think it's mature I haven't been following it closely and then there's you can run it through sigwin But a lot of people don't like using sigwin So it seems like if you're going to use distributed vision control on windows The real winner seems to be mercurial from general consensus that I've read around and mercurial is a great system I will not badmouth at all because it's wonderful and it's very similar to get in a lot of ways But hopefully git will eventually come to windows properly and people we can you know Not have this issue with at work people want to use it Yeah, bizarre this too. I'm sorry. I forgot about that. So yeah several there are other options and darks does too I think I like askel So is that five 10 great I have one addition. There is a nice talk from linus tobbles himself on google videos. Yes So if you have seven 70 minutes, I guess time, it's funny And interesting Yeah Who's who's watched linus's talk at google on google video is very well seen It's it's good. He really smashes the subversion people kind of he's kind of mean about it. Um Awesome, I bet he I bet he loved it But I think linus has really spot on a lot of ways in that video and it really is good to see what he's thinking about And why he made the choices he made With certain things and it really does clarify a lot of the design things Design choices that git has made in terms of that seemed like they might be bad choices at the beginning and they really Have turned out to really feel the better I knew you said You wouldn't go over how you went from subversion to git, but if you've got a little time Can you maybe go over that process a little because? To do to do what exactly going from subversion to git migrating. I can't go over that I mean I can tell you what we did, but there's better ways to do that now So there was a script that comes with um, I know a peer is gonna Yeah, I know yeah, I know what he's gonna say because he blogged about it and it's actually very exciting So we use there was a script that came with it to convert the repository It's this massive pearl script and it would go through the subversion repository and sort of guess What was the right thing to do it every time and it would convert it to a git like format And we had to hack theory had to hack that up insanely to get it to work for our messed up subversion repository But he managed to do it So that's how we did it but and then but the better way to do it is that there's actually a program called git-svn Which comes with it and that's what peer is raving about and I haven't had the opportunity to use it yet So I can't really talk about it very much, but basically it allows you to transparently use git with subversion repository so that Your co-workers don't know you're using git they don't have to care and you get all the benefits of using it Essentially with subversion being the back end So you can actually by making A clone using git svn you get a git repository that's totally converted and it just works And then so that's probably the best way to do it these days And you just get the repository for free and you don't have to deal with all the mess that we did So not having the experience with that myself. I can't really lead you through it But that seems to be the right way to do it Pierre do you want to add to that? He's actually got experience with it Actually, I'm using git svn for two things at work because We sadly use svn at work And for to work on the glibc because the glibc uses svn.dbn.org but I use it through git But in fact, git svn is a very good tool to migrate a repository because it does everything by itself But it's not a good idea to to believe you can learn git using git svn because You have most of the benefits of git but you have you still have svn behind and When you have things like that Here what you see is a merge It's basically that the the graph that is behind has a Convergence Merge point and you can't have that in svn. So in fact in svn you are you are forced to have a linear History and to use git svn you have you have to know how to Linearize your history and it's quite hard to to figure it out When you're new to to git so if you want to switch it's better to Sometimes run git svn to have a full git repository that is the same as your old svn one And use git on this repository And if you don't like it Go back to svn for a while and we try it every time you want because using git svn You have to know git a bit before Okay, I just quickly wanted to say I claim a little while ago that you could control users User access writing. I can't find the information anymore So I think it's better to assume that you can't do it and get the positive surprise I'll let you know if I find it still and I just quickly tagging on to this The the talk today is about git and debian, right? I just wanted to do it a little bit of a Self publication here because on the 21st, which is Thursday Manos and I are going to give a workshop at two o'clock For two hours, which is about using distributed version control for debian packaging and we hope to be able It's the same model for git or bizarre or any of these other ones We hope to be able to give some ideas of what other things you can do with branches to make your day easier So on thursday too Pierre you mentioned problems with using git and svn due to merge points, which I assume is from subversion not doing merge tracking itself Has anybody looked at integrating git with svk or with the With the extra merge point tracking that's basically what svk gives you over subversion Has anybody looked at integrating git with svk, which Basically stacks properties on top of subversion. I know it's horrible, but if you want to enter work then It's one decent way to do it actually, I don't think it has been even considered because There is no point in using in Using svk when you can use git git svn Yeah, sure, but git already already gives you that in fact, so you have many ways to work with With svn in back end and having many merges in git you can for example Create a squash commit Which is what git svn does anyways, so Okay in a git kind of way It's horrible, but when you work in with svn, you don't have a choice So you have many ways to hide the facts that were merges and In fact the also of git svn Uses it and I do that all the time also as a two way gateway to a svn repository and You don't really want to bother with svk? Yeah, sure. Yeah, I agree with you, but on the other end The other users of the svn repository won't benefit of it if they don't use svk as well And in fact, they could also use git Well, we're down to less than five minutes left. So if there's no further questions We may as well as he's holding up. I'm time out anyway, so we're done. Thank you all for coming. I appreciate it I really am overwhelmed by the response And I hope you've learned something that you'll enjoy