[00:11] How do you ignore a file or directory? [00:12] bzr ignore 'mask' isn't making anything get ignored.. [00:19] NEVERMIND [00:19] IT WILL ONLY IGNORE THINGS WHICH ARE NOT VERSION CONTROLLED ALREADY.. [00:19] WOW, I WISH THAT WAS IN THE DOCS ( ! ) [00:40] me_too: What version are you using? [00:40] More recent versions give you a list of versioned files that an ignore rule would otherwise ignore. === mw is now known as mw|out === kiko-fud is now known as kiko-zzz [01:49] igc: could you review the reconcile fix for bug 155730? [01:49] Launchpad bug 155730 in bzr "reconcile doesn't adjust knit index references to otherwise-unreferenced file revisions" [Critical,Fix committed] https://launchpad.net/bugs/155730 [01:50] I can try :-) [01:50] spiv: ^^^ [01:50] igc: poolie said he might not get it done today, and it's blocking the rc... [01:50] igc: excellent :) [01:50] np [01:50] don't know much about how it works but there's no better time to learn [01:51] igc: it's a pretty tricky area of the code, so feel free to ask lots of questions, or even give me a call. [01:51] thanks [01:51] I tried to remedy some of the horrible lack of docstrings a little, but it's probably going to have a few head-scratching moments still... [02:13] odd_choke: Whatever the latest buntu version is [03:07] moin [03:08] beuno: ping [03:18] * igc food [03:54] any ReST experts here? [03:54] i'm writing up some docs in ReST, and i'm not sure how to link between them [03:56] keir: I'm not an expert but might be able to help ... [03:57] all i want to do is make a link that is valid after converting to html [03:57] I usually just reference the other as an external link ... [03:57] should i just use http syntax? [03:57] asmmunig it's been converted to html [03:57] i want to eventually use latex.. [03:58] also, why is ###### used in index.txt for the user guide? instead of ---- or ====? [03:58] try something like ./other.html [03:58] because the topics uses === and --- for their top 2 levels of heading so ... [03:58] the user guide needs to pick something else [03:59] the expectation is that the User Guide will include the others soon ... [03:59] ok [03:59] i hadn't seen the ### mentioned in the ReST docs [03:59] i.e. using .. include:: instead of just referencing external topics [04:00] what is .. later include:: xxxxx.txt? [04:00] There are a heap of chars you can use ... [04:00] on an aside: i really like ReST. [04:00] almost any from memory [04:00] how does it determine what the ordering is? by nesting? [04:00] yes [04:00] so you can start with ---- then ==== then #### if you want? [04:01] .. starts a comment [04:01] when a space comes right after the .. [04:01] i thought .. was a directive? [04:01] .. _Gmail: http://www.gmail.com [04:01] yep - the 'empty' directive is a comment :-) [04:02] what is .. later include::? [04:03] it's ..include with ' later ' added to turn it into a comment [04:03] aah [04:03] the intention is to remove the ' later ' bit once the text is ready [04:03] i'm confused then; because .. _Blah: my_link_here is not a cmoment [04:03] *comment [04:03] yet has a space after the .. [04:04] hmm [04:04] not sure - as I said, no expert [04:04] ok [04:04] thanks for the help [04:04] np [04:32] has smart-server support for packs been addressed yet? [04:34] nDuff: spiv can probably give you the best answer on that [04:49] hrm. is there a simple way to get "bzr info" output in a form intended for parsability? [04:50] * nDuff actually rather likes the --xml arguments to several of svn's commands -- easy to pipe output into xmlstarlet to run xpath queries or such. [04:51] nDuff: I don't think there is. Getting it human readable was a lot of work as it was! [04:52] abentley: heh, granted. that said -- bzrlib is great when I'm writing Python, but not so useful when trying to do integration with shell; parsing human-targeted output with sed (and hoping it doesn't change between versions) isn't my idea of fun. [04:52] * nDuff supposes he can write some python glue [04:53] I agree it would be nice. It's just not properly factored yet. [04:53] There's a bunch of code that's too tightly tied to console output. [04:54] ooo, heh. [04:54] * nDuff finds https://launchpad.net/bzr-xmloutput [04:56] * AfC waves to all the strange people who bring him such a wonderful version control tool [04:57] AfC: Say, is Richard Dice a colleague of yours? [04:57] abentley: indeed he is [04:58] I know him through musician friends. Say Hi from me. [04:59] abentley: We go way back. He's one of my best friends, and is also one of my business partners http://www.operationaldynamics.com/about/staff/ [05:00] Very cool. [05:01] I know he's been through some rough times lately. I hope things get better. [05:01] abentley: Turns out we did Shad Valley the same year (though not the same campus) and actually met in 1993 but started working together in late 1996 [05:01] So you don't know Sarah Ternoway, do you? [05:01] abentley: he's the one who introduced me to Linux. I'm the one who explained to him that the blinking cursor after the $ sign on the screen was a Unix shell [05:01] Sure I know Sarah [05:01] I'm in a band with her. [05:01] [been a long time, mind] [05:01] Awesome [05:02] Yeah, small world. [05:05] Richard is right up there as one of the smarter people I know, period. Open Source wise he's very engaged in the Perl world. He and I don't really intersect there but he _is_ the one that got me onto Perl 5 in the first place. [05:05] (of course, I always have to point out to him that I remember the day when Perl 1 came across comp.source.unix, and along with everyone else on the planet I went "what the hell is this") [05:06] Yes, I heard about his involvement. [05:06] It was a funny conversation -- I don't usually have people asking for more and more technical details of my job. [05:06] [incidentally, that might be an angle if we want to try and win a major community over to Bazaar usage] [05:06] He's also a champion scotch drinker. [05:07] Didn't see him when I was up in Toronto couple weeks back but he and Vera were at my wedding there in June. [05:08] We talked VCSes. He was on real Eclipse kick-- any VCS had to work with Eclipse as well as svn does. [05:08] abentley: I've run into that in my work. It's a genuine source of pushback [05:09] and frankly, a legitimate point [So much so that it took me from looking good to looking suspect for having suggested bzr in the first place] [05:09] Oh, I agree about Eclipse integration being worthwile. [05:09] because the CVS integration into Eclipse is *so good* that, in essence, you are not using CVS. You are using something which is damn close to a distributed (or at least disconnectable) VCS [05:10] The lack is mainly because Bazaar hackers tend to be happy with text editors. [05:10] *you and I* know about multiple branches and merging and cross platform cross architecture and command line usability and all that other tough stuff [05:11] but for anyone in a average [and nothing wrong with being average] corporate or workplace environment with perfectly competent {Java, whatever} programmer [05:11] I know work is progressing on Eclipse integration, but I'm sure it would be faster if we were all using Eclipse. [05:12] s the advantages of Bazaar (or the other two 3rd generation DRCS) are not as readily apparent [05:12] abentley: yeah [05:12] abentley: and since most of you are Python ninjas and terminal based text editor guys, that's not likely any time soon [05:14] I feel that it's important for people to scratch their own itches. If you try to scratch someone else's itch on a volunteer basis, you'll do it wrong or get bored before it's complete. [05:14] [more to the point, its mere existence (with due credit to those working hard on it) is insufficient - if it doesn't have the blazing usability and downright SMARTS that Bazaar (cmd line) itself has, then it's not advantageous to even show anyone or claim "it's being worked on"] [05:14] abentley: yes indeed [05:14] abentley: I wouldn't dream of arguing against that [05:14] [although, I might note that there is a middle ground of 3rd party ... climate: [05:14] I just wish we had a better answer to that. [05:15] if people are at least supportive, then things tend to work out [05:15] but when people pooh pooh something (rightly or wrongly) that tends to be more than enough to suppress any possible enthusiasm] [05:15] I suppose I am more aware of this than most, being the Java guy in the GNOME world [05:16] Yeah, I can see that would be an unpopular choice. [05:16] I must admit that over the last 4 years patient work on my part to at least be a good GNOME citizen combined with Sun finally having started the ball rolling towards freeing their Java implementation plus [05:17] the retarded amount of work I am putting into developing a new java-gnome has added up to the "at least grudging tolerance" level of support rather than constant derision, for example [05:17] which makes a big difference [05:17] One final interesting angle, though, is that my project is kinda in this netherworld - [05:18] Mind you I have no idea why people are doing Mono instead of Java. [05:18] If you want a Java-like language, why on earth would you want the one from Microsoft? [05:18] Inheriting from the almost 10 years of history in the project there is certainly an established ... way approaching API ... that is uniquely java-gnome and not 100% faithful to GTK; [05:19] how can i change the log message for a given revision? [05:19] but on the other hand, most of the "traditional" ways of doing things in Java are _utter crap_ [05:19] so it's not 100% Javaish either [05:19] AfC, i'm sure eclipse integration will come. bzr doesn't have the 7 years of maturing that svn does... given the same amount of time bzr will be compelling too :) [05:19] pattern, if it's the last rev you can uncommit [05:19] Hi keir. [05:19] abentley, hey [05:20] keir, uncommit won't touch the file in my WorkingTree, though, right? [05:20] abentley, i'm still interested in 'relaxing' with some css or inkscaping, but i gotta get cart working first :) did you try with 0.4.0? [05:20] No, I thought I'd make it a dependency on 0.3.11 instead. [05:20] abentley, ok, great. [05:21] keir: perhaps, but reality is that this project is in fierce competition with many others, and is trailing in the adoption curve. If Bazaars developers want more people to use it (and indeed to win vs others) then perhaps rather faster progress on Eclipse integration (among many things) will be necessary. [05:21] AfC, yes, i have noticed that. [05:21] keir: as Aaron points out, this is a tricky problem [05:21] pattern: Correct. It will leave you ready to repeat the commit. [05:21] AfC, i don't really understand why either. at least, compared to hg, we are easier to use (though slower on some counts). compared to git, we are certainly easier to use. [05:22] great [05:22] abentley: Re vs dot Net ... indeed. That's probably why I'm getting grudging support as opposed to derision. The whole mono thing is insane, and most people quietly get that. [05:22] now, how about if i want to change the log message in a revision that's not the latest revision? [05:22] AfC, though personally i *vastly* prefer gitweb to any of the bzr visualizers. the tabular log format is _way_ easier to scan than the multi-line-per-commit views. [05:23] keir: it's not about that. Sun chose hg for Open Solaris. No shit they then chose it for Open JDK. Suddenly that has infected almost the entire Free Java hackers world with using hg and being ok with it. [05:23] keir: Unfortunately, it seems 0.3.11 is not easy_instalable. [05:23] AfC, yeah. losing sun was really unfortunate. [05:23] AfC, i totally agree that we need to get some big adopters to get people onto bzr [05:23] keir: meanwhile Ketih chose Git for X, told Carl to use it for Cairo and now all the freedesktop hackers (making up a not insignificant chunk of GNOME ones) are thrilled with Git. [05:24] keir: which leaves people like me outlying loners for having chosen Bazaar. [05:24] AfC, yes. [05:24] Yeah [05:24] So like it or not, the momentum isn't what we want, [05:24] and much as we'd love to not have to worry about such politics and just concentrate on coding on things we love, [05:25] i know, it is important. [05:25] it nevertheless is concerning [05:25] #mercurial - 84 people. #bzr - 95 people. #git - 200 [05:25] You know, that's not bad as a rough sampling technique :) [05:26] AfC, i agree :) [05:26] what does KDE use? [05:26] pattern, they are switching to git [05:26] Subversion, I think [05:26] from svn [05:26] keir: really? Oh shit [05:26] AfC, yes. their repos are 20 gigs [05:26] how about gcc? [05:26] AfC, in git they dropped to about 1gig [05:26] gcc is also going git [05:26] You see, unlike GNOME, they are rather monolithic in their development practices; they do make central decisions and impose them [05:26] haha [05:27] Yeah, that was one of Keith's points against svn at the time - Mozilla went to 3 GB in Subversion and broke svn; in Git it was 600 MB or something [05:27] yes [05:28] Anyway, things we take for granted [05:28] unfortunately, to win over big players bzr needs to do size reductions like that too [05:28] like merges actually working, correct internals, testing, [05:28] i'm not sure how well packs are [05:28] usability, etc [05:28] are things we REALLY need to push [05:28] to make it clear why you _don't_ want to use Git, for example [05:28] AfC, exactly. that's why i chose bzr [05:28] AfC, however, you can't win by extoling how BAD the competition is, you have to win by being BETTER [05:29] * AfC makes his tiny contribution by things like http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html [05:29] and the rest of http://research.operationaldynamics.com/blogs/andrew/software/version-control/ [05:29] keir: dead wrong [05:29] keir: that's engineers pretending that they are objective talking. [05:29] keir: tools use is an emotional choice. Always has been [05:30] keir: and _especially_ when the prevailing sentiment is that [in this case, "the other two"] are ok [05:30] from a practical standpoint, they are. which makes getting people to switch hard. [05:30] then effort needs to be invested to pretty clearly point out what's wrong with the others (thence leading to the perfectly reasonable why Bazaar is an improvement) [05:31] yes. and this is not clear at all from the website [05:31] keir: **exactly** [05:31] and right now the launchpad integration is not well explained [05:31] or at least, it's not well sold [05:32] Unfortunately, I'm not really competent to contribute to writing more [for Bazaar's website, taking your example] about what the problem is or why bzr is better. I hang out with Robert Collins and Peter Miller enough to truly believe it is so, [05:32] and have heard many arguments on the topic over the last 24 months, [05:32] but I can't articulate about things like hash collisions or merge complexity from an expert standpoint [05:33] else I would contribute more that way. So I've tried to blog about it, instead. [05:33] And encourage clients to use it... although that's when I ran smack into "Eclipse integration not even alpha quality. Screw off" [05:34] AfC, your blog is nice. we need more 'customer stories' like yours on the bzr site. [05:35] Mostly I've taken the trouble to write stuff like that because I *am* on planet.gnome.org, and so that's my way of injecting into the debate there. [05:35] speaking of the website, there are pages worth of whitespace at the top of it when you view it in opera (at least on linux) [05:35] so at first it looks nearly empty (at least in the main frame) [05:35] pattern: ouch! [05:35] you have to scroll down a bunch of pages to see the content [05:36] one thing that sounds wacky, but is actually very compelling, is video tutorials. [05:36] pattern: Please do file a bug for that - that's the sort of thing that people Canonical employs for just that sort of marketing & publicity can fix [05:36] no joke, they make a big difference to some people. [05:36] keir: my keynote at foss.in this year will effectively be one [05:36] we need to get bzr talks youtube'd and posted [05:37] really good ones, should be prominently featured! [05:38] if you make a good video tutorial, it's also likely to get programming.reddit'd or somesuch [05:39] screenshot of main bazaar-vcs.org page in opera/linux - http://img187.imageshack.us/img187/2995/bazaarci6.jpg (shrunk down from 1600x1200 resolution down to 800x600) [05:39] pattern: you could always just reduce the browser window to 800x600ish and then take a screenshot [05:40] yeah, i guess that would work too :) [05:40] i'm just not used to resizing my browser windows, pretty much ever [05:43] pattern: sure. It's just a good trick when you're screenshooting [05:43] pattern: I did that just yesterday when taking a snap of Rhythmbox to show someone - reduced a 150kB PNG to 30 or so [05:46] i don't really care about how much disk space the image takes up [05:46] i just resized it for the convenience of people with lower resolutions [05:46] not everyone uses 1600x1200, alas [05:54] bug filed [05:59] hi all [06:01] New bug: #157330 in bzr "bazaar-vcs.org blank in Opera/Linux" [Undecided,New] https://launchpad.net/bugs/157330 [06:01] hi all [06:01] what is the difference between bzr-init and bzr init-repo [06:01] *bzr init [06:01] help: that's a wicked nickname [06:02] help: bzr init creates a new branch in the [specified] directory. [06:03] As it happens... [06:03] {sigh} [06:03] Let me guess. He's trying to use a registered nick [06:04] * ksp is help [06:05] in the specified direcotory means, no need for the directory to be a repository ? [06:05] for which repo it would be a branch ? [06:05] Let's see, where were we [06:05] Ah yes [06:06] As it happens, Bazaar needs somewhere to store revisions you create and/or pull from other branches of this project [06:07] and so it will quietly create a directory called repository in .bzr [06:07] igc: btw, I got a call from poolie, saying he'd read my reconcile patch and is ok with me landing it. [06:07] AfC, so for creating a project initially, we should use bzr init-repo ? is it ewual to svnadmin create repo in subversion [06:07] no no [06:07] spiv: good - just finished it myself [06:07] igc: he had some comments about clarity but he's happy for those to be dealt with after merging. [06:07] just bzr init and you're on your way [06:07] igc: ah, great. [06:07] igc: I'm very glad to have more eyeballs on this code :) [06:07] spiv: a question ... [06:07] igc: P.S. I wanted to mention one thing to you about your slides but didn't have time to write an email [06:07] igc: it can wait [06:08] all_versions() in the tests ... [06:08] why are things removed in your changes? [06:08] igc: oh, right. [06:08] AfC, just bzr init is enough to create the iniial repository ? [06:08] igc: I think I should probably rename all_versions :) [06:08] to? [06:08] ksp: now. You might begin to wonder if it is necessary for each and every branch clone you make of the same source project to have its own ./.bzr/repository full of revisions [06:09] ksp: and that is what bzr init-repo is for [06:09] igc: that's the list of file versions that will have their SHAs checked before and after reconcile. [06:09] You use it (typically) in .. [06:09] where it creates ../.bzr/repository that will hold the revisions for all the branches in . [06:09] igc: the idea being that reconcile shouldn't change the SHA (or contents) of a file version, just the metadata. [06:10] spiv: ok - I'll write up a quick email mentioning the one small tweak I want [06:10] In the case of the project I work on, I tend to group a bunch of branches under a given directory [06:10] igc: but now reconcile removes some file versions if they are unreferenced, so just simply listing all the versions that were there initially isn't appropriate, because we don't care that their contents are preserved (they're not; the whole version is gone) [06:10] eg, [06:10] in src/andrew/ [06:10] I created src/andrew/java-gnome/ [06:10] AfC, so initially i will use bzr init-repo which will create the main project repository and cd /to/the/repo-directory, i can create sub folders using bzr init or jsut bzr add ? [06:11] to hold src/andrew/java-gnome/mainline/, src/andrew/java-gnome/treeview/, src/andrew/java-gnome/website/ etc [06:11] where {mainline,treeview,website,...} are branches [06:11] igc: so I guess something like 'versions_to_verify_shas_of', although that's a pretty awkward name, would be better than 'all_versions' [06:11] ksp: init [06:11] yes [06:11] ksp: the idea of repo is just a storage optimization. [06:11] hrm -- I can't export from a packs repository over http [06:12] ksp: you don't _need_ it like you do with Subversion [06:12] spiv: yes [06:12] ksp: and yes, I initially did bzr init-repo in src/andrew/java-gnome/ before creating the first 'mainline' branch there subsequently [06:12] http://pastebin.ca/750051 [06:12] That's it, really [06:13] ksp: If you hadn't asked I'm sure we would have just told you to `bzr init` and carry on. [06:13] AfC, if i am going to use bzr init under directory created using init-repo then there will again exist number of .bzr directories under each , right? and that will too complicated tree [06:14] You can always create a "repository" in a new directory tree later and move (using `bzr clone`) the branches there later [06:14] ksp: correct [06:14] ksp: what you will see is top/.bzr/repository/ [06:14] ok fine, so i will conclude like this................ bzr init-repo java-gnome, cd java-gnome, bzr add mainline [06:14] ksp: and top/mainline/.bzr/branch/ [06:15] ksp: and top/experimental/.bzr/branch/ [06:15] is this we can do have a simple repo ? [06:15] ksp: and top/bugfix-the-wacky-code/.bzr/branch/ [06:15] AfC, yes exectly [06:15] AfC, so is it needed to have so many .bzr folders? [06:15] but you WON'T see .bzr directories further down. There's just one per branch [06:15] If you HADN'T made top as a "repository" with bzr init-repo, [06:16] then what you would see would be [06:16] ksp: top/mainline/.bzr/branch/ AND [06:16] ksp: top/mainline/.bzr/repository/ [06:16] that's it [06:16] (oh, and nothing in top/) [06:16] ksp: get it? [06:16] ksp, wait, are you talking about doing "add" commands directly within your repository, rather than in a working tree? [06:17] * nDuff doesn't know that that's valid. [06:17] i'll be back in momment [06:18] * AfC notes to the wizards in channel that this continues to be a source of confusion to new users. We almost need to make this go away. That was one thing Darcs (and Git, maybe?) did nicely - they just hardlinked the files between branches thus no repository-quietly-pushed-up-to-parent concept [06:18] s/files/revisions/ [06:19] ksp: if you do "bzr init-repo ~/java-gnome.repo", then you can inside your mainline source tree do "bzr init", check in whatever code, then "bzr push ~/java-gnome.repo/mainline" to create and populate your mainline branch from the tree you're currently in, for instance; that's the approach I most commonly take when using repositories. Not that there aren't other ways of getting going. [06:19] ksp: Just do mkdir whatever ; cd whatever ; bzr init . and then carry on with bzr add ; bzr commit [06:20] ksp: that'll get you started. You can always do what nDuff or I have been suggesting later [06:20] nDuff: (that's interesting, and more traditional. I sorta got focused on working-on-the-peer-branches-I'm) === cprov-afk is now known as cprov-zz [06:21] nDuff, this is where i am getting the doubt. as u said, we will create the repo using "bzr init-repo ~/java-gnome.repo" later, we can jsut do mkdir, add codes and other suffs using bzr add , then bzr commit. why do i need to use bzr init again / [06:22] init-repo and init are different [06:22] ksp, you want to do the init before you can add [06:22] spiv: review sent to the list now with minor tweaks requested [06:22] igc: thanks! [06:22] ksp, but init-repo is to make a shared space to store multiple branches efficiently [06:23] ksp, if you don't have multiple branches, you don't need a shared repository yet, so don't need to do anything with init-repo. [06:23] ksp: yeah - just insert "bzr init" between "mkdir" and "add codes and others suffs" [06:23] and you're all set [06:23] * AfC doubts ksp is working on java-gnome :) [06:24] nDuff, yes, now i tried live, by using bzr init-repo and then bzr add , which threw an error saying, NOWorkingTree exists [06:24] so i used bzr init and then added using bzr add, it worked [06:24] so repo will hold number of branches under which we can add stufss [06:24] ksp, yes; init-repo makes a shared repository *without* a working tree; you don't add in it. [06:24] AfC, nDuff now its clear for me [06:25] and now when other users want to get the data, they use bzr branch url and checkout the source [06:25] modify it and upload using bzr push. right ? [06:26] ksp: right, you always need a branch (which is what 'bzr init' creates). A separate repository to optimise storage of branches (what 'bzr init-repo' creates) is completely optional. [06:26] ksp: ehh. if you want a traditional workflow (where everything goes into the shared repository as soon as it's committed), you should have your users use checkout and commit rather than messing with pull and push. [06:27] ksp: yes, that's a reasonable workflow. nDuff's suggestion (users use 'bzr checkout' rather than 'bzr branch') is fine as well. [06:27] ksp: if you want a distributed workflow, then what you described is roughly correct -- folks can make multiple commits on their local tree between when they pull and when they push. [06:28] hold on, again, what is difference between, bzr branch and bzr checkout ? [06:28] * nDuff looks at push's help and sees that --overwrite is so named... good; was concerned it might be named --force, which would be a little bit less clear about the need to merge up before pushing. [06:29] ksp: if someone does a branch, they can commit locally without those changes going back to the tree they pulled from; if you checkout, as soon as you commit it goes back to the place you did a checkout from. [06:29] so, branch allwos, commit offline and checkout allows commint online [06:29] ksp: pretty much. you can change your tree between the two types using "bind" and "unbind". [06:30] ok [06:31] and if i come to uor first procedure, forgtting about bzr init-repo, if i use bzr init for creating the initial java-gnome and then add the other stuff using bzr add, still it acts as the aboe discussed repository ? [06:32] or anything is there which varies ? nDuff [06:32] no, nothing that varies. [06:33] is it possible to have a nested branches ? [06:33] in a repository, sure. [06:33] like bzr init abc; cd abc; bzr init xyz ? [06:34] no idea. [06:35] ok, how can i allow authentication of users in bzr [06:35] like svn apache conf has, SVNAuthZFile [06:36] ksp: you can nest branches like that; the abc branch will just ignore the xyz branch inside it. [06:36] spiv, ignore ? [06:36] ksp: so e.g. a commit in abc will not have any effect on xyz, or vice versa. [06:37] spiv, oh, so if u commit in abc thenonly the modifications done in abc branch are applied to the repo, and isgnores the modifications done in xyz [06:37] Right. It's basically the same as if the branches weren't nested. [06:38] (There's some experimental code to do more advanced stuff with nested branches, but it's not ready for general consumption) [06:38] spiv, what about authenticating the commits [06:38] bzr has no authentication builtin at the moment. [06:38] Mostly people rely on something like SSH. [06:38] spiv, then how can we keep track of who is pushing which code ? [06:39] bzr+ssh ? [06:39] bzr stores a committer ID on each revision (see also the "bzr whoami" command). [06:39] And you can also configure bzr to GPG sign your revisions. [06:39] yeah, i remember now [06:39] Yes bzr+ssh, or even just sftp. [06:39] And leave the access control to your operating system/filesystem permissions. [06:40] spiv, fine. got the concept [06:40] spiv, one more silly question [06:40] ksp: I haven't seen a single silly question from you yet :) [06:41] spiv, i am used to subversion for more than a year and now planning to shift to bzr [06:42] and onw most advantage i read in bzr tutotial is that, we can do bzr commit when we are offiline [06:42] ksp: that is correct [06:42] that is it allows us to work offline also without connecting to the main repo [06:42] ksp: that is also correct [06:42] but how is it advantage [06:43] ksp: so, for get about "repositories" for a sec [06:43] bah [06:43] ksp: are you a commercial or open source user? [06:43] ksp: so, forget about "repositories" for a second [06:43] ksp, open source [06:43] ksp: and just think about branches; [06:43] ok [06:43] ksp: each branch contains full history and is _entirely_ independent and self-sufficient [06:43] ksp: then think of it this way: people can make their own branches without you giving them commit privileges for your repository. it makes the barrier to entry for new contributors much lower. [06:43] and is a peer of all the other branches in the project. [06:44] you move changes between them by "merging". [06:44] ksp: they can keep their branch on their own server, and then you can merge from it if and when you like. [06:44] but because you have a fully power branch, you can do anything you like to it (like committing, like viewing history, etc) [06:44] ksp: roger so far? [06:45] * ksp is trying to understand he above [06:45] There are two techniques which ... enhance ... matters, but the basic essence of fully distributed version control is the above [06:46] ksp: so that way, even people you don't trust with direct commit privileges get the benefit of having revision control tools. for a open source project, that's a big win. [06:46] ksp: so you get that a branch is self-contained and everything you ever needed and its own little island? [06:47] AfC, yes [06:47] nDuff: [I really do believe that starting with centralized version control and trying to explain distributed is suboptimal; better to start the other way round and then connect back, as I am about to do] [06:47] Right [06:48] ksp: so the two ... enhancements ... I mentioned are as follows: [06:48] ksp: If I'm on a train, with no net access, and I have a bzr branch on my laptop, I can still do everything I want to with it: I can make commits, I can make new branches from that branch, I can merge other branches into it, I can examine the history (log, annotate, etc) of that branch. [06:48] ksp: the first is a storage optimization. Obviously since every branch is it's own island and has everything, it might get to be a little large (on disk), right? [06:49] [or rather, lots of branches each with everything might get to be a little large on disk] [06:50] ksp: that's where Bazaar's idea of a (local, ie at .. or somewhere near ~) "repository" comes in. It doesn't change the fact that each branch has everything it needs [06:50] ksp: I don't need any access at all to a central blessed "repository" for any of that (and I don't need to be an official committer. I can just work on the code, and I can publish my work when I get online just by pushing my branch somewhere. [06:50] it just means that the various branches stored under that repository can share all the revision data (history, etc) so there's one copy rather than n copies of all that data. [06:51] * AfC notes that spiv is explaining this remarkable well :) [06:51] AfC: I suspect we've both had a bit of practice :) [06:52] ksp: so you got the Bazaar idea of full power "branch", now hopefully you see where (local) "repository" fits in. [06:52] ksp: Good so far? [06:53] AfC, spiv so far I understood well [06:53] Now onto the the second ... enhancement ... one that I actually regard somewhat askance. [06:53] here my query comes up [06:53] wait [06:54] AfC, ya, please go ahead with sec enhancement [06:55] Some people like to create a setup where they are _not_ allowed to commit to their branch unless they also simultaneously commit to some central (typically remotely hosted) branch [06:55] [the word repository is often misused here, but branch is correct] [06:55] this is known as a "bound" branch in Bazaar terms [06:55] and typically is created by using the [06:55] bzr checkout [06:55] command instead of the [06:55]