 We're going to talk here about that person called the system. And the name of it is Bazaar, but there's a bit of confusion about the name, because it was formerly known as Bazaar and Geese, Bazaar and New Generation. And at the same time, as it was called Bazaar and Geese, there was another project called Bazaar, which was written in C and based on art. But that project got created and is now known as BAS alone. So the meaning of this project, written in Python, is Bazaar. And the common is Bazaar art. So I don't want to say Bazaar, but that's the common. It's a New Generation vegetable system, so it's decentralized, or not if you don't want it. One of the features that I like very much is that branches can be published over plain HTTP. So there's no need for any touching of the HTTP demo on the server. So if you have HTTP polishing abilities, you can polish the server branch. And you can also push over plain SSH, which is the need for the program to be installed in the server. But if it's installed, you can use that, and the pushes will be noticeably faster. We'll see that the web page of the project and the documentation is in that URL. And for support, there's the list and the IRC channel. Both are, you will find very helpful people for solving even the most basic questions or complex problems. So let's go with the websites that everybody who has used any version of the system, like Subversion or CBS, or one of the new ones, will be familiar with. The first thing you want to do is put your name and your address, because within the version of the system, instead of the login, you use a full name and the address. You can do it in either of those ways. And then you go create a project with Bazaar in it, or to pull some upstream project or whatever with Bazaar branch. And the optional territory argument places it in another territory name differently, as, for example, in this case, FAN. So you have the standard commands. Here, like add, you add files so that they're kept under version control, or you can add directories and all the files underneath them will be add. And then you add, you make changes, whatever. With Bazaar Deep, you can XMI in the changes you've done, or you can, with Bazaar Deep along, it gives you a deep output of changes you've done, or if you specify, for example, a dash error option, you can see differences from already committed revisions. For example, what you did commit in revision six, or what you did commit in the latest revision, there's a rich syntax for specifying revisions, but it's basically a deep command of any other version control system. Bazaar Stages gives you a list of modified spiel files, add it, remove, rename, and so on. And you commit the changes to the branch. Unlike traditional version control systems, these do not propagate the changes to wherever you check out from. We'll see more about that later. So you have to do an extra step to publish your changes. Log just gives you detailed information about the revisions that are in the copy in the branch, and you pull changes from the string location you grabbed the branch from. Remember, for default, the first time you do a pull, you give the location, or when you branch it, it remembers the location, so you can specify a pull alone, and it will pull from the known location. If you want to change the location, because, for example, the string changes the location, the address, you can put here the new address. And if you specify, remember, that new address will be remembered for next uses of pull. And with dash v, which I like quite a bit, it will give you a list of the pulled revisions, so you can easily see what was changed or added or whatever. There's another set of commands, which are less often used, to remove files from version control, so if you don't know, you won't be able to do it. The turn object is committed, so you go back to the pristine state of the upstream branch, or the last committed state. But with uncommitted, you can uncommit the last committed version. So if it had a bar or whatever, you can uncommit it, fix whatever it was from, and you can uncommit again. Note that you can only uncommit the last revision, so you can, unlike other version control systems like ours, you cannot uncommit revisions which are not the last ones. You can, however, uncommit several of them until you arrive at the one you want to commit. That's up to you. The uncommitted is that the last provision of that file was changed to the last, so if you have a revision, it changes the file, and then another revision it doesn't. If you do an uncommit, does it take you back to the one with that file changed, or does it only uncommit, or does it an atomic uncommit? It only uncommits the top one. That whole revision across all files? Yes, because our work's across the entire tree. It's a long hit in the top one. Well, yes, but CDS works on per file basis, and there's yes. Bazaar works on the entire tree basis. So CDS could be atomic per file. And Bazaar info gives you some information about your copy, and it tells you the location of where you pulled from, the format you're in, the number of files. Well, some information you may want to have. Yeah, this is the furboss output, and with newer versions it will output less information. Well, you can request it as well. With Bazaar tab, you can tag revisions. We've given them a symbolic name. It's not like the submission where you make a copy. It's a real tab. And with Bazaar missing, you can know which commits you are missing from a sample from an upstream branch. For example, if you remember the location and pulls the server, yeah, and it outputs the revision that you're missing. So it can help you to decide whether you want to pull or not. But when was your tag introduced? 015, I think. Yeah, yeah, near 015. You have to, there's a gut shadow. You have to create the format of the branch to one name, just type dash tags. Because the default is compatible with lower versions and the format that supports tags is not. So if you want tags, you have to upgrade to that format. But it should be OK today, because we're on 017. So it's perhaps safe to assume that most people have at least 015. Actions 011. Actions 011? Yeah, well, it's a fast moving, it's still in development, so it's reasonable to assume that people have 015. And if the server help you get help for all commands and some topics like commands, you can get a list of all the commands with the server help commands. There's a lot of them, but the one use you will use most are those covered here. And if the server help topics gives you some topics you have not at command by themselves, which are nice to know. So as said, a committee in distributed dressing control systems does not automatically that extra step is, for example, push. You push the branch to somewhere, for example, an HTTP server, and then it's available. For example, this is our push, and it's an absolute directory by default, and you specify till that here. It's a relatively door to your home. For these two words, you have to install the Python Parameco package, which is a recommender of bizarre, so it should be installed by default. And you may want great practice, if, for example, if relative does not exist, you will need to create practice so that all intermediate paths are created. If not, you will fail. And as with pull, you can use remember to change the default location for push. So if you change the location, you can give a new one and have it remember for further pushes. The directory will look empty, because by default, only the dot bizarre directory gets pushed, which has all the information necessary to be able to pull from it. If you want to pull to push the contents as well, you can use the eras push command, which is part of a plugin, which will do a player, that will push the contents as well. So there, you get a basic people can submit the files directly and can pull as well. Another way of publishing is to send a patch by email. The standard way of creating patches in Bazaar is done with the div command, but with the bundle command, because it has some goodies. It's basically equivalent to a branch, but in one single file. It's human readable, because on the top, it has a div of all changes in one big picture. But after that, it has metadata, which is the copy of the branch, like all intermediate revisions. So when people apply them, a history is preserved. You create a bundle like this. In the working directory, you reserve bundle, and you give the branch the branch before it comes, so it confuses the difference and puts it into it. You can also give a list of revisions to the branch. You can give a list of revisions to create the difference. But normally, you use the parameters. By default, if you just use your bundle without partings, you'll take the parent branch, which you can, of course, choose arbitrary branches you want to bundle. So with distributed version control systems, the workflow is a bit different. So normally, if you want to hack in a project, making several changes to it, you keep a pristine copy of upstream. So there, you only do pulls, not commits. So you always have a local copy of the pristine upstream. So you can convert to it easily without having to contact the remote server. From this upstream pristine copy, you make branches. One for each feature, or boxes, or whatever, you are going to work on. For each independent stuff, you create a branch, like this. You, with the branch command, this is the location of the upstream branch, and then you give a meaningful name. Or you can use CP, which can be a bit faster, and it's the same. There's no real difference. So you make commits in your branch until the feature of the back piece, or whatever, is finished. And then you do one step, which is to march from the upstream branch to make sure that your changes are compatible with the latest changes that were introduced upstream. There may be conflicts, yes? No, I was wondering about the branches. Are those actual files, or are they hard ones? They're actual files. Yes. They're actual files, so you're quite a bit of a tree going on if you want to change your branching. Yeah. There's a feature for that, and it's the next issue. The next issue is the upstream branch. So marching before publishing is very important, because if there are conflicts, you, as the person making the change, are the one responsible to fix them. So it's not the extreme amount of person merging your changes who gets the conflict. This is very important. But in most cases, there won't be a conflict, but if there are, you must resolve them. And you publish the branch as seen above by either push or creating a bug. So as he said, when you branch a lot, since each branch has a full copy of the project history, it can need space quite quickly in big projects or when you make a lot of branches or both. So because all branches share more revisions, more commits, they're basically the same as that for the last five, 10 commits or whatever, it makes sense to share those revisions among branches. So here is where shared repositories come from, which is a feature that I don't think any, well, I don't know if any other version of the system has, but it was introduced in the start for this reason. So the idea is to keep the branches involved under one directory, which is called the shared repository, and the revisions that are shared among them, well, all revisions are kept in the top-tier directory and most of them will be shared. So you create a repository like this with init rebel, and then you just branch normally underneath it. So as long as it is in the story of it, it's fine, like this, you need the repository and then you branch for almost upstream the tribe, the stable branch, and then you can branch there for your feature, for your backfisher, or whatever. And all these four will be using the same copies of the common revisions. Do you need the special kind of the dashboard trees? It was changed, not anymore. Got it? Yeah. And this is also useful when you're pushing multiple branches in a server, because you don't have to push all of the common revisions each time you push a branch. You only push the new ones. So a set of all, besides the centralized, the centralized is only if you want it. You can also work in a workflow which is very similar to CVS or subversion. If you achieve that, we are check out. A check out is very similar to a check out in the CVS and subversion. There's a difference, there's still a difference that it still has a local copy of all of the history. So there's fast dev, fast log, and all the operations which in subversion or CVS need to contact the remote repository. So it's also offline, being able to work offline. Yeah. And so all operations. So instead of branch, you use check out, but note that you don't check out the HDB location. You have to check out the location for which there is writing support. So in order to make a check out, it only makes sense in properties. You have write access to, just like in subversion and CVS. You have, and like above, you update for commit, because the commit files, if you are not up to date, and you put that in the equivalent of pool. So you do a date, and then you commit. And the commit goes to the remote branch first. If it succeeds, it goes to the local branch. Updates, the equivalent of push, right? Yeah. No, of pool. Instead of pooling, you're meant to push. When you're meant to push. Yeah. There's another kind of check out which are called lightweight check outs, which are the very same or almost the very same as CVS and subversion check outs. There's no local copy of history, so lots of operations have to conduct their remote location, which is only makes sense if you really need to save space and the remote location. You have such trees for repost stories. You can't make repost stories that do not have working trees. You only want to write branches, and then you use lightweight check outs in a different location to get the direction tree contents. There you hack and commit, and it goes to the other location branches. And so in your local artist, so hitting the network for operations is not really a big problem in that case. But even if you use check outs, you can still work offline, as Lars said, and you can even commit offline. You commit with the local option, which commits only locally, and there when you are offline again, you push the location. So there are some queries with it because there may be innovations in there. You should be able to do it for back online. These are updates. We'll check the master branch for updates. If there are any, you can switch your local ones to pending mergers. And then you have to commit that. So the push is, if there are no string divisions. It's like, okay, okay, okay, maybe. But usually these are updates, okay. So, yeah, I skipped this version when I came home there. I, on the branch and emerging stuff, I skipped part of it, sorry to let you know. When you publish a branch and then upstream has to merge it, the history is preserved, which is what you made, which is many times what you want. I like, I particularly like very much the way Vasardos does it because it's in a non, what I call a non-inclusive way. The whole history is committed as one revision in the upstream repository, but your local changes, each of your revisions are kept in sub revisions. You can see an example. For example, imagine you made this, the Vasardos made plugin and this is the upstream pristine copy. Then I branch it to piece some book. I go to the branch. I use, I add something or whatever. I call this function, whatever, but it's wrong. The name is wrong. Okay, so I commit this, there it is, so revision number 26. Then I will list the name of one, so I fix it. Then I want to add recommendation for the plugin. So, I did three revisions, right? This one, 26, 27 and 28. And I do a bundle like this, a scene. You can see it as promised. There's a deep part with only, so I send it to upstream and upstream wants to merge it. Here in the master branch, well, it's the same computer, but this method is, now I'm spring. So I merge it, okay? No conflict, and upstream's merge it. Could you do the status, just in case? Fending merges, here I show the, where it's fending to merge, you commit. So upstream's committed, and then it commits revision 26 in the upstream repository, in the upstream branch. Here's 26, apply fix the message. And as through revision, there are three things that I did. But there is no direct way for you to know when you send to the stream, which revision numbers are your, is your patch going to get, whatever. Yes, I mean, the revision number, your soft patches are assigned when they are applied to the upstreams. Yeah, well, they are merged. Depends on what they do. No, but I mean, if they are applied at the end of everything, or they are applied at the point that you branched off there. At the end of it. At the end, the revision numbers only make sense in one branch. So 26 in one branch, it's not the 26 in another one. Yes, it's very, if people are working with one, it's very useful to refer revision 200, and you know, well, that's one that introduced one. There'll be context talking about one. Could you show, is it our work? That's their shell IDs. Because it's a decentralized system. So each revision means they have a globally unique identifier. Which is what it has underneath. Yeah, that's what I'm looking for. And that's preserved. Yes, because you want to refer to, well, I sent you this patch, and what's, where is it now? That's a. What you do have is the so-called post graph nodes. You see, you're far ahead of 1.3. Those are determined where you branch from. So if you branch from the email upstream from revision 25, you do stuff and send it in. You know the divisions you committed, and not the one that upstream was. So we'll have those, yeah, dotted provision numbers. In the only case when there will not be 25.1.3, et cetera, is when the upstream branch uncommits a version or does revisionistic changes operations. Right, and of course, this is not only our keeping the laws, of course. You can see the real changes, like, let's see all the changes, any particular changes, okay? So, history is really perceptible. Or if you read it 25, 26, you get a whole patch of, right, like if you need it. Does it save the original revision numbers from the branch? No, because revision numbers, say you save just the ID of what you know. Yes. And the revision numbers are determined by the shape of the history of the branch. And if you don't mind upstream to have your history, you can, of course, send a normal leave, and that's it, it's not compulsory. I think the way to marriage is like one of these two. And if you go out and in questions so far about how anything of this works, or you want to see some of the people thinking more today, they're ready one. Just to be clear, if you want to commit several files, you can just commit one file, but if you have different patch punks within one file, or a shell is what you would use to commit only one job. This one is a branch, as our tool is in Debbie. There's branch branch support, which means that you can access branches in other version code systems using bizarre commands like for subversion, which is package, and for work URL, which I think is only right on me. Which is broken. Oh, thank you very much. Okay, but bizarre has a question, it's working, it's really working, right? Subversion, yeah, I use bizarre subversion. Okay. And there's also a work call front end, bizarre DTK, and you can see all the list of plugins here. And finally, bizarre accepts ADS for commands, you can define them in this file, bizarre.buzzard.com, like this. Just use it by ADS section, and then you just give the name you want, equals whatever command you need, whatever options you want. So this is just an example. So everybody's talking about the decentralized version control system these days, so it's only a matter of using it and see which one you like the most. I enjoy bizarre pretty much, so I recommend it to everybody. Except for you, but which one do you use? You talked about R-Sync push, about R-Sync? Yes, it's in bizarre tool. You push with R-Sync. It's not something I really recommend, because in our case it's when you want to have the working tree at the remote end, if you're publishing a web page, for example, but if you have control of remote appearance, better to just do a PCR update. As each push takes two steps instead of one. You have to push sure. With R-Sync push, you're doing the direct ones. Yeah, you're transferring way more depth data that you really need. There's a plane that's called push and update, and why? So you invoke that, it pushes, as it says, SHH into the computer industrial sub-quart. So that's probably better to use. And that's in bizarre planes, like a separate tool? No, it's a separate plane, sorry, R-Sync push. Which plane? R-Sync. Push and update, it's written by Joel. A lot of people also think they need to have the content where they feel like if they're just using it to work in bizarre, so you can just push, pull, merge, carry things. Push, push, push and update. Are these the other on both ends? Yes. These? Well, it does. Yeah, yeah. But R-Sync push doesn't, it still doesn't. You're just asking. Okay, yeah. Right. If you have bizarre in the server where you're pushing from, instead of push, s, f, t, p, whatever, just use the R-Sync push. That uses the bizarre in the remote end and it goes quite a bit faster. Yeah, this is the equivalent of how CPS works with the SHH into invoke CPS on the roadside. You can also use just piece of art colon slash slash if you have a sort of demon running on the other side. But then you probably run into a lot of ankle parallelities with the storage format because that's been changing the storage format. It's been changing regularly. Storage? You shouldn't have any problems with the storage format if you're talking to a smart server. Unless you're just sending a request. Right. What you might run into is smart server protocol, different differences because we're still working on it. Finalize it a bit more. The bizarre SSH needs the smart server? No. Bizarre SSH only needs bizarre in the remote end. You don't need to go to need. All right. And it needs a compile Bizarre if you run Bizarre 0.8. And remotely and 16 locally, that will have some problems. But that's not the storage format. It's basically the Bizarre API. We do keep compatibility one or two things back and that creates things, but sometimes you forget something. Yeah. And if you have a huge difference in versions used, you might get some differences. But if you use the same version or one or two different, it should be okay. What about web fragments for browsing the code and things like that? There is one, but there are several. So actually there are at least two. I think the nicest one is lower head. Yes. That's the one deployed at launchpad. If you go to code process, the lower head plug in basically. Okay. There's even Bizarre truck. Yeah. Truck plus Bizarre 0. So you have to track that front end. It's code growth, right? If you go, when they go to the tap, there is Yeah, go into one of the branches. Up one of the branches. You get on the left side. That's something called code growth. Yeah. That's what it's like. This is like by revision and everything. Instead of the top, it's in files. Oh yeah? No, it's everything. It's just like this bit work. So can you browse the actual tree or? Oh, files. Added up the files that, for example, are revision, red, and files, whoops. Gunnery. Okay. So you have everything you need. Yeah, this one's pretty nice. There's another one. Both files are always printed out with annotate. So you see when you pass them, how it's lost. Right. Right. Okay. Here. Oh, right. One. It only brings the first one, right? Right. It's the same for the continuing branch. Now one question I have on this is, well, the Git people take much pride on preserving and properly preserving history when you move and join branches and whatever. I mean, I have not used the distributed system yet. So I don't know what to explain besides comparing your talk and the similar one that I've heard from them. But they say that Git is the only one that properly, when you branch and join, unbranch and join, preserves each line with history. I mean, well, this is. Developers of different projects of different views are most important. So Git does multiple parents for revision as we do, but they don't have an ordering. So we consider that's why you have the indenting revisions. Yes. Yes. They don't have that. So that's the case where these think, well, Git is talking information. But if you're branching, branching, branching, you should be able to represent at least the same thing they do. I also think that Git usually encourages what they call, re-basing your patches to new history so that it only gets applied with the patches itself, not only history, I think. But this one is destroying history. It is used for beautifying the dependency of your revision graph. Yeah. So if you merge a lot from graphs three and constantly merge them, your revision history gets quite ugly with the graph. The history looks nice. How do you, in part of the power, how do you maintain many packages? Is there like a... I look up there, apparently like a PCR code that... Yeah. Does it look like a code package and whatever the package does? Yeah. Well, is it like a PCR code that you're not aware of? I don't know what it looks like. Yeah, there is a code there. I maintain the package. Excellent. What do you thought about that? Well, the current plug-in, the built-in plug-in is... A plug-in that facilitates building a package maintained in a branch. There are several methods of ways of managing devian packages in a branch. For example, some people prefer to only version the devian subdirectory and some people prefer to manage the complete source stream. These are our built-in supports, both. You have a conflict file stored in a branch where you specify some options. For example, where is the location of the orange tower and is this a branch where you merge? So, you have a devian directory and you want to merge the upstream tower on it or if you have the complete upstream source and this plug-in is very flexible in how you maintain your branch, your package and the branch. So, then you just have the entire data in the diff. No. Just you just... What is the source that you just keep it on your drive? Or in the start of the devian door? Does that exist? Yes. We support the sort of package made from this. A strange thing here happened a couple of years ago. Everybody started seeing that there had to be a distributed control system and then there are so many that they say, well, I think many of us haven't switched because there's no strong argument in favor of one and against the other. Yeah. They're functionally the same, but... Yeah, basically, if you want to use one, you pick one, the one you like and then you have to learn all the ones that you are used in projects you want to help with. Yeah. Well, just... Do you know any of it? Any of it? Yeah. Well, I guess. Yes, I do. What kind of access do you need? It doesn't say if you want to use this right to this course or this is what you didn't come up with. Well, you request any of it to open up. Well, it should say something there, right? I think it's probably... I thought you didn't, but this version only doesn't say anything either. I don't want to argue about it. It's just... Shut up and send the patches. It is just a read-me file that you could drop into the directory in that. Yeah. So, if you want to know where to send it, I would suggest the Alliot team. Yeah. Because it's an Alliot facility. Which it doesn't say anymore either. Correct. What does it say? The partner's host name? It's just not actually directly... Yes, but it should say host name or something like that. No, this host name is bizarre. Okay. That's not helpful to get. It would be nice if we could have some work from them to browse the branches and perhaps a log-in instance. I'll talk to Arif. Yes, because they have a very nice web frontend from Necura. And have it clearly linked from within each project. Because, well, at least with this version what happens is that from G-Port you have links to CVS. Yeah. But then you don't have CVS anywhere anymore. That's a G-Port problem. Yeah. And G-Port is so... Yeah. I personally find that using different version control systems isn't that hard if you know a couple, but then again I'm a version control hacker. So, perhaps that's the best... Yeah, experience to do that. Now, I do think we're stabilizing and converging. There are a lot. At this time you don't have any new projects starting to pop up. It's just the ones that exist. Some are dying off. So, if you can't choose because... Yeah. And each of them has 20 branches which are mutually incompatible. It depends on what you call life. We have more. I think those are the most important ones. People still use ARC, apparently. Well, you can push and pull from SVM and Nazar so that... Subversion is obviously in a lot of use, but it's not decentralized. Though they've been talking about being too... It's not SVK, but it's... No. ...Hack Engine. This is regarding SVK. They've been working on merge tracking and some offline support which is not going to be 1.5, but perhaps 1.6. So, the Subversion folks are spending effort in this direction. We'll go out and see what they come up with. Right now it's still centralized. I'm trying to get a... a sort of popcorn list of all the merchant corporate systems but I need something more on that. All right. So the first one is CVS, then Subversion, then Git Core, DAWRX, Mercurial, PLA, is that... I don't know. A solo score? Yeah. It's solo? A solo? VZR or Nazar? So the VZR is actually open? No. VZR is open. No, it's quite high. Take a look at the... It's sorted. One second. So the highest score is at the bottom. Ah. Is it? Yeah. The first number is the position and the second number is the number of installations. Okay. But they are in the same range. I mean, the distance between DAWRX and VZR is not... Yeah, CVS and Subversion are... Yeah, they're... ...and I don't mind... But between the four of them, they're quite close. Yeah. And this doesn't come for the people... For example, I don't think anybody installs DAWRX on source because you have to compile it, et cetera, but Mercurial and VZR are at the briefing in Python, so... Well, and specifically with VZR, we take one property, which I think is very important for... At least me and she can just run it from source. So you get it all, you run it. You don't have to install anything, just run it from the directory. And you can keep it up to date by just pulling, also, say, you just go VZR pull, you have to do what VZR did if you're willing to. Nobody, it's also a thing of cultural adaptation. I mean, when people start using one decentralized version of the system, they will end up installing the four of them. Because it's people that tend to participate in more projects, and people who already are used to this before, but I can say that it's extremely easy R and bizarre and bizarre and G, yes. It was the best one, though. I said it at the beginning of the talk. So the audience started with TLA, so we were in V, then before that we were in the shell. Yeah, right. And then improvements to it were wanted, so the bizarre project was created, which we didn't see, of course, but it did not work. And at the same time, I think more or less, the bizarre and G project was created. It was thought to be a prototype in Python. After a while, it was seen that keeping it in Python was viable, so it was decided that bizarre and G would substitute bizarre. So, more or less now, the new name of the bizarre and G is bizarre, and the old bizarre is called bizarre. So it's a bit of a mess. And it still makes the changes are so different. And bizarre is still being built now. The project is called bizarre, as in the six letters, and one line two is bizarre. In that way, we can't just change the bizarre package to be bizarre because people like, yeah, upgrade, they have a different position. So we need to take a little care there. I have a question about the deadline, about publishing and pushing. What transport methods are supported there besides SSH and HTTP for pulling only? SSH, there is, if you have a smart server over pushing over HTTP and web.tcp, if you're just going to custom a bizarre server? I think for what you need to plug in. Yes, well, the rest is in, R5 isn't in core either. R sync isn't in core? No, but it's in bizarre tools that most people have. And you can even use plain R-sync. You can also just get... You can carve a lot of your files in SCQ. Sure, man. Bizarre works over the dump transport, so any way you can get a bizarre branch somewhere else, if it's by CP or R-sync or mailing, will also work. Or NFS, we don't require a smart server. So it's more or less just copying files from one place to another? It's copying files from one place to another, and transport support that's in place ensures the ordering is also good, and if you have report stories that it doesn't... If you just R-sync across it may copy more information than needed, the basis is just copying files across. How does that compare to some of the other distributed systems? Are there other others that do that kind of a model? Uh... Mercuro comes close. They use a lot of hard links, locally. Well... So are you asking a question, or a literary reference to their stuff? I mean, VCR, if you copy the files over to another machine, you can use that as a report story. That's all you have to do. And that's one of the features I really like about it, and I'm wondering what other ones might have that feature. I think the R-sync does that. I'm not well versed in not being able to be sure to say, but I think it should be able to... Well, you can try. I think you can copy him. Yeah, check it out. But I mean, I'm talking about this room. You can do it first first. This? I don't have it installed. Oh, then... Just give me your... Well... Or show how easy it is to install it. Okay, any of them? Well, yeah, okay. Just use the kit. You want this or...? This is fine. Oh, a lot of packages. Well, it's only... No, no, no. That's all the packages. These are the ones that we will be able to install. Yes. It's simply delayed. Why are you being... Because I didn't change it. I'm afraid. That for you is ES, not SE. Well, I must confess to... This server is the one that gets the push first, I think. This? Yeah, TI is for PIS. I prefer that. Well, then... Possibly if you're using W install... So the whole interface acts like a plug-in, not as an independent primary. Yeah, correct. You also have standalone from that, Olive. Which is more like a... Yeah, it's there. Can you please again output PIS without buttons? There's no tricky play around. Where is your PIS without coming from? Oh, good question. Right. Right. Well, you can now click on the revolution we are looking for and press on... Don't click, yes? Oh, this is mine. It's also... It's... It's a different side icon. It has... One button diff. The diff is a bit kind. Do we draw a patch above? So the top one? Yes. At the bottom you see two parents. You can look at the diff to each parent separately. And then you can move separately. So especially if you are on a merge revision, it's sometimes useful to see the diff to the one or to the other branch. Yeah, only. That's about it. No, that's not about it. It's just a copy feature. Oh, that's not it. The only thing you committed there was... Yes, I write... Yeah, right. So every merge and every join just makes the change of colors. I mean, the color means it was merge and join or what is it? The colors basically mean different branches. You could... You look at the PZR Dev visualization. Okay, yeah, and the base one is... So in this case it's only just one branch, but the PZR Dev we sometimes have 18 outside branches and you get very wide tracks. Yes. If you want you could just quickly demo writing a blog. I leave that up to you. Do you want the cable? I don't want cable. Now this will work with you. We'll just take your handle. Okay. Yes, Spanish? I guess I can... The Spanish surely fucks up with the braces and the brackets. I can try it. Okay, I can try it. Oh, yeah. But you could... Well, what do you want me to do? We have a living documentation here. Right. I'd start with an isolation and do a... Right. Is it all right in here? Not at all. Just paint something. Or a little... Yeah. You want to register? Yes. And register is somewhere else, right? No, it's in PZR. PZR. If you like to do more interesting stuff. Yeah. Like PZR. So you just do PZR checkout some scan URL. You get a PZR checkout and if you put it in there, it goes to suppression. There's somewhere a good tutorial about the overview of the PZR API. PZR. The people new to it experience the conditions and stuff like that. Yeah. Not really. Well, I think it's improved, but I still don't like what the approach is. What I usually do is just start iPython and then interact with me. Inspect classes and stuff like that. There's documentation in Doc developers. I just used Yeah. On the site, we have Wikipedia. The world site is a Wikipedia. There was also generated documentation. The source is very well-developed. So if you just run IPPIDoc, it will extract all the Doc strings. IPPIDoc or PZR. No, NFIDoc. PIDoc will also work. Interesting. Try PZR. So, yeah, this is also branded to HTML like Doxygeon. So he wants the only coding Yeah, it's probably easy to get something that works, but more difficult to get something that is correct. Well, I know I hoped there was a relief to get something done which you wanted, but I'm sure it wasn't done in the most correct way. Wow. For cases like that, we have a workflow Yeah, right. I just did the main list and I reviewed them, so well, this was for a private time. I don't know if anybody is already in the line a while ago, but I just made the dash R option of Diff a single revision and I'll put the Diff like PZR. See for a change set. Yeah, right. I have a small question on my hand. I'm not sure how generous it managed to make this one. It doesn't look apparent, but it's not the first provision. Is that PZR-SVN? That's PZR-SVN. Yes, well, in working on that, you may do some interesting stuff. So that's a bug, it's broken, or is it intentionally and it's entirely possible. Okay. What we are to do if you're just modeling. Well, you can merge arbitrary revision graphs together if you want to. It's just one revision has a parent of a revision that's not connected to the rest of the graph. You can have multiple entry points to the graph. So I can merge independently developed projects. Yes, if you want. I think PZR-RDef has four or five but because, well, one of them is a bug in the test suite that broke, yeah. So we have a revision called A normally doesn't in common use but we act on the code base and sometimes do interesting things. Okay, and could you perhaps explain if two person decides, okay, let's join both trees. How to do that? Yes, how to do that? So let's PZR merge that's r0 dot dot minus one. What was that again? PZR dash dot merge? Zero dash dash, sorry. Zero dot dot minus one and then the branch you're merging. That should be merging unrelated branches with each other. I see, I remember something we made with this. For practical use they're unrelated but they share no revision that's where the zero comes from. So basically everything doesn't matter but normally you see it. That's interesting. And it will cause five conflicts if there are fights in the 7. So if you want to do that you will probably first move all the files in one of the branches to directly merge it or use nested tree support which is probably about to do. Okay, and for nested tree it works with default branch and storage layout introduced in L17 or do I have no? I need this special nested tree with subtree Yes, I'm still working on that support. Okay. But if you use your SCN it uses that for the or maybe. Right, and I made the mistake to convert our use it or branches to that repository in a repository with DSDate support and then I noticed that I can't push to Elio anymore. No, I had a shared repository of all of our plugins with DSDate support. Yeah, right. And then I cannot push back. The problem why you can't do that is because your storing information that cannot be represented by the work format. Right. But I'm not using that information. No. I see your point. So one option would be to just upgrade the repository in Elio. Yes, and that's done great. Which is not possible. It is. Okay. You can upgrade and run into that problem. A few times. I just ended up updating the other branch and I don't have to confirm that. All right. I don't know. I think you should be able to do just by branching. But it might be if you're running into it perhaps it's more general than default because it is a format that's not default so you have to specifically upgrade to it. Right. Even so, perhaps we should support something to get back from people who do that foolish thing. We already were telling you about this. You can Exactly. Pkj Pkj Bizarre is a shared repository. You can check out Bizarre as being into it because it uses the repository number three. How it done great. Oh, thank you, right. This should work. If that's not a repository or something. Yeah. So, I'd like to have breakfast. So, what I join you with having dinner. This is my first meal today. It's great.