| mwhudson | blueyed: you'll probably need to cherry pick | 00:09 |
|---|---|---|
| blueyed | mwhudson: thought so.. too bad.. should I adjust my workflow? | 00:10 |
| blueyed | ..since merging is a lot nicer than cherrypicking. | 00:10 |
| blueyed | I've thought about reverse-cherrypicking to reverse the local changes in the main dev branch..?! | 00:11 |
| beuno | blueyed, feature branches are great if you need to move around features | 00:11 |
| jam | blueyed: if you know you'll never want main.local in the real mainline, you can do | 00:12 |
| jam | cd main | 00:12 |
| jam | bzr merge ../main.local | 00:12 |
| jam | bzr revert . | 00:12 |
| jam | bzr commit -m "null merge main.local" | 00:12 |
| jam | That will explicitly revert the changes in main.local into main | 00:13 |
| blueyed | jam: "cd main"? do you mean the feature branch? | 00:16 |
| blueyed | would this be necessary for each future feature branch? | 00:16 |
| jam | blueyed: just a sec, phone | 00:18 |
| blueyed | jam: np, take your time. I'm drunken already anyway :D | 00:19 |
| jam | blueyed: no, you are rejecting the changes in your .local branch, by 'null merging' them into your mainline branch | 00:19 |
| jam | so that when you merge your feature branch, it is built on something that has already been "merged" | 00:20 |
| jam | even though those changes have been rejected | 00:20 |
| Jc2k | mwhudson: http://blogs.gnome.org/johncarr/2008/06/26/the-mirror-man-says/ | 00:23 |
| Jc2k | how does that read? | 00:23 |
| blueyed | jam: I have main.local (where the feature branches are derived from). You mean I should "null merge" the changes into the feature branch then merging this into the main dev branch? | 00:24 |
| jam | blueyed: you said you were trying to get the features into the main dev branch, right? | 00:24 |
| jam | so if you null merge what it is based on | 00:24 |
| blueyed | jam: yes | 00:24 |
| mwhudson | Jc2k: "which is handing after setting" ? | 00:24 |
| jam | then the next merge will just grab the feature | 00:24 |
| jam | blueyed: I probably left off the last steps | 00:25 |
| jam | bzr merge ../main.local | 00:25 |
| jam | bzr revert . | 00:25 |
| jam | bzr commit -m "rejecting the local changes" | 00:25 |
| jam | bzr merge ../feature | 00:25 |
| jam | bzr commit -m "bringing in feature which was base on local" | 00:25 |
| * Jc2k looks | 00:26 | |
| mwhudson | Jc2k: otherwise fine | 00:26 |
| blueyed | jam: in what directory? | 00:26 |
| Jc2k | mwhudson: "which is handy after setting" | 00:26 |
| Jc2k | after-midnight-fail | 00:26 |
| mwhudson | Jc2k: thought so :) | 00:26 |
| jam | blueyed: in what you consider your official mainline, versus main.local | 00:27 |
| blueyed | jam: yes, I see. I'm in the process of trying it already. | 00:27 |
| blueyed | jam: well, too bad I had merged the feature already into the main.local branch.. :D | 00:28 |
| jam | blueyed: bzr merge -r -2 ../main.local | 00:29 |
| blueyed | jam: "Nothing to do." now. | 00:30 |
| jam | blueyed: well *now* that you've already done the other merges | 00:30 |
| blueyed | jam: I'm going the "bzr uncommit" route already, yes. | 00:30 |
| blueyed | jam: well, "bzr merge ../feature/" said "Nothing to do." now still. | 00:32 |
| blueyed | jam: worked it out. thanks! | 00:39 |
| jam | blueyed: great | 00:39 |
| blueyed | ..seems like I've done the revert wrong before (answering "n" or something alike) | 00:40 |
| cj | mwhudson: let me try that | 00:46 |
| cj | $ bzr pull | 00:46 |
| cj | bzr: ERROR: Not a branch: "/opt/src/bzr/mysql-server/.bzr/branch/". | 00:46 |
| mwhudson | cj: :/ | 00:46 |
| mwhudson | maybe you'll have to restart the pull then | 00:47 |
| cj | that's dumb. | 00:47 |
| cj | :) | 00:47 |
| cj | $ bzr branch lp:mysql-server | 00:47 |
| cj | bzr: ERROR: exceptions.KeyError: 'getpwuid(): uid not found: 10069' | 00:47 |
| cj | that was the original exception | 00:47 |
| cj | we've got our users in ldap, not /etc/passwd | 00:48 |
| cj | password | 00:48 |
| mwhudson | er | 00:48 |
| mwhudson | that's extremely strange | 00:49 |
| mwhudson | can you test with a smaller branch | 00:49 |
| james_w | cj: have you ever run "bzr whoami" ? | 00:49 |
| james_w | or indeed "bzr launchpad-login" ? | 00:49 |
| james_w | KeyError is weird though, that's a bug no matter what's going on. A bug report with the relevant section of your ~/.bzr.log would be appreciated. | 00:50 |
| jam | cj, usually you have pam consult ldap | 00:51 |
| jam | but I'm guessing you haven't done anything yet for it to find users | 00:52 |
| jam | your username | 00:52 |
| cj | jam: yeah :) | 00:52 |
| cj | I don't have a launchpad user id configured for bzr | 00:52 |
| cj | how do I do that? :) | 00:52 |
| cj | maybe I should man bzr | 00:53 |
| jam | cj: 'bzr whoami "Joe Foo <joe@foo.com>" | 00:55 |
| jam | bzr launchpad-login username | 00:55 |
| cj | cool. done. | 00:56 |
| cj | ooh, look. SSH authentication and everthin. | 01:01 |
| === kiko is now known as kiko-zzz | ||
| jml | lifeless: where does your extended test result whitepaper hang out? | 01:40 |
| jml | mwhudson: I thought pydoctor also provided a link to source code? | 01:42 |
| mwhudson | jml: only really works with svn & trac currently | 01:42 |
| jml | mwhudson: ahh ok. | 01:43 |
| mwhudson | i think there may even be a bug open about this... | 01:43 |
| beuno | ok, I'm definetly not going to get anywhere today. Closing all vim's | 01:51 |
| beuno | Jc2k, I'll have to pospone the dir-templating bit til tomorrow, when my brain decides to wake up again | 01:51 |
| * jml pimps bzrlib.tests to python-dev | 02:02 | |
| === mw is now known as mw|out | ||
| * igc out for a few hours | 02:42 | |
| lifeless | jml: I don't have an extended test result paper AFAIK | 03:25 |
| jml | lifeless: I ended up linking to the spec on the wiki | 03:25 |
| lifeless | Peng: yes, massive API break landed last night | 03:26 |
| poolie | hello lifeless, etc | 03:30 |
| Peng | lifeless: Yeah, VersionedFiles, right? | 03:32 |
| * spiv -> lunch | 03:32 | |
| lifeless | Peng: yes | 03:33 |
| lifeless | Jc2k: cool | 03:33 |
| lifeless | beuno: cool | 03:33 |
| Peng | Has 1.6's development cycle been longer than usual? | 03:33 |
| Verterok | moin | 03:33 |
| lifeless | Peng: yes, as discussed on the list :P | 03:34 |
| RAOF | Hm. bzr-svn in intrepid seems to be broken with a svn_ra_get_log2 error. Also, the initial branch of bzr & bzr-svn isn't exactly snappy :(. | 03:52 |
| Peng | Does intrepid have svn 1.5? | 03:53 |
| RAOF | Yes. | 03:53 |
| Peng | Yeah, I don't think bzr-svn is entirely compatible with it yet. | 03:54 |
| Peng | At least, 0.4.10. | 03:54 |
| RAOF | Right :( | 03:54 |
| Peng | The current development version of bzr-svn has some major changes (using custom Python bindings for svn), and I dunno if it works. | 03:54 |
| mwhudson | i think there is a 1.5 branch | 03:54 |
| Peng | that too | 03:55 |
| lifeless | RAOF: welcome to intrepid | 03:55 |
| lifeless | RAOF: going where no code has gone before | 03:55 |
| RAOF | :) | 03:55 |
| mwhudson | https://code.edge.launchpad.net/~jelmer/bzr-svn/svn-1.5 <- here | 03:56 |
| RAOF | Why git cloning so much faster than bzr branching? | 03:57 |
| lifeless | because | 03:57 |
| RAOF | Beacause git does more server-side? | 03:58 |
| lifeless | several things | 03:58 |
| lifeless | git is optimised for one project one repo; so it has a full list of heads (hg does this too).compare with the test repo I've got with 13K heads. | 03:59 |
| lifeless | git uses a bidirectional streaming protocol AFAIK, which can't tunnel through http | 03:59 |
| lifeless | (our smart server protocol tunnels through http fine) | 03:59 |
| lifeless | because we haven't fixed some of our bugs | 04:00 |
| lifeless | bzr is not as fast as the bzr design permits it to be | 04:00 |
| RAOF | And because lp is in England, and round-trips kill .au performance? :) | 04:01 |
| lifeless | round trips are a significant factor | 04:01 |
| lifeless | doing a branch over bzr+ssh should stream [mostly], and not with bzr.dev which just had some blunt trauma inflicted on it to sort out infrastructural problems | 04:02 |
| * mwhudson finds himself looking at another savaging of the insides of loggerhead | 05:12 | |
| Peng | Poor Loggerhead. | 05:15 |
| mwhudson | after this one, there really will be hardly any of it left | 05:16 |
| Peng | How large is LH, compared to, like, hgwebdir? | 05:18 |
| Peng | mwhudson: What are you going to savage? | 05:18 |
| mwhudson | um, it's about 5000 lines i think | 05:19 |
| mwhudson | a lot of that is templates though | 05:19 |
| mwhudson | Peng: i don't want loggerhead to keep all the branches it has ever seen open | 05:19 |
| Peng | ./mercurial/hgweb/*.py is 2253 lines. | 05:20 |
| Peng | mwhudson: Oh. That sounds good. That'll help memory usage? | 05:20 |
| mwhudson | Peng: maybe | 05:21 |
| mwhudson | Peng: but file descriptor usage is the pressing issue ... | 05:21 |
| Peng | Oh. | 05:21 |
| mwhudson | (we want loggerhead to access branches over http, it seems having a branch open over http keeps the socket around) | 05:21 |
| Peng | How many descriptors does it keep open per branch? | 05:22 |
| mwhudson | Peng: only 1 it seems | 05:26 |
| mwhudson | alternatively, i can try to rig things to share transports, but i think the threading implications of that scare me off | 05:39 |
| Peng | Ah! Googlebot finally started poking around my Loggerhead instance. :) | 06:00 |
| spiv | Hooray, my net connection came back. | 06:50 |
| spiv | (Although bizarrely the odd spam email still snuck through when nothing else could...) | 06:50 |
| lifeless | markh: how is tbzr installer coming along? | 07:20 |
| lifeless | markh: been chatting with zou_ in #gnash, and he's a windows developer that would love a gui ... | 07:20 |
| zou_ | markh: hi, how is the status of TortoiseBzr now? | 07:29 |
| lifeless | Jc2k: ping | 07:35 |
| lifeless | jam: re sort order in search, relevance >> revno's in my opinion | 07:36 |
| lifeless | jam: (not that relevance is really cooked today, but in principle) | 07:36 |
| RAOF | So, I'm trying to branch bzr.dev. This is proving surprisingly difficult. bzr branch lp:bzr seemed to hang about a 1/4 of a progress bar into "Transferring 0/4", and branching over http from bazaar-vcs.org hung in the same place, ending up with http://pastebin.com/d69baea29 | 07:37 |
| RAOF | bzr 1.5 from Intrepid. | 07:38 |
| lifeless | RAOF: you would appear to have unreliable DNS | 07:38 |
| RAOF | I haven't noticed with anything else, but it's possible. | 07:39 |
| lifeless | Couldn't resolve host 'bazaar-vcs.org' (-2, 'Name or service not known') | 07:40 |
| lifeless | thats coming from below bzr | 07:40 |
| * RAOF goes to find opendns howtos before trying again. | 07:41 | |
| lifeless | RAOF: do you have a local dns server? | 07:42 |
| lifeless | RAOF: if not, its a failed request to your ISP's; just installing a local cache-only server would do | 07:43 |
| RAOF | Hm. Not deliberately. | 07:43 |
| RAOF | Is that hard? | 07:43 |
| lifeless | not at all | 07:43 |
| lifeless | apt-get install bind + edit /etc/resolv.conf :P | 07:44 |
| RAOF | Oh, no. It seems that my router acts as a dns server. So I do have a local dns server. | 07:44 |
| RAOF | It's possible my router is crap, though. | 07:44 |
| matkor | Is there any tool to find out during wich commit some string was deleted from given file ? | 07:45 |
| lifeless | matkor: deleted is a tricky problem :P I want bzr-search to address this; but it doesn't yet. however bzr bisect + grep will do it in optimal iterations | 07:46 |
| igc | back | 07:46 |
| matkor | lifeless: OK. thanks readinf about bzr bisect :) | 07:46 |
| Jc2k | lifeless: pong? | 07:49 |
| lifeless | Jc2k: so, can you ask robtaylor today | 07:49 |
| lifeless | exactly what options he'd give rebase -i | 07:49 |
| lifeless | (give me an example to make work under bzr :P) | 07:50 |
| Jc2k | will do | 07:50 |
| lifeless | also, the gnome header on bzr-mirror.gnome.org - the viewvc page might want to go to loggerhead :) | 07:50 |
| lifeless | ditto the loggerhead ones - why bounce to the svn vc page? | 07:50 |
| Jc2k | lifeless: an example of how i used git rebase -i... | 07:50 |
| Jc2k | i had 2 commits on libgitcore | 07:51 |
| Jc2k | i did git rebase -i HEAD~2 | 07:51 |
| lifeless | while in your tree? | 07:51 |
| Jc2k | yep | 07:51 |
| Jc2k | then i did an "edit" | 07:52 |
| Jc2k | and split those commits into multiple commits | 07:52 |
| lifeless | so HEAD~2 is a revision spec right? | 07:52 |
| Jc2k | yep | 07:52 |
| Jc2k | last 2 revisions | 07:52 |
| lifeless | ok | 07:52 |
| lifeless | so that is 'edit my last two commits kthxbye' ? | 07:53 |
| Jc2k | yep | 07:53 |
| lifeless | ok | 07:53 |
| Jc2k | you get an editor window that lets you chose to "squash", "edit" or "kill" | 07:53 |
| lifeless | feed me defects to work out. I shall do stuff | 07:53 |
| Jc2k | squash turns 2 or more commits into 1 | 07:53 |
| Jc2k | edit stops the replaying and lets you commit a bit at a time | 07:54 |
| Jc2k | then you do git rebase --continue to carry on | 07:54 |
| Jc2k | kill just drops a patch from the replay process | 07:54 |
| lifeless | https://bugs.edge.launchpad.net/bzr-rebase/+bug/243150 | 07:54 |
| ubottu | Launchpad bug 243150 in bzr-rebase "support -i flag as per git" [Undecided,New] | 07:54 |
| Jc2k | oh wait, i made kill up :) | 07:55 |
| Jc2k | thats something bzr can do that git cant then :p | 07:55 |
| lifeless | btw | 07:55 |
| lifeless | ewww at the details | 07:56 |
| lifeless | I'm going to make this nice, not nasty | 07:56 |
| Jc2k | http://pastebin.com/mb8ed0fa | 07:56 |
| Jc2k | is the view that you get in $EDITOR | 07:56 |
| Jc2k | have to go now | 07:56 |
| lifeless | k, thanks and bye | 07:57 |
| === RAOF_ is now known as RAOF | ||
| vila | can anyone tell me why I can't install several ftp servers under Ubuntu (most of them seems to be conflicting with a ftp-server package which appears to be virtual or something) ? | 08:16 |
| vila | Or may be the question should be: how can work-around that since I understand the rationale but want several ftp servers anyway for tests purpose | 08:17 |
| bob2 | have to use dpkg's --force-depends or rebuild the package without the Conflict, I guess | 08:17 |
| lifeless | vila: file bugs; there are valid use cases for concurrent installs of any server that can run on an alternate port | 08:18 |
| vila | lifeless: bugs against packages or against the distro ? | 08:19 |
| vila | bob2: what are the risks of my dpkg getting fubared in the long run ? | 08:19 |
| lifeless | vila: packages I think | 08:19 |
| vila | lifeless: k | 08:20 |
| lifeless | vila: they probably all install /usr/sbin/ftpd or similar | 08:20 |
| lifeless | vila: so highly likely that they genuinely can't coexist | 08:20 |
| vila | lifeless: good point, I'll investigate | 08:20 |
| lifeless | vila: you could run up N VM's though, with one server each | 08:21 |
| vila | lifeless: that's an idea but it doesn't fit my needs... or may be it will but will require to much admin. The aim is to inject these servers into bzr test suite without requiring too much admin privileges. | 08:23 |
| bob2 | aside from root to install the packages ;) | 08:23 |
| vila | bob2: a couple of clicks away with synaptic, should fit :) | 08:24 |
| vila | I'm trying to find the right balance here, the aim is to help testing not becoming an expert in ftp server admin :-/ | 08:24 |
| vila | I nearly got it for vsftpd but that beast is too secured :) I can't get chmod authorized for anonymous users :) | 08:25 |
| lifeless | jelmer: bzr selftest rebase fails 7 tests | 08:28 |
| lifeless | mm, one is bogus | 08:28 |
| * lifeless fixes local edit | 08:28 | |
| lifeless | jelmer: 2 failures | 08:30 |
| vila | hmm, vsftpd and wu-ftpd conflicts on /etc/ftpusers, nice diagnostic lifeless | 08:35 |
| jelmer | lifeless: Oh, I only get 2 failures | 08:35 |
| jelmer | lifeless: Can you pastebin the output? | 08:36 |
| === prateeksaxena is now known as prtk | ||
| lifeless | jelmer: its bzrlib.plugins.rebase.test_rebase.TestReplayWorkingtree.test_multiple and | 08:38 |
| lifeless | bzrlib.plugins.rebase.test_blackbox.TestRebaseSimple.test_pending_merges | 08:39 |
| jelmer | lifeless: Yep, those are the ones | 08:42 |
| jelmer | lifeless: That's only two :-) | 08:42 |
| lifeless | dang, pysizer and heapy are not packaged :( | 08:42 |
| lifeless | 17:28 * lifeless fixes local edit | 08:42 |
| lifeless | 17:30 < lifeless> jelmer: 2 failures | 08:42 |
| jelmer | ah, never mind me | 08:42 |
| lifeless | :) | 08:43 |
| lifeless | I'm implementing -i support | 08:43 |
| lifeless | any tips or requests about how its done? or just do it and send you a patch ? | 08:43 |
| lifeless | jelmer: what is replace_map too - is the idea that you precalculate what things are being done? | 08:50 |
| lifeless | jelmer: (rather than e.g. recording what has been done then using the result when you need a merge etc?) | 08:50 |
| jelmer | lifeless: Yes | 08:51 |
| jelmer | lifeless: This shows a bit of rebase' background, since it was written as svn-upgrade backend | 08:51 |
| lifeless | so what I appear to need is: | 08:52 |
| lifeless | for combining, to just skip a revision | 08:53 |
| lifeless | and output a different one | 08:53 |
| lifeless | this will propogate; I guess I can write tests to update a map thusly | 08:53 |
| lifeless | to split, I need to insert one, this should be kindof easy | 08:53 |
| lifeless | also, the user needs the ability to edit stuff | 08:53 |
| lifeless | as in to choose operations | 08:54 |
| lifeless | I kind of like the shelve interactive operaiton | 08:54 |
| lifeless | but there is the git style open-an-editor option too | 08:54 |
| lifeless | jelmer: ^ | 08:55 |
| jelmer | re | 08:56 |
| lifeless | spiv: have you used heapy/guppy? | 08:56 |
| jelmer | lifeless: Yeah, updating a map makes sense | 08:56 |
| jelmer | lifeless: Something else that would make sense is creating a new class | 08:57 |
| lifeless | jelmer: for editing, we could make the plan have an editable area, or use a separate file to list what is pending (and thus what can be controlled) | 08:57 |
| jelmer | and using that rather a dictionary | 08:57 |
| jelmer | lifeless: gmta | 08:58 |
| jelmer | lifeless: I think we're both saying the same thing but you're talking about the file format and I'm talking about the data type it's read into | 08:58 |
| lifeless | jelmer: well I'm thinking UI largely; rebasing including merges clearly needs to rebase the side branches as well and so on | 08:59 |
| jelmer | "side branches" ? | 09:00 |
| lifeless | if I rebase three commits in this branch | 09:00 |
| lifeless | and that includes a merge from another branch that is also not in the target i'm rebasing onto | 09:00 |
| lifeless | surely I need to rebase them too ? | 09:00 |
| jelmer | ahh, ok | 09:01 |
| jelmer | true | 09:01 |
| lifeless | but I'm not trying to fix any flaws in rebase :) | 09:01 |
| lifeless | just to teach it -i | 09:02 |
| jelmer | heh | 09:03 |
| lifeless | so it sounds like my plan is: | 09:03 |
| lifeless | -i should generate the plan and not execure | 09:03 |
| lifeless | there should be some sort of edit-plan call | 09:03 |
| lifeless | after which the plan is adjusted as needed to accomodate | 09:03 |
| lifeless | refactor stuff so there is an 'execute_plan' method | 09:04 |
| lifeless | which will know how to drop commits, and return to the shell to edit commits that are selected to edit | 09:04 |
| lifeless | does that sound complete/sufficient? | 09:04 |
| jelmer | yeah | 09:06 |
| jelmer | Sorry for the slow responses, I'm not entirely here | 09:06 |
| * lifeless pictures partial-jelmer | 09:06 | |
| LarstiQ | is that a derivative? | 09:11 |
| LarstiQ | or have I been doing too much calculus lately | 09:11 |
| LarstiQ | lifeless, jelmer: moin, btw :) | 09:12 |
| lifeless | moin :) | 09:12 |
| lifeless | poolie: I'm done for the day, rebase -i is doable tomorrow I think | 09:17 |
| zou_ | lifeless: there? | 09:40 |
| zou_ | http://rafb.net/p/qfCzZn85.html | 09:41 |
| lifeless | zou_: was there a previous operation you interrupted/had an error of? | 09:42 |
| zou_ | yes, I did a "bzr commit --local" and there was too much prints, then I used "ctrl + c" stopped the process. | 09:43 |
| lifeless | bzr break-lock | 09:43 |
| matkor | and better leave commit to finish ... you can always revert/uncommit it ... | 09:43 |
| lifeless | ctrl-c _should_ be safe but its possible you got it just the wrong point | 09:44 |
| zou_ | thanks, it's fine now. | 09:46 |
| zou_ | bzr commit --local; | 09:47 |
| zou_ | Now there are too much modifed files than I expect. what could be the problem? | 09:48 |
| zou_ | some are binary files | 09:48 |
| matkor | zou_: so check what is different in files you expect being utouched | 09:49 |
| lifeless | zou_: bzr st/bzr diff can show you the changes | 09:49 |
| zou_ | bzr commit --local >> output.txt | 09:50 |
| zou_ | got message: "Saving data locally - Stage 2/5Vim: Warning: Output is not to a termianl" | 09:51 |
| zou_ | then bzr seems stops after that message. | 09:51 |
| james_w | you've got a vim process open waiting to receive your commit message. You can use "-m <message>" to stop it from opening an editor. | 09:53 |
| zou_ | then I need to interrupt bzr again with "ctrl + c" | 09:59 |
| zou_ | sorry, "ctrl + z" | 10:00 |
| lifeless | zou_: do you have a vim window popped up somewhere? | 10:00 |
| lifeless | zou_: exporting EDITOR="vim -X" might help (or whatever the similar thing is in windows) | 10:00 |
| zou_ | I am using cygwin on windows. | 10:01 |
| zou_ | message: "=== modifed file 'xxxxxx/tests.png' (properties changed: +x to -x)" | 10:05 |
| === timchen1` is now known as nasloc__ | ||
| zou_ | what does "+x to -x" mean? | 10:05 |
| matkor | zou_: executable bit ? | 10:06 |
| matkor | zou_: are you under linux ? | 10:06 |
| zou_ | I am using Cygwin(a linux emulator) under windows. | 10:06 |
| matkor | ah cygwin .. so I do not know how it works with executable bit | 10:07 |
| zou_ | what is " executable bit"? | 10:07 |
| === Mathilda is now known as uws | ||
| zou_ | "===modefied file 'backend/render_handler_agg.h' (properties changed : +x to -x)" | 10:09 |
| zou_ | render_handler_agg.h is a text file. | 10:09 |
| zou_ | bzr -m "my message" commit --local | 10:12 |
| luks | did you checkout the branch with native bzr and committing using cygwin bzr? | 10:12 |
| zou_ | got: bzr: ERROR: unknow command "-m" | 10:12 |
| matkor | bzr commit -m "my mes" --local | 10:12 |
| luks | you want bzr commit -m "..." | 10:12 |
| eMBee | he looks german enough | 10:13 |
| eMBee | ooops | 10:13 |
| eMBee | wrong channel | 10:13 |
| zou_ | bzr commit -m "my message" --local <---- this works, thanks. | 10:14 |
| zou_ | luks: I checked out the branch with cygwin bzr. | 10:20 |
| zou_ | Now I'v finished "bzr commit --local". | 10:21 |
| zou_ | How do I check the difference between my local source and the source on the other server? | 10:22 |
| matkor | bzr diff <remote_branch> | 10:23 |
| matkor | or bzr missing | 10:23 |
| zou_ | If I don't want to type the " <remote_branch>", do I have a way to show the diff between my local source and the source from the branch I checked out? | 10:25 |
| zou_ | sorry, I am still thinking bzr in a cvs way. | 10:26 |
| mlh | zou_: ctrl-Z doesn't stop a program, it merely suspends it | 10:29 |
| zou_ | mlh: thanks. | 10:29 |
| mlh | you're welcome | 10:29 |
| mlh | weird things could happen if you have multiple bzr's suspended | 10:30 |
| zou_ | btw, I really need a GUI-based bzr on windows. | 10:32 |
| zou_ | I am not used to command lines. | 10:32 |
| matkor | zou_: so bzr diff/missing <local_path> | 10:33 |
| zou_ | matkor: there are two type of diffs after a local change IIRC: (1)difference within local source; (2)difference between local source and remote source. right? | 10:37 |
| matkor | let's name them branch | 10:37 |
| matkor | so there are differences between branches and branches vs working trees | 10:38 |
| matkor | so yours (1) is diff working tree vs branch (of same woriking tree) | 10:38 |
| matkor | and (2) is diff between branches | 10:39 |
| zou_ | ok, clear. | 10:39 |
| zou_ | then command "bzr diff" gives (1)? | 10:40 |
| zou_ | and command "bzr diff remote_branch" gives (2)? | 10:40 |
| matkor | ad (1) - yes | 10:40 |
| matkor | ad (2) - not sure - I am not using diff with uncommited working trees ... I suspect it shows working tree vs remote branch but not sure | 10:41 |
| matkor | oh seems one can't diff to other place than local | 10:43 |
| zou_ | Are my local branch and the remote branch always two different branches in concept, or they can be the same one? | 10:43 |
| luks | you can | 10:43 |
| luks | see bzr help diff | 10:43 |
| luks | especially the --old option | 10:43 |
| awilkins_ | jelmer: Does the bzz-gtk bundle buggy supercede patches automatically? If so which criteria does it use? | 10:44 |
| awilkins_ | zou_: Olive works on windows, but isn't mature yet | 10:45 |
| awilkins_ | zou_: And you can bind your local branch to a remote one ; they are still distinct branches, but they are much closer | 10:46 |
| zou_ | I used TortoiseCVS a lot, so I would probably choose TortoiseBzr. | 10:47 |
| awilkins_ | zou_: Or you can ``bzr checkout --lightweight`` which makes no local branch, just a working copy. | 10:47 |
| awilkins_ | zou_: AFAIK TortoiseBZR is Olive with some shell extensions and I'm not sure how mature that is either. | 10:47 |
| awilkins_ | zou_: I'm a longtime user of TSVN and I'd like to see the bzr GUI on Windows that mature, but I find that CLI with some of the commands from bzr-gtk is pretty ok. | 10:48 |
| zou_ | awilkins_: right, I haven't install either of them. Both of them require you to download and install lots of other things. | 10:48 |
| zou_ | I just need a binary executable file. | 10:49 |
| awilkins_ | zou_: There's a prepacked installer for bzr-gtk that has most of the deps in it. | 10:49 |
| awilkins_ | http://d5190871.u44.websitesource.net/bzr-gtk/ | 10:49 |
| luks | I don't think it will work with cygwin python though | 10:50 |
| awilkins_ | Ah, I didn't catch that zou_ was running cygwin python | 10:50 |
| zou_ | if it works on my window, I don't need the cygwin version:) | 10:50 |
| zou_ | window/Windows | 10:50 |
| awilkins_ | zou_: I've been running it on windows since ...ooo , at least all the way back to 1.2 (last tuesday :-p ) | 10:51 |
| zou_ | thanks, downloading now. | 10:53 |
| zou_ | <awilkins_> zou_: Or you can ``bzr checkout --lightweight`` which makes no local branch, just a working copy. | 10:54 |
| zou_ | so "bzr commit --local" doesn't make sense with this working copy? | 10:55 |
| awilkins_ | zou_: --local is for use when you have a bound branch but don't want to push your commit to the master branch immediately | 10:57 |
| zou_ | yes, I think I understand that. | 11:00 |
| zou_ | ah, a new name "bound branch". | 11:00 |
| awilkins_ | "attached to a remote branch to which it pushes all commits" | 11:02 |
| zou_ | that's exactly what I need. At the first stage, I just want to my local bzr rep. works exactly like my old cvs rep. | 11:03 |
| zou_ | awilkins: how do I use the bzr-gtk? I'v installed it. | 11:04 |
| zou_ | where could I expect the GUI? | 11:04 |
| awilkins_ | zou_: It adds some commands to your bzr command line ; for the GUI thing, ``bzr olive`` | 11:04 |
| awilkins_ | zou_: I tend to just use the command line with some of the sub-commands | 11:05 |
| awilkins_ | like ``bzr gconflicts`` ``bzr viz`` ``bzr gdiff`` | 11:05 |
| zou_ | I see some *.py files are installed to ..../bazaar/2.0/plugins/gtk dir under my Windows. | 11:09 |
| zou_ | Do I expect to compile these *.py file to produce a executable file? | 11:09 |
| jelmer | awilkins_, hi | 11:10 |
| AfC | Hm. If one does `bzr merge -r X..Y` (or uses `bzr rebase`, which I am slowly gathering is the same thing), one "loses history" right? Which can lead to conflicts later, which is, as I understand it, why we don't encourage people to rebase. Is that right? | 11:17 |
| AfC | (this should probably be an email to the list, but feel free to poke at me now) | 11:17 |
| jelmer | awilkins_, No, should only be if it was merged | 11:19 |
| AfC | If so, then would the following clean matters up? 1) Create the nice orthogonal patch with one or more `bzr merge -r X..Y --force` and or `bzr merge --force ../path/to/file/in/other/branch` | 11:19 |
| jelmer | AfC: rebae isn't the same as "bzr merge -r X..Y" | 11:19 |
| AfC | then 2) bzr commit to create a new revision, then 3) immediately merge that new orthogonal half ass cherry pick revision _back_ into the branch that sourced it. | 11:20 |
| zou_ | hmmm, "bzr olive" got a runtime error. I'll try tomorrow. Thanks awilkins. | 11:20 |
| AfC | Would that not remove the problem of (some time later) having the cherry pick / orthogonal / rebase / whatever come back to visit you causing problems? | 11:20 |
| AfC | jelmer: [I have been given to understand here that bzr rebase is, under the hood, nothing more than a sequence of bzr merge -r N..N+1 and copying the commit message and forcing you to resolve conflicts] | 11:21 |
| jelmer | AfC: yeah, that's how it's implemented at the moment - as a series of cherrypicks | 11:21 |
| jelmer | AfC: merge -rX..Y does a single cherrypick | 11:22 |
| AfC | jelmer: [but I'm not saying I know what I'm talking about. More to the point, Robert long ago advised me to use the `bzr merge -r X..Y [--force]` form to cherry pick orthogonal patches off of feature branches. | 11:22 |
| AfC | jelmer: since then I have largely been trying to understand what the benefits/costs/implications of doing so are] | 11:22 |
| AfC | jelmer: (right) | 11:22 |
| AfC | ok, so back to my suggestion: | 11:23 |
| AfC | if, having just done this nasty operation (be it X..Y or {N..N+1}*) | 11:23 |
| AfC | would immediately (ie, while you still have control of the tip of the original branch and nothing else has yet happened to it) | 11:24 |
| luks | so you just want to merge some branch, and not include the original revisions? | 11:24 |
| AfC | merging that new branch with the evil nastiness on it back into the feature branch allow you to dismiss any conflicts and get back to work without fear? | 11:24 |
| AfC | luks: the scenario I have is a lot of people working on long long LONG feature branches. After a while, they want to start contributing bits of it. | 11:25 |
| AfC | luks: *yes* I can teach them how to make orthogonal patches (I've blogged extensively about this, in fact) | 11:25 |
| luks | well, the answer for that is they are doing it wrong :) | 11:25 |
| AfC | luks: but the problem comes when they continue on ... of course they don't want the very act of making a contribution upstream to screw them up when they later pull their own work back | 11:26 |
| AfC | luks: [I hope you're trolling, in which case I return your :) with a good hearted {grin}. But otherwise, I really have to tell you that the scenario I am describing is *very* common. Not all languages, environments, and projects are suited to micro branches where each little feature is worked on in complete isolation and you have no dependence on a branch containing all of your work] | 11:27 |
| luks | no, I'm not trolling | 11:28 |
| AfC | {sigh} | 11:28 |
| AfC | Then what I said is honest, and from the bottom of my heart. | 11:28 |
| luks | if you have a feature branch, with more than one feature, it's no longer a feature branch | 11:28 |
| AfC | People really do work on long feature branches. | 11:28 |
| AfC | Ok, call it whatever you want then. | 11:28 |
| luks | yes, but there is a big difference | 11:29 |
| luks | if you have small feature branches, and you merge them to your "fork" branch it's fine | 11:29 |
| luks | because the upstream can easily merge the feature branches separately | 11:30 |
| AfC | Ok. Whatever you want to call the opposite of small isolated pieces of work | 11:30 |
| AfC | "long line of development" | 11:30 |
| luks | there is really no way to completely avoid conflicts if you start duplicating revisions via cherry picking | 11:31 |
| james_w | AfC: as I understand it conflicts should be minimal if the act of cherrypicking doesn't change the code much from what's in the long-lived branch. | 11:32 |
| AfC | james_w: that's sort what I'm figuring | 11:33 |
| james_w | obviously if mainline makes big changes in the same areas as the long-lived branch then you get conflicts. | 11:33 |
| AfC | james_w: I never thought of this before because one doesn't normally "no-op" (sic) merge into oneself (sic) | 11:33 |
| AfC | james_w: sure | 11:33 |
| james_w | though I guess you are asking if there is anyway bzr could be smarter when merging back as some of the conflict resolution has presumably been done. | 11:34 |
| AfC | james_w: which would probably arise anyway | 11:34 |
| AfC | james_w: well, really, I'm still bashing my way down workaround wobble | 11:34 |
| AfC | james_w: as is anyone who is a Darcs refugee still struggling to cope with the fact that revisions aren't the diffs they look like. | 11:35 |
| AfC | james_w: a specific technical question is "how much information is preserved if I cherry pick" to which there seem to be varying opinions. I tired to figure it out from the sources, but I'm not smart enough I'm afraid. | 11:36 |
| james_w | not a lot I believe, I think the operation is currently equivalent to diff + patch | 11:36 |
| james_w | so all the merging that is done is done purely on the text level. | 11:37 |
| AfC | james_w: we discussed it a bit in London; Robert was talking about storing origins (file or rev) in revision properties as a possible first-hack approach. But it was all in the future tense, which seemed a bit discouraging. | 11:37 |
| james_w | you can store cherrypick meta-data, but it's not exactly clear what to do with that, or at least how to do it in a way that doesn't cripple performance. | 11:38 |
| AfC | james_w: yeah. Shame, though. | 11:38 |
| james_w | yeah, you could stick it in revision properties, but the problem then is using the information. Let me find you a post on the subject. | 11:38 |
| AfC | james_w: [it just seems really counter intuitive that I can create a revision that, to all outside appearances, looks exactly like one (or a small set of) revisions from a branch, | 11:39 |
| AfC | only to have those new revisions come back some other day to not merge cleanly because they aren't the same. I understand the technology now, but socially I still struggle with it. Or, more to the point, I struggle to explain it to people, which is always a good marker that you don't really know what you're talking about.] | 11:39 |
| AfC | Anyway, I'll give the "immediate merge back" thing a try in some of my work | 11:40 |
| james_w | yeah, there's a few issues that make it difficult to do, but not doing it also makes it difficult | 11:40 |
| AfC | (me being one of these evil people with long running branches) | 11:40 |
| james_w | http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/33962/ | 11:42 |
| AfC | That looks familiar :) | 11:49 |
| Pilky | wow, what did the dev team do in 1.6? Just ran 1.6b2 through my unit test suite for BazaarX and it ran 40% faster than 1.5 | 12:02 |
| === kiko__ is now known as kiko | ||
| lifeless | Pilky: is that good? | 12:10 |
| Pilky | well the average run times of the test suite was 22.19s for bzr 1.3, 23.55 for 1.4, 22.92 for 1.5 and now 16.43 for 1.6b2 | 12:11 |
| lifeless | Pilky: this is something that uses bzrlib ? | 12:12 |
| Pilky | no | 12:12 |
| lifeless | oh, bzr's test suite itself ? | 12:13 |
| Pilky | no, it's for my GUI client for OS X | 12:13 |
| lifeless | ah, to me thats something that uses bzrlib: P | 12:13 |
| Pilky | heh, well I'm using an NSTask to call via the command line, I believe you need to know python to use bzrlib, right? | 12:14 |
| lifeless | directly sure | 12:14 |
| lifeless | you're using it indirectly, not a big distinction I thnk | 12:14 |
| Pilky | here's the graphs for the tests if you're interested: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Test_Graphs_1.6b2-20080626-121643.png | 12:17 |
| lifeless | Pilky: I'd be interested in seeing what bzr.dev as of today does | 12:17 |
| Pilky | has there been a lot more optimisation since b2? | 12:17 |
| lifeless | massive api change yesterday | 12:18 |
| lifeless | 6 weeks of work or so | 12:18 |
| Pilky | well I'll branch it, install it and run the tests | 12:18 |
| lifeless | thanks | 12:20 |
| === prateeksaxena is now known as prtk | ||
| Pilky | lifeless: completes in 17.08s | 12:31 |
| Pilky | here's the graphs: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png | 12:31 |
| guilhembi | jam: hello! I posted comments in the issue. | 12:31 |
| lifeless | Pilky: thanks! | 12:31 |
| Pilky | still a huge improvement over 1.5 but some things are a bit slower than b2 | 12:31 |
| Pilky | want me to write up a brief description of each test, so you know what each one means? | 12:33 |
| jelmer | Pilky: how did you generate those fancy graphs? | 12:34 |
| Pilky | Numbers (iWork 08) | 12:34 |
| Pilky | I'm just running my tests through 3 times and putting them in a spreadsheet, then graphing the average | 12:35 |
| Pilky | jelmer, lifeless: Here's a quick description of what each test does: http://dropbox.mcubedsw.com/bazaarxtests.txt | 12:45 |
| \sh | moins | 12:48 |
| \sh | guys, how do I "branch" from launchpad.net via eclipse-bzr plugin? neither http://bazaar.launchpad.net/<branch loc> nor bzr+ssh://... works | 12:48 |
| james_w | hi \sh | 12:49 |
| james_w | I'm not familiar with eclipse-bzr, do you get some sort of error? | 12:49 |
| \sh | james_w: yes :) | 12:49 |
| \sh | Command.executing | 12:49 |
| \sh | Command.error | 12:49 |
| \sh | bzr: ERROR: Invalid url supplied to transport: "Host empty in: http:///bazaar.launchpad.net/~shermann/leonov/leonov-kde-mdi-style/" | 12:49 |
| \sh | bzr: ERROR: Invalid url supplied to transport: "Host empty in: http:///bazaar.launchpad.net/~shermann/leonov/leonov-kde-mdi-style/" | 12:49 |
| \sh | something like this comes into the console of eclipse | 12:50 |
| james_w | http:/// looks wrong | 12:50 |
| \sh | yepp :)= | 12:50 |
| james_w | urlsplit will make that ('http:', '', ...) | 12:50 |
| james_w | I assume that you are not entering that. | 12:50 |
| james_w | can you try "lp:~shermann/leonov/leonov-kde-mdi-style", it may work, it may not. | 12:52 |
| \sh | it doesn't work :) | 12:55 |
| \sh | I tried that already...the eclipse-bzr plugin url check doesn't like that style :) | 12:55 |
| \sh | and you are right: http:/// I didn't enter that | 12:56 |
| james_w | worth a go. | 12:56 |
| james_w | it smells like a bug to me, but I'm a bit stuck about how to track it down. | 12:56 |
| \sh | I'll file a bug :) | 12:57 |
| === thekorn_ is now known as thekorn | ||
| lifeless | Pilky: that would be nice | 13:00 |
| Peng | Haha, LH is using 125 MB of RAM now. | 13:06 |
| Peng | Go Googlebot! | 13:06 |
| * Jc2k is getting googlebotted too | 13:09 | |
| Pilky | lifeless: the link is above | 13:11 |
| Peng | If my Loggerhead instance ever gets hit by an abusive bot that downloads pages as fast as it can, my VPS will be swapping to death in 10 minutes. :\ | 13:14 |
| Peng | (Actually, its RAM usage is hardly growing now. Googlebot probably already has every branch open, and has already downloaded several large pages.) | 13:20 |
| Peng | I never configured Loggerhead to store its logs. | 13:21 |
| Peng | I should probably RTFM, but how do you do that with serve-branches.py? | 13:22 |
| ToyKeeper | BTW, after branch stacking is on launchpad, will that reduce the amount of data users need to upload to publish a branch? | 13:34 |
| Peng | That's the idea. | 13:34 |
| Peng | I have LP mirror my branches from my own server, so I'm not sure it'll help me though. | 13:35 |
| Pilky | do any other VCSs have anything like stacked branches | 13:35 |
| ToyKeeper | 'k. So, they download a thousand revisions, make a change, and when they publish they only need to upload their new revisions? | 13:35 |
| Peng | Something like that. | 13:36 |
| ToyKeeper | I'm looking forward to it. :) | 13:37 |
| lifeless | Pilky: I'll peek tomorrow. its waay bedtime now | 13:38 |
| Pilky | heh, ok | 13:38 |
| LarstiQ | jelmer: is/should it be supported to push completely unrelated revisions into a new branch in svn? init, hack, hack, push svnrepo/newpath/foo | 13:38 |
| LarstiQ | night lifeless | 13:38 |
| Peng | Whee, Googlebot found its way to a LH URL that tracebacks with a NoSuchRevision in tree None. :) URL: http://snurl.com/2p8ye Log: http://paste.pocoo.org/show/77818/ | 13:38 |
| Peng | (LH trunk, bzr.dev.) | 13:38 |
| * Peng disappears. | 13:39 | |
| ToyKeeper | Heh, at least googlebot didn't click all the "delete" buttons. :) | 13:40 |
| Peng | Ooooh. | 13:40 |
| Peng | LH is using my system bzr, not bzr.dev. Go sys.path. | 13:40 |
| Peng | Probably for the best, since VersionedFiles would probably break it anyway. | 13:40 |
| Peng | ToyKeeper: Heh. | 13:40 |
| Peng | God, there are probably a couple hundred thousand pages. | 13:42 |
| Peng | This is the first time I've ever had enough "interesting" content for Googlebot to make more than 4 requests per day. :> | 13:42 |
| spiv | lifeless: I have used heapy/guppy a little bit. The remember the documentation wasn't particularly good. | 14:03 |
| spiv | It seem to recall it working ok. | 14:04 |
| VSpike | I can't quit seem to get the syntax - how do I find out where and how two branches diverge? | 14:15 |
| lamalex | Hey guys, bzr is telling me I cant branch because of my public key, shouldn't I be able to branch anywhere? | 14:17 |
| awilkins_ | lamalex: Are you trying to branch into launchpad ? | 14:17 |
| lamalex | branch from | 14:18 |
| awilkins_ | lamalex: You've set a launchpad login? | 14:18 |
| james_w | VSpike: "bzr missing" is useful for this. | 14:18 |
| lamalex | might have | 14:18 |
| === awilkins_ is now known as awilkins | ||
| awilkins | lamalex: Have you uploaded a public key? | 14:18 |
| james_w | VSpike: or do you want to know the last revision that both share? | 14:19 |
| lamalex | yeah | 14:19 |
| lamalex | but not from this box | 14:19 |
| lamalex | is there a way to logout? | 14:19 |
| awilkins | Do you have the private key available to you now? | 14:19 |
| lamalex | no | 14:19 |
| VSpike | james_w: yes, that would be excellent | 14:20 |
| james_w | VSpike: "bzr find-merge-base" I think | 14:20 |
| VSpike | james_w: ah yeah, missing is good too | 14:20 |
| VSpike | thanks | 14:20 |
| awilkins | lamalex: Go to your bazaar.conf file and remove the "launchpad_username" setting | 14:20 |
| james_w | lamalex: use a http:// url, rather than an lp: one, or delete the launchpad line from ~/.bazaar/bazaar.conf | 14:20 |
| lamalex | thanks | 14:21 |
| jam | spiv: I used heapy/guppy, except it didn't work on 64-bit or Mac OS X, which were the 2 platforms I was using the most at the time :) | 14:24 |
| jam | Pilky: glad to hear about the performance improvements | 14:24 |
| jam | and at least commit is faster yet in bzr.dev | 14:25 |
| Pilky | yeah | 14:25 |
| jam | I'm not sure what the other speedups are. Given the raw values (0.88 => 0.52s for create repo) I'm tempted to say it is an import thing | 14:25 |
| jam | but in general, we seem faster at finding and opening branches | 14:25 |
| jam | I've done a few performance improvements, but I wouldn't have expected to see it effect this many places. | 14:27 |
| jam | Pilky: out of curiosity, are you running with plugins in your 1.3/1.4/1.5 branches but without plugins for 1.6? | 14:27 |
| jam | Just something to think about | 14:27 |
| Pilky | nope, no plugins afaik, though I installed 1.3/1.4/1.5 with the OS X installer but 1.6 from source | 14:27 |
| Pilky | and I don't think I've changed anything on my laptop which is where I ran all the other tests | 14:28 |
| Pilky | I mean, there's always the possibility it could be something in the setup that's different that I've missed | 14:29 |
| jam | Pilky: well, you could run the old benchmarks again :) | 14:29 |
| james_w | perhaps the pyrex helpers. | 14:30 |
| Pilky | yeah, I'll try them again... it could be something stupid and I'm using numbers from this desktop or something | 14:30 |
| jam | james_w: that *shouldn't* effect the "open an existing repository" tests | 14:30 |
| Pilky | I'll try doing them all from source | 14:30 |
| jam | I'd like to think we really are improving :) | 14:30 |
| jam | Pilky: just make sure to run 'make' first | 14:31 |
| Pilky | hmm, I've just been doing sudo pythong setup.py install | 14:31 |
| Pilky | *python | 14:31 |
| jam | Pilky: that will build the extensions | 14:35 |
| jam | If you are going to be running from source, 'make' will run the right stuff for you | 14:35 |
| jam | or you can do | 14:35 |
| jam | python setup.py build_ext -i | 14:35 |
| jam | yourself | 14:35 |
| jam | (build extensions --in-place) | 14:35 |
| * Pilky sighs | 14:43 | |
| Pilky | this is why I dislike the command line, everything seems to be way too complicated :P | 14:43 |
| Pilky | I'll just run the OS X installer for the previous versions, much easier | 14:44 |
| Pilky | ah... seems I may have run my previous tests on my iMac... | 14:47 |
| Pilky | should really have checked that before hand | 14:47 |
| Pilky | well that buggers everything up then... | 14:49 |
| Pilky | I was sure I ran everything on my MacBook, because I was already on 1.5 on my iMac... | 14:49 |
| Pilky | jam: guess there isn't a 40% speed increase then | 14:52 |
| jam | :( | 14:52 |
| markh | lazy question: what is the best way to see what remains to be pushed (somewhat similar to the mercurial 'outgoing' command)? | 14:52 |
| guilhembi | jam: hello! I don't know if you saw that: I posted comments in the issue. | 14:52 |
| Pilky | I could've sworn I ran them on my MacBook though, because I took it back to 1.3 | 14:52 |
| guilhembi | markh: "bzr missing" maybe? | 14:52 |
| markh | guilhembi: thanks - that looks right1 | 14:54 |
| jam | guilhembi: I replied, but I don't know if you replied to my reply :) | 14:54 |
| guilhembi | markh: note, "bzr missing" shows merge revisions, but not what they merged. There's a bug report for that. | 14:54 |
| guilhembi | So, when you see a revision in the output, it may actually contain many revisions. | 14:54 |
| * markh had one upset pidgin! | 14:55 | |
| guilhembi | jam: ok, now I read it. When you write: | 14:56 |
| guilhembi | "2) Simple sorting of the parents wasn't enough" etc, are you talking about the "bzr --weave" breakage? | 14:56 |
| jam | guilhembi: just referencing what I thought would fix it a post or 2 ago | 14:57 |
| jam | the --weave breakage is probably something else | 14:57 |
| jam | since you don't have my sorting-parents fix yet (3519) | 14:57 |
| guilhembi | jam: mmm the sorting-parents seems to be a fix for a problem which I don't really know. I see your older post saying "My current guess is that I need to look a bit closer about left-versus-right parents"; | 15:01 |
| guilhembi | jam: is it that you're trying to fix --weave so that --full-weave isn't needed? | 15:01 |
| jam | guilhembi: yes | 15:02 |
| guilhembi | jam: ahah. But "merge --weave; remerge --full-weave" was sexy enough for me, I'd say. | 15:03 |
| guilhembi | Hi jaypipes | 15:03 |
| jaypipes | guilhembi: hi! | 15:03 |
| guilhembi | jaypipes: every time I see your name, I think about its French translation (pipes->tuyaux), which could be interpreted as Jay-the-tips (in the sense of a guy who has good tips to share). | 15:04 |
| jam | guilhembi: I'd rather '--weave' Just Worked (tm), there is no conceptual reason it shouldn't | 15:05 |
| AfC | james_w, luks: thanks for chatting earlier. Good night. | 15:05 |
| jaypipes | guilhembi: hehe. Funnily, with our onboarding at Sun, many people thought JPipes was a Java project... ;) | 15:05 |
| guilhembi | jam: ok. I worry a bit of the time it'll take to get --weave to just work, vs time to fix path conflicts, .OTHER etc. Maybe I'm too worried. | 15:06 |
| guilhembi | Java Pipes... | 15:06 |
| === mw|out is now known as mw | ||
| jam | guilhembi: can you quickly describe how "--weave" was broken? If only giving me a single file example so I can track it down | 15:15 |
| jam | I can do it myself, but if you have it available ... | 15:16 |
| guilhembi | digging | 15:16 |
| guilhembi | ah, if only Konsole showed the last million lines and not a thousand or so... | 15:17 |
| guilhembi | jam: not available; you'd need to run "bzr --weave" on your two branches | 15:18 |
| guilhembi | and see the 208 conflicts. | 15:18 |
| guilhembi | should take ~4 minutes | 15:18 |
| fjw | hello? | 15:28 |
| james_w | hi fjw | 15:29 |
| fjw | Hello, I had a specific prolem with bazaar earlier and was wondering where I could get info | 15:37 |
| fjw | The problem I had was that a commit failed due to running out of disk space. It failed at: "Saving data locally [stage 2/5]". It took me a couple of attempts before I figured out the problem. | 15:37 |
| fjw | Afterwards I checked the repository and it looked like the repository was undamaged, and the commit just didn't complete. I cleared up some disk space and also ran a "bzr pack" | 15:37 |
| fjw | However, after trying another commit the repository grew by a large amount. It was around 112MB, was multiplying in size. After a while it was over 500MB. The commit had only included a couple of small text files. | 15:37 |
| fjw | After investigating I found that there were large files in .bzr/repository/upload and .bzr/repository/pack-obsolete | 15:37 |
| Peng | fjw: Packing saves a copy of any packs it removes in obsolete_packs. So you doubled your disk space to save a couple KB. :P | 15:38 |
| fjw | I figure that some of these may be related to failed checkins and could be deleted. Is there a proper way to do this? | 15:38 |
| fjw | Ah I see. So it is safe to delete the contents of pack-obsolete? And is there an appropriate command to purge this or is it a case of just wiping that dir? | 15:38 |
| Peng | fjw: upload is where stuff that's being committed or uploaded is put. Since the commit exited, you can just nuke the files in it. | 15:39 |
| fjw | ok thanks for your help | 15:39 |
| Peng | fjw: Well, the reason obsolete_packs exists is in case your new packs get corrupted in some way, like an NFS error causes them not to be written out. But yeah, you can nuke 'em. | 15:39 |
| fjw | I figured it might be the case. I am wondering why the contents of upload could be so large when it was involving small commits, though I don't really understand how that works | 15:40 |
| Peng | When you're repacking, I'm sure the new packs are put in upload. | 15:40 |
| Peng | Make sure everything is okay before nuking obsolete_packs. | 15:40 |
| fjw | Ah interesting | 15:40 |
| jam | guilhembi: I'm not sure what you saw, I'm curious if you didn't do a "bzr revert" first, but at revno 3519, when I do "wbzr merge --weave" I get 42 conflicts | 15:40 |
| jam | I'll try with 3518 | 15:40 |
| guilhembi | jam: I used clean branches | 15:41 |
| fjw | I figure that when I ran out of disk space, it started leaving failed packs in upload and then the packing also gobbled up even more disk space as I tried saving it. Nice to know I can safely delete these files - thaks | 15:41 |
| jam | guilhembi: I'm trying with 3518, just in case 3519 fixed something | 15:42 |
| jam | guilhembi: we probably should also assert that we are using the same 6.0-ndb and 5.1-telco-6.2-merge revisions, just in case you are using a slightly newer tip than I (I haven't updated them since I started working on this, just to make sure you didn't resolve the problems manually.) | 15:45 |
| guilhembi | jam: ok, here's the last revids I have: | 15:45 |
| jam | guilhembi: ok... now that is weird | 15:45 |
| jam | 3519 does fix it | 15:45 |
| jam | but for reasons.... | 15:45 |
| guilhembi | 6.0-ndb tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j | 15:46 |
| jam | guilhembi: so... update to 3519 | 15:46 |
| guilhembi | 5.1-telco-6.2-merge frazer@mysql.com-20080604171340-hesp1emb6dqpstkz | 15:46 |
| Peng | Haha, Loggerhead just got swapped to hell. :) | 15:46 |
| guilhembi | jam: ok | 15:46 |
| jam | 2629 tomas.ulin@sun.com-20080619071842-gav9h5zkks8406rh => 2654 tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j | 15:46 |
| guilhembi | weird | 15:47 |
| jam | guilhembi: so we are using different versions, though I'm not sure *how* different yet | 15:47 |
| guilhembi | jam: among what you pasted, what is 6.0-ndb? | 15:47 |
| jam | 5.1 => ndb | 15:47 |
| jam | guilhembi: you can use "bzr revision-info -r -1" in each branch | 15:48 |
| jam | to give the revno and the revision id | 15:48 |
| jam | With the revno, I'll know whether *I* need to update, or *you* do :) | 15:48 |
| jam | though judging by the dates, I do | 15:48 |
| guilhembi | jam: well: | 15:49 |
| guilhembi | in 5.1-telco-6.2-merge I don't have any of your two revids | 15:49 |
| guilhembi | and in 6.0-ndb I have revid:tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j but not the other. | 15:50 |
| jam | guilhembi: oh, just a sec, this is mysql-5.1-telco-6.2 not the -merge branch | 15:50 |
| jam | guilhembi: 5.1-telco-6.2-merge is 2662 frazer@mysql.com-20080604171340-hesp1emb6dqpstkz | 15:50 |
| jam | same as yours | 15:50 |
| jam | *why* are your branches named so similarly :) | 15:50 |
| jam | I've been doing the right merge, I just switched to the wrong dir when I went to check the revision | 15:51 |
| guilhembi | jam: we have exact same branches. | 15:53 |
| jam | ok, good | 15:53 |
| jam | guilhembi: and I did see 208 conflicts with 3518, and only 42 with 3519... though looking at the actual change makes me wonder why | 15:57 |
| jam | 3519 should be "more correct" than 3518, but I don't know why 3518 suddenly decided to puke on everything, as it should be the same basic stuff as previous ones | 15:58 |
| jam | guilhembi: ok, I think I have an idea now. Probably 3518 was using a set() which could not be properly indexed by toposort. And since 3519 changes it to a list, everything works again. | 16:00 |
| jam | set()[0] has no meaning, you have to use list(set())[0] | 16:00 |
| guilhembi | jam: right, set() is the prominent change I saw when diffing 3517 and 3518 | 16:01 |
| jam | anyway, 3519 will give you "bzr merge --weave; bzr remerge --full-weave" | 16:01 |
| guilhembi | jam: and full-weave won't: | 16:01 |
| guilhembi | print: bzr: ERROR: Revisions have no common ancestor | 16:01 |
| guilhembi | ? | 16:01 |
| guilhembi | "bzr merge full-weave", I meant? | 16:01 |
| jam | guilhembi: oh, it will still do that, but that is a quick fix :) | 16:01 |
| guilhembi | ok, looking forward to 3520 then :) | 16:01 |
| jam | guilhembi: done, though somewhat untested | 16:03 |
| jam | should be available on my website | 16:03 |
| jam | and in a bit when LP mirrors it | 16:03 |
| guilhembi | jam: thanks | 16:05 |
| jam | guilhembi: you might need http://paste.ubuntu.com/23130/ | 16:12 |
| jam | If you try it and need that patch, let me know | 16:12 |
| jam | I'm trying to focus on some other things first, but I'll merge that if it is necessary | 16:12 |
| guilhembi | jam: ok | 16:13 |
| guilhembi | thanks | 16:13 |
| VSpike | Is it a bad idea in a shared repository to delete a branch by just "rm -rf branch"? | 16:26 |
| VSpike | Should I use a bzr command instead | 16:26 |
| LeoNerd | It won't break anything, you'll just end up with unreachable revisions that nothing uses | 16:26 |
| VSpike | thanks LeoNerd | 16:27 |
| VSpike | what is the correct way to do it? | 16:29 |
| LeoNerd | I'm not personally sure there is... it's a safe enough thing to do, as long as you don't care about recovering that extra bit of disk space... | 16:30 |
| LeoNerd | Maybe there is better way, but I don't know it | 16:30 |
| guilhembi | jam: support phoned me, and I recap-ed the status of the merge, in the support issue. | 16:30 |
| guilhembi | time for a pause now. | 16:31 |
| jam | nap time ? :) | 16:31 |
| VSpike | LeoNerd: it's unclear if bzr rm on the top level branch dir will do it | 16:32 |
| LeoNerd | bzr rm is for removing a single file from a branch | 16:32 |
| jam | LeoNerd: or multiple files, but no "rm -rf branch" is the recommended way | 16:35 |
| VSpike | OK thanks guys | 16:35 |
| LeoNerd | jam: How's bzr vacuum coming on? :) | 16:36 |
| fjw | If you are particularly concerned about that lost disk space, what would be a way to remedy this? At this point I can only imagine setting up a new repository and doing bzr branch from the old repository into it for each branch. then once confident everything is preserved deleting the old repository. | 16:38 |
| jam | LeoNerd: I've never worked on vacuum. :) I think jelmer has something like that, which creates a new repo, copies all referenced revisions into it, and replaces your current one. Might be "vacuum" I'm not sure. | 16:39 |
| james_w | fjw: that's the current recommended way. | 16:39 |
| jam | fjw: Essentially there is a plugin that does that for you | 16:39 |
| LeoNerd | jam: Well, for B in `bzr branches`; do push $B newrepo/$B; done would do that.. | 16:39 |
| LeoNerd | A bit expensive though | 16:39 |
| jam | LeoNerd: it also doesn't do it "in place" which means all the branches get new parents, etc | 16:40 |
| jam | and it doesn't re-use the working trees you have | 16:40 |
| jam | etc | 16:40 |
| LeoNerd | jam: Indeedily | 16:41 |
| awilkins | Is there a way to make log emit status changes for a single file (renamed, in particular) | 16:42 |
| jam | jelmer: ping... what is the name of your plugin to GC a repository. I can't find it on BzrPlugins or searching in launchpad | 16:42 |
| LeoNerd | bzr log path/to/file | 16:42 |
| awilkins | Yes, but it doesn't tell you if the file was renamed, just emits the log messages (by default) | 16:43 |
| awilkins | Got it, bzr status <path> -r 2.. | 16:44 |
| jam | awilkins: does --verbose not do that for you? | 16:44 |
| jam | status gives you the snapshot between 2 to now | 16:44 |
| jam | which may or may not be what you need | 16:44 |
| awilkins | jam: --verbose in this case, is waaay to long for comfort | 16:44 |
| awilkins | The tree has over 3400 files in it | 16:45 |
| awilkins | And verbose has no meaningful way of filtering the lines (via grep, for example) because the statuses are on a different line to the paths | 16:45 |
| awilkins | I got the information I wanted, which was "has the file been renamed between these two revisions" | 16:46 |
| awilkins | I think 1.6b is noticeably snappier on these log-heavy things by the way | 16:47 |
| awilkins | And on bzr status : is it supposed to be, or am I imgaining it? | 16:47 |
| awilkins | And on the subject : there are no win32 installers for 1.6b2 ; I built my own but I'm sure there are others who might like to try it out who don't have the Taurean stubborness required to build it on Windows. | 16:49 |
| === NfNitLoo` is now known as NfNit|oop | ||
| * Peng waits. | 17:20 | |
| === kiko is now known as kiko-fud | ||
| === cprov is now known as cprov-afk | ||
| baco | hi, i don't really get which are all the different ways in which I can set a bazaar server, I realize one is an ssh+ftp server but I wish something that does not require an user account on my server, something that could authenticate against PAM-file for example | 18:24 |
| awilkins | baco: You can use the smart HTTP server and make Apache do the auth | 18:28 |
| awilkins | baco: Alternatively, you could create one user for the server, and make people who want access send you a public key, and just add them all to that users authorized_keys file | 18:30 |
| baco | awilkins: but the commits will all be done by that user, and I don't want to give access to my server except for committing | 18:31 |
| awilkins | baco: If users are using bzr+ssh rather than sftp their commits should be in their user name | 18:32 |
| awilkins | And you can restrict the rights of that single user a lot. | 18:32 |
| awilkins | baco: In fact, if they are using sftp, their commits should be in their name too. | 18:33 |
| baco | awilkins: really? It doesn't happen that when using the smart server only | 18:34 |
| awilkins | baco: Don't all commits get logged under the name of the client user that commits them? | 18:35 |
| baco | awilkins: that smart http server you mention, works for writing commits? | 18:35 |
| awilkins | baco: Allegedly ; I've never used it though | 18:35 |
| awilkins | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id76 | 18:35 |
| baco | awilkins: ok, perhaps I can identify who does the commits with the smart server, but I can not restrict who can and who can not | 18:37 |
| awilkins | baco: Nothing stops you serving it over plain http at the same time | 18:41 |
| awilkins | read-only users only get plain http access | 18:41 |
| baco | awilkins: how would the scheme end? could I have read-only access to anybody with http, and write access to selected users via smart http server for users I want? is that possible? | 18:44 |
| fullermd | One way is that you use http for the readonly, and https for the write side, and just enable auth on the https side. | 18:45 |
| baco | that is not documented, is it? | 18:45 |
| Peng | Huh, Googlebot just requested "/loggerhead/my/branchrevision/138" <-- Bad link? | 18:50 |
| awilkins | I have to say, whever I look for these things, I get frustrated. Would other people agree that the documentation could benefit from having this stuff broken out into a dedicated "Bazaar Server Guide" ? | 18:50 |
| baco | awilkins: I agree | 18:51 |
| Peng | Uh-oh, it's doing it again. | 18:51 |
| Peng | Well, at least the bzr+http docs could be moved out of an appendix. | 18:51 |
| awilkins | It's a major factor in deciding the feasibility of Bazaar use in an organisation ; how it can be fitted within existing infrastructure | 18:52 |
| awilkins | A nice service matrix would go a long way to convincing managers to like it, for example :-) | 18:53 |
| * Peng wanders off. | 18:53 | |
| LarstiQ | awilkins: I think that would be beneficial. | 18:53 |
| fullermd | Well, a AAA-capable smart server would be too :p | 18:54 |
| awilkins | AAA? Anti Aircraft Attack? | 18:54 |
| * baco LOL | 18:54 | |
| fullermd | Man, I would totally switch to SVN if it supported that... | 18:55 |
| fullermd | ... well, OK, maybe not. | 18:55 |
| fullermd | Authentication/Authorization/Accounting | 18:55 |
| awilkins | Aha. Yes, it could do with those things | 18:56 |
| fullermd | As it is, authentication is pawned off to Apache (or whatever server), authorization is limited to "everyone can {do nothing,read,write}", and accounting is nonexistent. | 18:56 |
| awilkins | 3 is suppliable by requiring sign-my-commits | 18:57 |
| fullermd | Well, 3 isn't suppliable period as long as there are VFS methods. | 18:57 |
| baco | fullermd: YES! that's what I was actually looking for, but I don't find it yet | 18:57 |
| fullermd | I mean, I can use the VFS methods to delete every pack in the repository. | 18:57 |
| * awilkins is definitely glad he's going for public-key auth | 18:58 | |
| fullermd | sign-my-commits gives you 3 if you always trust the client side. | 18:58 |
| * fullermd points at Raph Koster. | 18:58 | |
| awilkins | Nah, sign-my-commits is pretty trustworthy, regardless of client integrity | 18:59 |
| abentley | I wonder whether bzr+http can support openid? | 18:59 |
| fullermd | Not at all. I can connect up and do *ANYTHING* via the VFS methods. Delete all the packs. Replace the existing revisions with totally bogus data. Add commits with no signatures. ANYTHING. | 19:00 |
| fullermd | I think there's an auth_openid apache module... | 19:00 |
| fullermd | I'm not sure I see how it would work, but... | 19:00 |
| awilkins | Hmm. Ok, I was coming at it from the point of view that you can always be sure that a signed commit was signed by the owner of the key | 19:00 |
| * fullermd hasn't thought much about it. | 19:00 | |
| abentley | fullermd: There is. It's the client side I wonder about. | 19:00 |
| === kiko-fud is now known as kiko | ||
| awilkins | You can't fake other peoples signed revisions with the VFS methods | 19:01 |
| awilkins | But the other actions are obviously rather insecure | 19:01 |
| fullermd | No, I can't do that. But unless everybody's validating signatures of every revision they grab... | 19:01 |
| awilkins | I presume then there isn't a reciprocal "verify commit signatures" plugin? | 19:02 |
| fullermd | I think there is. | 19:03 |
| awilkins | But you can't ensure that everyone is using it... it's the Visual Sourcesafe family of problems | 19:03 |
| fullermd | I recall jam having/writing something some years ago. | 19:03 |
| awilkins | VSS is also a fat client which accesses a filesystem backend and does what it will. | 19:03 |
| awilkins | Of course, VSS fubared things a lot more because it wasn't as careful | 19:04 |
| fullermd | Yeah. If you solved that problem, VSS would still be [unprintable] :) | 19:04 |
| awilkins | There was a third-party thing that created a VSS "server" by wrapping a client up in a server process. | 19:05 |
| awilkins | So you could use it across the wider internet without exposing win32 SMB shares to the world | 19:05 |
| === thumper_laptop is now known as thumper | ||
| awilkins | It also dealt with some other howlers like timezone support | 19:06 |
| awilkins | But didn't fix things like being able to set your clock to the future, in order to be able to commit revisions there. | 19:06 |
| awilkins | THe revisions wouldn't show up until the future date, so you could commit a nasty delayed logic bomb that wouldn't even show in the code until someone did a build in the furture. | 19:07 |
| * awilkins is a VSS survivor and converts it to SVN on sight these days. | 19:08 | |
| * fullermd makes a note to maintain a safe distance. | 19:08 | |
| fullermd | The problem with the signing commits is 3-fold. First, you have to sign them. Second, the other side has to verify them. | 19:09 |
| fullermd | And third, you have to KNOW they're signed. If you have a bunch of signed revs, they're trustworthy even if I get access to fiddle files in the repository. | 19:10 |
| fullermd | But if I replace your revs with bogus revs of mine, and don't put up any signatures, you have to KNOW there were SUPPOSED to be signatures to be able to tell it's spurious. | 19:10 |
| awilkins | True ; this is somewhere Monotone and git score. | 19:10 |
| fullermd | Yah. In a lot of ways, signing revs gives all the same assurances as the checksum being the rev name, but it doesn't quite cover it. | 19:11 |
| fullermd | (it gives more in other ways of course; assuming the web-of-trust does its job right, you have assurance of WHO did it, which the checksums can't directly give you) | 19:11 |
| awilkins | Signed digests 4tw | 19:12 |
| awilkins | (as intrisic parts of the revision that can't be replaced) | 19:12 |
| fullermd | mtn is great on that sort of assurance. It's too bad it's so unpleasant to use [for me anyway]. | 19:12 |
| awilkins | I suppose there is nothing stopping Bazaar adopting it in newer repo formats | 19:13 |
| awilkins | Unless it would hopelessly break revids? | 19:13 |
| fullermd | Well, the revid would have to become the hash, and the client would have to know to validate it. | 19:14 |
| fullermd | Of course, since our revids are always opaque, we have a leg up in that we could use multiple hashes. The revid could be 12f57a2[...]a3:SHA1 or ab41d[...]85:SHA256 or what have you; easier to switch in the future. | 19:15 |
| awilkins | I'd just stick to one ; hash function breaks or not I can't imagine people expending the effort | 19:15 |
| fullermd | git or mtn would have a little more trouble, since they're build considering the id's as meaningful much deeper down. Though, to use them as such, we may have to duplicate that much depth of knowledge, so it may not be any better :| | 19:16 |
| awilkins | I mean, you'd have to construct hash collision data for each revision ; together with the delta-i-ness of VCS systems, you'd rapidly have a huge pile of crap in your tree that everyone would spot as a hash attack. | 19:17 |
| fullermd | I don't like to guess other than very conservatively the consequences of breaking assumed uniqueness... | 19:24 |
| === cprov-afk is now known as cprov | ||
| * lamont wonders idly if there is already a bug in the system that bzr status spits out filenames that are only useful if you happen to be in the root of the source tree | 19:33 | |
| lamont | rather than making them relative to the current working directory | 19:34 |
| fullermd | I'm sorry, it's still 3 days until that debate is scheduled to come up again... | 19:34 |
| abentley | fullermd: :-) | 19:35 |
| === SteveA_ is now known as SteveA | ||
| LarstiQ | lamont: yes, there is | 19:36 |
| abentley | lamont: I don't think anyone disagrees that status should be able to use cwd-relative paths. | 19:36 |
| lamont | abentley: it accepts and uses them. it's the output that's the issue... | 19:36 |
| LarstiQ | lamont: https://bugs.launchpad.net/bzr/+bug/30159 | 19:36 |
| ubottu | Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] | 19:37 |
| abentley | lamont: The contention has mainly been about whether parent directories and their children should be displayed) | 19:37 |
| abentley | lamont: For output, I meant. | 19:37 |
| lamont | abentley: not that it helps the arguement, but git does. :-) | 19:37 |
| abentley | lamont: In UI terms, Git occupies a similar space to CVS: Git does it that way? Okay, what would the right way be? | 19:39 |
| lamont | abentley: lol | 19:41 |
| lamont | like I said, I rather expected it doesn't help the arguement... | 19:41 |
| lamont | I rather expect that a naked "bzr status" should show the entire tree, with relative paths, while "bzr status $LIST" should show only the status of the listed files and directories (and children) | 19:42 |
| lamont | git always does the full dump, with relative paths | 19:42 |
| jelmer | jam: bzr-remove-revisions | 19:55 |
| jelmer | LarstiQ: yeah, that should work - you still ahve to use svn-push though | 19:55 |
| jelmer | jam: it's pretty specific to knits though, I haven't used it in quite some time | 19:55 |
| LarstiQ | jelmer: ok, then it's time to file some bugs I guess. | 19:56 |
| jelmer | LarstiQ: please do :-) | 19:56 |
| jprieur | Hi guys, any clue about this problem? http://rafb.net/p/TE4SMk67.html | 19:57 |
| === kiko is now known as kiko-afk | ||
| jelmer | jprieur: hmm, looks like bzr-search relies on bzr-svn being there | 19:58 |
| jelmer | I think that's a bug and that the intention was to have an optional dependency on bzr-svn | 19:59 |
| kiko-afk | did lifeless' massive VF work land? | 20:00 |
| kiko-afk | I'm curious about that one | 20:00 |
| jelmer | kiko-afk: yes | 20:00 |
| jelmer | at least a very major part of it | 20:00 |
| kiko-afk | wooo, that's worth a drink and fireworks | 20:01 |
| * jelmer doesn't have time for that sort of thing, I need to fix bzr-svn now that the API is all broken again :-P | 20:02 | |
| jelmer | (by the vf changes...) | 20:02 |
| LarstiQ | jelmer: you're welcome to come hack here, and I'll supply the drink (no fireworks though) | 20:09 |
| jam | jprieur: Looking at this http://mail.python.org/pipermail/python-dev/2006-August/068078.html | 20:11 |
| jam | It seems that maybe 'bzr search' is trying to import the python files before it actually imports their containing dirs | 20:11 |
| jam | so maybe it should do | 20:12 |
| jam | import bzrlib.plugins | 20:12 |
| jam | import bzrlib.plugins.svn | 20:12 |
| jam | import bzrlib.plugins.svn.branch | 20:12 |
| jam | But I can't really say for sure | 20:12 |
| jam | beuno: do you have your links for the fancy loggerhead with integration to bzr-search? | 20:16 |
| beuno | jam, well, gnome is running it: http://bzr-mirror.gnome.org:8080/banshee/trunk/changes | 20:18 |
| * Jc2k grins | 20:19 | |
| LarstiQ | sweet! | 20:19 |
| Pieter | hmm, too bad there aren't a lot ofpeople making the right points for git on pgo | 20:21 |
| dato | I just read the post from they guy that went, "why not let each project use what they prefer" | 20:22 |
| jam | beuno: well, you're making it into 'this week' so all the world will know :) | 20:23 |
| LaserJock | anybody here happen to know about the Gnome bzr mirror? | 20:26 |
| LaserJock | specifically, is http the only protocol for it? | 20:27 |
| Peng | beuno! Just the person I wanted to harass! | 20:27 |
| LarstiQ | ok, that's one for the quotes page | 20:29 |
| Jc2k | Pieter: i'd love it if they were, then i'd file bugs against the right bits of bazaar | 20:33 |
| jam | beuno: anything you would want us to mention? | 20:35 |
| jam | We're showcasing your work today | 20:36 |
| beuno | jam, one sec, phone, and yes :) | 20:39 |
| Pieter | Jc2k: how about real branch support? :) | 20:40 |
| jam | beuno: when you get back, do you have skype? We can bring you in on our call | 20:44 |
| Jc2k | Pieter: theres already a bug filed for that as its one the Git GNOME people seem unlikely to let go of | 20:44 |
| Jc2k | Pieter: i imagine it will be useful for jhbuild, too | 20:45 |
| LarstiQ | Pieter: what is 'real branch' support? | 20:45 |
| Jc2k | (whilst looking at your blog) though it will be implemented as a plugin ;) | 20:45 |
| Jc2k | LarstiQ: hide everything in one directory and make people switch branches with bzr switch | 20:46 |
| LarstiQ | Jc2k: ah, figures, git style branch handling | 20:48 |
| beuno | jam, I'll be off the phone in 5', and yes, I have skype | 20:48 |
| Pieter | you also currently have to do a "bzr branch http://..." yourself every time someone creates a branch, right? | 20:48 |
| Jc2k | or put another way, i only have branches that i care about | 20:49 |
| Jc2k | some of the GNOME modules have *lots* of branches | 20:49 |
| Pieter | yeah, that's why you use namespaces :) | 20:50 |
| Jc2k | (to be honest, i've nearly finished a plugin that pulls *all* branches) | 20:50 |
| Pieter | Jc2k: and you can also add git-like conflict resolution | 20:51 |
| Jc2k | whats that? isnt there something like that already, with bzr merge --pull ? | 20:53 |
| Pieter | with git, files that aren't in conflict are added to the index | 20:53 |
| Pieter | so "git diff" will only show you files in conflict | 20:53 |
| LaserJock | is there anything faster than bzr branch for creating local branches? | 20:54 |
| Pieter | and when you resolved one, and do a "git add file", that one will disappear from the diff too, allowing you to kee ptrack of what cnoflicts there still are | 20:54 |
| LarstiQ | Pieter: what part of that are you after? | 20:54 |
| Jc2k | Pieter: so basically, you want the index? | 20:55 |
| LarstiQ | Pieter: `bzr conflicts` will tell you what conflicts. | 20:55 |
| Pieter | Jc2k: yeah, it's great | 20:55 |
| LarstiQ | Pieter: I have been using hacked up version of bzr vimdiff that has an option to only diff conflicting files | 20:55 |
| jelmer | LarstiQ, heh, some other time | 20:56 |
| * jelmer is in Germany | 20:56 | |
| beuno | back | 20:57 |
| LaserJock | oh man, locally branching gtk+ takes almost as long as branching it remotely, that doesn't make much sense :/ | 20:57 |
| jam | beuno: what' is your user id | 20:57 |
| beuno | Peng, your new-style-class-patch went into trunk, so thanks for that | 20:57 |
| beuno | jam: pentacorp | 20:57 |
| beuno | I should probably open it though | 20:57 |
| jam | beuno: I just asked to be your friend | 20:58 |
| Pieter | LaserJock: bzr branch is pretty slow, especially if you don't have a rich root | 20:58 |
| LaserJock | it's rich-root | 20:58 |
| LaserJock | anything that would be faster? | 20:58 |
| LarstiQ | LaserJock: are you branching within a repository? | 20:58 |
| LaserJock | we're looking at almost 3.5 min | 20:58 |
| LaserJock | no | 20:58 |
| LarstiQ | LaserJock: or is it the working tree creation that takes tht long? | 20:58 |
| LaserJock | the working tree doesn't take too long | 20:59 |
| LarstiQ | LaserJock: if you branch within a repository, branch won't need to copy revisions across. | 20:59 |
| LaserJock | it's mostly copying history it seems | 20:59 |
| LaserJock | LarstiQ: well sure, but I don't have a repository | 20:59 |
| LarstiQ | LaserJock: ok, could you confirm it's that? | 20:59 |
| beuno | jam, just heard background noise, try again :/ | 21:00 |
| LaserJock | LarstiQ: how can I confirm other than watching the progress bar? | 21:00 |
| LarstiQ | LaserJock: trying to branch within a repository would do the trick. | 21:00 |
| LarstiQ | LaserJock: --hardlink is only for working tree it seems, otherwise I would have suggested that | 21:01 |
| Pieter | Jc2k: and also add something to modify history | 21:01 |
| Jc2k | Pieter: they are already working on rebase -i | 21:05 |
| Pieter | good, and then you also need something like the reflog :) | 21:05 |
| Jc2k | eh | 21:08 |
| Jc2k | whats the reflog :) | 21:08 |
| Jc2k | i know i won't need it for libgitcore, but thats about all :) | 21:09 |
| Pieter | it records what your HEAD pointed to in time | 21:09 |
| Pieter | so if you switch branches, or use something like rebase -i, you can always get back to a previous point | 21:09 |
| Pieter | just in case you didn't want to do the rebase -i anyway :) | 21:09 |
| LarstiQ | something likes looms? | 21:10 |
| Jc2k | LarstiQ: i think its more like the backwards and forwards in your web browser | 21:11 |
| Pieter | yeah, what jc2k says | 21:11 |
| Pieter | it means you can always get back to your repository state, however you fucked up | 21:11 |
| LarstiQ | hmm | 21:11 |
| LarstiQ | Pieter: ah, so git people _don't_ insist on destroying history! ;p | 21:12 |
| LaserJock | LarstiQ: ok yeah, without shared repo 3m25s, within shared repo 5s ;-) | 21:12 |
| LarstiQ | LaserJock: ok, so the workingtree building really isn't the bottleneck :) | 21:12 |
| Pieter | LarstiQ: nothing is ever destroyed in git, just changed :)) | 21:12 |
| LarstiQ | Pieter: heh :) | 21:13 |
| jam | Pieter: unless you run "git gc" | 21:13 |
| LarstiQ | Pieter: so when does the reflog record what your head is at? | 21:13 |
| LaserJock | LarstiQ: but git takes only ~2s for a git clone :/ | 21:13 |
| Pieter | LarstiQ: every time it changes | 21:13 |
| LarstiQ | Pieter: and how do you navigate it? That would cause a lot of points you're not interested in I'd think? | 21:13 |
| Pieter | LarstiQ: merge, switch branch, pull, revert, rebase | 21:13 |
| Pieter | LarstiQ: if you do "git reflog", it gives you a pointer to a commit and a time you were there, together with the action that caused your head to be there | 21:14 |
| LarstiQ | Pieter: the most recent one? All of them? | 21:15 |
| Pieter | jam: yes, but that's after it's gone from your reflog, which stays for 30 days by default | 21:15 |
| Pieter | LarstiQ: yes, for the last 30 days | 21:15 |
| LarstiQ | Pieter: 'git reflog' gives you a list of all head changes for the last 30 days? | 21:15 |
| Pieter | yes | 21:15 |
| LarstiQ | Pieter: ok | 21:16 |
| LarstiQ | shouldn't be hard to do | 21:16 |
| Pieter | :) and proper cherry picking would also be nice | 21:19 |
| LarstiQ | hook post_change_branch_tip to record changes, and a command to print them out | 21:19 |
| LarstiQ | Pieter: 'proper cherry picking' is a rather ambiguous statement. Does anything but darcs do that? | 21:19 |
| Pieter | well, something that keeps commit messages would be nice | 21:20 |
| Pieter | and "git cherry" allows you to see which of your commits have been applied upstream | 21:20 |
| LarstiQ | Pieter: recodring that a cherry pick happened is something that needed to be done last I looked at it, that is certainly true | 21:21 |
| LarstiQ | Pieter: how does 'git cherry' differ from 'bzr missing'? | 21:21 |
| Pieter | bzr missing looks at commit id, right? | 21:21 |
| LarstiQ | assuming we record the cherry pick | 21:21 |
| Peng | beuno: Anyway, I wanted to mention something. My Loggerhead instance finally got hit by Googlebot, so it's been very busy (and almost ran my VPS out of RAM). Anyway, certain annotation pages cause it to traceback with NoSuchId in the tree None. | 21:21 |
| Peng | Ew, I said "Anyway" twice. | 21:22 |
| Pieter | git cherry also works when you apply patches, for example | 21:22 |
| beuno | Peng, ah, can I take a look at the traceback? | 21:22 |
| LarstiQ | Pieter: ah, so it's more of a text content comparison? | 21:22 |
| Peng | beuno: Hold on. | 21:23 |
| Pieter | LarstiQ: yes, it calculates a diff id | 21:23 |
| Peng | beuno: URL where it happens: http://snurl.com/2p8ye Log: http://paste.pocoo.org/show/77818/ | 21:23 |
| Pieter | so upstream doesn't even have to use git for it to work | 21:23 |
| LarstiQ | Pieter: what does git cherry identify then? | 21:24 |
| LarstiQ | Pieter: when upstream only applies some hunks of your patch for instance | 21:24 |
| LarstiQ | Pieter: does it say something like 'incomplete merge of revision foo'? | 21:24 |
| Pieter | I think it's all or nothing | 21:24 |
| Peng | beuno: (Loggerhead trunk, but bzr 1.5 or so.) | 21:24 |
| LarstiQ | Pieter: ok | 21:24 |
| LarstiQ | Pieter: is there some document describing all these different missing features you would like to see? | 21:25 |
| LarstiQ | Pieter: or do we have to edit the irc log | 21:25 |
| Peng | beuno: Also, there's a small inconsistency in the logs: The "built revision graph" message basename()s the branch's name, but most others don't. | 21:25 |
| Pieter | LarstiQ: I never wrote it down :) | 21:26 |
| Peng | beuno: (Both of which just use self.log.info(), but one of them must be configured differently.) | 21:26 |
| beuno | Peng, it seems to be tracebacking in bzr. Do you have that file in the branch? | 21:26 |
| Peng | beuno: I have nooo idea. I'd assume I do, since Googlebot found a link to it... | 21:27 |
| Peng | Also, this is an obscure one, but you know how LH links to "/MYBRANCH/revision/123"? Googlebot somehow managed to find some links to "/MYBRANCHrevision/123". | 21:27 |
| beuno | Peng, right, makes sense. I'll look inyo reproducing it, thanks. | 21:28 |
| LarstiQ | Peng: missing slash? | 21:28 |
| Peng | LarstiQ: Yes, exactly. | 21:28 |
| beuno | hrm | 21:28 |
| jam | beuno: posted, thanks for your help | 21:28 |
| guilhembi | jam: I posted a comment in the support issue | 21:28 |
| beuno | I'll run a spider through my local LH and see how it could get generated | 21:28 |
| jam | http://jam-bazaar.blogspot.com/2008/06/this-week-in-bazaar_26.html | 21:28 |
| beuno | jam, my pleasure | 21:28 |
| Peng | beuno: Thank you for the help. :) | 21:28 |
| beuno | Peng, thanks for the feedback :) | 21:29 |
| Peng | beuno: No problem. I'm always happy to break software and whine about it. ;D | 21:30 |
| LarstiQ | and you do it so well :) | 21:31 |
| LarstiQ | ok, cutting power to replace the electra, bbl | 21:31 |
| Peng | LarstiQ: It's a gift. :) | 21:32 |
| Peng | Wow, Googlebot tried the bad revision links 300 times. :\ | 21:34 |
| lifeless | :P | 21:34 |
| lifeless | not the smartest bot in the shed I guess | 21:34 |
| Peng | It usually requested a page every 1-3 seconds, but after each 500 error, it stopped for a minute or two. :) | 21:35 |
| beuno | lifeless, good morning | 21:35 |
| beuno | you broke bzr search! | 21:36 |
| beuno | (may of not been you) | 21:36 |
| lifeless | beuno: oh noes | 21:36 |
| beuno | I pulled bzr.dev a while ago, and it blew up: http://paste.ubuntu.com/23183/ | 21:37 |
| beuno | I assume one of your billion line patches passed PQM :) | 21:38 |
| Peng | beuno: I've got it! The /atom pages are generating the bad links. | 21:39 |
| Peng | beuno: Can I fix it? :> | 21:39 |
| beuno | Peng, pretty please :) | 21:39 |
| Peng | beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/fix-atom-links should do it, but I didn't test it. | 21:43 |
| Peng | beuno: Yeah, it fixes it. | 21:44 |
| beuno | Peng, was that related to fileids in any way? | 21:45 |
| beuno | (branching) | 21:45 |
| Peng | beuno: This bug? No, just missing / in the template. | 21:45 |
| lifeless | beuno: oh yes | 21:47 |
| lifeless | beuno: hmm, I should do a 1.5/1.6b2 branch of search I guess | 21:47 |
| beuno | Peng, alright, I'll try and find out what the fileid issue is then | 21:47 |
| beuno | lifeless, bad timing, huh :) | 21:48 |
| lifeless | beuno: not at all; I did warn about massive api breakage for this patch | 21:49 |
| lifeless | beuno: it should be trivial to fix; I'm just ensuring I have the latest .dev to test with | 21:49 |
| beuno | lifeless, ah, good then. You have your talk today, don't you? | 21:49 |
| lifeless | yes | 21:49 |
| lifeless | haven't heard from verterok about eclipse shiny :( | 21:50 |
| lifeless | but loggerhead is plenty shiny | 21:50 |
| beuno | I think he got side-tracked by the BB-to-pg thing | 21:50 |
| beuno | lifeless, I'm also going to push the last bit of javascript needed to fix it as soon as I get a few minutes off. It's been a crazy work day today | 21:51 |
| lifeless | beuno: oh awesoem | 21:52 |
| lifeless | beuno: is it merged to trunk yet ? :P (btw I'm surprised loggerhead is working with bzr.dev :)) | 21:53 |
| beuno | lifeless, I wish. It will be next week, although it depends on how many things mwhudson can review at once :) | 21:53 |
| lifeless | well, in about 6 minutes he should be online | 21:54 |
| beuno | loggerhead works with bzr.div, mainly because I'm using bzr.dev, and fixing anything that breaks as I pull | 21:54 |
| lifeless | :P | 21:54 |
| lifeless | beuno: but does it work with 1.5 still ? :P | 21:54 |
| beuno | lifeless, yeap. Peng is living proof of it | 21:54 |
| walkeraj | Hello, the company I work for is evaluating revision control systems, and I've decided to use and then present on Bazaar. Currently, we maintain a CVS repository, and I was wondering what the best way to work with CVS would be as a single user attempting to evaluate Bazaar. I've read the docs, and Tailor is suggested as well as the rather awkward sounding (cvs to svn | svn to bzr) method. What's a good way to evaluate it and still work with the ex | 21:55 |
| Peng | (Only because I forgot to set sys.path.0 | 21:55 |
| Peng | ) | 21:55 |
| lifeless | walkeraj: your text cut off at: | 21:55 |
| lifeless | What's a good way to evaluate it and still work with the ex | 21:55 |
| walkeraj | ...existing repository? | 21:55 |
| lifeless | I don't think I'm qualified to offer marital advice :) | 21:55 |
| Peng | Dammit! | 21:56 |
| lifeless | Peng: ? | 21:56 |
| Peng | It cuts off at "with the e" for me. My IRC client still has that off-by-one bug. | 21:56 |
| Peng | I thought it had been fixed. | 21:56 |
| lifeless | walkeraj: I would say tailor, because although its PITA to set up, you need ongoing incremental and that is one of the use cases its designed to do an ok job at | 21:56 |
| lifeless | walkeraj: when you actually go to migrate, I'd suggest doing a full fresh conversion with bzr-cvsps-import | 21:57 |
| walkeraj | lifeless: sure, but in the meantime, I want to evaluate it as closely as I can to how it would be working in a purely bazaar environment. What's the difference between using tailor and just creating a new bazaar repository with my CVS-controlled directory (periodically doing checkins on a task-by-task basis) | 21:59 |
| lifeless | walkeraj: tailor tries to preserve individual cvs commits | 22:00 |
| lifeless | walkeraj: other than that, not much difference | 22:00 |
| walkeraj | so, basically, I could do something similar simply by making my CVS-controlled directory a shared repository that I could then make branches from on a task-by-task basis? | 22:01 |
| walkeraj | and basically do a bzr merge followed by a cvs merge as each task was completed? Maybe? Am I close? | 22:02 |
| lifeless | walkeraj: you could keep both in one tree yes | 22:03 |
| walkeraj | Hmm. My terminology is still a little fuzzy then. So, I have directory under CVS control. I want that directory to house all of the files and then be able to make "branches" on a task-by-task basis without copying the entire directory each time. What's the organizational tree for that in bazaar terms? | 22:04 |
| lifeless | walkeraj: we have three key objects on disk | 22:10 |
| lifeless | walkeraj: 'repository' - stores history details, file texts etc. | 22:10 |
| lifeless | 'branch' - stores a pointer into the repository for the latest commit on the branch (the tip), and pointers for each tag, as well as configuration options | 22:10 |
| lifeless | 'working tree' - has a copy of editable texts representing the current tree which you can then do things to like: merge, commit, rename, edit etc | 22:11 |
| lifeless | walkeraj: you can use a repository created with 'no-trees' containing N branches, and then a single tree (created by bzr checkout --lightweight), which you can 'bzr switch' between branches | 22:12 |
| lifeless | jelmer: is there a bzr.dev branch of bzr-svn yet ? | 22:15 |
| jelmer | lifeless, yes, the 0.4 branch | 22:15 |
| jelmer | there is no non-bzr.dev branch :-) | 22:15 |
| lifeless | is 0.4 trunk? | 22:15 |
| jelmer | no, trunk is different | 22:15 |
| lifeless | jelmer: so I've been running trunk | 22:19 |
| lifeless | jelmer: what should I run | 22:19 |
| jelmer | 0.4 | 22:20 |
| thekorn | hi, is it a known bug that bzr sometimes shows a files as (M)odified after a merge although the file did not change, although the file obviously did not change (according to 'bzr status' and 'bzr diff')? | 22:20 |
| lifeless | thekorn: no | 22:21 |
| lifeless | thekorn: is the tree public ? | 22:22 |
| thekorn | http://paste.ubuntu.com/23202/ | 22:22 |
| thekorn | yes, | 22:22 |
| lifeless | thekorn: url? | 22:23 |
| thekorn | trying to get the url from launchpad, but its slow | 22:23 |
| thekorn | lifeless, merging latest changes from lp:python-launchpad-bugs | 22:24 |
| thekorn | into lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge | 22:24 |
| walkeraj | I see now (mostly). So, let's say I create a branch for a particular bug. That branch is basically just an aggregate of diffs, then? And bzr switch will then un-apply and apply diffs to change the configuration of files from one branch to another? | 22:25 |
| lifeless | thekorn: let me try | 22:26 |
| bkor | Pieter: I'd love to get real arguments that are pro Git | 22:26 |
| lifeless | walkeraj: bzr is not patch based; the branch is a pointer to a tree - an exact copy of the code a point in time | 22:27 |
| lifeless | walkeraj: switch does a transform between two trees, both of which are historical, and preserves any local edits you had | 22:27 |
| walkeraj | Okay, so just replace applying diffs then with shuffling files about? | 22:28 |
| Pieter | bkor: read above log | 22:28 |
| lifeless | walkeraj: sure, handwaving :P | 22:28 |
| thekorn | lifeless, ok, thanks, I can reproduce it here with fresh copies of both branches | 22:29 |
| lifeless | Pieter: could you paste it somewhere, my router was offline | 22:29 |
| Pieter | hmm | 22:29 |
| Pieter | that's not very easy in irssi+screen | 22:29 |
| lifeless | ctrl-A [, select, enter to copy | 22:30 |
| lifeless | switch to console | 22:30 |
| lifeless | cat - | xsel | 22:30 |
| lifeless | ctrl-A ] | 22:30 |
| Pieter | it spans a lot of pages | 22:30 |
| lifeless | ctrl-D | 22:30 |
| lifeless | Pieter: fair enough | 22:31 |
| walkeraj | So, in this use-case scenerio, my CVS directory becomes a working tree with branches, and the repository can just basically reside in that directory? | 22:31 |
| lifeless | Pieter: uhm, are there some key points? | 22:31 |
| lifeless | walkeraj: yes | 22:31 |
| Pieter | http://frim.frim.nl/bzr.log | 22:31 |
| lifeless | walkeraj: I suggest having a bit of a play with the tutorial before trying to do this | 22:32 |
| walkeraj | Oh for certain | 22:32 |
| walkeraj | this is all about getting my terminology straight. | 22:32 |
| lifeless | Pieter: you're a gitter aren't ? | 22:32 |
| walkeraj | Excellent. Thanks for the help. | 22:32 |
| Pieter | lifeless: http://frim.frim.nl/goodlog.txt | 22:33 |
| lifeless | Pieter: I want to get someone who likes git to give bzr-loom a spin, not as a patch assembler, but as a 'all my branches in one spot' workflow | 22:34 |
| Pieter | lifeless: I'm actually evaluating git, bazaar and mercurial personally, but I've used igt mostly | 22:34 |
| lifeless | Pieter: and tell me what they are missing | 22:34 |
| Pieter | *git | 22:34 |
| lifeless | not in terms of features(git) - features(bzr-loom), but in terms of (features_used_by_me_in_git - features(bzr-loom) | 22:34 |
| pickscrape | Is there an easy way to get bzr to gracefully exit from within a plugin (i.e. without a stacktrace) | 22:37 |
| Pieter | I can take a look at it, but I don't think bzr-loom does anything that's by default in Git.. it looks more like something like StGit | 22:38 |
| lifeless | pickscrape: you are writing a plugin, and for some command you want to say 'ok all finished now' ? | 22:38 |
| lifeless | Pieter: well it offers a single branch object that can contain multiple editable refs | 22:38 |
| pickscrape | It's more a case if "Erm, you need to set this up before this will work", but yet. | 22:38 |
| Pieter | yes, but they're all dependent or each other, right? | 22:38 |
| lifeless | no | 22:38 |
| pickscrape | * s/yet/yes/ | 22:38 |
| lifeless | pickscrape: if you want to do that, create a BzrError subclass | 22:39 |
| Pieter | I thought everything under a current thread gets merged in | 22:39 |
| lifeless | pickscrape: give it the message and so on, and raise it | 22:39 |
| lifeless | pickscrape: it will show as 'bzr: ERROR: <message>' | 22:39 |
| pickscrape | lifeless: Do I need a subclass, or can I just use BzrError directly? | 22:39 |
| lifeless | Pieter: there are layers involved | 22:40 |
| jelmer | lifeless: looms need a simpler ui to be usable as multiple-branches-in-a-dir thing imo | 22:40 |
| lifeless | pickscrape: subclass | 22:40 |
| pickscrape | lifeless: ok, thanks. | 22:40 |
| lifeless | jelmer: well, I think there is too much tension to use looms directly yes. But I'm trying to evaluate the gap | 22:40 |
| lifeless | Pieter: if you do: | 22:40 |
| lifeless | bzr branch THING test | 22:40 |
| lifeless | cd test | 22:40 |
| lifeless | bzr nick test | 22:41 |
| lifeless | bzr loomify | 22:41 |
| lifeless | that will set you up to play | 22:41 |
| lifeless | ui wise, bzr show-loom will list the 'branches' | 22:41 |
| lifeless | bzr switch NAME will switch within them | 22:41 |
| lifeless | bzr pull/merge/push etc work as normal only affecting the current one you are on (except when you interoperate with another loom, which is one of the reasons that loom-as-loom is not a good answer for multiple-branches-in-a-dir | 22:42 |
| Pieter | lifeless: well, then it's kinda worthless, if you can't merge? | 22:42 |
| lifeless | what I plan to do is to improve loom for this use case as far as it can without sacrificing the things that make it loom | 22:43 |
| lifeless | Pieter: it totally can merge; but doing a merge against another loom object merges the list of branches | 22:43 |
| lifeless | Pieter: because it is indeed a collaborative stit | 22:43 |
| lifeless | *stgit* | 22:43 |
| lifeless | Pieter: anyhow, the idea is to find what things you first cry out for, and what things get in the way (some I know about, see above) | 22:44 |
| Pieter | lifeless: ok, but still take a look at that log, there are other things on there too | 22:45 |
| lifeless | Pieter: and then reuse some of the code to do a plugin that offers this for people want it | 22:45 |
| lifeless | Pieter: doing so | 22:45 |
| lifeless | Pieter: so this is how long making a branch of bzr itself takes: | 22:47 |
| lifeless | Pieter: cold cache | 22:47 |
| lifeless | robertc@lifeless-64:~/source/baz$ time bzr branch bzr.dev sample-Pieter | 22:47 |
| lifeless | Branched 3512 revision(s). | 22:47 |
| lifeless | real 0m0.957s | 22:47 |
| lifeless | user 0m0.672s | 22:47 |
| lifeless | sys 0m0.124s | 22:47 |
| lifeless | Pieter: I'm really not sure why you say it takes a long time | 22:48 |
| === mario_ is now known as pygi | ||
| thekorn | lifeless, I filed bug 243359 about my 'bzr merge' issue | 22:49 |
| ubottu | Launchpad bug 243359 in bzr "bzr merge shows file as modified although they did not change" [Undecided,New] https://launchpad.net/bugs/243359 | 22:49 |
| Pieter | Vienna:bzr pieter$ time bzr branch 5.0 test2 | 22:49 |
| Pieter | Branched 2635 revision(s). | 22:49 |
| Pieter | real0m23.254s | 22:49 |
| lifeless | Pieter: do you have a shared repo ? | 22:49 |
| Pieter | I tried it on the mysql one | 22:49 |
| lifeless | Pieter: and was that creating a working tree? | 22:49 |
| Pieter | yes | 22:50 |
| lifeless | to both ? | 22:50 |
| Pieter | to both what? | 22:50 |
| lifeless | there were two questions :P | 22:50 |
| Pieter | ah | 22:50 |
| Pieter | shared repo == rich root? | 22:50 |
| Pieter | then, yes | 22:50 |
| lifeless | no, shared repo == 'storage area for texts which multiple branches can use' | 22:51 |
| lifeless | Pieter: can you pastebin 'bzr info' for me | 22:51 |
| jelmer | Pieter, there is nothing particularly faster about rich roots | 22:51 |
| lifeless | jelmer: I'm suspecting a terminology clash | 22:51 |
| Pieter | I meant I did a git init-repo in the top dir | 22:52 |
| Pieter | what's the name for that? | 22:52 |
| Pieter | *bzr | 22:52 |
| lifeless | shared repo | 22:52 |
| Pieter | ah, sorry | 22:52 |
| Pieter | then, yes | 22:52 |
| jelmer | ah, ok | 22:52 |
| lifeless | as opposed to the private repo created by bzr init/bzr branch if there is no shared repo to use | 22:52 |
| Pieter | yes, I did that first, but that's unbearably slow :) | 22:52 |
| lifeless | Pieter: so, jamesh is working on a plugin to provide better defaults for C projects - a shared repo, etc, with no fuss | 22:53 |
| lifeless | Pieter: but thats about better-ui | 22:53 |
| lifeless | Pieter: do you have a few minutes for me to show you our existing equivalent to the 'git switch' workflow ? | 22:54 |
| Pieter | sure | 22:54 |
| lifeless | ok | 22:54 |
| lifeless | first, do you have a no-working-trees file in .bzr/repository/ | 22:54 |
| lifeless | (thats under your shared repo dir itself) | 22:54 |
| Pieter | no | 22:54 |
| lifeless | touch that file | 22:55 |
| lifeless | now, make another new branch | 22:55 |
| Pieter | right | 22:55 |
| Pieter | that's faster | 22:55 |
| lifeless | it should be a little faster :) | 22:56 |
| Pieter | because it doesn't create a working tree :) | 22:56 |
| lifeless | I think it still checks the whole graph depth | 22:56 |
| lifeless | so we can make it faster still | 22:56 |
| lifeless | but yes, its doing less work -> faster | 22:56 |
| lifeless | now | 22:56 |
| lifeless | you need a place to have your source files that you edit | 22:56 |
| awilkins | Who's doing the Windows builds? | 22:56 |
| walkeraj | I realized I forgot to ask one important question. Let's take a scenerio where I have a branch, then I do a cvs checkout on the tree, then commit the branch using bazaar. Would that then overwrite the CVS changes leading to a destructive CVS commit? | 22:56 |
| lifeless | awilkins: I believe markh will be | 22:57 |
| lifeless | Pieter: this place will be a tree, but have no branch itself. and you'll switch it between branches | 22:57 |
| awilkins | lifeless: Hmm, I'm building my own at present because the betas don't get packages | 22:57 |
| === NfNit|oop is now known as NfNitLoop | ||
| awilkins | lifeless: Do the C extensions change much between versions? | 22:57 |
| lifeless | Pieter: anywhere you like - can be outside this repository, or inside - it does not matter | 22:57 |
| lifeless | Pieter: do 'bzr checkout --lightweight PATH_TO_ONE_OF_THESE_BRANCHES' | 22:58 |
| lifeless | awilkins: they can but we try not to | 22:58 |
| awilkins | lifeless: I don't know what it is, but 1.6b2 seems MUCH faster than 1.5, and I'm wondering if it's because I built it myself and perhaps my build has some differences to the officail ones | 22:58 |
| lifeless | awilkins: no, its faster | 22:58 |
| lifeless | awilkins: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png | 22:59 |
| awilkins | lifeless: Is it mostly import times, or are dirstate ops faster too? | 22:59 |
| awilkins | lifeless: I presume those are *nix benches? | 22:59 |
| lifeless | awilkins: I don't know exactly where we won | 22:59 |
| lifeless | awilkins: mac os X | 22:59 |
| lifeless | Pieter: once you've done the checkout | 23:00 |
| lifeless | Pieter: you can cd to it | 23:00 |
| awilkins | lifeless: It's especially pronounced on the branches I'm working with ; they are not deep in history but they do have a lot of files | 23:00 |
| lifeless | Pieter: if you do 'bzr switch BRANCHNAME' where BRANCHNAME is the basename of a sibling of the branch you checkedout (actually, is reachable by ../BRANCHNAME) then bzr will switch without you needing to supply full paths or anything | 23:01 |
| Pieter | lifeless: that's nice, but awfully slow | 23:03 |
| lifeless | Pieter: well; speed we can improve | 23:03 |
| pickscrape | lifeless: those graphs are tres impressive... | 23:03 |
| lifeless | pickscrape: thanks | 23:04 |
| lifeless | Pieter: how slow is slow? seconds? 10's of seconds? and how different were the branches you were switching between? | 23:04 |
| Pieter | it's still running | 23:04 |
| lifeless | Pieter: ! | 23:04 |
| lifeless | Pieter: the checkout, or the switch ? | 23:04 |
| Pieter | the switch | 23:04 |
| Pieter | pieter$ time bzr switch ../5.0 | 23:04 |
| Pieter | Updated to revision 2635. | 23:04 |
| Pieter | Switched to branch: /Users/pieter/m/bzr/5.0/ | 23:04 |
| Pieter | real2m18.943s | 23:04 |
| lifeless | Pieter: so should be able to do 'time bzr switch 6.0' | 23:05 |
| lifeless | Pieter: without the .. | 23:05 |
| lifeless | Pieter: if 6..0 and 5.0 are in the same dir | 23:05 |
| Pieter | ah, that's nice :) | 23:05 |
| Pieter | I actually did ../ to do tab completion :) | 23:06 |
| Verterok | mornin' lifeless | 23:06 |
| lifeless | Pieter: thats what I was trying to say above. its a bit awkward to say 'it will just work' :) | 23:06 |
| walkeraj | or, in that case, would bazaar see the changes CVS had made to the tree and merge properly? | 23:06 |
| lifeless | walkeraj: | 23:06 |
| Pieter | lifeless: yeah, I understood, but when I read that, I'd already done the command :) | 23:06 |
| lifeless | walkeraj: I don't understand the question | 23:07 |
| lifeless | walkeraj: I think this is a case of 'give it a whirl' | 23:07 |
| lifeless | Pieter: if you were switching from 6.0 to 5.0 there are huge differences involved. I can say that we know some performance problems int hat area and are working on them now | 23:07 |
| walkeraj | did you see the earlier line? I was talking about, like you said, having a CVS directory acting as a tree. What I asked was: if I created a branch, then made changes to it, but before committnig those changes with bazaar, did a CVS up on the tree. | 23:08 |
| Peng | jam: Quibble: Re http://jam-bazaar.blogspot.com/2008/06/this-week-in-bazaar_26.html, it's "serve-branches.py", with a hyphen, not an underscore. | 23:08 |
| lifeless | Pieter: if it was between two 5.x branches then I would suspect a bug | 23:08 |
| Pieter | it was 6.0 to 5.0 | 23:09 |
| walkeraj | would committing the branch then destropy the changes downloaded by CVS to the tree, or would bazaar detect that the tree had changed and merge the branch commit? | 23:09 |
| lifeless | walkeraj: bzr will try to preserve your local edits | 23:09 |
| lifeless | walkeraj: e.g. a cvs change that you haven't committed into bzr | 23:09 |
| lifeless | Pieter: right, try something that isn't three years work or whatever it was :) | 23:09 |
| lifeless | Pieter: (that 2m is fixable, but its also not the common case) | 23:10 |
| Verterok | g'afternoon beuno :) | 23:10 |
| lifeless | Verterok: hey! | 23:10 |
| lifeless | Verterok: I'm doing my talk tonight, can I ask for a more recent bzr-eclipse-search screen shot ? | 23:10 |
| Verterok | lifeless: I made some small progress (project/workspace scoping) but it's far from what I wanted. how much hours I have untill deadline? :) | 23:11 |
| walkeraj | Right, but what I'm saying is: since CVS is date-based, what if someone else committed something in CVS to a file I was editing in a branch, and then I did CVS up on the Tree. Would committing my changes in the branch (which itself was based off of an earlier version) then overwrite their changes and commit only my branched version to CVS? | 23:11 |
| lifeless | Verterok: 5 or so ? | 23:11 |
| Pieter | lifeless: it's just that, everything I try something with bzr, I have to wait.. merging is slow, "bzr log" is slow, branching is slow, switching is slow, it's kinda frustrating | 23:11 |
| lifeless | Verterok: I guess I need to get bzr-eclipse going too | 23:11 |
| lifeless | Pieter: are you primarily working with mysql in bzr ? | 23:12 |
| Verterok | lifeless: sure, I can upload some new screens | 23:12 |
| beuno | Verterok, I didn't have time to warn you so you could hide :p | 23:12 |
| Pieter | lifeless: I'm testing mysql because the repository I'd convert is about the same size | 23:12 |
| lifeless | Pieter: in history, or filecount, or both ? | 23:13 |
| Pieter | history primarily | 23:13 |
| lifeless | Pieter: ok. so, uhm, can I make some forward looking statements ? ;) | 23:13 |
| lifeless | Pieter: also, try 'log --line' | 23:13 |
| Pieter | sure | 23:13 |
| Pieter | (log --line doesn't show full history, right? only on the 'mainline') | 23:13 |
| Verterok | beuno: I read the backlog, so no problem :) | 23:14 |
| lifeless | Pieter: yah | 23:14 |
| Verterok | lifeless: I'll be glad to help in any means to get bzr-eclipse going | 23:14 |
| walkeraj | in other words, if I directly edited a file in the tree with a text-editor (which is basically what a CVS up would do), would a branch merge destroy that change? | 23:14 |
| lifeless | Pieter: merging is slow - it can be slow for a couple of reasons; one is having a lot to do; the other is defects in bzr - either code or current disk layout | 23:15 |
| lifeless | Pieter: I don't find merging slow for instance: | 23:15 |
| lifeless | well, when eclipse isn't starting up I don't find it slow :P | 23:15 |
| Pieter | :) I was merging the 5.1 branch to 6.0 in mysql, it takes 12 seconds here, for something that differs only 6 commits or so | 23:16 |
| * lifeless waits to get his disk back | 23:16 | |
| awilkins | Verterok: setupBestAvailableBackend, according to my IDE, is never called. | 23:17 |
| lifeless | so this is about 60 commits | 23:17 |
| lifeless | 3 conflicts encountered. | 23:17 |
| lifeless | real 0m5.464s | 23:17 |
| lifeless | user 0m5.092s | 23:17 |
| Verterok | awilkins: hi, do you mean in bzr-eclipse? | 23:17 |
| lifeless | sys 0m0.256s | 23:17 |
| awilkins | Verterok: Unless I need to grab branches for the eclipse plugins as well as the library | 23:18 |
| awilkins | Verterok: That could be it... | 23:18 |
| lifeless | Pieter: but if I do: | 23:18 |
| lifeless | bzr --lsprof-file foo.callgrind merge ../shallow-branch/ | 23:18 |
| lifeless | I can then pop it open in kcachegrind and fix its speed some more :P | 23:18 |
| awilkins | Verterok: I don't see any XMLRPC specific Eclipse plugin branches in LP though | 23:19 |
| lifeless | hmm I'm not meaning to say 'fix it for yourself'. I'm meaning to say - | 23:19 |
| lifeless | please filea bug saying its slow with such a callgrind file | 23:19 |
| Verterok | awilkins: you 're right, I didn't merge it in trunk yet | 23:19 |
| lifeless | and I'll see if there is a low hanging fruit we've missed, or if some of the stuff I know folk are working on will help in the short term | 23:19 |
| Verterok | awilkins: I assumed that you need the xmlrpc for your in house project :P | 23:20 |
| walkeraj | lifeless: in other words, if I directly edited a file in the tree with a text-editor (which is basically what a CVS up would do), would a branch merge destroy that change? | 23:20 |
| awilkins | Verterok: My in-house project is using both the Eclipse UI plugins and the client code | 23:20 |
| lifeless | walkeraj: it would not | 23:20 |
| lifeless | walkeraj: it might conflict, but it won't destroy | 23:21 |
| awilkins | Verterok: Actually, I don't really care about XMLRPC for my client-only code ; it's a couple of status calls and some other bits | 23:21 |
| Verterok | awilkins: oh, nice! I didn't know :) | 23:21 |
| awilkins | Verterok: But the Eclipse projects have over 3400 files in them and really need a speed boost on the VCS plugin | 23:21 |
| lifeless | Verterok: so where are the bzr-eclipse install instructions | 23:21 |
| walkeraj | lifeless: so once I start doing this (after the tutorial of course ;), I needn't worry about making destructive cvs commits? | 23:21 |
| Verterok | awilkins: I can push my dev branch to lp, so you can use that | 23:22 |
| awilkins | That would be much appreciated | 23:22 |
| Verterok | lifeless: http://bazaar-vcs.org/BzrEclipse ;-) | 23:22 |
| walkeraj | I suppose it would be smart to get updates to my branches before committing them, thus ensuring that they were up-to-snuff with the CVS-controlled tree... | 23:22 |
| awilkins | It's not a fast Eclipse RCP anyway ; it's Borland Together and it really doesn't like 3400 class models either :-) | 23:22 |
| Pieter | hmm | 23:23 |
| Verterok | awilkins: I also have a merge (work in progress) with your eclipse.dev and plugin.dev branches if you are interested | 23:23 |
| lifeless | walkeraj: as a design principle, bzr tries to be very obvious about what is going on, and to never ever discard user data | 23:23 |
| Pieter | lifeless: I think I found a bug? | 23:23 |
| Verterok | lifeless: I can build it as a single plugin/bundle with the search feature, so it's easier to setup (and with the xmlrpc client, so it's a *bit* snapier) | 23:23 |
| lifeless | Pieter: cool | 23:23 |
| lifeless | Pieter: I love bug reports | 23:24 |
| Pieter | lifeless: http://pastie.textmate.org/private/juncspdiusl6alpqjzuxg | 23:24 |
| lifeless | Verterok: please! | 23:24 |
| Verterok | lifeless: eclipse-3.3, right? | 23:24 |
| lifeless | I'm just going for breakfast | 23:24 |
| walkeraj | lifeless: I don't mean to be asking fringe use-case scenerio questions here, but I just wanted to make sure I could be reasonably safe testing out baz by basically using an existing CVS directory as a tree. | 23:24 |
| lifeless | Verterok: hardy : 3.2.2 | 23:24 |
| walkeraj | And it seems I can. | 23:24 |
| lifeless | walkeraj: well, I would always say test on a clean checkout | 23:25 |
| lifeless | walkeraj: because while bzr may be as safe as houses you could still get confused :) | 23:25 |
| Verterok | lifeless: mmm....that's old, I'll check what I can do :( | 23:25 |
| walkeraj | lifeless: sure. All I really want to avoid is making destructive cvs commits. In such a scenerio, would there be any reason to run an update on my branches after each CVS up on the tree? | 23:26 |
| awilkins | Verterok: If you have an ongoing merge, that's fine, but I'll probably try to merge my branches with your dev ones locally anyway | 23:26 |
| walkeraj | lifeless: or would conflicts still be conflicts either way? | 23:26 |
| lifeless | walkeraj: oh, well 'cvs diff' before any cvs commit - standard good practice:) | 23:27 |
| walkeraj | hah. True indeed. | 23:27 |
| walkeraj | ok. Thanks. | 23:27 |
| awilkins | Although I have done no work on that log cache, I still think some of the structural changes and API refactoring is worthwhile | 23:27 |
| Verterok | awilkins: ok, I have it almost in place, I'll publish those branches if you need them, just ping me | 23:27 |
| awilkins | Verterok: I've merged my changes for BazaarClient already, but I'm not sure how well they fit with the new "xml<command>" structure | 23:28 |
| Verterok | awilkins: I some of that in a bracnh that is a merge with your java-client-lib code | 23:29 |
| jam | Peng: fixed | 23:33 |
| Peng | jam: Thanks. :) | 23:34 |
| Peng | I just wanted to get this off my chest: Loggerhead is great! Squee! | 23:35 |
| awmcclain_ | Ug. How do I get bzr to create new branches with group +w? | 23:36 |
| LarstiQ | lifeless: hmm, could the axes in http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png start at the origin? | 23:39 |
| LarstiQ | lifeless: (well, the time one anyway ;) | 23:39 |
| === kiko-afk is now known as kiko | ||
| LarstiQ | Pieter: thanks for goodlog.txt btw | 23:41 |
| LarstiQ | lifeless: where are you at that you're giving a talk? | 23:42 |
| Verterok | awilkins: I pushed my dev branch and xmlrpc-integration (which is a merge with your client-dev branch, so it use enum, etc) | 23:42 |
| LarstiQ | heya Verterok | 23:42 |
| Verterok | hi LarstiQ :) | 23:43 |
| Verterok | awilkins: I must warn, all that code is quite bleeding edge :) | 23:44 |
| Verterok | awilkins: now pushing my bzr-eclipse integration (that match xmlrpc-integration) | 23:48 |
| rick_h_ | anyone give me a hand getting the avahi plugin going for bzr? | 23:51 |
| rick_h_ | when I installed the plugin it went into my plugins dir | 23:51 |
| rick_h_ | using advertise I get an error that Unable to load plugin 'avahi' from '/home/rharding/.bazaar/plugins' | 23:52 |
| rick_h_ | and if I try to run setup on the plugin I get ImportError: No module named dbus.server_mainloop | 23:52 |
| rick_h_ | but I have python-dbus installed as well as python-avahi | 23:52 |
| LarstiQ | rick_h_: hmm, only thing I can think of right now is if you installed the dbus service file | 23:55 |
| rick_h_ | LarstiQ: any hint on where I'm looking for that? | 23:56 |
| LarstiQ | rick_h_: yeah, the bzr-dbus README lists all steps involved | 23:59 |
| LarstiQ | rick_h_: (and the org.bazaarvcs.plugins.dbus.Broadcast.service is right next to it) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
