| me_too | How do you ignore a file or directory? | 00:11 |
|---|---|---|
| me_too | bzr ignore 'mask' isn't making anything get ignored.. | 00:12 |
| me_too | NEVERMIND | 00:19 |
| me_too | IT WILL ONLY IGNORE THINGS WHICH ARE NOT VERSION CONTROLLED ALREADY.. | 00:19 |
| me_too | WOW, I WISH THAT WAS IN THE DOCS ( ! ) | 00:19 |
| Odd_Bloke | me_too: What version are you using? | 00:40 |
| Odd_Bloke | More recent versions give you a list of versioned files that an ignore rule would otherwise ignore. | 00:40 |
| === mw is now known as mw|out | ||
| === kiko-fud is now known as kiko-zzz | ||
| spiv | igc: could you review the reconcile fix for bug 155730? | 01:49 |
| ubotu | 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:49 |
| igc | I can try :-) | 01:50 |
| igc | spiv: ^^^ | 01:50 |
| spiv | igc: poolie said he might not get it done today, and it's blocking the rc... | 01:50 |
| spiv | igc: excellent :) | 01:50 |
| igc | np | 01:50 |
| igc | don't know much about how it works but there's no better time to learn | 01:50 |
| spiv | 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 |
| igc | thanks | 01:51 |
| spiv | 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... | 01:51 |
| me_too | odd_choke: Whatever the latest buntu version is | 02:13 |
| Verterok | moin | 03:07 |
| Verterok | beuno: ping | 03:08 |
| * igc food | 03:18 | |
| keir | any ReST experts here? | 03:54 |
| keir | i'm writing up some docs in ReST, and i'm not sure how to link between them | 03:54 |
| igc | keir: I'm not an expert but might be able to help ... | 03:56 |
| keir | all i want to do is make a link that is valid after converting to html | 03:57 |
| igc | I usually just reference the other as an external link ... | 03:57 |
| keir | should i just use http syntax? | 03:57 |
| igc | asmmunig it's been converted to html | 03:57 |
| keir | i want to eventually use latex.. | 03:57 |
| keir | also, why is ###### used in index.txt for the user guide? instead of ---- or ====? | 03:58 |
| igc | try something like ./other.html | 03:58 |
| igc | because the topics uses === and --- for their top 2 levels of heading so ... | 03:58 |
| igc | the user guide needs to pick something else | 03:58 |
| igc | the expectation is that the User Guide will include the others soon ... | 03:59 |
| keir | ok | 03:59 |
| keir | i hadn't seen the ### mentioned in the ReST docs | 03:59 |
| igc | i.e. using .. include:: instead of just referencing external topics | 03:59 |
| keir | what is .. later include:: xxxxx.txt? | 04:00 |
| igc | There are a heap of chars you can use ... | 04:00 |
| keir | on an aside: i really like ReST. | 04:00 |
| igc | almost any from memory | 04:00 |
| keir | how does it determine what the ordering is? by nesting? | 04:00 |
| igc | yes | 04:00 |
| keir | so you can start with ---- then ==== then #### if you want? | 04:00 |
| igc | .. starts a comment | 04:01 |
| igc | when a space comes right after the .. | 04:01 |
| keir | i thought .. was a directive? | 04:01 |
| keir | .. _Gmail: http://www.gmail.com | 04:01 |
| igc | yep - the 'empty' directive is a comment :-) | 04:01 |
| keir | what is .. later include::? | 04:02 |
| igc | it's ..include with ' later ' added to turn it into a comment | 04:03 |
| keir | aah | 04:03 |
| igc | the intention is to remove the ' later ' bit once the text is ready | 04:03 |
| keir | i'm confused then; because .. _Blah: my_link_here is not a cmoment | 04:03 |
| keir | *comment | 04:03 |
| keir | yet has a space after the .. | 04:03 |
| igc | hmm | 04:04 |
| igc | not sure - as I said, no expert | 04:04 |
| keir | ok | 04:04 |
| keir | thanks for the help | 04:04 |
| igc | np | 04:04 |
| nDuff | has smart-server support for packs been addressed yet? | 04:32 |
| igc | nDuff: spiv can probably give you the best answer on that | 04:34 |
| nDuff | hrm. is there a simple way to get "bzr info" output in a form intended for parsability? | 04:49 |
| * 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:50 | |
| abentley | nDuff: I don't think there is. Getting it human readable was a lot of work as it was! | 04:51 |
| nDuff | 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:52 | |
| abentley | I agree it would be nice. It's just not properly factored yet. | 04:53 |
| abentley | There's a bunch of code that's too tightly tied to console output. | 04:53 |
| nDuff | ooo, heh. | 04:54 |
| * nDuff finds https://launchpad.net/bzr-xmloutput | 04:54 | |
| * AfC waves to all the strange people who bring him such a wonderful version control tool | 04:56 | |
| abentley | AfC: Say, is Richard Dice a colleague of yours? | 04:57 |
| AfC | abentley: indeed he is | 04:57 |
| abentley | I know him through musician friends. Say Hi from me. | 04:58 |
| AfC | 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/ | 04:59 |
| abentley | Very cool. | 05:00 |
| abentley | I know he's been through some rough times lately. I hope things get better. | 05:01 |
| AfC | 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 |
| abentley | So you don't know Sarah Ternoway, do you? | 05:01 |
| AfC | 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 |
| AfC | Sure I know Sarah | 05:01 |
| abentley | I'm in a band with her. | 05:01 |
| AfC | [been a long time, mind] | 05:01 |
| AfC | Awesome | 05:01 |
| abentley | Yeah, small world. | 05:02 |
| AfC | 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 |
| AfC | (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:05 |
| abentley | Yes, I heard about his involvement. | 05:06 |
| abentley | It was a funny conversation -- I don't usually have people asking for more and more technical details of my job. | 05:06 |
| AfC | [incidentally, that might be an angle if we want to try and win a major community over to Bazaar usage] | 05:06 |
| AfC | He's also a champion scotch drinker. | 05:06 |
| AfC | 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:07 |
| abentley | We talked VCSes. He was on real Eclipse kick-- any VCS had to work with Eclipse as well as svn does. | 05:08 |
| AfC | abentley: I've run into that in my work. It's a genuine source of pushback | 05:08 |
| AfC | 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 |
| abentley | Oh, I agree about Eclipse integration being worthwile. | 05:09 |
| AfC | 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:09 |
| abentley | The lack is mainly because Bazaar hackers tend to be happy with text editors. | 05:10 |
| AfC | *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:10 |
| AfC | but for anyone in a average [and nothing wrong with being average] corporate or workplace environment with perfectly competent {Java, whatever} programmer | 05:11 |
| abentley | I know work is progressing on Eclipse integration, but I'm sure it would be faster if we were all using Eclipse. | 05:11 |
| AfC | s the advantages of Bazaar (or the other two 3rd generation DRCS) are not as readily apparent | 05:12 |
| AfC | abentley: yeah | 05:12 |
| AfC | abentley: and since most of you are Python ninjas and terminal based text editor guys, that's not likely any time soon | 05:12 |
| abentley | 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 |
| AfC | [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 |
| AfC | abentley: yes indeed | 05:14 |
| AfC | abentley: I wouldn't dream of arguing against that | 05:14 |
| AfC | [although, I might note that there is a middle ground of 3rd party ... climate: | 05:14 |
| abentley | I just wish we had a better answer to that. | 05:14 |
| AfC | if people are at least supportive, then things tend to work out | 05:15 |
| AfC | but when people pooh pooh something (rightly or wrongly) that tends to be more than enough to suppress any possible enthusiasm] | 05:15 |
| AfC | I suppose I am more aware of this than most, being the Java guy in the GNOME world | 05:15 |
| abentley | Yeah, I can see that would be an unpopular choice. | 05:16 |
| AfC | 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:16 |
| AfC | 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 |
| AfC | which makes a big difference | 05:17 |
| AfC | One final interesting angle, though, is that my project is kinda in this netherworld - | 05:17 |
| abentley | Mind you I have no idea why people are doing Mono instead of Java. | 05:18 |
| abentley | If you want a Java-like language, why on earth would you want the one from Microsoft? | 05:18 |
| AfC | 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:18 |
| pattern | how can i change the log message for a given revision? | 05:19 |
| AfC | but on the other hand, most of the "traditional" ways of doing things in Java are _utter crap_ | 05:19 |
| AfC | so it's not 100% Javaish either | 05:19 |
| keir | 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 |
| keir | pattern, if it's the last rev you can uncommit | 05:19 |
| abentley | Hi keir. | 05:19 |
| keir | abentley, hey | 05:19 |
| pattern | keir, uncommit won't touch the file in my WorkingTree, though, right? | 05:20 |
| keir | 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 |
| abentley | No, I thought I'd make it a dependency on 0.3.11 instead. | 05:20 |
| keir | abentley, ok, great. | 05:20 |
| AfC | 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 |
| keir | AfC, yes, i have noticed that. | 05:21 |
| AfC | keir: as Aaron points out, this is a tricky problem | 05:21 |
| abentley | pattern: Correct. It will leave you ready to repeat the commit. | 05:21 |
| keir | 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:21 |
| pattern | great | 05:22 |
| AfC | 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 |
| pattern | now, how about if i want to change the log message in a revision that's not the latest revision? | 05:22 |
| keir | 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:22 |
| AfC | 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 |
| abentley | keir: Unfortunately, it seems 0.3.11 is not easy_instalable. | 05:23 |
| keir | AfC, yeah. losing sun was really unfortunate. | 05:23 |
| keir | AfC, i totally agree that we need to get some big adopters to get people onto bzr | 05:23 |
| AfC | 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:23 |
| AfC | keir: which leaves people like me outlying loners for having chosen Bazaar. | 05:24 |
| keir | AfC, yes. | 05:24 |
| AfC | Yeah | 05:24 |
| AfC | So like it or not, the momentum isn't what we want, | 05:24 |
| AfC | and much as we'd love to not have to worry about such politics and just concentrate on coding on things we love, | 05:24 |
| keir | i know, it is important. | 05:25 |
| AfC | it nevertheless is concerning | 05:25 |
| keir | #mercurial - 84 people. #bzr - 95 people. #git - 200 | 05:25 |
| AfC | You know, that's not bad as a rough sampling technique :) | 05:25 |
| keir | AfC, i agree :) | 05:26 |
| pattern | what does KDE use? | 05:26 |
| keir | pattern, they are switching to git | 05:26 |
| AfC | Subversion, I think | 05:26 |
| keir | from svn | 05:26 |
| AfC | keir: really? Oh shit | 05:26 |
| keir | AfC, yes. their repos are 20 gigs | 05:26 |
| pattern | how about gcc? | 05:26 |
| keir | AfC, in git they dropped to about 1gig | 05:26 |
| keir | gcc is also going git | 05:26 |
| AfC | You see, unlike GNOME, they are rather monolithic in their development practices; they do make central decisions and impose them | 05:26 |
| AfC | haha | 05:26 |
| AfC | 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 |
| keir | yes | 05:27 |
| AfC | Anyway, things we take for granted | 05:28 |
| keir | unfortunately, to win over big players bzr needs to do size reductions like that too | 05:28 |
| AfC | like merges actually working, correct internals, testing, | 05:28 |
| keir | i'm not sure how well packs are | 05:28 |
| AfC | usability, etc | 05:28 |
| AfC | are things we REALLY need to push | 05:28 |
| AfC | to make it clear why you _don't_ want to use Git, for example | 05:28 |
| keir | AfC, exactly. that's why i chose bzr | 05:28 |
| keir | AfC, however, you can't win by extoling how BAD the competition is, you have to win by being BETTER | 05:28 |
| * AfC makes his tiny contribution by things like http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html | 05:29 | |
| AfC | and the rest of http://research.operationaldynamics.com/blogs/andrew/software/version-control/ | 05:29 |
| AfC | keir: dead wrong | 05:29 |
| AfC | keir: that's engineers pretending that they are objective talking. | 05:29 |
| AfC | keir: tools use is an emotional choice. Always has been | 05:29 |
| AfC | keir: and _especially_ when the prevailing sentiment is that [in this case, "the other two"] are ok | 05:30 |
| keir | from a practical standpoint, they are. which makes getting people to switch hard. | 05:30 |
| AfC | 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:30 |
| keir | yes. and this is not clear at all from the website | 05:31 |
| AfC | keir: **exactly** | 05:31 |
| keir | and right now the launchpad integration is not well explained | 05:31 |
| keir | or at least, it's not well sold | 05:31 |
| AfC | 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 |
| AfC | and have heard many arguments on the topic over the last 24 months, | 05:32 |
| AfC | but I can't articulate about things like hash collisions or merge complexity from an expert standpoint | 05:32 |
| AfC | else I would contribute more that way. So I've tried to blog about it, instead. | 05:33 |
| AfC | And encourage clients to use it... although that's when I ran smack into "Eclipse integration not even alpha quality. Screw off" | 05:33 |
| keir | AfC, your blog is nice. we need more 'customer stories' like yours on the bzr site. | 05:34 |
| AfC | 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 |
| pattern | 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 |
| pattern | so at first it looks nearly empty (at least in the main frame) | 05:35 |
| AfC | pattern: ouch! | 05:35 |
| pattern | you have to scroll down a bunch of pages to see the content | 05:35 |
| keir | one thing that sounds wacky, but is actually very compelling, is video tutorials. | 05:36 |
| AfC | 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 |
| keir | no joke, they make a big difference to some people. | 05:36 |
| AfC | keir: my keynote at foss.in this year will effectively be one | 05:36 |
| keir | we need to get bzr talks youtube'd and posted | 05:36 |
| keir | really good ones, should be prominently featured! | 05:37 |
| keir | if you make a good video tutorial, it's also likely to get programming.reddit'd or somesuch | 05:38 |
| pattern | 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 |
| AfC | pattern: you could always just reduce the browser window to 800x600ish and then take a screenshot | 05:39 |
| pattern | yeah, i guess that would work too :) | 05:40 |
| pattern | i'm just not used to resizing my browser windows, pretty much ever | 05:40 |
| AfC | pattern: sure. It's just a good trick when you're screenshooting | 05:43 |
| AfC | pattern: I did that just yesterday when taking a snap of Rhythmbox to show someone - reduced a 150kB PNG to 30 or so | 05:43 |
| pattern | i don't really care about how much disk space the image takes up | 05:46 |
| pattern | i just resized it for the convenience of people with lower resolutions | 05:46 |
| pattern | not everyone uses 1600x1200, alas | 05:46 |
| pattern | bug filed | 05:54 |
| help | hi all | 05:59 |
| ubotu | New bug: #157330 in bzr "bazaar-vcs.org blank in Opera/Linux" [Undecided,New] https://launchpad.net/bugs/157330 | 06:01 |
| help | hi all | 06:01 |
| help | what is the difference between bzr-init and bzr init-repo | 06:01 |
| help | *bzr init | 06:01 |
| AfC | help: that's a wicked nickname | 06:01 |
| AfC | help: bzr init creates a new branch in the [specified] directory. | 06:02 |
| AfC | As it happens... | 06:03 |
| AfC | {sigh} | 06:03 |
| AfC | Let me guess. He's trying to use a registered nick | 06:03 |
| * ksp is help | 06:04 | |
| ksp | in the specified direcotory means, no need for the directory to be a repository ? | 06:05 |
| ksp | for which repo it would be a branch ? | 06:05 |
| AfC | Let's see, where were we | 06:05 |
| AfC | Ah yes | 06:05 |
| AfC | As it happens, Bazaar needs somewhere to store revisions you create and/or pull from other branches of this project | 06:06 |
| AfC | and so it will quietly create a directory called repository in .bzr | 06:07 |
| spiv | igc: btw, I got a call from poolie, saying he'd read my reconcile patch and is ok with me landing it. | 06:07 |
| ksp | AfC, so for creating a project initially, we should use bzr init-repo ? is it ewual to svnadmin create repo in subversion | 06:07 |
| AfC | no no | 06:07 |
| igc | spiv: good - just finished it myself | 06:07 |
| spiv | igc: he had some comments about clarity but he's happy for those to be dealt with after merging. | 06:07 |
| AfC | just bzr init and you're on your way | 06:07 |
| spiv | igc: ah, great. | 06:07 |
| spiv | igc: I'm very glad to have more eyeballs on this code :) | 06:07 |
| igc | spiv: a question ... | 06:07 |
| AfC | 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 |
| AfC | igc: it can wait | 06:07 |
| igc | all_versions() in the tests ... | 06:08 |
| igc | why are things removed in your changes? | 06:08 |
| spiv | igc: oh, right. | 06:08 |
| ksp | AfC, just bzr init is enough to create the iniial repository ? | 06:08 |
| spiv | igc: I think I should probably rename all_versions :) | 06:08 |
| igc | to? | 06:08 |
| AfC | 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:08 |
| AfC | ksp: and that is what bzr init-repo is for | 06:09 |
| spiv | igc: that's the list of file versions that will have their SHAs checked before and after reconcile. | 06:09 |
| AfC | You use it (typically) in .. | 06:09 |
| AfC | where it creates ../.bzr/repository that will hold the revisions for all the branches in . | 06:09 |
| spiv | igc: the idea being that reconcile shouldn't change the SHA (or contents) of a file version, just the metadata. | 06:09 |
| igc | spiv: ok - I'll write up a quick email mentioning the one small tweak I want | 06:10 |
| AfC | In the case of the project I work on, I tend to group a bunch of branches under a given directory | 06:10 |
| spiv | 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 |
| AfC | eg, | 06:10 |
| AfC | in src/andrew/ | 06:10 |
| AfC | I created src/andrew/java-gnome/ | 06:10 |
| ksp | 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:10 |
| AfC | to hold src/andrew/java-gnome/mainline/, src/andrew/java-gnome/treeview/, src/andrew/java-gnome/website/ etc | 06:11 |
| AfC | where {mainline,treeview,website,...} are branches | 06:11 |
| spiv | 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 |
| AfC | ksp: init | 06:11 |
| AfC | yes | 06:11 |
| AfC | ksp: the idea of repo is just a storage optimization. | 06:11 |
| nDuff | hrm -- I can't export from a packs repository over http | 06:11 |
| AfC | ksp: you don't _need_ it like you do with Subversion | 06:12 |
| igc | spiv: yes | 06:12 |
| AfC | ksp: and yes, I initially did bzr init-repo in src/andrew/java-gnome/ before creating the first 'mainline' branch there subsequently | 06:12 |
| nDuff | http://pastebin.ca/750051 | 06:12 |
| AfC | That's it, really | 06:12 |
| AfC | ksp: If you hadn't asked I'm sure we would have just told you to `bzr init` and carry on. | 06:13 |
| ksp | 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:13 |
| AfC | You can always create a "repository" in a new directory tree later and move (using `bzr clone`) the branches there later | 06:14 |
| AfC | ksp: correct | 06:14 |
| AfC | ksp: what you will see is top/.bzr/repository/ | 06:14 |
| ksp | ok fine, so i will conclude like this................ bzr init-repo java-gnome, cd java-gnome, bzr add mainline | 06:14 |
| AfC | ksp: and top/mainline/.bzr/branch/ | 06:14 |
| AfC | ksp: and top/experimental/.bzr/branch/ | 06:15 |
| ksp | is this we can do have a simple repo ? | 06:15 |
| AfC | ksp: and top/bugfix-the-wacky-code/.bzr/branch/ | 06:15 |
| ksp | AfC, yes exectly | 06:15 |
| ksp | AfC, so is it needed to have so many .bzr folders? | 06:15 |
| AfC | but you WON'T see .bzr directories further down. There's just one per branch | 06:15 |
| AfC | If you HADN'T made top as a "repository" with bzr init-repo, | 06:15 |
| AfC | then what you would see would be | 06:16 |
| AfC | ksp: top/mainline/.bzr/branch/ AND | 06:16 |
| AfC | ksp: top/mainline/.bzr/repository/ | 06:16 |
| AfC | that's it | 06:16 |
| AfC | (oh, and nothing in top/) | 06:16 |
| AfC | ksp: get it? | 06:16 |
| nDuff | ksp, wait, are you talking about doing "add" commands directly within your repository, rather than in a working tree? | 06:16 |
| * nDuff doesn't know that that's valid. | 06:17 | |
| ksp | i'll be back in momment | 06:17 |
| * 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 | |
| AfC | s/files/revisions/ | 06:18 |
| nDuff | 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 |
| AfC | ksp: Just do mkdir whatever ; cd whatever ; bzr init . and then carry on with bzr add ; bzr commit | 06:19 |
| AfC | ksp: that'll get you started. You can always do what nDuff or I have been suggesting later | 06:20 |
| AfC | nDuff: (that's interesting, and more traditional. I sorta got focused on working-on-the-peer-branches-I'm) | 06:20 |
| === cprov-afk is now known as cprov-zz | ||
| ksp | 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:21 |
| nDuff | init-repo and init are different | 06:22 |
| nDuff | ksp, you want to do the init before you can add | 06:22 |
| igc | spiv: review sent to the list now with minor tweaks requested | 06:22 |
| spiv | igc: thanks! | 06:22 |
| nDuff | ksp, but init-repo is to make a shared space to store multiple branches efficiently | 06:22 |
| nDuff | 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 |
| AfC | ksp: yeah - just insert "bzr init" between "mkdir" and "add codes and others suffs" | 06:23 |
| AfC | and you're all set | 06:23 |
| * AfC doubts ksp is working on java-gnome :) | 06:23 | |
| ksp | nDuff, yes, now i tried live, by using bzr init-repo and then bzr add , which threw an error saying, NOWorkingTree exists | 06:24 |
| ksp | so i used bzr init and then added using bzr add, it worked | 06:24 |
| ksp | so repo will hold number of branches under which we can add stufss | 06:24 |
| nDuff | ksp, yes; init-repo makes a shared repository *without* a working tree; you don't add in it. | 06:24 |
| ksp | AfC, nDuff now its clear for me | 06:24 |
| ksp | and now when other users want to get the data, they use bzr branch url and checkout the source | 06:25 |
| ksp | modify it and upload using bzr push. right ? | 06:25 |
| spiv | 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 |
| nDuff | 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:26 |
| spiv | ksp: yes, that's a reasonable workflow. nDuff's suggestion (users use 'bzr checkout' rather than 'bzr branch') is fine as well. | 06:27 |
| nDuff | 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:27 |
| ksp | 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:28 | |
| nDuff | 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 |
| ksp | so, branch allwos, commit offline and checkout allows commint online | 06:29 |
| nDuff | ksp: pretty much. you can change your tree between the two types using "bind" and "unbind". | 06:29 |
| ksp | ok | 06:30 |
| ksp | 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:31 |
| ksp | or anything is there which varies ? nDuff | 06:32 |
| nDuff | no, nothing that varies. | 06:32 |
| ksp | is it possible to have a nested branches ? | 06:33 |
| nDuff | in a repository, sure. | 06:33 |
| ksp | like bzr init abc; cd abc; bzr init xyz ? | 06:33 |
| nDuff | no idea. | 06:34 |
| ksp | ok, how can i allow authentication of users in bzr | 06:35 |
| ksp | like svn apache conf has, SVNAuthZFile | 06:35 |
| spiv | ksp: you can nest branches like that; the abc branch will just ignore the xyz branch inside it. | 06:36 |
| ksp | spiv, ignore ? | 06:36 |
| spiv | ksp: so e.g. a commit in abc will not have any effect on xyz, or vice versa. | 06:36 |
| ksp | 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 |
| spiv | Right. It's basically the same as if the branches weren't nested. | 06:37 |
| spiv | (There's some experimental code to do more advanced stuff with nested branches, but it's not ready for general consumption) | 06:38 |
| ksp | spiv, what about authenticating the commits | 06:38 |
| spiv | bzr has no authentication builtin at the moment. | 06:38 |
| spiv | Mostly people rely on something like SSH. | 06:38 |
| ksp | spiv, then how can we keep track of who is pushing which code ? | 06:38 |
| ksp | bzr+ssh ? | 06:39 |
| spiv | bzr stores a committer ID on each revision (see also the "bzr whoami" command). | 06:39 |
| spiv | And you can also configure bzr to GPG sign your revisions. | 06:39 |
| ksp | yeah, i remember now | 06:39 |
| spiv | Yes bzr+ssh, or even just sftp. | 06:39 |
| spiv | And leave the access control to your operating system/filesystem permissions. | 06:39 |
| ksp | spiv, fine. got the concept | 06:40 |
| ksp | spiv, one more silly question | 06:40 |
| spiv | ksp: I haven't seen a single silly question from you yet :) | 06:40 |
| ksp | spiv, i am used to subversion for more than a year and now planning to shift to bzr | 06:41 |
| ksp | and onw most advantage i read in bzr tutotial is that, we can do bzr commit when we are offiline | 06:42 |
| AfC | ksp: that is correct | 06:42 |
| ksp | that is it allows us to work offline also without connecting to the main repo | 06:42 |
| AfC | ksp: that is also correct | 06:42 |
| ksp | but how is it advantage | 06:42 |
| AfC | ksp: so, for get about "repositories" for a sec | 06:43 |
| AfC | bah | 06:43 |
| nDuff | ksp: are you a commercial or open source user? | 06:43 |
| AfC | ksp: so, forget about "repositories" for a second | 06:43 |
| ksp | ksp, open source | 06:43 |
| AfC | ksp: and just think about branches; | 06:43 |
| ksp | ok | 06:43 |
| AfC | ksp: each branch contains full history and is _entirely_ independent and self-sufficient | 06:43 |
| nDuff | 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 |
| AfC | and is a peer of all the other branches in the project. | 06:43 |
| AfC | you move changes between them by "merging". | 06:44 |
| nDuff | ksp: they can keep their branch on their own server, and then you can merge from it if and when you like. | 06:44 |
| AfC | but because you have a fully power branch, you can do anything you like to it (like committing, like viewing history, etc) | 06:44 |
| AfC | ksp: roger so far? | 06:44 |
| * ksp is trying to understand he above | 06:45 | |
| AfC | There are two techniques which ... enhance ... matters, but the basic essence of fully distributed version control is the above | 06:45 |
| nDuff | 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 |
| AfC | ksp: so you get that a branch is self-contained and everything you ever needed and its own little island? | 06:46 |
| ksp | AfC, yes | 06:47 |
| AfC | 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 |
| AfC | Right | 06:47 |
| AfC | ksp: so the two ... enhancements ... I mentioned are as follows: | 06:48 |
| spiv | 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 |
| AfC | 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:48 |
| AfC | [or rather, lots of branches each with everything might get to be a little large on disk] | 06:49 |
| AfC | 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 |
| spiv | 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 |
| AfC | 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:50 |
| * AfC notes that spiv is explaining this remarkable well :) | 06:51 | |
| spiv | AfC: I suspect we've both had a bit of practice :) | 06:51 |
| AfC | ksp: so you got the Bazaar idea of full power "branch", now hopefully you see where (local) "repository" fits in. | 06:52 |
| AfC | ksp: Good so far? | 06:52 |
| ksp | AfC, spiv so far I understood well | 06:53 |
| AfC | Now onto the the second ... enhancement ... one that I actually regard somewhat askance. | 06:53 |
| ksp | here my query comes up | 06:53 |
| AfC | wait | 06:53 |
| ksp | AfC, ya, please go ahead with sec enhancement | 06:54 |
| AfC | 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 |
| AfC | [the word repository is often misused here, but branch is correct] | 06:55 |
| AfC | this is known as a "bound" branch in Bazaar terms | 06:55 |
| AfC | and typically is created by using the | 06:55 |
| AfC | bzr checkout | 06:55 |
| AfC | command instead of the | 06:55 |
| AfC | bzr branch aka bzr clone | 06:55 |
| AfC | command. | 06:55 |
| AfC | This is what powers the 1st generation centralized version control model that Bazaar is capable of supporting even though it is otherwise a 3rd generation decentralized version control tool. | 06:56 |
| AfC | Now: here are the catches: (or details) | 06:57 |
| AfC | A checkout is still a full stocked branch | 06:57 |
| AfC | It's just that you're not allowed to commit to it unless you have commit rights to the central (probably remote) branch. | 06:57 |
| AfC | There is an additional sub type created with | 06:58 |
| AfC | bzr checkout --ligthtweight | 06:58 |
| AfC | which, quite exceptionally and in variance with everything else that's going on, | 06:58 |
| AfC | does NOT create a full power branch and does NOT copy all the history which means it really IS crippled unless you have live network access to the remote branch. | 06:59 |
| AfC | (in other words, Subversion. Yetch) | 06:59 |
| AfC | So now that you've heard about it, don't touch it. | 06:59 |
| AfC | Final catch, | 06:59 |
| AfC | or detail or feature | 07:00 |
| AfC | and actually, this is the best part, | 07:00 |
| AfC | a proper bzr checkout (which is a branch that just happens to be bound to some other [typically remote] branch) can't be committed to | 07:00 |
| AfC | unless you have write rights on the central branch, | 07:01 |
| AfC | BUT | 07:01 |
| AfC | you *can* always just create a local copy [with bzr clone aka bzr branch, same thing] | 07:01 |
| AfC | of the checkout aka bound branch | 07:02 |
| AfC | thus creating a new branch locally that you DO have write access to, wherein you can carry on doing whatever you want, committing, etc | 07:02 |
| AfC | If you hadn't guessed, the final part of the story is submitting the revisions you've made locally in your own branch back to the parent project if you don't have write access to it, but that's kinda another topic. | 07:03 |
| AfC | That's how I handle the "can't commit to remote" thing, but there is also a concept called "local commits" which allows you to make revisions for later return to a remote branch (repository, sigh) that you do have write access to. | 07:04 |
| AfC | ksp: Well, that's about it I think. | 07:04 |
| * nDuff files bug #157335 (can't export from a packs repository over http) | 07:04 | |
| ubotu | Launchpad bug 157335 in bzr "AssertionError trying to export from a packs repository over http" [Undecided,New] https://launchpad.net/bugs/157335 | 07:04 |
| ksp | AfC, great explanation. i understood everything well now | 07:05 |
| ubotu | New bug: #157335 in bzr "AssertionError trying to export from a packs repository over http" [Undecided,New] https://launchpad.net/bugs/157335 | 07:05 |
| ksp | AfC, how to set priviliges for users to commit, read or write etc | 07:05 |
| nDuff | ksp: through whatever mechanism is native for the transport you use. if you're using a shared filesystem (or something that uses one like sftp), use file permissions. | 07:06 |
| ksp | ok | 07:07 |
| * AfC recommends bzr+ssh for the case where the remote system has ssh logins for the various users | 07:07 | |
| * nDuff is using packs (needs it, 100K+ file tree), so bzr+ssh doesn't work for him. | 07:07 | |
| ksp | AfC, nDuff spiv thanks a lot | 07:08 |
| AfC | ksp: frankly, I'd recommend just getting used to working with Bazaar in its basic full power local mode for a bit. You can then explore the ways of shipping revisions around later. | 07:08 |
| spiv | ksp: you're welcome. | 07:08 |
| spiv | nDuff: we'll fix that soon I hope | 07:08 |
| AfC | ksp: have a peek at http://java-gnome.sourceforge.net/4.0/HACKING.html for discussion of the other way of shutting revisions around - manually. | 07:09 |
| spiv | nDuff: thanks very much for finding these issues! | 07:09 |
| nDuff | spiv: heh, not a problem. Wish I had more time to get involved in fixing them. | 07:09 |
| ksp | i just got theoritical knowledge, i will do experiments in local as AfC suggested and then may come out with lot more queries | 07:09 |
| * AfC runs for the ferry. | 07:09 | |
| ksp | spiv, i am plannig to use for a large project named BOSS GNU/Linux, http://bosslinux.in | 07:10 |
| ksp | to maintain the source of BOSS (based on debian) and thus thinking that, do i need to make a sturcture like each package is a seperate branch | 07:11 |
| nDuff | ksp: the packs format works well for very large trees. that said, I don't know your requirements -- if folks will want to check out and work on only one package at a time, then that would make sense to break them out. | 07:14 |
| * nDuff finds that he can work around the export thing by using lightweight checkouts, which appear to work over http. | 07:15 | |
| nDuff | (well, using lightweight checkouts and then deleting the extra files) | 07:16 |
| nDuff | ...hmm, though I'll bet I could do an export from the checkout | 07:16 |
| spiv | ksp: I think a branch per package sounds like a good way to do it. | 07:19 |
| ksp | ok, thankyou for the suggestions | 07:25 |
| spiv | Argh, poolie's callCatchWarnings breaks under python -Werror. | 08:10 |
| spiv | I guess as part of its hackery of global state in the warning module it should temporarily disable -Werror. Hmm. | 08:11 |
| mwhudson | have fun with that | 08:12 |
| === weigon__ is now known as weigon | ||
| ksp | if i have a problem in accessing loggerhead using http protocol (throught the browser) then where will be the related logs be available ? | 08:36 |
| mwhudson | ksp: loggerhead dumps files to logs/debug.log | 08:36 |
| mwhudson | relative to the start-loggerhead script | 08:37 |
| ksp | but, when i access it through http://ip:port, ten it doesn't appear in browser, to trace that, where do i need to check the logs? | 08:37 |
| * ksp is indraveni , yesterday | 08:37 | |
| mwhudson | oh, i thought there was _another_ person with loggerhead problems | 08:38 |
| mwhudson | it's probably worth checking the apache logs too | 08:38 |
| igc | night all - have a great weekend | 09:11 |
| spiv | igc: g'night | 09:14 |
| igc | thanks spiv | 09:14 |
| spiv | Gar, *and* the test for callCatchWarnings didn't pass under 2.4. | 09:14 |
| * spiv fixes | 09:14 | |
| spiv | igc: Btw, | 09:14 |
| spiv | igc: Once this final branch lands, we're ready to cut the rc | 09:15 |
| spiv | igc: I'll do that sometime tonight. | 09:15 |
| igc | cool | 09:15 |
| igc | hope it goes well | 09:15 |
| spiv | Me too! | 09:15 |
| dato | can somebody suggest an option name for sorting the output of `bzr tags` chronologically? --chronollogically seems too long, maybe `--bytime`? | 11:00 |
| Peng | What about --sort=time? | 11:00 |
| Peng | Or "date". | 11:00 |
| Peng | Do any other commands do sorting? | 11:00 |
| fullermd | I like --sort. That gives you options for future extension. | 11:03 |
| LeoNerd | --sort is also what GNU ls takes, so might be an idea to see what it does and do things similarly | 11:04 |
| dato | yeah. plus if you alias tags=tags --sort=time, you should be able to run `bzr tags --sort=alpha` afterwards. | 11:05 |
| dato | only, I don't know off-hand how to implement it. :) | 11:07 |
| fullermd | I'm more of an idea rat... | 11:07 |
| ksp | mwhudson, from whom can i get i get help about apache configuration for loggerhead | 11:16 |
| mwhudson | ksp: i don't really know | 11:21 |
| mwhudson | ksp: there's nothing very special about loggerhead though | 11:21 |
| mwhudson | ksp: so i'd start with apache's mod_proxy documentation | 11:21 |
| ksp | mwhudson, i have done the confugurations what u explained but i think there is something else that i am missing | 11:23 |
| ksp | i have downlaoded the bzr-gtk , olive plugin | 11:48 |
| ksp | how to enable that plugin | 11:48 |
| ksp | i have done the steps given in the README and then when i executed, i am getting an error message .... | 11:48 |
| ksp | Unable to load plugin 'bzr-gtk' from '/root/.bazaar/plugins': It is not a valid python module name. | 11:48 |
| fullermd | You have to call it 'gtk'. | 11:49 |
| fullermd | (of course, first you have to stop running as root...) | 11:49 |
| ksp | u mean rename ? | 11:49 |
| fullermd | Yah. | 11:49 |
| === bac_afk is now known as bac | ||
| === mrevell is now known as mrevell-lunch | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === cprov-zz is now known as cprov | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === mw|out is now known as mw | ||
| ksp | i am seeing a good gui of olive here http://bazaar-vcs.org/Olive | 13:01 |
| ksp | i added the olive plugin under the ~/.bazaar/plugins and executing the bzr viz int eh working tree gave me a window | 13:02 |
| ksp | but how can i see such a GUI given in site, ? | 13:02 |
| ksp | i think its using nautilus and i have done the nautilus way of installation as per README explained | 13:03 |
| ksp | copying the nautilus.py file into the nautilus extensions path but i am not knowing how to use it | 13:03 |
| ksp | can some one here help me, in getting a good GUI like OLIVE work for me | 13:03 |
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === kiko-zzz is now known as kiko | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| === Mez is now known as Mez|Away | ||
| === Mez|Away is now known as Mez | ||
| jam-laptop | ksp: I don't think nautilus.py is what you want | 13:35 |
| jam-laptop | You probably just want to run "olive-gtk" | 13:35 |
| jam-laptop | which should be in ~/.bazaar/plugins/gtk/olive-gtk | 13:35 |
| === mrevell-lunch is now known as mrevell | ||
| ksp | jam-laptop, yes running olive-gtk gave me the window | 13:38 |
| ksp | jam-laptop, i am not ablet o do any operation like pushing, pulling, branching or any | 13:38 |
| ksp | do i need to run it from a working tree | 13:38 |
| jam-laptop | ksp: probably, I haven't used olive a whole lot | 13:38 |
| jam-laptop | Though I thought you could browse for a working tree | 13:39 |
| ksp | jam-laptop, then do u use commands prompt ? | 13:39 |
| jam-laptop | I use the command prompt for most of my work | 13:39 |
| jam-laptop | but I keep bzr-gtk installed for | 13:39 |
| jam-laptop | gannotate | 13:39 |
| jam-laptop | gviz sometimes | 13:39 |
| jam-laptop | sorry, 'viz' | 13:39 |
| ksp | i checked viz, its good enough | 13:39 |
| ksp | but how to use gannotate ? | 13:39 |
| jam-laptop | bzr gannotate filename | 13:39 |
| ksp | jam-laptop, should i be in the working tree / | 13:40 |
| ksp | ? | 13:40 |
| jam-laptop | yes | 13:40 |
| jam-laptop | well, you need to give the path to the file you want to annotate | 13:40 |
| jam-laptop | so it might be | 13:40 |
| jam-laptop | bzr gannotate tree/filename | 13:40 |
| jam-laptop | (that should work) | 13:40 |
| ksp | jam-laptop, thats popping up an error , http://pastebin.ca/750314 | 13:41 |
| ksp | jam-laptop, do u use loggerhead ? | 13:41 |
| === jelmer is now known as jelmer_ | ||
| === jelmer_ is now known as jelmer | ||
| jam-laptop | ksp: well, I use it in as much as codebrowse.launchpad.net uses it | 13:43 |
| jam-laptop | http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes | 13:44 |
| jam-laptop | But I have not personally set it up | 13:44 |
| jam-laptop | hmm.. your gannotate error confuses me, as Branch objects have never exposed "get_transaction" | 13:45 |
| jam-laptop | Let me investigate bzr-gtk | 13:45 |
| jam-laptop | ksp: can you give me the output of "bzr revno ~/.bazaar/plugins/gtk" ? | 13:46 |
| ksp | jam-laptop, error, | 13:47 |
| ksp | bzr: ERROR: Not a branch: "/root/.bazaar/plugins/gtk/". | 13:47 |
| jam-laptop | ksp: where did you install the 'gtk' plugin? | 13:48 |
| jam-laptop | You at least said you put it under "~/.bazaar/plugins" | 13:48 |
| jam-laptop | Did you put it there as 'olive'? | 13:48 |
| ksp | no, its as, gtk only | 13:48 |
| fullermd | I think he got a tarball, not a branch. | 13:49 |
| jam-laptop | ah, you probably just downloaded one of the snapshots/releases where did you ge | 13:49 |
| jam-laptop | where did you get it from? | 13:49 |
| jam-laptop | (just to make sure I'm using the same one as you) | 13:49 |
| ksp | jam-laptop, i downloaded the tar.gz file from http://bazaar-vcs.org/Olive | 13:50 |
| jam-laptop | ok, that would be a very old version (0.12) | 13:50 |
| jam-laptop | They have a warning at the beginning, but that should probably be made clearer on the "install" section | 13:50 |
| jam-laptop | ksp: http://bazaar-vcs.org/bzr-gtk | 13:51 |
| jam-laptop | Has a link for | 13:51 |
| jam-laptop | https://launchpad.net/bzr-gtk/0.91/0.91.0/+download/bzr-gtk-0.91.0.tar.gz | 13:51 |
| fullermd | Probably should move those links off to an Archive page somewhere... | 13:51 |
| jam-laptop | try that one | 13:51 |
| ksp | jam-laptop, should i the above source? | 13:52 |
| jam-laptop | you should download it | 13:53 |
| jam-laptop | and then put it in the same location | 13:53 |
| jam-laptop | just rm -rf ~/.bazaar/plugins/gtk | 13:53 |
| jam-laptop | and put the new one there | 13:53 |
| ksp | yes, now gannotate worked | 13:54 |
| ksp | jam-laptop, thankyou | 13:54 |
| ksp | i am facing difficulty in setting up the loggerhead for remote access through apache webserver | 13:55 |
| ksp | need help in this aspect | 13:55 |
| jam-laptop | I really don't know how to set up loggerhead | 14:11 |
| jam-laptop | mwhudson might know | 14:11 |
| fullermd | I think he's through all the loggerhead part of it, and having issues with the Apache side. He's been with mhudson on it the last couple days. | 14:12 |
| jam-laptop | ah | 14:13 |
| jam-laptop | Isn't it just a proxy redirect? | 14:13 |
| fullermd | Dunno. I've been mostly ignoring it in favor of alternating between a flood of Real Work, and spewing verbiage about multi-branch commands. | 14:13 |
| jam-laptop | of course, he left before I noticed | 14:14 |
| jam-laptop | ... | 14:14 |
| fullermd | He didn't _leave_, he's just 'distributed'. | 14:16 |
| fullermd | Disconnected IRCing is just ONE of the benefits... | 14:16 |
| jelmer | hmm, not good: | 15:00 |
| jelmer | bzr: ERROR: Revision {('pqm@pqm.ubuntu.com-20071025022746-ftudwmzir8v2lccc',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x9a57f4c>". | 15:00 |
| jelmer | that's what I get pulling from bzr.dev into my own copy (that is using packs) | 15:01 |
| siretart | any idea what could be causing this? http://paste.debian.net/40689 | 15:02 |
| jam-laptop | jelmer: did you run "bzr reconcile" before you converted to packs? | 15:02 |
| jam-laptop | There are some known data inconsistencies with bzr.dev | 15:02 |
| jam-laptop | which 'bzr reconcile' should fix up | 15:02 |
| fosstux | Hi! I'm really new to bazaar. In a local directory I entered bzr init and bzr add - and then I changed everything again. How can I completely delete the revision history? Or how can I start from scratch? | 15:02 |
| jam-laptop | (that I believe are not caught by the pull into packs) | 15:03 |
| Lo-lan-do | Hi there | 15:03 |
| fosstux | Is the bzr directory dependant? | 15:03 |
| LeoNerd | If you remove .bzr, you'll remove all the bazaar history and start from scratch | 15:03 |
| fosstux | ah ok | 15:03 |
| fosstux | thanks | 15:03 |
| jam-laptop | siretart: unfortunately the most likely cause of that is actual disk corruption | 15:03 |
| Lo-lan-do | I'm looking for a git-vs-bzr shootout, or a migration guide from one to the other, or something along these lines. | 15:03 |
| jam-laptop | We can try to work with you to investigate | 15:03 |
| jam-laptop | siretart: but whenever we've seen that, it seems that parts of the file are set to all NULL's | 15:04 |
| jelmer | jam-laptop: No, I didn't - I started off with poolie's copy of bzr.dev, which I thought was reconciled | 15:04 |
| jam-laptop | (it has happened with people using XFS, and people with machines that are a little flaky) | 15:04 |
| jam-laptop | jelmer: I don't know when/if poolie's was reconciled | 15:04 |
| jam-laptop | you might try reconcile or 'check' after the afct | 15:04 |
| jam-laptop | fact | 15:04 |
| jelmer | jam-laptop: k, thanks | 15:04 |
| jam-laptop | Lo-lan-do: http://bazaar-vcs.org/BzrForGITUsers | 15:05 |
| jam-laptop | though i'm not sure if it is fully fleshed out | 15:05 |
| Lo-lan-do | Not much, but it'll be a start | 15:05 |
| Lo-lan-do | Thanks :-) | 15:05 |
| Lo-lan-do | Is there a public bzr mirror/gateway for the kernel (or for Mozilla)? | 15:10 |
| === cprov is now known as cprov-lunch | ||
| === kiko is now known as kiko-fud | ||
| siretart | jam-laptop: could you imagine that file permissions could cause such an error? | 16:26 |
| jam-laptop | siretart: that specific error is caused when we try to uncompress a chunk | 16:27 |
| jam-laptop | Which means that we've already read the data | 16:27 |
| jam-laptop | it just happens to not contain gzip data | 16:27 |
| jam-laptop | So I'm guessing permissions aren't the issue | 16:28 |
| nekohayo | hello, is it only deltas that are saved between commits, or is a whole copy of the repository created? (I think I can guess the answer, but I'd just like to be 100% sure) | 16:34 |
| fosstux | Hi! How long can the initial push last? My initial push is at phase 1 of four - after 2 hours??? | 16:34 |
| jam-laptop | nekohayo: Generally it is a delta against the previous commit | 16:35 |
| jam-laptop | There are times when we store a fulltext, just so you don't have to apply 10,000 deltas to get the newest revision | 16:35 |
| fosstux | All together I have 65000 small files - with 404 MB! | 16:36 |
| jam-laptop | fosstux: There are a few factors involved, but if you have a lot of files in your project, and a lot of latency, it can take a while | 16:36 |
| fosstux | ok thanks | 16:36 |
| jam-laptop | fosstux: where are you pushing to? (launchpad?) | 16:36 |
| fosstux | yes | 16:36 |
| fosstux | The project is an icon theme for kde and gnome, but other desktops as well | 16:36 |
| jam-laptop | make sure you are using "bzr+ssh://" rather than "sftp://" | 16:36 |
| jam-laptop | 65k icons? Sounds interesting | 16:37 |
| jam-laptop | anyway "bzr+ssh" has about 1/3rd the round-trip latencies | 16:37 |
| fosstux | that number is including the bzr directory | 16:37 |
| fosstux | https://launchpad.net/lila-theme | 16:37 |
| jam-laptop | jelmer: ping | 16:37 |
| jelmer | jam-laptop, pong | 16:38 |
| jam-laptop | jelmer: are you a list admin for bzr-gtk? | 16:38 |
| jam-laptop | I just sent a big patch, and it is pending moderator approval | 16:38 |
| nekohayo | jam-laptop: thanks for the info :) is there a page documenting in which cases that fulltext is saved? (for the space-constrained cases) | 16:38 |
| jelmer | jam-laptop: no, I believe you and poolie are | 16:38 |
| phanatic | jam-laptop: i've already approved your mail | 16:38 |
| jelmer | jam-laptop: but I do have moderator access, so I can approve it | 16:38 |
| jam-laptop | jelmer: technically I am, but he forgot to give me the password | 16:39 |
| jelmer | never mind then :-) | 16:39 |
| jam-laptop | phanatic: thanks | 16:39 |
| jam-laptop | nekohayo: It is based on a simple heuristic, once the size of all deltas ~= size of the previous fulltext | 16:39 |
| jam-laptop | we create a new fulltext | 16:39 |
| jam-laptop | Or at 200 | 16:39 |
| fosstux | jam-laptop: all together there are icon themes, backgrounds, window decorations, Login manager themes etc included | 16:40 |
| nekohayo | jam-laptop: actually, even if it stores the fulltext, it's only a per-file thing, not the whole repository is saved full text periodically I presume? | 16:40 |
| jam-laptop | (the maximum delta length == 200) | 16:40 |
| jam-laptop | nekohayo: right, per-file | 16:40 |
| nekohayo | jam-laptop: this is great to know, thank you | 16:40 |
| fosstux | jam-laptop: and there are even color mods for some files | 16:40 |
| jelmer | hmm, looks like the bzr-gtk pqm is down | 16:40 |
| phanatic | jelmer: is there a pqm for bzr-gtk? | 16:41 |
| jam-laptop | jelmer: then just approve it offline :) | 16:41 |
| jelmer | s/pqm/bundlebuggy/ | 16:41 |
| dato | jam-laptop: I'm not sure I quite understand your last paragraph, "Just do it as part of the "--format" documentation, rather than doing it as separate options.". do you mean mentioning all the possible values in the help="" of the option? | 16:41 |
| jam-laptop | The trunk is accessible to all ~bzr developers | 16:41 |
| jam-laptop | dato: I'll try to give you an example | 16:41 |
| dato | jam-laptop: (I also prefer --foo=bar, fwiw) | 16:41 |
| jelmer | jam-laptop: we use bundlebuggy though, and hope to start using pqm at some point (lifeless was going to add bzr-gtk) | 16:42 |
| dato | jam-laptop: what I have is http://dpaste.com/23448/ | 16:42 |
| jam-laptop | dato: http://dpaste.com/23449/ | 16:43 |
| === cprov-lunch is now known as cprov | ||
| jam-laptop | dato: sure, that will let you set | 16:43 |
| jam-laptop | --sort=alpha | 16:43 |
| jam-laptop | It just doesn't document it | 16:43 |
| jam-laptop | if you had value_switches=true | 16:43 |
| jam-laptop | you could do | 16:43 |
| jam-laptop | --alpha | 16:44 |
| dato | jam-laptop: right, so I have to add the documentation by hand. | 16:44 |
| dato | jam-laptop: yeah, I understand the difference :) | 16:44 |
| jam-laptop | dato: unless you want to write support for doing it like http://dpaste.com/23449/ | 16:44 |
| jam-laptop | Which *I* think would be nice | 16:44 |
| dato | I'm just not sure what whoever wrote RegistryOption wants users of value_switches=False to do wrt documentation | 16:44 |
| jam-laptop | jelmer: sure, but you need to have a bit more of a test suite before pqm would help a lot :) | 16:44 |
| jam-laptop | dato: Abentley wrote RegistryOption, and added value_switches because he wanted --knit instead of --format=knit | 16:45 |
| jam-laptop | The documentation just falls out | 16:45 |
| fullermd | While we're speaking of those sort of options, does it annoy the crap out of anybody else how --format's description of "default" gives the description of that format, rather than telling me which of the formats IS the default? | 16:45 |
| jam-laptop | because you easily add documentation for a *real* option | 16:45 |
| jam-laptop | (optparse does it for us) | 16:45 |
| jam-laptop | We need to do a bit more custom hacking to add it as part of RegistryOption to add them to the normal help | 16:45 |
| fosstux | why is the latency for bzr+ssh so big? | 16:46 |
| dato | I see. though in the thread he said not including the documentation for v_s=False was *intentional* | 16:46 |
| jelmer | jam-laptop: true, but we've got to start somewhere :-) | 16:46 |
| jelmer | jam-laptop: your bundle has some conflicts against current trunk | 16:46 |
| jam-laptop | jelmer: probably, I can go through and try to clean them up | 16:46 |
| jam-laptop | Not listing the possible values was intentional | 16:47 |
| jam-laptop | But I think that was because of the "not adding them as command line switches/options" | 16:47 |
| jam-laptop | not because he wanted to hide the documentation. | 16:47 |
| jam-laptop | I'll reply to aaron and see what he sasy | 16:47 |
| jam-laptop | sasy | 16:47 |
| jam-laptop | says | 16:47 |
| dato | ok | 16:47 |
| jam-laptop | argh... | 16:47 |
| dato | I wouldn't mind taking a stab at implementing it | 16:48 |
| jelmer | jam-laptop: I've almost got them fixed, ok if I just send an updated version of it to the list? | 16:48 |
| jam-laptop | jelmer: I'm happy to have you do my work for me :) | 16:48 |
| fullermd | Well, he saw the way you were typing... | 16:48 |
| dato | heh | 16:51 |
| lifeless | hola | 16:57 |
| james_w | hi lifeless | 16:58 |
| james_w | lifeless: where have you made it to? | 16:58 |
| lifeless | now I just need to fogure out the time here | 16:58 |
| lifeless | now I just need to fogure out the time hereand I'm set | 16:58 |
| lifeless | bleh, I swear I didn't ht up arrow thre. | 16:59 |
| lifeless | LA | 16:59 |
| lifeless | notice my sparkling latency crippled typing | 16:59 |
| lifeless | fosstux: bzr+ssh - the startup time is likely/probably ssh handshaking; how long does 'ssh host echo' take ? | 17:00 |
| fullermd | Might just be that LA air. | 17:00 |
| lifeless | I'm using the bottled stuff | 17:00 |
| dato | jam-laptop: thanks for the mail | 17:02 |
| fosstux | lifeless: well the prompt to enter my passphrase comes instantly | 17:02 |
| jam-laptop | lifeless: I don't think you can do "ssh echo" to bazaar.launchpad.net | 17:03 |
| fosstux | I entered 'ssh bazaar.launchpad.net echo' - then my passphrase - then I have to press Ctrl-C to quit | 17:03 |
| jam-laptop | I suppose you could do "time sftp bazaar.launchpad.net" and then quit right away | 17:03 |
| fosstux | well... that time sftp... takes 7 secons to launch and quit - so ssh is not the problem | 17:05 |
| jam-laptop | lifeless: do you know any way to time the "ping" to launchpad.net ? | 17:06 |
| jam-laptop | ping bazaar.launchpad.net is blackholed | 17:06 |
| fosstux | I canceled my bzr push - when I try to restart bzr push I get the following error: Unable to obtain lock bzr+ssh://fosstux@bazaar.launchpad.net/%7Efosstux/lila-theme/main/.bzr/repository/lock held by fosstux@gmail.com on host fosstux [process #11873] - locked 1 hour, 55 minutes ago | 17:07 |
| fullermd | I can ping code. ~150 from here. | 17:07 |
| fosstux | what is wrong? | 17:07 |
| james_w | fosstux: the lock was not removed when you cancelled. | 17:07 |
| fosstux | and what can I do about it? | 17:08 |
| jam-laptop | fosstux: you just need to | 17:08 |
| james_w | you can 'bzr break-lock bzr+ssh://fosstux@bazaar.launchpad.net/%7Efosstux/lila-theme/main/' | 17:08 |
| jam-laptop | bzr break-lock URL | 17:08 |
| fosstux | ok. thanks. | 17:08 |
| lifeless | jam-laptop: no | 17:08 |
| lifeless | jam-laptop: but its the same dc, so pingling lp is equivalent except in exceptional crcumstances | 17:09 |
| fosstux | I'll simply let bzr push run - however long that lasts... | 17:09 |
| jam-laptop | well, if you got 65k files from 'find', and 150ms latency | 17:21 |
| jam-laptop | that would be something like 65k*.150 = 9750 seconds | 17:22 |
| jam-laptop | or 2.7 hours of round trip time | 17:22 |
| jam-laptop | and then add a bit more for other stuff | 17:22 |
| jam-laptop | which is why 0.92 is going to have a streaming protocol | 17:22 |
| jam-laptop | to avoid all the round trips | 17:22 |
| === kiko-fud is now known as kiko | ||
| james_w | is it sha1s that log -v --show-ids puts by the filenames? | 17:29 |
| fullermd | I'm pretty sure it shows the file-ids... | 17:29 |
| james_w | ah, that makes more sense, thanks. | 17:30 |
| jam-laptop | james_w: so if you are using a hash for bzr-git, then you would see something that looks a lot like a hash :) | 17:30 |
| james_w | yeah, that's what confused me. | 17:31 |
| james_w | I should have spotted it was too short for a sha though. | 17:31 |
| fullermd | So it's a sh then? | 17:32 |
| lifeless | also | 17:35 |
| lifeless | packs for the win | 17:35 |
| lifeless | james_w: I don't think 0.92 has streaming push, only sreaming pull | 17:37 |
| * fullermd blinks. | 17:38 | |
| fullermd | It isn't the same operation? | 17:38 |
| lifeless | no | 17:38 |
| lifeless | while it is symmetrical, wire protocols that are request-response are not symmetrical | 17:38 |
| lifeless | symmetry is broken | 17:38 |
| fullermd | So it has "gimme a box full of crap" but no "here's a box full of crap", even though both boxes would be packed up identically? | 17:40 |
| lifeless | right | 17:41 |
| lifeless | and the support code for crapping, and pawing through the crap is reusable | 17:41 |
| lifeless | it just has to be [heh heh] glued together | 17:42 |
| fullermd | Well, as long as we have a box to hold the crap until we get around to gluing it... | 17:43 |
| lifeless | rofl | 17:43 |
| * fullermd contemplates titles that could be printed on spiv's business cards... | 17:43 | |
| lifeless | I think that may have not been the best impression to give | 17:43 |
| lifeless | possibly the most accurate | 17:43 |
| fullermd | Hm. Y'know those "how shit happens" lists of religions? We should write one for version control systems based around "you crap in a box"... | 17:44 |
| jam-laptop | fullermd: One of the big reasons is that it is easy to send a HTTP POST and stream the response that is sent back | 17:44 |
| lifeless | making me squeal in an airport lounge is nasty | 17:44 |
| jam-laptop | it is *hard* to stream the POST | 17:44 |
| jam-laptop | I don't know if you saw spiv 's comments | 17:44 |
| jam-laptop | but basically, the problem is the remote side may not support the request | 17:45 |
| fullermd | Darcs: You crap in a box, and put it with all your other boxes. When you're not looking, your boxes are rearranged. | 17:45 |
| LeoNerd | SVN: Any time you want to change the crap, you just take a cheap copy of it and modify it in some small way | 17:45 |
| jam-laptop | and you don't really want to POST up a 10MB stream | 17:45 |
| jam-laptop | just to get back "not supported" | 17:45 |
| lifeless | jam-laptop: this is not http related though | 17:45 |
| lifeless | jam-laptop: this is our initial smart server protocol model | 17:45 |
| jam-laptop | lifeless: sure, I'm just mentioning why some of it is that way | 17:46 |
| jam-laptop | at least at a conceptual level | 17:46 |
| lifeless | right, I'm only objecting to the HTTP thing there | 17:46 |
| lifeless | request-response protocols are hard | 17:46 |
| lifeless | so I'm down to only two uses of inventories in commit.py | 17:47 |
| jam-laptop | I have a feeling there is a big jump from 2 to 0 | 17:48 |
| jam-laptop | but nice to see progress :) | 17:48 |
| lifeless | one is 'set of all ids' | 17:50 |
| lifeless | the other is record_entry_contents | 17:50 |
| lifeless | once this is done, the uses of inventory are hidden on the tree interface | 17:50 |
| jam-laptop | why is bzr.0.91 in Launchpad owned by jml? | 17:50 |
| jam-laptop | https://code.edge.launchpad.net/~jml/bzr/bzr.0.91 | 17:50 |
| lifeless | if we then implement a native iter_entries_by_dir | 17:51 |
| jam-laptop | lifeless: I would like to see a way to get the root id for a tree | 17:51 |
| jam-laptop | That Tree.inventory.root.file_id is a bit ugly | 17:51 |
| jam-laptop | that is separate | 17:51 |
| lifeless | jam-laptop: add a tree_implementations/test_root_id.py with a trivial test and trivial method | 17:51 |
| jam-laptop | lifeless: so you consider it worthy? | 17:52 |
| lifeless | yes | 17:52 |
| jam-laptop | I just know it is one of the inventory accesses I need to do for tests | 17:52 |
| lifeless | its punishing to do a full conversion to inventory for that one attribute | 17:52 |
| lifeless | I really want to promote most things to tree | 17:52 |
| lifeless | inventory is a great *impklementation*, not a great generic interface | 17:52 |
| jam-laptop | jml: ping | 17:53 |
| lifeless | rofl | 17:56 |
| lifeless | 3am for him | 17:56 |
| lifeless | on saturday | 17:56 |
| jam-laptop | lifeless: I've seen you and igc around at those times :) | 17:56 |
| jam-laptop | I can always just create the 0.91 mirror | 17:57 |
| jam-laptop | It just seemed silly to have 2 of them | 17:58 |
| lifeless | what is the issue ? | 17:58 |
| lifeless | is his one wrong? or just wrong owner ? | 17:59 |
| jam-laptop | just the wrong owner | 17:59 |
| jam-laptop | and marked as Development/New rather than Mature | 17:59 |
| lifeless | hmm | 18:00 |
| lifeless | I think you are confused | 18:00 |
| lifeless | thereis no 0.91 blessed branch - https://edge.launchpad.net/bzr/0.91 | 18:00 |
| lifeless | jml has chosen to have a 0.91 branch of his own is all | 18:00 |
| jam-laptop | you are probably right, but there is a mirror of 0.91 already in launchpad | 18:00 |
| jam-laptop | And I *think* you can't register 2 mirrors | 18:00 |
| jam-laptop | for the same branch | 18:01 |
| jam-laptop | But maybe that is just for the same user | 18:01 |
| lifeless | per user | 18:01 |
| lifeless | because otherwise randoms could attack namespaces | 18:01 |
| jam-laptop | weird, it allowed me to register a branch as ~jml | 18:02 |
| jam-laptop | by going to code.../~jml/+addbranch | 18:03 |
| jam-laptop | Or at least it tried and failed because it was already mirrored | 18:03 |
| jam-laptop | lifeless: you are wrong | 18:03 |
| jam-laptop | It is failing to register as ~bzr | 18:04 |
| jam-laptop | because it is registered as ~jml | 18:04 |
| lifeless | uhm | 18:04 |
| lifeless | oh, this is a nonsense IMNSHO | 18:04 |
| lifeless | hang on I'll fix, but please file a bug :) | 18:05 |
| jam-laptop | I'll file a bug | 18:05 |
| jam-laptop | is this under launchpad-bazaar? | 18:05 |
| jam-laptop | Or just launchpad | 18:05 |
| lifeless | launnchpad I think and let it get moved by them | 18:05 |
| jam-laptop | k | 18:05 |
| lifeless | actually wait a second | 18:06 |
| lifeless | no do it | 18:06 |
| lifeless | whats happened though is that the owner/registrant thing has confused you | 18:06 |
| jam-laptop | how so? | 18:06 |
| jam-laptop | I am unable to change the status for that branch | 18:06 |
| jam-laptop | which means it has the wrong owner | 18:06 |
| lifeless | the owner/reigstrant split for branches is a hack | 18:07 |
| lifeless | its not done generally thoughout the lp datamodel yet | 18:07 |
| lifeless | https://code.edge.launchpad.net/bzr/ | 18:07 |
| lifeless | look for 0.91 there | 18:07 |
| jam-laptop | sure, it is down low for bzr.0.91 | 18:08 |
| jam-laptop | And the link is to ~jml/... | 18:08 |
| lifeless | but the name beside it is 'bazaar developers' | 18:08 |
| lifeless | anyhow, fixed | 18:08 |
| lifeless | registrant/auhtor split I should have said | 18:09 |
| jam-laptop | sure, the Author was Bazaar Developers, but the registrant was ~jml | 18:09 |
| === BasicMac is now known as BasicOSX | ||
| lifeless | so jam-laptop journalled inventories, did my reply make sense? | 18:47 |
| jam-laptop | I think so, but I haven't fully parsed it yet | 18:47 |
| lifeless | coo | 18:48 |
| lifeless | nDuff: did you mail me another callgrind file? I may have missed it but I didn't see one | 18:49 |
| lifeless | ok, time for pancakes. Just because. | 18:52 |
| lifeless | next stop cambridge | 18:52 |
| Vantage | hi, how do you revert out all changes from a specific branch/merge (older than the previous merge)? | 19:20 |
| james_w | Vantage: you can use bzr merge. | 19:20 |
| Vantage | eg. if I merge files from brance a, then branch b, then branch c into my branch and commit each. How do I later revert out the changes from branch A? | 19:20 |
| james_w | I'm not positive it works for merge commits though. | 19:21 |
| james_w | if you give the revisions "backwards" then merge will undo those changes. | 19:21 |
| james_w | so 'bzr merge -r4..3' will revert the changes between 3 and 4. | 19:21 |
| james_w | if you don't like what happens, simply bzr revert. | 19:22 |
| Vantage | are the revono per file or for the whole tree | 19:22 |
| Vantage | or how do I see the history of merges in the repo? | 19:23 |
| james_w | whole tree. | 19:24 |
| james_w | bzr log will show you. | 19:24 |
| james_w | commits that were merged in will be indented. | 19:24 |
| Vantage | k. I thought that was per file, but that's good to know it's the whole tree | 19:24 |
| Vantage | hrmm when I do a bzr merge -r14437..14436 I get "bzr: ERROR: Requested revision: u'14437' does not exist in branch: BzrBranch5" | 19:26 |
| Vantage | but those are the numbers I get from bzr log | 19:26 |
| james_w | try adding a '.' at the end. | 19:27 |
| james_w | doing that will make it use your current branch as the merge source. | 19:27 |
| Vantage | ah.... :) | 19:27 |
| james_w | at the moment it is using the remembered merge source. | 19:27 |
| Vantage | that works. Of course this means you can't cherry pick out a previous merge, right? Only rolling back to a previous revision? | 19:28 |
| james_w | sorry, I don't understand the question. | 19:29 |
| Vantage | If I'm at rev 10, I can go from 10 to 9 or 10 to 7, but I can't keep revisions 10 and 9, but remove 8 | 19:29 |
| james_w | if you do 'bzr diff' does it just show the changes that were introduced by that merge being reverted? | 19:30 |
| james_w | yes, you can, that is what this should be doing. | 19:30 |
| james_w | 'bzr merge 9..8' should do that. | 19:30 |
| Vantage | oh really? That would be really cool. Let me try that (I was only trying new commit to older) | 19:30 |
| james_w | (though sometimes I get the numbers wrong) | 19:30 |
| james_w | remembering what the boundaries should be can be tricky. | 19:31 |
| fullermd | I think removing 8 would be 8..7 | 19:31 |
| james_w | see :) | 19:31 |
| jam-laptop | -rX..Y is "merge the changes from Y versus X" | 19:32 |
| jam-laptop | so the change of 8 | 19:32 |
| jam-laptop | is against 7 | 19:32 |
| jam-laptop | -r 8..7 | 19:32 |
| jam-laptop | is correct | 19:32 |
| jam-laptop | just like cherry picking revs 8, 9 and 10 is the difference from 7 - 10 | 19:32 |
| jam-laptop | so bzr merge -r 7..10 | 19:32 |
| james_w | thanks fullermd and jam-laptop. | 19:32 |
| jam-laptop | also "bzr diff -r X..Y" should give you a preview of what it will do | 19:33 |
| Vantage | jam-laptop: so when you say "preview" how would you do that before you merge? specify the other repo? | 19:36 |
| jam-laptop | Vantage: yes | 19:37 |
| Vantage | jam-laptop: very cool | 19:37 |
| jam-laptop | Just saying that diff takes approximately the same arguments as merge | 19:37 |
| jam-laptop | There may be a bug about "bzr diff -r X..Y http://remote/branch" not working | 19:37 |
| jam-laptop | jelmer: any comments on my patch? | 19:55 |
| jelmer | jam-laptop: Yes, they're coming up | 19:55 |
| jam-laptop | (I'm guessing if you are submitting it under your name that you like it :) | 19:55 |
| jam-laptop | k | 19:55 |
| bos | jelmer: ping | 19:55 |
| jelmer | jam-laptop: will send them once I finish my slot in the open week session | 19:55 |
| jelmer | bos: Hi | 19:55 |
| bos | jelmer: what does bzr-svn do when you try to push changes from a branchy bzr repo to svn? | 19:56 |
| bos | does it create temporary branches in the svn repo so all of history is preserved? | 19:56 |
| jam-laptop | I'm pretty sure it just pushes the mainline revs | 19:56 |
| jam-laptop | and just marks the others as theoretical merges | 19:57 |
| bos | oh, right, bzr has a mainline :-) | 19:57 |
| jelmer | bos: yes, it just pushes the mainline revisions | 19:57 |
| jam-laptop | but jelmer would know better | 19:57 |
| bos | ok, thanks. | 19:57 |
| jam-laptop | bos: long time no see | 19:57 |
| jelmer | bos: and ignores the merged revisions | 19:57 |
| jam-laptop | how are things going? | 19:57 |
| bos | i'm trying to decide what the hg equivalent ought to do, since we don't have a mainline. | 19:57 |
| jelmer | bos: when pulling changes in, they're recognized as ghosts | 19:57 |
| bos | jam-laptop: all's well. and yourself/ | 19:57 |
| bos | ? | 19:57 |
| jelmer | bos: How's hg-svn going? | 19:57 |
| bos | jelmer: i just started work on it. | 19:58 |
| jam-laptop | bos: things are going well here | 19:58 |
| bos | i'll probably just pick the hg branch with the most accumulated changes and push that | 19:58 |
| jam-laptop | do you know how git-svn does it? | 19:59 |
| jam-laptop | Since they have similar ancestry as hg would | 19:59 |
| bos | git-svn picks an arbitrary branch | 19:59 |
| bos | the doco says "please please oh please keep your history linear", pretty much | 19:59 |
| jam-laptop | bos: so for hg, you don't preserve merge parent order, right? (you sort() the hashes?) | 19:59 |
| bos | we do preserve the order, yes. | 20:00 |
| * fullermd blinks. | 20:00 | |
| bos | the left parent is "mine", and the right parent is "theirs". | 20:00 |
| jam-laptop | so when you merge, you remember which was left and which was right? | 20:00 |
| jam-laptop | ok | 20:00 |
| jam-laptop | I thought I saw a sort() in the past | 20:00 |
| fullermd | That sounded almost like the question was "which branch do you push", and the answer was "these are the revs in the branch we push"... | 20:00 |
| jam-laptop | But that might have been something else | 20:00 |
| * bos detests the svn client API | 20:01 | |
| jam-laptop | ah, it is just when you generate a child hash | 20:02 |
| jam-laptop | you sort the parents first | 20:02 |
| jam-laptop | and then hash the set | 20:02 |
| bos | heh. that's probably not even worth doing, since the hash is going to depend on the order of the parents anyway. | 20:03 |
| Vantage | Hi, I did a cvs import of a project to bzr, and when I checkout/branch from one of the CVS branches, I get the knit files for the whole repository, which causes the branch to be really slow. Is there a way to only get what's required for the branch? | 22:31 |
| fullermd | Well, those files _are_ what's required for the branch :) | 22:39 |
| fullermd | If you wrap a shared repository around the branches, you'll save the copying time (as well as space). | 22:39 |
| Vantage | fullermd: all of them? I should just need the ones for the branch I'm checking out, right? | 22:39 |
| Vantage | fullermd: I end up getting 791MB worth of knits for a 200MB checkout... | 22:40 |
| fullermd | Well, it should only copy the revs for the branch you're making. | 22:40 |
| fullermd | Well, with a reasonably length history, that sounds reasonable. | 22:41 |
| Vantage | fullermd: it doesn't seem to. If I look in the repo created by bzr-cvsps-import the knits are all stored together, not sorted by branches. When I checkout I get all of them | 22:41 |
| fullermd | That doesn't mean you get all the data from the kints, though. There's a knit per file, and all the branches probably have the same files, so you'd get all the same named knits. | 22:42 |
| fullermd | But I'm pretty sure you should only get the revs in each knit that apply to the given branch. | 22:42 |
| Vantage | fullermd: hrmm, I think your right. The sizes don't seem to match up quite right | 22:44 |
| fullermd | Still a lot of history, 'course. Using a shared repo around your branches would be a big savings cvsps-import puts all its branches in a repo together already, I think) | 22:44 |
| Vantage | fullermd: yeah, but you have to do lightweight checkouts, right? | 22:44 |
| fullermd | Wow, how'd I miss the ( before cvsps-import in that line? I must be tired... | 22:44 |
| fullermd | Not necessarily. You could use lightweight checkouts, or you could use normal bzr-ish colocated working trees in the branches. | 22:45 |
| Vantage | normal bzr-ish colocated working trees in the branches? | 22:45 |
| Vantage | fullermd: what's that? | 22:49 |
| fullermd | Hrm. What's your bzr experience? | 22:50 |
| Vantage | fullermd: just getting started :) | 22:50 |
| fullermd | Ah, OK. CVS background? | 22:51 |
| Vantage | fullermd: yup and trying to get a fairly large repo converted over | 22:51 |
| Vantage | fullermd: the conversion has gone fine, I'm just trying to figure out the best way for us to use it | 22:51 |
| jam-laptop | Vantage: how big is your CVS repo | 22:52 |
| Vantage | fullermd: so far lightweight checkouts is the front runner, but i'm curious if there's a way to speedup normal branching | 22:52 |
| fullermd | 'k. Well, let's skim over concepts quick first, then look at what you'll do with it. | 22:52 |
| fullermd | In CVS you have your two pieces; your checkout, and the repo. In bzr there are 3 pieces; your working tree (which is equivalent to the CVS checkout), the branch, and the repo (those two together roughly correspond to the CVS repo) | 22:53 |
| fullermd | All 3 can be in the same place; that's what you get with a normal "bzr init"; your working tree is right there, and your branch/repo are in the .bzr dir in the root of that tree. | 22:53 |
| Vantage | right, took awhile, but I've got that one figured out :) | 22:53 |
| Vantage | right | 22:53 |
| fullermd | Or all 3 can be in different places, or 2 can be in one place with the third in another. | 22:54 |
| fullermd | What you have from cvsps-import should be a shared repo (with the repo in somedir/.bzr), with a set of branches in it (somedir/branch1, somedir/branch2, etc, or some slightly differing layout, but all inside somedir/) | 22:54 |
| Vantage | yup | 22:54 |
| fullermd | And no working trees at all (they don't _have_ to exist for bzr to have the data, any more than a CVS repo _needs_ checkouts) | 22:55 |
| fullermd | Of course, you need the working trees to... y'know. Work. So you'll have to get 'em somewhere. | 22:55 |
| fullermd | You can have them "normal bzr-fashion", colocated with the branches (that happen to be in the repo, though that's just a detail). Or you can have them somewhere separate from the branches. | 22:56 |
| fullermd | To work out how you should go, now we need to look at your particular use-cases. | 22:56 |
| fullermd | So, how big is this, how many people are working on it, and what sort of physical infrastructure are you working over? All on one box, 3 guys on the moon, etc? | 22:57 |
| Vantage | well the repo size for the one module i'm testing with is 2.3GB in cvs. We have several large modules we might be converting | 22:58 |
| Vantage | each module has roughly 5-10 developers working on it | 22:58 |
| Vantage | the repo is on one machine, everyone else has their own checkout sandboxes they develop in | 22:59 |
| Vantage | plus testing environments | 22:59 |
| Vantage | so shared repo with lightweight checkouts seems to fit from what I've been reading | 23:00 |
| fullermd | OK. I presume you're also intending to mostly duplicate your existing CVS workflow and then phase in more distributed pieces over time, rather than try to jump whole-hog into an uber-distributed setup. | 23:00 |
| Vantage | fullermd: right | 23:01 |
| jelmer | abadger1999: Please feel free to send patches you include in the fedora packaging for bzr-gtk to the bzr-gtk mailing list | 23:01 |
| fullermd | Lightweight checkouts would work well, as long as you're one one machine. Across a fast LAN, they may work OK (I've not tried). But they would be unpleasant on anything slower. | 23:01 |
| jelmer | abadger1999: we'd be interested in including some of them | 23:01 |
| abadger1999 | jelmer: Cool. Where's the bzr-gtk mailing list? | 23:01 |
| abadger1999 | I'll sign up and start sending. | 23:01 |
| jelmer | the address is bzr-gtk@lists.canonical.com | 23:02 |
| jelmer | details on https://lists.ubuntu.com/mailman/listinfo/bzr-gtk | 23:02 |
| abadger1999 | Thanks | 23:02 |
| fullermd | (me, I'd use normal 'heavy' checkouts any time the branch wasn't on local disk) | 23:02 |
| Vantage | fullermd: more unpleasent than cvs? The checkins are more resource intensive than the cvs ones? | 23:02 |
| fullermd | Well, theoretically, it could be much better. In practice, right now, going across the network is slow and somewhat clumsy. | 23:03 |
| fullermd | (clumsy internally, I mean; from the outside it's all black-box) | 23:03 |
| Vantage | fullermd: is it bad to the point of unusable? | 23:03 |
| fullermd | You wouldn't notice it on commit or update, probably. But things like diff and log would probably be really sluggish. | 23:03 |
| Vantage | fullermd: now we also do feature based branching, so a lot of new branches with small changes are created. This is where heavyweight checkouts and branching can become a problem, since these are very slow even on the local machine... | 23:04 |
| fullermd | Well, the [first] heavyweight checkout will be slow to initially create. But later branches, as long as they're done in a repo, should be pretty fast. | 23:05 |
| fullermd | And later checkouts of related branches should be pretty fast in a repo too, since they'd only have to copy non-shared data. | 23:05 |
| Vantage | fullermd: I'm not sure I follow. So I'd do a heavyweight checkout (slow), and then how would I make the branches within the repo? Or is the new branch the repo? | 23:06 |
| fullermd | Well, this is a mental departure from CVS. In CVS, the repo is pretty important; in bzr, it's conceptually not. | 23:06 |
| jam-laptop | Vantage: http://bazaar-vcs.org/Tutorials/CentralizedWorkflow | 23:07 |
| jam-laptop | Vantage: you can have a *local* "shared repository" and a centralized one | 23:07 |
| fullermd | A shared repo can exist or not, and the only difference generally is performance/space. | 23:07 |
| fullermd | Right, what jam-laptop said. The devs would have a shared repo on their system, into which they checkout (and within which they branch). | 23:08 |
| radix | the problem is that "shared repository" sounds an awful lot like a thing used to share branches between developers. | 23:08 |
| fullermd | There's also a shared repo on the server, containing the branches there. The two don't have any necessary relation to each other; it's all about the branches. | 23:09 |
| Vantage | fullermd: So with a shared repo and lightweight checkout I can create a new branch on the remote server (fast) and then use bzr switch on my local checkout (also fast). With a heavyweight checkout what would be the equivelant process? | 23:09 |
| jam-laptop | "shared" is between branches, not between people | 23:10 |
| fullermd | Pretty much the same. | 23:10 |
| Vantage | fullermd: also, when you branch into your local shared repo do these have to be manually merged back to the central shared-repo | 23:10 |
| jam-laptop | radix: but I agree there isn't a good term for distinguishing | 23:10 |
| fullermd | I think 'switch' doesn't work for heavy checkouts, so the steps there would be a bit different. But there's no reason it _couldn't_ (and probably should). | 23:10 |
| fullermd | If you _branch_ locally, that branch you created only exists locally. So if you want it visible outside, you either need to merge it into an outside branch, or push it somewhere. | 23:11 |
| fullermd | Here's a common workflow I have: | 23:11 |
| Vantage | fullermd: right, switch doesn't, so i'm wondering what you would do instead with heavyweight checkouts. branch from remote, branch local, commit, merge back? | 23:11 |
| fullermd | - Central branch on a server way out 'cross the Internet from me. | 23:11 |
| fullermd | - [Heavy] Checkout of that branch on my workstation. | 23:11 |
| fullermd | (that checkout called 'trunk' let's say) | 23:12 |
| fullermd | - I 'bzr branch trunk feature-x' to make a branch to work on some feature, then I go off and work in that branch for a while. | 23:12 |
| fullermd | So feature-x accumulates commits for a while, independently of trunk. That branch doesn't exist and isn't known about anywhere but on my system. | 23:12 |
| fullermd | (meanwhile, other people can be making commits in trunk. Or _I_ can, for other stuff that comes up while I'm working on the feature) | 23:13 |
| fullermd | Eventually, feature-x is done (or done enough to take live). | 23:13 |
| fullermd | I go into my 'trunk' checkout, do an 'update' to be sure I'm up to date (just like with CVS). | 23:13 |
| fullermd | Then I "bzr merge ../feature-x" to merge in my feature changes. Check it over, resolve any conflicts, then commit. | 23:13 |
| fullermd | Since 'trunk' is a checkout of the main trunk, that commit then takes all those changes live and widely visible. | 23:13 |
| fullermd | The feature-x branch itself has never lived or existed anywhere but on my workstation. But after the merge, its revisions are in the trunk, so they're visible to everywhere. | 23:14 |
| fullermd | Now, if feature-x were going to be a longer project involving other people, I'd make the feature-x branch on the server instead of my workstation, and we'd all check it out alongside/instead of 'trunk'. | 23:15 |
| Vantage | fullermd: so does bzr branch trunk feature-x create another working tree? | 23:15 |
| fullermd | Well, it creates another branch, which may or may not have a WT with it. In my case, it does. | 23:15 |
| Vantage | fullermd: and once you've merged it to the central server could someone conceivably checkout specifically that branch? Or is only the history available? | 23:15 |
| jam-laptop | Vantage: if the history is available, you can checkout a WT | 23:16 |
| Vantage | fullermd: Is there a way to do it without another working tree? That's another appealing part of the bzr switch. Only one copy of the working tree | 23:16 |
| Vantage | jam-laptop: thanks | 23:16 |
| fullermd | Well, somebody could _recreate_ the branch (not _quite_ entirely, but near enough) | 23:16 |
| fullermd | Well, you could use local lightweight checkouts, and not have WT's in your local repository. | 23:17 |
| Vantage | fullermd: how would you get the local repository without doing a checkout/working tree and still have commits in the local tree go back to the central server? | 23:18 |
| fullermd | Then you'd have (lightweight checkout) -> (local heavy checkout with no working tree) -> (remote branch you checked out) | 23:18 |
| Vantage | fullermd: how do you get "local heavy checkout with no working tree"? | 23:18 |
| fullermd | It would take a few more commands to work with, but it's workable. | 23:19 |
| fullermd | I dunno if you can easily make it happen directly. What you'd do is make the local heavy checkout the normal way, then dispose of its working tree ("bzr remove-tree"). | 23:19 |
| Vantage | ah.. | 23:20 |
| jam-laptop | "bzr branch + bzr bind" into a repository with "no-working-trees" set | 23:20 |
| fullermd | I s'pose you could branch (into a non-tree repo), then bind. | 23:20 |
| jam-laptop | Is the easiest way | 23:20 |
| jam-laptop | You could leave no-trees set | 23:20 |
| jam-laptop | and then just manually "bzr checkout ." | 23:20 |
| fullermd | That works because as an implementation detail, a heavy checkout is actually a branch, with some extra fixins to push changes upstream. | 23:20 |
| Vantage | of course it's not too bad to have one extra working tree, as long as we're not keeping many working trees... | 23:21 |
| fullermd | (which I really wish we'd de-emphasize) | 23:21 |
| fullermd | And don't forget, you can dump working trees with remove-tree and re-create them with checkout at will. | 23:21 |
| fullermd | So if you're not gonna work on a branch for a while, you can just get rid of its tree until you need it again, just like you could rm -rf the checkout of a CVS module you don't need for a while. | 23:22 |
| Vantage | nice | 23:23 |
| Vantage | ok, well this gives me some stuff to play with. Thanks for the tutorial guys! I'm sure I'll be back with more questions later :) | 23:24 |
| fullermd | Gaah. CentralizedWorkflow has that evil "make ~ a repo" thing going on :| | 23:25 |
| === fbond_ is now known as fbond | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
