| jelmer | lifeless: those are good goals | 00:00 |
|---|---|---|
| jelmer | lifeless: and I think your existing proposal is in line with those goals, so +1 | 00:01 |
| lifeless | thanks. | 00:01 |
| jelmer | lifeless: I'll keep thinking about a good way to have Samba use this, while not losing our existing progress bar functionality | 00:02 |
| lifeless | I'm open to having a heirarchy | 00:02 |
| lifeless | something like | 00:02 |
| lifeless | progress: 5 | 00:03 |
| lifeless | progress_push: | 00:03 |
| lifeless | <suite runs> | 00:03 |
| lifeless | progress_pop: | 00:03 |
| lifeless | progress_push: | 00:03 |
| lifeless | <suite 2> | 00:03 |
| lifeless | progress_pop: | 00:03 |
| * emmajane waves from her flaky wifi connection at oscon | 00:04 | |
| lifeless | I think push/pop is a better idiom than fractions, because fractions require global knowledge in each stream | 00:04 |
| lifeless | hi emmajane | 00:04 |
| emmajane | lifeless: hey :) | 00:04 |
| lifeless | emmajane: have you played with 2a formats yet? | 00:04 |
| * jelmer waves back from a less flay wifi connection at debconf | 00:04 | |
| emmajane | lifeless: not yet. | 00:04 |
| jelmer | lifeless: Yeah, that makes sense | 00:04 |
| emmajane | jelmer: nice :) | 00:04 |
| jelmer | lifeless: actually, push/pop seem to match start-testsuite/stop-testsuite pretty well :-) | 00:05 |
| dazjorz | if I understand correctly, "bzr pull" is for when you want to keep two repositories *exactly* the same, and "bzr merge" is when you want to get your changes from a master repository into your local repository? | 00:05 |
| dazjorz | (which has been modified) | 00:05 |
| jelmer | dazjorz: basically, yeah | 00:05 |
| dazjorz | nice, I like bzr's syntax :O | 00:06 |
| dazjorz | and its integration with svn is one of the best surprises I've had in a while :P | 00:06 |
| poolie | hi emmajane | 00:07 |
| emmajane | poolie: hey :) | 00:07 |
| emmajane | poolie: I got your email and that looks fine. I need to get a real mail client so that i can do offline email. gmail != win. | 00:07 |
| dazjorz | emmajane: gmail == win, just configure your client to do imap :p | 00:07 |
| poolie | emmajane, i got an HTC Magic android recently and it does gmail on flakey connections very well | 00:07 |
| poolie | and also imap | 00:08 |
| emmajane | nice! | 00:09 |
| emmajane | Clearly I just need better toys. :) | 00:09 |
| emmajane | dazjorz: I'm just doing browser-based email right now. I installed ubuntu about 12 hours before I left onto my netbook and forgot things like a useful mail client (sorry evolution) | 00:09 |
| lifeless | evolution needs some | 00:10 |
| emmajane | I'm even using pidgin for irc. It feels so... wrong. | 00:11 |
| poolie | it's a shame, 12h would have been about enough time for evolution to sync too :) | 00:11 |
| emmajane | LOL | 00:11 |
| fullermd | mutt's worked fine for the last 11 years or so :p | 00:11 |
| * dazjorz uses Quassel for IRC, Thunderbird for e-mail | 00:12 | |
| emmajane | fullermd: I have too many family members who insist on HTML email and clients that want to send attachments. | 00:12 |
| emmajane | fullermd: I used mutt for years with righteous indignation though. | 00:12 |
| fullermd | Nothing a little tasering can't cure... | 00:12 |
| * emmajane chuckles. | 00:12 | |
| emmajane | I'll be sure to let them know. | 00:12 |
| emmajane | my main computer has Kontact and Xchat-gnome. | 00:13 |
| lifeless | poolie: I fixed that bug :P | 00:13 |
| poolie | lifeless: i was thinking last night about reconfigure | 00:13 |
| lifeless | dangerous times | 00:13 |
| lifeless | how was the talk? | 00:13 |
| poolie | "lifeless is right, writing code really is easier than thinking | 00:13 |
| poolie | or more specifically, easier than talking about it in advance" | 00:14 |
| poolie | sometimes. | 00:14 |
| poolie | the talks were ok | 00:14 |
| poolie | jml's was good but not new to me | 00:14 |
| poolie | the other one, about ocamlp4 was, well, ok | 00:14 |
| poolie | summary is that you can use macros to let you write your program in more amenable syntax | 00:15 |
| poolie | ... even in ocaml | 00:15 |
| emmajane | poolie: are you at debconf too? | 00:15 |
| poolie | nup, that was fp-syd, the sydney functional programming seminar | 00:15 |
| * emmajane nods | 00:16 | |
| lifeless | poolie: so, reconfigure was easier to do that think about ? | 00:17 |
| poolie | yep | 00:17 |
| poolie | well, easier to do this specific case than to describe the general one | 00:17 |
| poolie | i think there is some kind of general lesson here but | 00:17 |
| poolie | one step at a time | 00:17 |
| lifeless | :) | 00:17 |
| jelmer | hmm, I guess I should start doing reviews on lp:bzr now ... :-) | 00:44 |
| lifeless | jelmer: yes indeed | 00:45 |
| jelmer | abentley: any chance you could remove bzr-gtk, bzr-stats and trac-bzr from bb ? | 00:48 |
| jelmer | abentley: (we discussed switching bzr-gtk to lp during UDS, and the other two projects already are using lp rather than bb in practice) | 00:48 |
| jelmer | abentley: there's one open merge request in bzr-gtk atm which I can migrate manually if necessary | 00:49 |
| abentley | jelmer: Hmm. I'm sure there's a way, but I don't have code that actually *deletes* projects rather than adding them. | 00:54 |
| jelmer | abentley: ah, ok | 00:54 |
| jelmer | abentley: We can just point out lp to people who use bb I guess | 00:55 |
| abentley | jelmer: I'll do it, but I can't do it immediately. | 00:55 |
| jelmer | abentley: thanks, no hurry | 00:56 |
| dazjorz | jelmer: for bzr-svn, does "bzr commit" push the patch forward to the SVN repository already? | 00:57 |
| jelmer | dazjorz: in a checkout, yes | 00:57 |
| dazjorz | jelmer: can I tell it to keep the changes local until I run bzr push, or something like that? :) | 00:57 |
| jelmer | dazjorz: you can keep the changes local if you use a standalone branch | 00:58 |
| jelmer | dazjorz: this works in the same way as it would for "native" bzr branhces | 00:58 |
| dazjorz | I see | 00:58 |
| dazjorz | can I make a standalone branch of an SVN repository, and alternatively, can I make a standalone branch as a copy of this dual-bzr-svn-checkout I already have? :) | 00:58 |
| jelmer | dazjorz: yes | 00:59 |
| dazjorz | jelmer: oooh, this seems to be a bug... | 00:59 |
| dazjorz | jelmer: I ran "bzr commit", and in a different window, I edited another previously not modified file | 01:00 |
| jelmer | dazjorz: ? | 01:00 |
| dazjorz | the ChangeLog | 01:00 |
| poolie | spiv, shall we meet up today? | 01:00 |
| dazjorz | then the commit went through, but it didn't send in ChangeLog; now, ChangeLog has its new contents but both bzr and svn say it's up-to-date with the repository when it actually isn't | 01:00 |
| jelmer | dazjorz: ah, this is a svn lightweight checkout? | 01:01 |
| spiv | poolie: good morning, | 01:02 |
| jelmer | dazjorz: if you can reproduce this, please file a bug (including the steps to reproduce) | 01:02 |
| dazjorz | jelmer: I think so, I just ran "bzr status" in my SVN checkout | 01:02 |
| lifeless | poolie: You still have a chinese lunch scheduled with me ;P | 01:02 |
| dazjorz | jelmer: I'll do that | 01:02 |
| dazjorz | jelmer: I'll file it tomorrow :) | 01:02 |
| spiv | poolie: sounds good. First I'll call. | 01:04 |
| emmajane | talk time. woo! :) | 01:04 |
| * emmajane turns off her flaky wireless. | 01:04 | |
| jelmer | dazjorz: thanks | 01:05 |
| poolie | beuno: hi? | 01:08 |
| lifeless | poolie: were we going to do that lunch we talked about last week? | 01:11 |
| poolie | ah, ok | 01:13 |
| poolie | i'm double booked, can we push that back again | 01:13 |
| lifeless | lol sure | 01:13 |
| lifeless | spiv: have you seen the bugs about pulling cross format? | 01:23 |
| lifeless | spiv: I think your new one is a dupe | 01:24 |
| spiv | lifeless: quite possibly, none of them jumped out at me as the one obvious dupe though so I figured I'd file and let someone more knowledgeable dupe it if so. | 01:24 |
| spiv | And the test patch may be useful. | 01:25 |
| lifeless | spiv: ack | 01:26 |
| lifeless | spiv: look at bugs by newest first | 01:26 |
| lifeless | I targeted one against 2.0 this morning | 01:26 |
| spiv | lifeless: "NoSuchRevision error when branching with rocketfuel-get"? (402778) | 01:28 |
| spiv | Could well be. | 01:29 |
| spiv | Or "upgrading branch on launchpad to 2a resulted in missing revision error" (399140)? | 01:30 |
| lifeless | spiv: 402778 specifically | 01:39 |
| lifeless | possible 399140 as well, mtaylors upgrade bug | 01:40 |
| spiv | lifeless: well, it's not clear to me that they are dupes. If you're sure then of course go ahead, but I'm not planning to dig deeper into that today. | 01:45 |
| lifeless | spiv: I'm not 100% | 01:46 |
| lifeless | spiv: I suggest your new bug be 2.0 targeted though | 01:46 |
| spiv | Fair enough. | 01:53 |
| igc | morning | 02:01 |
| spiv | igc: g'morning. | 02:02 |
| igc | hi spiv! | 02:03 |
| RenatoSilva | How can CVS be just cvs.exe with ~700KB and Bazaar ~54MB (without plugins)? | 02:14 |
| RenatoSilva | ok remove 17,5MB for python's dll and library | 02:16 |
| RenatoSilva | It is 36,5MB yet! | 02:16 |
| RenatoSilva | it seems that it's not strictly because of bazaar itself, but secondary stuff like qt gui, etc... | 02:19 |
| lifeless | and docs | 02:21 |
| lifeless | are you talking about a windows binary install? | 02:21 |
| RenatoSilva | yes | 02:21 |
| RenatoSilva | other ones too | 02:22 |
| lifeless | we bundle everything | 02:22 |
| RenatoSilva | I just need to get the essential files | 02:22 |
| RenatoSilva | compared to cvs.exe | 02:22 |
| lifeless | the core (source, docs, tests) is 18MB uncompressed | 02:22 |
| RenatoSilva | docs are not essential | 02:22 |
| RenatoSilva | cvs.exe does not contain such docs | 02:22 |
| lifeless | and if you compress it, 4.6MB | 02:23 |
| RenatoSilva | just the part whcih would just work,, I mean | 02:23 |
| lifeless | well, this is true | 02:23 |
| RenatoSilva | just bzr.exe + python files | 02:23 |
| RenatoSilva | but I don't know if any other files are needed | 02:24 |
| RenatoSilva | dlls etc | 02:24 |
| lifeless | however, its our experience that the more things to download, and options about it, the easier it is for users to download the wrong thing | 02:24 |
| lifeless | so we just provide a single package with it all, to make it as likely to work as possible. | 02:24 |
| RenatoSilva | I just want to compare the size of cvs.exe with {bzr essential files} | 02:24 |
| lifeless | why though? | 02:25 |
| lifeless | its not like they do the same thing... | 02:25 |
| RenatoSilva | it's noteworthy you can have a full-featured cvs environment with just a ~700kb executable :) | 02:25 |
| lifeless | I can have a full featured OS with a 1.44MB floppy too, but that doesn't make it useful or even desirable | 02:28 |
| lifeless | where full featured, means 'very well defined and not extensible or robust' | 02:28 |
| lifeless | :) | 02:28 |
| dazjorz | hm, how did kernels ever fit on a 1.44 mb floppy | 02:30 |
| dazjorz | they supported nothing? | 02:30 |
| dazjorz | my current Mach kernel is 10 mb | 02:30 |
| dazjorz | all vmlinuz kernels on my Linux machine are at least 3.6 mb :P | 02:30 |
| dazjorz | just *everything* compiled out or so? :) | 02:30 |
| lifeless | dazjorz: I remember one particular microkernel unix which had a GUI web browser, web server, generic PCI networking and disk, all on a floppy | 02:31 |
| dazjorz | whoa nice | 02:32 |
| lifeless | damned if I can remember the name though | 02:32 |
| dazjorz | even damn small linux is 50 mb now | 02:32 |
| lifeless | anyhow, for embedding you use things like busybox, strip docs, man pages, compile with -Os, compress heavily | 02:33 |
| lifeless | RenatoSilva: I don't mean to say that wanting bzr to be small is bad; its a good thing to want | 02:33 |
| lifeless | RenatoSilva: but comparing the size of two hugely different tools with wildly different capabilities, written in totally different languages, isn't a meaningful comparison | 02:34 |
| lifeless | RenatoSilva: it can be summarised as 'compiled C is smaller than python' | 02:34 |
| RenatoSilva | lifeless: well, it is more about the cvs size | 02:34 |
| lifeless | RenatoSilva: that its small? Its mainly small because it doesn't do much. Try 'cvs push'. or | 02:35 |
| lifeless | 'cvs uncommit' | 02:35 |
| RenatoSilva | lifeless: we like it or not, bzr x cvs is more about vcs x dvcs than any super feature of bzr missing in cvs, or than cvs sucks absolutely and does not work | 02:36 |
| RenatoSilva | lifeless: maybe as I become more familiar with both tools I can get the complexity involved in a dvcs or in bzr | 02:37 |
| RenatoSilva | lifeless: actually I'm not that impressed with bzr size, but with CVS | 02:37 |
| RenatoSilva | lifeless: we can do more or less the same sort of work we do with bzr | 02:37 |
| AfC | lifeless: lost cause, Robert. | 02:39 |
| RenatoSilva | lifeless: I was considering adopting bzr at work, but cvs is enougth for us. At least, it does the basic job. A possible argument would be the leak of atomic commits in CVS, however Eclipse does magic. We just need to define ourselves 2 points of comparison (tags, branches or dates), and the result is the same as viewing a revision in bzr: you see a list of modified files, each one with the changes made. | 02:41 |
| lifeless | RenatoSilva: We'll be here when you're ready :) | 02:41 |
| lifeless | RenatoSilva: Its a shame that bzr isn't doing what you need (and I'm really not clear what that is, download size surely can't be it... | 02:42 |
| lifeless | not if you're using eclipse! | 02:42 |
| RenatoSilva | I'm just thinking of tracking each commit. Currently we'd have to create a tag for each commit, which is a bit non-sense. I've heard cvs 1.12 has commit-ids which would make it possible to emulate atomic commits, but I don't know if Eclipse supports it | 02:42 |
| lifeless | RenatoSilva: CVS is essentially dead | 02:43 |
| lifeless | RenatoSilva: I really wouldn't hold out any hope for improvements in it, or support for it. | 02:43 |
| lifeless | if you could make sure bugs are filed for the things that make bzr not comfortable for you, I'd appreciate that. | 02:44 |
| RenatoSilva | lifeless: if we started from nothing, bzr or another modern vcs like git or hg would certaintly be my option. The problem is that we have all of our code base under cvs. It would need a migration _effort_, including training to the whole team. Also, Eclipse's CVS support is _very_ mature (Eclipse itself uses CVS), while BzrEclipse is still in beta (ok I solved some bugs and I could help the project more, but CVS in Eclipse is far more mature and does magic | 02:46 |
| lifeless | RenatoSilva: Yes, migrating does take investment | 02:48 |
| RenatoSilva | CVS is not dead. I don't like these flamewars. When I go to #cvs, they say the contrary, and that some dvcs (git I guess) is not a vcs, but just a patching system | 02:48 |
| lifeless | ;) | 02:48 |
| lifeless | they may mean darcs, which is very patch focused | 02:48 |
| AfC | RenatoSilva: admittedly, you are in the Bazaar hackers' IRC channel, so you need to expect a certain bias. The people here aren't in the business of fixing CVS. | 02:48 |
| RenatoSilva | certaintly it is git, bzr or hg. Can't recall | 02:49 |
| RenatoSilva | AfC: bias? | 02:49 |
| lifeless | preconceptions | 02:49 |
| RenatoSilva | I think that's really really bad | 02:49 |
| RenatoSilva | we are technicall people | 02:49 |
| lifeless | Yup. And I've spent the last 10 years working on/with/around VCS systems | 02:50 |
| RenatoSilva | we shouldn't be sfanatic I think | 02:50 |
| AfC | RenatoSilva: Yes, but this is the Bazaar IRC channel, not the "let's all just chat about what CVS isn't good at" channel. We had that conversation 15 years ago. | 02:50 |
| lifeless | including CVS - written a python implementation of the protocol (nods to Kinnison who did a chunk of that too) | 02:50 |
| lifeless | *I* am not being fanatic. I did consider fixing CVS at one point. Why I didn't go down that path is a fascinating dicussion, but not one to have right now. | 02:51 |
| lifeless | bzr isn't perfect | 02:52 |
| lifeless | theres lots of things we haven't got right; and many things we have. | 02:52 |
| lifeless | anyhow, I'm *primarily* interested in knowing what does and doesn't work for you with bzr | 02:58 |
| lifeless | because that helps us make bzr better than it is | 02:58 |
| tethridge | I'm trying to get loggerhead setup on a hardy system. I've ran through the instructions and I'm able to start it, but it dies immediately. Nothing in the logs. Anybody know what is going on? | 02:59 |
| lifeless | tethridge: when you say dies, what do you mean? | 02:59 |
| lifeless | and how are you starting it? | 03:00 |
| tethridge | no process | 03:00 |
| tethridge | the pid is created and then it disappears | 03:00 |
| lifeless | there is no output at all? | 03:00 |
| tethridge | I'm just trying to use the start-server script to verify it works before I setup the script in init.d | 03:00 |
| RenatoSilva | I do agree that bzr/git/hg/dvcs is so much better than CVS, I just don't think that CVS sucks completely. We can live with it and that's what matters for me. These software 'gangs' are so prejudicial to the sofwtare world ihmo. | 03:00 |
| tethridge | no, | 03:00 |
| tethridge | strange | 03:00 |
| lifeless | tethridge: serve-branches, or bzr serve --http, are the current ways to start loggerhead | 03:01 |
| tethridge | it tells me "Launching loggerhead into the background" and it tells me the location of the pid file, but that is it | 03:01 |
| tethridge | this is the 1.10 release | 03:01 |
| lifeless | RenatoSilva: I think you've taken me saying 'essentially dead' and turned it into a much larger statement than I meant to make. | 03:01 |
| lifeless | RenatoSilva: I didn't say, nor did I mean to imply, that CVS sucks | 03:02 |
| RenatoSilva | lifeless: I think you're more open than them actually | 03:02 |
| spm | tethridge: suggest strace'ing the startup and seeing if anything obviously broken leaps out | 03:03 |
| lifeless | RenatoSilva: what can I do to help you at the moment? | 03:03 |
| tethridge | using serve-branches starts it and keeps it going | 03:03 |
| RenatoSilva | lifeless: sorry, I was just talking | 03:03 |
| lifeless | RenatoSilva: nothing to apologise for | 03:03 |
| lifeless | I'm going to go put my head down and get some complex stuff sorted out | 03:04 |
| lifeless | later y'all | 03:04 |
| tethridge | thanks for the help | 03:04 |
| * igc lunch | 03:13 | |
| cogita | hello all. I have a question. According to StackOverflow | 03:36 |
| cogita | (http://stackoverflow.com/questions/97850/version-control-on-a-2gb-usb-drive) | 03:36 |
| cogita | its posible to install Bazaar on a USB drive using portable Python as the python framework. | 03:36 |
| cogita | I was wondering if there was anyone who could tell me which version of Portable python to use, and how to install Bazaar correctly for this solution? | 03:36 |
| dazjorz | hmmm | 04:10 |
| dazjorz | bzr push in my bazaar repository checked out from svn, says "no push location known or specified" | 04:11 |
| dazjorz | shouldn't it have remembered that when I checked out from svn? :) | 04:11 |
| poolie1 | dazjorz: is it a checkout or a separate branch? | 04:11 |
| poolie1 | if it's a checkout, you don't need to push, committing will implicitly do it | 04:11 |
| dazjorz | ugh, netsplits | 04:12 |
| dazjorz | poolie1: it's a seperate branch | 04:12 |
| spiv | Huh, test_branch_from_trivial_stacked_branch_streaming_acceptance in blackbox tests blows up if you change it to use a 2a branch. | 04:12 |
| poolie1 | bzr doesn't assume that you want to push back on top of the parent | 04:13 |
| dazjorz | ah, and then "bzr pull" / "bzr up" didn't tell me there were new svn revisions to merge, but bzr merge handled them nicely | 04:13 |
| dazjorz | I figured it would be something like that :) | 04:13 |
| dazjorz | hmmm | 04:14 |
| dazjorz | okay so now I have a merge conflict between a committed revision on my checkout, and a pulled/merged revision from SVN | 04:14 |
| dazjorz | when I run bzr status, I see "pending merge tips:", then the remote revision which made for a conflict in Changelog which I already resolved (bzr resolved ChangeLog after editing it) | 04:15 |
| dazjorz | so what now? :/ | 04:15 |
| dazjorz | running "bzr merge" again makes the conflict reappear | 04:15 |
| dazjorz | any ideas? poolie1 maybe? | 04:16 |
| lifeless | you need to commit | 04:17 |
| lifeless | the sequence for merge is: | 04:17 |
| lifeless | merge; resolve if needed; commit | 04:17 |
| dazjorz | even if bzr diff shows no differences atm? | 04:17 |
| lifeless | if 'bzr st' shows anything | 04:18 |
| lifeless | such as a pending merge | 04:18 |
| lifeless | or altered files | 04:18 |
| dazjorz | okay | 04:18 |
| * dazjorz wonders how that will show up on SVN | 04:18 | |
| lifeless | well without the commit it can't show up on svn :) | 04:18 |
| dazjorz | so, lifeless, what exactly am I committing when I commit now? a sign to bzr that says "merges nicely against that and that remote revision" ? | 04:19 |
| lifeless | yes | 04:19 |
| lifeless | if you don't want to make that record, you can 'bzr revert' | 04:19 |
| dazjorz | hm okay | 04:19 |
| lifeless | to get rid of the pending merge | 04:19 |
| lifeless | but it sounds like *it does not merge cleanly* | 04:19 |
| dazjorz | that will revert the commit I already made, right? | 04:19 |
| lifeless | so in fact, you're recording what it should look like when merged. | 04:20 |
| lifeless | no, revert doesn't get rid of commits | 04:20 |
| lifeless | uncommit gets rid of commits | 04:20 |
| dazjorz | lifeless: so if I already did the merge itself and everything is resolved, if I run bzr revert now I have to do that again when I run bzr merge, but when I bzr commit I actually get, from the outside, an "empty" commit that just makes for a better merge against that remote revision? | 04:21 |
| dazjorz | oh shi- | 04:21 |
| lifeless | I have no idea what you just said | 04:21 |
| lifeless | perhaps you should start from the beginning :) | 04:22 |
| dazjorz | 1) I made a bzr branch from a SVN checkout | 04:22 |
| dazjorz | 2) while I was editing, the SVN checkout got another commit that changed the ChangeLog | 04:22 |
| dazjorz | 3) I ran 'bzr commit' on my changes, but when I wanted to push, it said I had to merge | 04:22 |
| dazjorz | 4) I ran 'bzr merge', and got a conflict on ChangeLog | 04:23 |
| lifeless | is there a 5? | 04:23 |
| dazjorz | 5) I resolved the conflict and I'm trying to figure out what to do next | 04:23 |
| lifeless | commit | 04:23 |
| lifeless | until you do this commit the merge isn't saved | 04:23 |
| dazjorz | okay oh well | 04:23 |
| dazjorz | we'll just see how it looks in svn :p | 04:23 |
| lifeless | bzr diff should be showing you the contents of the change made to svn in 2) | 04:24 |
| lifeless | if bzr diff *isn't* showing you that contents, then you've actually done something else in the middle, that you've forgotten about | 04:24 |
| dazjorz | it showed me nothing | 04:24 |
| fullermd | A perhaps better solution would have been to go the other way, and use the svn checkout to gate changes in/out of svn. | 04:24 |
| lifeless | did you perhaps run 'bzr revert .' ? | 04:24 |
| spiv | Hmm, "bzr commit" on a fresh stacked 2a repository looks like it can make a repo that fails without the fallback present. | 04:24 |
| dazjorz | lifeless: for the life of me, I don't know that command, so I didn't run it, no :P | 04:25 |
| lifeless | dazjorz: ok, do this for me | 04:25 |
| lifeless | 'bzr revert' | 04:25 |
| lifeless | 'bzr st' | 04:25 |
| lifeless | (should show nothing) | 04:25 |
| lifeless | 'bzr merge' - should conflict again | 04:25 |
| dazjorz | btw, I just committed the empty revision 4300 and bzr commit said, under the line "this line and those below won't appear", that there was a pending merge, and just that | 04:25 |
| dazjorz | nothing else | 04:25 |
| dazjorz | oh | 04:25 |
| lifeless | 'bzr diff' - should show the changes made to svn in 2), as well as the conflicts you had | 04:25 |
| lifeless | dazjorz: ok, lets roll it back | 04:26 |
| lifeless | 'bzr uncommit' | 04:26 |
| dazjorz | want me to uncommit it? :) | 04:26 |
| lifeless | that will pop off your commit | 04:26 |
| dazjorz | do I need to add 4300 or will it default to the last local commit? :) | 04:26 |
| lifeless | 'bzr revert' - that will discard any changes that were in the commit | 04:26 |
| lifeless | run what I put between the ' ' ;) | 04:26 |
| dazjorz | okay, done | 04:26 |
| lifeless | 'bzr st' - should show nothing | 04:26 |
| dazjorz | it shows nothing | 04:27 |
| lifeless | 'bzr merge' - should conflict | 04:27 |
| dazjorz | yep | 04:28 |
| dazjorz | 1 conflict in ChangeLog | 04:28 |
| lifeless | bzr st | 04:28 |
| lifeless | sorry, 'bzr st' - that should list the changes made to svn | 04:29 |
| lifeless | including ChangeLog | 04:29 |
| dazjorz | I see modified ChangeLog, unknown ChangeLog.{BASE,OTHER,THIS], conflicts: Text conflict in ChangeLog | 04:30 |
| lifeless | sounds like the only changes made to svn were to ChangeLog :) | 04:30 |
| dazjorz | and a pending merge tip, dazjorz 2009-07-23 [log message for the SVN commit] | 04:30 |
| dazjorz | lifeless: yep, in that commit, the only change was the ChangeLog | 04:31 |
| lifeless | ok good | 04:31 |
| lifeless | edit the ChangeLog and resolve the conflict | 04:31 |
| lifeless | then run 'bzr resolve' | 04:31 |
| dazjorz | done | 04:31 |
| lifeless | and 'bzr diff' should show you the change still, but no long conflicted with <<<< markers | 04:31 |
| dazjorz | bzr diff shows no output | 04:32 |
| lifeless | so , when you resolve, you're just deleting the svn changes? | 04:32 |
| dazjorz | note that I already locally committed (not pushed) the change that conflicted with the SVN revision | 04:32 |
| lifeless | ah | 04:32 |
| lifeless | ok, *thats* why you're seeing no difference | 04:32 |
| dazjorz | lifeless: no - the thing is, my commit made the same changes to ChangeLog, plus one extra line, which is in that committed commit ;) | 04:32 |
| lifeless | 'bzr commit' | 04:32 |
| dazjorz | lifeless: vim shows me "----- This line and the folowing will be ignored ------" and below that one pending merge, the SVN revision | 04:33 |
| dazjorz | is that all ok ? :) | 04:33 |
| lifeless | yes | 04:33 |
| lifeless | here is whats happening | 04:33 |
| lifeless | you're getting a false conflict; we're conflicting where it would be better if we didn't | 04:33 |
| lifeless | once you resolve it you have no textual differences. | 04:33 |
| lifeless | the commit says 'the way to resolve this conflict is to use this new version of ChangeLog', which happens to be the same as you already had. | 04:34 |
| lifeless | in general it would be different. | 04:34 |
| dazjorz | ah, okay | 04:34 |
| dazjorz | so the actual SVN commit, in a second, will have an empty diff, since it doesn't really change anything | 04:35 |
| dazjorz | since SVN doesn't have all that additional DVCS merging cargo for each commit or so? :) | 04:35 |
| dazjorz | okay so I have a commit 4299 with some changes to source plus some changes to ChangeLog, and commit 4300 which is actually empty | 04:36 |
| dazjorz | going to push now... | 04:36 |
| lifeless | The SVN commit will have an extra line, according to what you told me | 04:36 |
| dazjorz | o_O | 04:36 |
| dazjorz | bzr: ERROR: Operation denied because it would change the mainline history | 04:37 |
| lifeless | jelmer: ^ | 04:37 |
| dazjorz | et the append_revisions_only setting to False on branch "https://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess" to allow the mainline to change. | 04:37 |
| lifeless | svn has this set always | 04:37 |
| dazjorz | aw shit, am I really this bad? :P | 04:37 |
| lifeless | its a bit odd to tell you that warning | 04:37 |
| dazjorz | of course, svn most probably doesn't allow you to change earlier commits | 04:37 |
| lifeless | right | 04:37 |
| lifeless | so if I can make a couple of small suggestions | 04:37 |
| dazjorz | 1) throw out your SVN repository | 04:38 |
| dazjorz | 2) ??? | 04:38 |
| lifeless | you can either 'bzr dpush' at this point, to push into svn | 04:38 |
| dazjorz | 3) profit | 04:38 |
| lifeless | this does a local rewrite-of-history to make it fit what svn thinks happened | 04:38 |
| lifeless | this is fine, unless you're sharing your branch with other people. (Its the same as rebase, basically) | 04:38 |
| dazjorz | I'm not, so that's ok | 04:38 |
| lifeless | alternatively, and this is the way I'd tend to do it. | 04:39 |
| dazjorz | (why would it be a problem if I am sharing it with other people? because it invalidates their cache of my branch or so?) | 04:39 |
| lifeless | handwaving, yes. | 04:39 |
| lifeless | it creates new uuids for all the history that you're pushing | 04:39 |
| lifeless | anyhow, the way I would do it is to have two branches | 04:39 |
| lifeless | one that is a /checkout/ of svn | 04:40 |
| dazjorz | does it push all commits as one commit or does it still have two seperate commits? | 04:40 |
| lifeless | (bzr checkout https://kmess.svn.sourceforge.net/svnroot/kmess/trunk/kmess trunk) | 04:40 |
| lifeless | and then your other branch that you work on offline and so on | 04:40 |
| lifeless | to land something in svn | 04:40 |
| lifeless | cd trunk | 04:40 |
| lifeless | bzr update | 04:40 |
| lifeless | bzr merge ../your-branch | 04:40 |
| lifeless | bzr commit | 04:40 |
| lifeless | that reflects what svn is limited to | 04:41 |
| lifeless | and is standard for doing centralised management of a branch with bzr | 04:41 |
| dazjorz | maybe I'll put that bzr checkout repository on a remote server, and push my changes there | 04:41 |
| dazjorz | and have it automatically sync with SVN and vice-versa | 04:41 |
| lifeless | if you push to it, it won't work | 04:41 |
| lifeless | because push is a mirror operation, it will stop it corrsponding 1:1 with svn | 04:42 |
| lifeless | which is the point of using checkout + update | 04:42 |
| lifeless | rather than branch + merge | 04:42 |
| dazjorz | yeah | 04:42 |
| lifeless | now, if your branch is small this will perform just fine out of the box | 04:42 |
| lifeless | if its a large tree theres a couple of small steps to give you a single working tree and use switch to switch between the trunk checkout and your feature branches | 04:43 |
| dazjorz | may I ask you for some advise - | 04:43 |
| lifeless | of course | 04:44 |
| dazjorz | the reason I'm playing with DVCS integration with SVN, is that I'm going on a holiday this sunday, and I'm going to work on the project there, too | 04:44 |
| dazjorz | most probably | 04:44 |
| lifeless | cool | 04:44 |
| dazjorz | however - it's going to be offline and I still want to commit now and then | 04:44 |
| lifeless | yup, your own branch for that is a good idea | 04:44 |
| dazjorz | previously, that was a pain, since I had to sum up all my commits, or commit one large change and suffer some hours of manual merging to get it right again | 04:45 |
| dazjorz | so what do you recommend me to do - make a bzr checkout, and then make a seperate bzr branch where I merge and commit to, and every time I get internet access I bzr update the checkout, bzr push my changes to that checkout, then bzr push the changes from the checkout back to svn? | 04:46 |
| lifeless | nearly | 04:46 |
| lifeless | a complete recipe would be: | 04:47 |
| lifeless | bzr checkout <svn> trunk | 04:47 |
| lifeless | bzr branch feature1 | 04:47 |
| lifeless | hack in feature 1 | 04:47 |
| lifeless | when online: | 04:47 |
| lifeless | cd trunk | 04:47 |
| lifeless | bzr update | 04:47 |
| lifeless | bzr merge ../feature1 | 04:47 |
| lifeless | bzr commit -m "Current stuff -> SVN" | 04:47 |
| lifeless | cd ../feature1 | 04:47 |
| lifeless | bzr pull ../trunk | 04:47 |
| lifeless | --fin-- | 04:48 |
| dazjorz | that seems to make perfect sense | 04:48 |
| dazjorz | one thing: that will make all my changes one single commit to SVN, or won't it? | 04:49 |
| dazjorz | except, of course, when I make a branch for every group of changes I make | 04:49 |
| lifeless | right | 04:49 |
| lifeless | you can have as many features as you want | 04:49 |
| dazjorz | and the exact branch command is, if ./trunk is the bzr svn checkout, bzr branch trunk feature1 ? | 04:50 |
| lifeless | yup | 04:50 |
| dazjorz | nice | 04:50 |
| lifeless | try it now :) | 04:50 |
| dazjorz | I was about to, just need to get bzr-svn installed on my macbook :) | 04:50 |
| * dazjorz will package it to Fink, too | 04:50 | |
| dazjorz | what is the system-wide alternative to ~/.bazaar/plugins if there is one? | 04:55 |
| dazjorz | ah, must be bzrlib/plugins/svn | 04:55 |
| dazjorz | uh, bzrlib/plugins | 04:55 |
| lifeless | yes | 04:55 |
| lifeless | setup.py in the plugin should install it there for you | 04:56 |
| spiv | "Ideally chroot transports would know enough to cause the external url to be the exact one used that caused the chrooting in the first place, but that is not currently the case. | 05:13 |
| spiv | " | 05:13 |
| * mwhudson lacks context but agrees | 05:13 | |
| spiv | What does that sentence in Transport.external_url's docstring mean? | 05:13 |
| mwhudson | admittedly i don't know why it's not true | 05:14 |
| spiv | I guess I'm not sure exactly what "the exact one used that caused the chrooting in the first place" means. | 05:14 |
| lifeless | spiv: Neither am I | 05:15 |
| spiv | (urls don't kill people^W^Wchroot, code kills people^W^Wchroots...) | 05:16 |
| lifeless | but I would guess at 'the original url' | 05:16 |
| lifeless | or something | 05:16 |
| spiv | Yeah, that's my guess too. I was hoping to avoid guesswork, but I guess I'll cope :) | 05:16 |
| spiv | It seems like a bit of a non-sequitur for that docstring. | 05:18 |
| poolie1 | spiv i think it means the real absolute url | 05:19 |
| poolie1 | but i don't think i wrote it | 05:19 |
| poolie1 | (igc) i'm reading https://code.edge.launchpad.net/~bzr/bzr/smooth-upgrades/+merge/8921 | 05:22 |
| igc | poolie1: thanks | 05:28 |
| jetole | can anyone tell me if there is a way to do a push on commit? | 05:29 |
| poolie1 | jetole: if you use a checkout, committing implicitly synchronously pushes | 05:29 |
| jetole | hmm, I used branch but checkout sounds familiar from my limited history with svn | 05:30 |
| jetole | I will delete the dir and do a checkout | 05:30 |
| jetole | yep | 05:32 |
| jetole | checkout did it when I commited | 05:32 |
| jetole | poolie1: I am recreating the branch | 05:41 |
| poolie1 | jetole: you could have also just used 'bzr bind' :) | 05:41 |
| jetole | do I need to do an initial push or is there a way I can specify the master in commit or some other way I should do thi | 05:42 |
| jetole | *this | 05:42 |
| * jetole reads bind | 05:42 | |
| jetole | poolie1: what is the proper way to initiate a master? | 05:44 |
| jetole | should I push then bind? | 05:44 |
| fullermd | There isn't a "master" per se. Commit goes to what you checked out from. | 05:44 |
| jetole | fullermd: I haven't checked out. I deleted the local repo and the repo on launchpad and then recreated the dir, copied the source back in and did a bzr init, now I know I can do a push to launchpad | 05:45 |
| jetole | but I am wondering if that is how I should go, push then bind? | 05:45 |
| lifeless | that will be fine | 05:45 |
| jetole | ok | 05:46 |
| jetole | also fullermd, bzr help bind => "...commits must succeed on the master branch..." | 05:46 |
| * fullermd adds a bit of documentation to add to his list to take out behind the shed and beat the crap out of. | 05:46 | |
| jetole | lol | 05:47 |
| jetole | also how come the only valid launchpad url starts with +junk for me? | 05:48 |
| poolie1 | they must have either a project name or +junk | 05:49 |
| poolie1 | do you want to work on an existing or new project? | 05:50 |
| jetole | new project | 05:53 |
| jetole | btw, although this is probably rather implied, I am a complete bzr newbie and been months to a year since I used svn | 05:53 |
| fullermd | Well, you should be well on the road to recovery then 8-} | 05:57 |
| jetole | heh | 05:57 |
| poolie1 | igc: done | 06:14 |
| poolie1 | jetole: https://help.launchpad.net/Projects/Registering | 06:15 |
| poolie1 | lifeless: want to merge your check-1 branch, it's reportedly approved... | 06:15 |
| poolie1 | lifeless: also, it looks like your review of https://code.edge.launchpad.net/~garyvdm/bzr/register_lazy_decorated/+merge/8430 is conclusive | 06:16 |
| poolie1 | therefore it needs to be resubmitted, not reviewed by anyone else | 06:16 |
| poolie1 | if that's true, mark it so? | 06:16 |
| poolie1 | otherwise i'll read it if desired | 06:17 |
| lifeless | poolie1: check - yes, i should | 06:20 |
| lifeless | gary's branch I don't recall offhand | 06:20 |
| lifeless | I don't think I read the entire thing, just bits based on other peoples reviews. | 06:20 |
| lifeless | igc: did you see my comment on mp 8921 about --pack being unneeded | 06:34 |
| lifeless | (and infact a bug, as it will cause double packs) | 06:35 |
| igc | lifeless: yes, I saw it | 06:36 |
| lifeless | kk | 06:37 |
| lifeless | EOD | 06:59 |
| lifeless | closing in on this | 06:59 |
| dazjorz | btw - | 07:08 |
| dazjorz | I got bzr-svn working nicely on Fink (os x), and I'll package it sometime soon :) | 07:09 |
| dazjorz | along with subvertpy :) | 07:09 |
| verterok | Hi! any OSX 10.5 user around willing to help test the 1.17 DMG? | 07:15 |
| * verterok just got working a semi automated build script for 10.4 and 10.5 (still needs a some love, but works!) | 07:17 | |
| * spiv is off | 07:31 | |
| spiv | Have a good weekend, all! | 07:32 |
| dazjorz | lifeless: seems to work perfectly, the commands you gave me - thanks a lot :) | 07:57 |
| === gdmfsob is now known as mishok13 | ||
| igc | poolie: any chance of a *quick* call? | 08:28 |
| * igc dinner | 09:01 | |
| jelmer | moin | 09:07 |
| LarstiQ | morning | 09:10 |
| ronny | jelmer: for dulwich, ever tought of using binascii.hexlify/unhexlify for converting digests and hexdigests? | 09:28 |
| jelmer | ronny: not until now :-) | 09:32 |
| ronny | hmm, git trees have bad parsing properties | 09:33 |
| ronny | zero terminated strings in quasi-binary file formats | 09:34 |
| jelmer | ronny: Thanks for pointing that out, it seems like a good alternative to our own custom implementations | 09:34 |
| ronny | jelmer: are trees basically matching r"((?P<mode>[0-7]+) (?P<name>[^\0]+)\0(?P<digests>.{20}))+" ? | 09:36 |
| jelmer | ronny: generally, yeah | 09:37 |
| jelmer | ronny: (any reason for parsing manually btw, rather than through dulwich?) | 09:37 |
| ronny | jelmer: just diging around in dulwich, trying to figure if there are good way to implement it without c | 09:38 |
| jelmer | ronny: ah | 09:39 |
| ronny | jelmer: going to implement history listing for anyvc soon | 09:39 |
| jelmer | ronny: implement it without C and perform well you mean :-) | 09:39 |
| ronny | jelmer: perform well == good | 09:39 |
| jelmer | ronny: heh, ok | 09:40 |
| ronny | i wonder how re.findall compares to your parser | 09:40 |
| jelmer | only one way to find out (-: | 09:45 |
| jelmer | I'm pretty sure my parser will be faster than re.findall | 09:46 |
| jelmer | Not sure whether the difference will be significant enough to really matter though | 09:46 |
| ronny | jelmer: re.findall is 3 times slower, and dosnt yet convert the data propperly | 09:54 |
| jelmer | ronny: and in comparison to the existing python implementation? | 09:54 |
| ronny | mom | 09:56 |
| ronny | jelmer: got sidetracked, will try to get it tested the next hour | 10:03 |
| jelmer | ronny: *nod* | 10:06 |
| ronny | jelmer: ok, compiledre.findall seems to be ~9 times faster than the parser in python, however it doesnt yet convert the data | 10:08 |
| jelmer | details, details, .. :-P | 10:09 |
| ronny | so i hope ~7-8 times the speed is possible | 10:09 |
| dazjorz | hmmm | 10:10 |
| dazjorz | jelmer: I just ran bzr up on a checkout created by bzr checkout http://..[svn repository] | 10:10 |
| dazjorz | uh, bzr merge, even | 10:10 |
| dazjorz | and the remote changes were added as changes to my local checkout | 10:11 |
| dazjorz | hm, wait, I talked about this with lifeless earlier, he said I had to recommit it | 10:11 |
| ronny | jelmer: ok, re.findall in naive use + correct converting is about 6 times faster than the normal python implementation, and about 3,7 times slower than the c implementation | 10:14 |
| ronny | jelmer: i think the time loss can be accounted in the python loops | 10:15 |
| jelmer | ronny: cool | 10:17 |
| ronny | jelmer: i wonder if it can be done more efficient tho | 10:18 |
| jelmer | ronny: without C extensions? I think it's hard | 10:19 |
| jelmer | ronny: depending on the application it might also not matter very much | 10:19 |
| ronny | jelmer: im im still hoping to get in a range of half the speed of the current c implementation | 10:20 |
| jelmer | ronny: for bzr-git we have to access and parse every single tree when fetching data but generally this is not the case | 10:20 |
| ronny | (better loop, smarter regex) | 10:20 |
| jelmer | ronny: for anyvc I would imagine this isn't particularly performance-critical - being able to look up objects in packs and resolve deltas would be much more important I think | 10:21 |
| ronny | yes | 10:21 |
| ronny | i'll take a look at that, to | 10:21 |
| ronny | hmm, and i need to implement the "pythonic fs apis" on top of the vcs's | 10:22 |
| ronny | next week will be much fun | 10:23 |
| ronny | generating + reading linear history for all vcs, generating dags of history for the dvcs's and figuring a mapping for svn | 10:23 |
| === asabil__ is now known as asabil | ||
| === mrevell is now known as mrevell-lunch | ||
| homy | What is a "rich root" format? It is used in loads of places in the documentation, but I couldn't find its explanation anywhere. | 13:01 |
| === mrevell-lunch is now known as mrevell | ||
| ronny | homy: the difference is in the amount of places where metadata may be, basically all newer formats are rich, any you never ever want a non-rich one | 13:05 |
| jelmer | igc: hi | 13:05 |
| maxb | Does bzr have an option for pointing at a branch which is not the current directory? | 13:15 |
| homy | ronny: thanks. | 13:15 |
| maxb | i.e. bzr --something foo revno, instead of cd foo; bzr revno; cd .. | 13:15 |
| dazjorz | ewww | 13:22 |
| dazjorz | jelmer: there? | 13:22 |
| dazjorz | or lifeless | 13:22 |
| dazjorz | this could possibly be seen as a bzr-svn bug | 13:23 |
| dazjorz | same problem as yesterday: a conflict is preventing me from being able to push back a revision to SVN | 13:24 |
| dazjorz | in other words: I merged, got a conflict, solved it and committed it to my local branch, but bzr is trying to commit that merge fix back to svn | 13:24 |
| dazjorz | expected behaviour: it sees that that commit only merged a svn commit locally, and doesn't try to edit the commit at svn because it knows it won't work | 13:26 |
| dazjorz | real behaviour: bzr says "you're asking me to change commit history, but I'm not allowed to do that here" (note how it doesn't even say "I can't do that here") | 13:29 |
| dazjorz | "operation denied because it would change the mainline history, set [...] to false on branch [...] to allow the mainline to change" | 13:29 |
| igc | hi jelmer | 13:36 |
| jelmer | dazjorz: hi | 13:49 |
| dazjorz | hey | 13:50 |
| jelmer | dazjorz: I'm not sure I understand what the problem is exactly | 13:50 |
| dazjorz | the problem is that, after I run bzr merge on a bzr checkout of a svn repository and I get some conflicts, and resolve them then commit, I can't push anymore | 13:52 |
| dazjorz | I get the error under "real behaviour" instead of the behaviour under "expected behaviour" | 13:52 |
| dazjorz | do you think that could be fixed? :) | 13:52 |
| LarstiQ | maxb: `bzr revno [LOCATION]` from `bzr help revno` | 13:55 |
| jelmer | dazjorz: that's correct behaviour | 13:57 |
| jelmer | dazjorz: the operation you did would change the mainliune in svn | 13:58 |
| jelmer | since you probably don | 13:58 |
| jelmer | t want that bzr-svn requires you to set an option before you can do so | 13:58 |
| dazjorz | jelmer: I don't want it, but it's not even possible, I'd say, so how does it work when you indeed set that option | 13:59 |
| dazjorz | also | 13:59 |
| dazjorz | jelmer: behaviour may be correct - but it would be more "natural" for bzr-svn to handle that situation gracefully and understand that commit doesn't *have* to be changed in SVN history, since it's the same one, just a local merge :) | 13:59 |
| jelmer | dazjorz: it would not require that option to be set previously and that's gotten people upset (because it did change their svn mainline while they weren't expecting it) | 14:03 |
| jelmer | dazjorz: the merge changed the mainline | 14:03 |
| jelmer | dazjorz: e.g. see "bzr log -n1" and compare that to the current revisions in your svn branch | 14:04 |
| dazjorz | jelmer: well, I don't want to change my svn mainline, but I do want to tell bzr to just not push that commit since it's already there, and stop acting up and just do what I ask it: push the rest of my commits | 14:05 |
| dazjorz | jelmer: is it possible to make an option to just ignore changes to the mainline instead of failing to do everything? | 14:06 |
| dazjorz | failing the complete push operation because it's not allowed to merge that one commit in that I don't even *want* to be merged in? :) | 14:06 |
| jelmer | dazjorz: bzr push (by definition) pushes the existing history from the local branch to the target branch without changing it | 14:09 |
| jelmer | dazjorz: if you don't want a change to the mainline, use rebase instead of merge | 14:09 |
| dazjorz | jelmer: okay, I'll take a look, thanks :) | 14:10 |
| dazjorz | (the thing about that is: it does push existing history from the local branch to the target branch - but as far as I'm concerned, the fact I had to manually merge the revision doesn't actually *change* the revision, so it doesn't have to be pushed back for me) | 14:11 |
| jelmer | dazjorz: it might in this particular case not change the contents of the tree, it does change the contents of the history | 14:12 |
| awilkins | Can I clarify the exact events here, because I'm using bzr to work with SVN and it's starting to worry me? What is occuring is that dazjorz has a "trunk" branch from an SVN repo, and a "local" branch of that trunk, and he's merged a revision from "trunk" to "local"? | 14:15 |
| jelmer | awilkins: yeah, that's what he's done | 14:15 |
| awilkins | And that revision gave rise to conflicts? And if you want to merge local back to trunk, and push that to SVN, it gives the error described? | 14:15 |
| awilkins | Or are we talking pushing local straight into the SVN/trunk | 14:16 |
| jelmer | awilkins: pushing local straight into the svn/trunk | 14:16 |
| jelmer | awilkins: something that bzr-svn refuses as it would involve removin the merged revision from mainline in svn | 14:16 |
| awilkins | Right, so would merging bzr/local to bzr/trunk and pushing that back to SVN/trunk work? | 14:16 |
| jelmer | awilkins: yeah, as that wouldn't change the mainline | 14:17 |
| awilkins | Good, I think that's the practice I've been intuitively doing anyway :-) | 14:17 |
| awilkins | Oh, I mean merging bzr/local with the merged revision containing the conflict, back to bzr/trunk and pushing that | 14:18 |
| awilkins | Just to be super-clear | 14:18 |
| jelmer | awilkins: conflicts aren't relevant here | 14:18 |
| awilkins | Ah, it's the merge | 14:18 |
| awilkins | How would it overwrite an existing revision in SVN anyway? I didn't think that was possible remotely (do you have to enable some evil on the server?) | 14:19 |
| jelmer | awilkins: it would overwrite anything, but it can change the history of a branch in subversion | 14:20 |
| jelmer | awilkins: e.g. by replacing /trunk with an older copy of itself | 14:20 |
| awilkins | Eww. | 14:20 |
| jelmer | awilkins: well, that's what changing the mainline involves in svn, but bzr-svn won't do this by default unless you set that option | 14:21 |
| awilkins | jelmer: I think that's fair... so keeping trunk as a bzr branch and merging back to that seems to be the right way to go? | 14:23 |
| jelmer | awilkins: yeah | 14:24 |
| dazjorz | jelmer: is there a way to tell bzr to throw away the changes to the history, and will that make it behave "correctly" for me? | 14:24 |
| jelmer | dazjorz: bzr uncommit can remove revisions from the local branch | 14:24 |
| jelmer | dazjorz: "bzr revert" can be used to update the working tree | 14:25 |
| dazjorz | okay | 14:25 |
| dazjorz | maybe you should add a note about that in the message I said | 14:25 |
| dazjorz | "if you don't want to change the history, use uncommit to revert your merge commit, then use revert to update the working tree to the correct version" | 14:25 |
| dazjorz | since the current notice is really unclear | 14:26 |
| jelmer | dazjorz: The current notice assumes some knowledge about bzr's model | 14:26 |
| jelmer | dazjorz: uncommit + revert only gets you back to the state before the merge | 14:26 |
| jelmer | dazjorz: it's also very specific for your current situation | 14:27 |
| dazjorz | I think many of the people using bzr-svn come from svn and simply want to use bazaar as their client, and therefore start without a lot of knowledge about bzr's model | 14:28 |
| jelmer | dazjorz: I can't explain bzr's model in a single error message | 14:29 |
| dazjorz | uncommit + revert brings my working copy back to before I started my changes, effectively throwing away my changes so I can update cleanly, and then can hope I still have the patch or I'll have to fix the bug again - sounds like exactly the thing a dvcs with advanced merging capabilities is designed to circumvent | 14:30 |
| awilkins | dazjorz: How about uncommit + shelve in this case | 14:31 |
| awilkins | You get to keep your changes and reapply them afterwards | 14:31 |
| dazjorz | sounds good | 14:31 |
| dazjorz | I didn't know about shelve | 14:31 |
| dazjorz | jelmer: what about putting that in the error message? | 14:31 |
| dazjorz | explaining to the user that he merged the conflict in a way that changes SVN history, and if that's not what he meant, he should uncommit and shelve, then update and apply again? | 14:32 |
| awilkins | I think it's essentially the same as what rebase does but i) included and ii) manual | 14:32 |
| awilkins | (is rebase in core now?_ | 14:32 |
| dazjorz | bzr: ERROR: No help could be found for 'rebase'. | 14:33 |
| awilkins | Guess not then | 14:33 |
| dazjorz | I guess not, then? Or at least in my version | 14:33 |
| dazjorz | 1.15, which is old | 14:33 |
| * dazjorz downloads the newest bzr to update the fink package | 14:33 | |
| awilkins | dazjorz: Which OS? | 14:34 |
| jelmer | awilkins: rebase is still a separate plugin | 14:34 |
| dazjorz | awilkins: Fink - Mac OS X | 14:34 |
| jelmer | dazjorz: uncommit + shelve would be very specific to your current situation | 14:35 |
| awilkins | jelmer: I should know that... I updated my plugins a few days ago | 14:35 |
| dazjorz | jelmer: as far as I understand the situation, many users which tried to update and got a conflict would get that error message | 14:35 |
| jelmer | dazjorz: this is unrelated to update | 14:35 |
| dazjorz | jelmer: and you'd help all of them with a little hint "if you [.....], try uncommit + shelve, see the help for foo" | 14:35 |
| dazjorz | jelmer: this is caused by update -> get conflict -> fix conflict -> commit conflict fix -> changed history but not patch, right? | 14:36 |
| awilkins | I think what would be most helpful is a recipe for working from an SVN repo using Bazaar that doesn't encourage working in a branch of svn/trunk. | 14:36 |
| awilkins | And prominently linked to from wherever people get introduced to bzr-svn from | 14:37 |
| jelmer | dazjorz: I don't think uncommit + shelve is what you would want here actually | 14:37 |
| jelmer | dazjorz: no, this is unrelated to conflicts | 14:38 |
| jelmer | dazjorz: unrelated to *file* conflicts | 14:38 |
| dazjorz | do you mean to say it could be unrelated to conflicts but in my specific case it turned out to be? | 14:38 |
| dazjorz | related* | 14:39 |
| jelmer | dazjorz: it's caused by the fact that you are pushing a mainline into subversion that doesn't match what's there at the moment | 14:39 |
| jelmer | dazjorz: no, even in your case it's not related to merge conflicts | 14:39 |
| dazjorz | jelmer: well, history was changed because of that file conflict, because I had to commit it | 14:39 |
| dazjorz | maybe I misunderstood someone's explanation | 14:39 |
| dazjorz | but when I ran bzr up in my changed working tree which had a commit not in svn which I was about to push, bzr told me of a conflict, and applied the changes in svn to my working tree | 14:39 |
| jelmer | dazjorz: history wasn't changed, the mainline was | 14:39 |
| dazjorz | as lifeless recommended, I fixed the conflict, ran bzr resolved, and committed the changes | 14:40 |
| dazjorz | then tried to push, since I thought the conflict was resolved and now my commit could be pushed.. | 14:40 |
| dazjorz | oooooh | 14:40 |
| dazjorz | I get it | 14:40 |
| dazjorz | you mean I'm trying to insert a commit *before* the last commit on svn? | 14:40 |
| dazjorz | instead of appending my commit to the top of the tree, like `svn commit` would do | 14:41 |
| awilkins | You've already done it... | 14:43 |
| awilkins | Just not pushed it up | 14:43 |
| jelmer | dazjorz: I'm not sure I'm following what you've done exactly. | 14:43 |
| jelmer | dazjorz: You were working in a checkout of your svn branch? | 14:44 |
| dazjorz | a bzr checkout of the svn branch, yeah | 14:44 |
| dazjorz | I made some changes, then committed - but as it turned out, svn was changed while I was editing | 14:44 |
| dazjorz | and I wanted to commit my changes to the top of that | 14:44 |
| jelmer | ok | 14:44 |
| jelmer | so the commit was refused I guess | 14:45 |
| jelmer | ?? | 14:45 |
| jelmer | then you ran update and then commit? | 14:45 |
| dazjorz | well, the bzr push was refused because my checkout was out of date | 14:45 |
| dazjorz | so yeah, I ran bzr merge to get up-to-date with svn again | 14:45 |
| jelmer | dazjorz: So you weren't working in a checkout but in a standalone branch? | 14:48 |
| jelmer | dazjorz: (otherwise the commit would have failed, because the local branch was out of date with the master branch) | 14:49 |
| dazjorz | I think I was working in a checkout, I think I created it with "bzr checkout http://...", is there anyway to check that? | 14:50 |
| dazjorz | either way, the commit was local | 14:50 |
| dazjorz | so maybe it was a standalone branch, yeah | 14:50 |
| jelmer | dazjorz: if the commit was local you would be working in a standalone branch indeed | 14:51 |
| dazjorz | okay | 14:52 |
| dazjorz | sorry for the confusion, then it was a standalone branch | 14:52 |
| awilkins | http://pastebin.ubuntu.com/230489/ # << this seems to be what we are discussin | 14:53 |
| awilkins | http://imagebin.ca/view/pBuP7v1.html # illustrated with this | 14:54 |
| dazjorz | thank you awilkins | 14:55 |
| jelmer | awilkins: right | 14:55 |
| jelmer | dazjorz: so in the screenshot awilkins posted the second svn revision has disappeared from mainline | 14:55 |
| awilkins | http://imagebin.ca/view/oGTTEoWU.html ## here we've fixed it | 14:56 |
| jelmer | dazjorz: bzr-svn would push revisions 1, 2 and 3 onto mainline but that would mean removing 1.1.1 | 14:56 |
| * dazjorz is confused by the "bzr switch local" and "bzr switch trunk", but for the rest, seems about what I was doing | 14:56 | |
| jelmer | awilkins: alternatively, you could just merge into a checkout of trunk *or* rebase | 14:57 |
| awilkins | In screenshot 2 ; we've merged local into trunk (which is our mirror branch for SVN) | 14:57 |
| awilkins | This revision pushes to SVN cleanly | 14:57 |
| awilkins | jelmer: Screenshot 2 is the former ; switched our checkout to trunk and merged into it | 14:57 |
| awilkins | bzr switch trunk ; bzr merge ../repo/local ; bzr commit -m "Fixed problem" | 14:58 |
| dazjorz | jelmer: it would mean inserting 2 in front of 1.1.1, while 1.1.1 is latest in the SVN revision and you usually don't want to insert a revision in front of another one in svn | 14:58 |
| dazjorz | right? | 14:58 |
| jelmer | awilkins: no, screenshot 2 contains an extra unnecessary merge commit | 14:58 |
| dazjorz | actually I think awilkin's paste is even more complex than what I did | 14:59 |
| jelmer | dazjorz: no, 1.1.1 wouldn't be on the mainline at all anymore given screenshot 1 | 14:59 |
| jelmer | dazjorz: (revision numbers without dots are on the mainline) | 14:59 |
| dazjorz | okay, as a SVN user, I'm jumping through hoops to follow you while you're talking about mainline and moving that SVN revision to a branch off the mainline | 14:59 |
| dazjorz | I never wanted to do that, but apparantly, that's how it turned out :P | 15:00 |
| jelmer | dazjorz: I'd recommend using checkouts if you're only familiar with svn, they are most similar to svn checkouts | 15:00 |
| jelmer | dazjorz: rather than standalone branches, which don't really exist in svn | 15:00 |
| dazjorz | well then I could just as well use svn directly - I'm looking into this specifically because I need a DVCS on my client, sending commits to a central SVN repository | 15:04 |
| jelmer | dazjorz: if you alternatively you could look into using "bzr rebase" to pull in new revisions from mainline | 15:04 |
| dazjorz | but if possible, I'd like to avoid problems like this and having to uncommit and stack up changes because I can't make bzr-svn correctly merge svn changes with my changes so I can still send my changes in nicely | 15:04 |
| jelmer | dazjorz: I guess that matches more closely what you would do in subversion | 15:04 |
| dazjorz | yeah | 15:05 |
| dazjorz | I'll look at it | 15:05 |
| dazjorz | lifeless also gave me a different solution which came down to having a bzr checkout, and a bzr branch of that checkout | 15:05 |
| dazjorz | so I could bzr update in the checkout, then merge my changes from the branch, and commit them as one large patch, then update the branch back from the checkout | 15:05 |
| awilkins | That's effectively what I do but not quite the same way | 15:05 |
| jelmer | dazjorz: yeah, that would work as well | 15:05 |
| awilkins | I use a no-trees repository with a trunk branch in it and use switch (as illustrated in paste) | 15:06 |
| dazjorz | I think bzr rebase sounds like what svn does: basing your repository on a different version, while keeping your changes "on top" of the rest | 15:06 |
| dazjorz | amirite? | 15:06 |
| jelmer | dazjorz: yeah | 15:06 |
| dazjorz | great | 15:06 |
| jelmer | dazjorz: it keeps your history linear | 15:06 |
| awilkins | lifeless's way has it's advantages in that because "trunk" is a checkout it won't let you commit "inserted" revisions accidentally. | 15:06 |
| dazjorz | yeah | 15:07 |
| dazjorz | but then rebase works around that problem by changing "inserted" revisions to become revisions "on top" of the ones already in svn | 15:07 |
| awilkins | I only find out I screwed it up when I try to push | 15:07 |
| awilkins | But I usually pull / merge / push quickly enough not to bump into other peoples commits | 15:08 |
| awilkins | It helps that everyone else is in another timezone :-) | 15:08 |
| === raimue is now known as Raim | ||
| Tak | blargh, I just had the same issue as dazjorz | 15:21 |
| dazjorz | Tak: you made my day ;) | 15:21 |
| Tak | hmm, rebase tells me no revisions to rebase | 15:28 |
| dazjorz | I think you may need to uncommit until before the merge, then rebase? | 15:31 |
| awilkins | Tak: Are you passing the svn branch as the parameter to rebase? | 15:34 |
| Tak | the upstream branch? | 15:34 |
| awilkins | Yes | 15:34 |
| Tak | same result | 15:35 |
| awilkins | Hmm | 15:35 |
| Tak | my flow of events: I pulled this morning, fixed a bug, committed locally, went to push, was notified that the trees were out of sync, merged, went to push again, got complaint about changing mainline history | 15:38 |
| awilkins | Tak... ok, try this. Branch your current branch to a sibling folder (say "trunk"). cd trunk ; bzr pull <svn url> --overwrite | 15:39 |
| awilkins | cd ../original_branch ; bzr rebase ../trunk | 15:39 |
| Tak | No revisions to rebase. | 15:42 |
| awilkins | What does bzr missing ../trunk say ? | 15:42 |
| Tak | shows 2 revisions | 15:42 |
| awilkins | Both yours? Or theirs too? | 15:42 |
| Tak | my bugfix rev, and the merge commit | 15:43 |
| awilkins | I think dazjorz is right, you might have to uncommit that merge and rebase instead | 15:43 |
| Tak | in that case I agree with him | 15:44 |
| awilkins | It's small risk - it will tell you which revision you are (not) trashing | 15:44 |
| === thunderstruck is now known as gnomefreak | ||
| awilkins | It doesn't think you have to rebase that revision because you already merged it | 15:44 |
| awilkins | Bah, these things do my head in | 15:44 |
| dazjorz | or, bzr diff -r[yourcommit-1]:[yourcommit] >yourcommit.diff; bzr uncommit [yourcommit]; bzr rebase; patch -p0 <yourcommit.diff; bzr commit | 15:45 |
| dazjorz | maybe. | 15:45 |
| awilkins | I don't think you need to take special measures to preserve your changes | 15:48 |
| Tak | I diffed just in case | 15:48 |
| awilkins | That's what rebase is doing ; it's effectively replaying your patches on top of the new history and forging a new history | 15:48 |
| Tak | but bzr uncommit -r-3; bzr pull; bzr commit; bzr push seems to have worked | 15:48 |
| awilkins | If you'd had more than one revision committed locally that would have smunged them all together, but that works equivalently as well as rebase for 1 revision | 15:50 |
| Tak | better, because it actually saw my revision ;-) | 15:51 |
| === Guest14657 is now known as jelmer__ | ||
| === jelmer__ is now known as jelmer___ | ||
| SamB | how do I find out the HTTP URL corresponding to an lp: URL? | 16:46 |
| beuno | SamB, http://bazaar.launchpad.net/$whatever comes after lp: | 16:47 |
| SamB | ... without the nonexistant lp-logout command or going and hand-editing the config file that it would edit? | 16:47 |
| beuno | unless it's an lp:project URL | 16:47 |
| SamB | I wonder why that isn't in the web UI | 16:47 |
| SamB | beuno: well, it is a project URL yes | 16:47 |
| SamB | but I have the SSH URL so I can figure it out | 16:47 |
| beuno | SamB, you want the web UI to expose the long URL? | 16:48 |
| beuno | why? | 16:48 |
| beuno | it's not needed | 16:48 |
| SamB | it might be handy | 16:48 |
| SamB | especially since when I run "bzr info" on the lp: one it gives me back useless info | 16:49 |
| SamB | with -v, I get this about the format: | 16:49 |
| SamB | Format: | 16:49 |
| SamB | control: bzr remote bzrdir | 16:49 |
| SamB | branch: Remote BZR Branch | 16:49 |
| SamB | repository: bzr remote repositor | 16:49 |
| SamB | oops, missed a y. still, doesn't that seem pretty useless? | 16:50 |
| beuno | "it might be handy" is not a great argument to pollute the Launchpad UI :) | 16:50 |
| beuno | yes, that's a problem with bzr | 16:50 |
| beuno | not being able to read remote formats properly with the smart server | 16:50 |
| SamB | one more line would hurt? | 16:50 |
| beuno | yes, *anything* extra on theUI hurts | 16:50 |
| beuno | more places competing for your attention | 16:51 |
| SamB | hmm, actually it could be a very subdued-tone link after the "bzr branch" command or something ... | 16:51 |
| SamB | a short one | 16:51 |
| SamB | with the URL only in the href field | 16:51 |
| beuno | again, without a reasonable use case.... | 16:52 |
| beuno | and | 16:52 |
| beuno | Launchpad *tells* you the format already on the UI | 16:52 |
| SamB | is that the same thing bzr would say? | 16:52 |
| SamB | no, it gives it to you in some "human-readable" format that is useless for figuring out what to pass to init-repo ... | 16:53 |
| beuno | well, there yout go | 16:53 |
| beuno | that's the problem we need to fix :) | 16:53 |
| SamB | ah, but so does bzr on the part I pasted before ;-) | 16:53 |
| SamB | branch: Branch format 6 | 16:54 |
| SamB | repository: Packs containing knits without subtree support | 16:54 |
| beuno | right | 16:54 |
| SamB | but at least the first line is helpful here: | 16:54 |
| SamB | Standalone branch (format: pack-0.92) | 16:54 |
| SamB | I'm looking at https://code.launchpad.net/~mailman-coders/mailman/3.0 if that matters ;-) | 16:54 |
| beuno | file a bug on launchpad about it, and I'll chase it up and see how we can show that instead | 16:54 |
| SamB | but if "bzr info" isn't displaying enough info in those lines, isn't that an issue too? | 16:56 |
| beuno | yes | 16:56 |
| SamB | so do I need to report those seperately or together ? | 16:57 |
| beuno | two bugs! your karma will go through the roof! ;) | 16:57 |
| SamB | heh | 16:57 |
| SamB | I've reported a lot more than that | 16:57 |
| SamB | hmm, looks like someone did already: https://bugs.launchpad.net/bzr/+bug/248900 | 17:02 |
| ubottu | Ubuntu bug 248900 in launchpad-code "More understandable format strings needed" [Medium,Triaged] | 17:02 |
| * SamB renames the bug | 17:03 | |
| SamB | bug 248900 | 17:03 |
| ubottu | Launchpad bug 248900 in launchpad-code "More understandable format strings needed" [Medium,Triaged] https://launchpad.net/bugs/248900 | 17:03 |
| SamB | wrong! | 17:03 |
| beuno | heh | 17:06 |
| beuno | you now know that ubottu caches :) | 17:06 |
| beuno | SamB, I'll chase developers about that bug | 17:06 |
| bialix | igc: hi | 17:16 |
| igc | hi bialix | 17:23 |
| amanica | igc: btw. nice new doc frontpage | 17:24 |
| igc | amanica: thanks | 17:25 |
| * emmajane waves | 17:27 | |
| emmajane | bazaar made it to the front page of slideshare.net. :) | 17:29 |
| igc | emmajane: well done! | 17:31 |
| emmajane | thanks :) | 17:32 |
| === verterok_ is now known as verterok | ||
| === ja1 is now known as jam | ||
| corporate_cookie | if I want to use bzr+ssh to check something out do I just run bzr serve --directory=foo ...then open up port 4155 on the remote machine ? | 18:45 |
| SamB | corporate_cookie: bzr+ssh seems to use the usual SSH port | 18:46 |
| corporate_cookie | amazing : ) | 18:46 |
| SamB | and attempt to invoke bzr as if it were in fact connecting to an ordinary SSH server | 18:47 |
| amanica | yes --serve is for the custom and not-secured protocol | 18:47 |
| SamB | not to say that this is by any means necessarily the case ;-) | 18:47 |
| amanica | you can also use sftp:// | 18:47 |
| SamB | but if it is the case, it should work without special configuration as long as you're allowed to run whatever command you like on the server ;-) | 18:47 |
| corporate_cookie | ive been using sftp ....but im curious in checking out hpss | 18:48 |
| corporate_cookie | there is only a couple of lines in the users guide referring to it | 18:49 |
| SamB | it's pretty typical of ssh-based access to VCSs that they work without any special configuration for people who have ssh shell access | 18:49 |
| SamB | the trickiest bit being to make sure that the VCS (or subsystem of VCS needed to commit) be findable | 18:50 |
| SamB | basically meaning either it has to be in the PATH used by the sshd to find the command, or the VCS client has to specify an absolute path to it | 18:52 |
| agrippa | Getting an error when trying bzr status | 18:55 |
| agrippa | bzr: ERROR: Could not acquire lock "/Volumes/web$/tipsv2/.bzr/checkout/dirstate": [Errno 45] Operation not supported | 18:55 |
| agrippa | Using bzr 1.16.1 on OS X 10.5.7 | 18:55 |
| agrippa | Is this a current bug that needs to be fixed? | 18:55 |
| SamB | agrippa: what does mount say ? | 18:55 |
| LarstiQ | corporate_cookie: all you need is ssh access and a runnable bzr on the remote side | 18:55 |
| corporate_cookie | thanks SamB : ) | 18:55 |
| LarstiQ | agrippa: what is /Volumes/web$ for a filesystem (what SamB said) | 18:56 |
| agrippa | It's mounted via SMB | 18:56 |
| SamB | hmm | 18:56 |
| SamB | my guess is it's an issue with OS X's SMB driver and/or SMB | 18:57 |
| SamB | jelmer___: do you know anything/ | 18:57 |
| agrippa | Volumes/web$ (smbfs, nodev, nosuid, mounted by rsmith) | 18:57 |
| SamB | s|/|?| | 18:57 |
| agrippa | hmmm | 18:57 |
| SamB | agrippa: so what is this volume provided by? | 18:58 |
| agrippa | It's mounting a share off of our Windows development server | 19:00 |
| agrippa | The server is a Windows 2003 SP1 | 19:00 |
| Tak | is there a way to flag another email address as "me" on launchpad? | 19:00 |
| SamB | poor you, having to develop for windows :-( | 19:00 |
| SamB | Tak: you can add it to your account, yeah | 19:00 |
| agrippa | Well, we're developing Flash, but we use Windows for the web server | 19:01 |
| SamB | just go to your account and then find the little edit icons (I think they look like exclamation marks?) | 19:01 |
| SamB | agrippa: odd thing to do | 19:01 |
| agrippa | Although I wish we didn't use a Windows server sometimes | 19:01 |
| agrippa | Well, when you're organization buys whole hog into MS, that's what happens :p | 19:01 |
| Tak | hmm, I don't have one of those next to the email | 19:01 |
| LarstiQ | agrippa: in or on Flash? | 19:01 |
| SamB | agrippa: but not so whole-hog that *you* have to use Windows on your machine? | 19:02 |
| LarstiQ | SamB: some people actually like windows :P | 19:02 |
| agrippa | Larstiq: Well, in Flash, and ActionScript | 19:02 |
| SamB | LarstiQ: but for a server ? | 19:02 |
| Tak | blargh - also, why can't I sign the CoC with my ssh key? | 19:02 |
| LarstiQ | SamB: yes | 19:02 |
| SamB | it doesn't seem like a suited job for the software that's available on Windows | 19:02 |
| agrippa | SamB: Yeah, our central IT likes Windows, we use OS X in our group though | 19:03 |
| SamB | well, maybe there's more stuff available there than there used to be ... | 19:03 |
| SamB | well, I suppose it's better than using Novell services :-( | 19:03 |
| SamB | ... maybe I'm just biased because I've never really had money to spend on development tools :-) | 19:04 |
| Tak | aha, found it! | 19:04 |
| SamB | and they didn't used to offer those free for Windows | 19:04 |
| agrippa | SamB: Windows 2003 isn't too bad really, it's pretty easy to manage, does most of what I need. There are more OS web apps developed for Linux in some situations, so I wish we had a Linux server, but our central IT doesn't have the skill set for it. | 19:04 |
| SamB | I mean, MS didn't | 19:04 |
| SamB | but I still wish it had SSH and a decent network filesystem -- though the latter could be said of *nix as well, I think? | 19:05 |
| SamB | ... one thing I really hate about windows is the cost of process creation :-( | 19:06 |
| agrippa | SamB: By it, you mean Windows 2003? | 19:06 |
| SamB | agrippa: well, in general | 19:06 |
| SamB | I actually only have XP | 19:07 |
| agrippa | SamB: Our version does not have SFTP which is a bummer, but more recent versions do | 19:07 |
| agrippa | In general though, you can get SSH for Windows | 19:07 |
| SamB | is that an actual variant of FTP, or some SSH-based protocol, or both? | 19:07 |
| SamB | agrippa: without paying for it ? | 19:08 |
| agrippa | SFTP, I think it's built on top of SSH | 19:08 |
| SamB | I thought there might be two SFTPs or something | 19:08 |
| agrippa | SamB: Yeah, I've been using puTTY for years | 19:08 |
| agrippa | I think there are two SFTPs | 19:09 |
| SamB | I meant an sshd for windows, actually | 19:09 |
| agrippa | They both run on top of SSH though, if I'm right | 19:09 |
| jelmer___ | luks: hi | 19:09 |
| SamB | agrippa: even worse! | 19:09 |
| jelmer___ | luks: I've finished and merged the 'bzr send --format=svn' branch | 19:09 |
| SamB | jelmer___: so do you know anything about locks not working over SMB from OS X? | 19:09 |
| jelmer___ | luks: It'll now also report property changes | 19:09 |
| SamB | jelmer___: what does that do? | 19:10 |
| SamB | hmm. I guess I should just try it? | 19:10 |
| jelmer___ | SamB: Sorry, not familiar with the Mac OS X client | 19:10 |
| agrippa | SamB: I think MS would have to improve their shell for sshd to be any good on Windows :p | 19:10 |
| SamB | jelmer___: thought it was worth a try :-) | 19:10 |
| jelmer___ | SamB: it generates a files similar to "svn diff" | 19:10 |
| jelmer___ | SamB: without any bzr metadata | 19:10 |
| SamB | agrippa: oh, but it could spawn bash or something | 19:10 |
| agrippa | SamB: Yeah, I guess spawning a bash shell from Cygwin would be cool | 19:11 |
| SamB | jelmer___: is that "without" supposed to be a feature? | 19:11 |
| jelmer___ | SamB: yes | 19:11 |
| SamB | agrippa: and even cmd is better than nothing! | 19:11 |
| agrippa | But MS did do a decent job with RDP | 19:11 |
| SamB | agrippa: hmm. | 19:11 |
| jelmer___ | SamB: there's no point in sending complex bzr bundles when upstream isn't using bzr | 19:11 |
| SamB | agrippa: does that forward a terminal ? | 19:12 |
| SamB | jelmer___: yeah ... | 19:12 |
| agrippa | You could open a DOS prompt in RDP or a bash shell if you had Cygwin installed | 19:12 |
| SamB | jelmer___: but it's too bad you can't get the bzr metadata into svn that way :-( | 19:12 |
| SamB | agrippa: well, yeah ... | 19:13 |
| SamB | but it seems kind of an inefficient way of going about things | 19:13 |
| agrippa | SamB: Have you tried this http://web.mit.edu/pismere/ssh/ssh-port.html | 19:14 |
| SamB | maybe I should try it before I say that though | 19:14 |
| agrippa | Oh wow, I just found out that OS X allows tabbed terminals by accident | 19:15 |
| SamB | oh, cygwin has sshd now? | 19:15 |
| SamB | well ... I guess that's *kind* of nice | 19:15 |
| agrippa | SamB: You know, I did get SVN working over SSH from a Windows server a while back, so maybe it might just work | 19:16 |
| LarstiQ | anyone got an idea what time lifeless tends to get online nowadays? | 19:17 |
| SamB | well, it looks like he left around midnight EST last night | 19:18 |
| SamB | and got on around 17:52 EST | 19:19 |
| SamB | it's now about 14:19 EST, so I guess you'd best wait 3-4 hours ? | 19:20 |
| LarstiQ | right | 19:20 |
| LarstiQ | which is around my midnight | 19:20 |
| SamB | or you could try to see him in your morning? | 19:21 |
| LarstiQ | yeah, I will. In the meantime updated the bug and going to do some more investigative work. | 19:22 |
| agrippa | blarg, tried to create a symlink and that did not work either :( | 19:22 |
| SamB | agrippa: well, I'm pretty sure that would be MS's fault | 19:23 |
| agrippa | SamB: heh | 19:25 |
| agrippa | Well, if I copy locally it works, but meh, I don't want that | 19:27 |
| agrippa | Does bzr use the svn you have installed on your system or does it have its own copy? | 19:31 |
| SamB | agrippa: it probably depends on where you get bzr ;-) | 19:32 |
| SamB | for me, it uses the installed SVN, but I'm running Debian | 19:33 |
| SamB | (though I imagine it would for anyone who had built from source as well ;-) | 19:33 |
| SamB | (Well, built subvertpy from source, that is) | 19:33 |
| agrippa | hmm | 19:37 |
| agrippa | I might get ambitious and give it a shot, but I generally do have a harder time compiling things from source on OS X | 19:37 |
| SamB | agrippa: I can't say as I have any idea what svn subvertpy from the OS X will use | 19:47 |
| LarstiQ | agrippa: I think it's highly likely that it will use the standard system OSX, but I can't verify | 19:51 |
| jam | any qbzr developers here? | 19:58 |
| jam | I'm seeing a lot of deprecation warnings with a checkout of qbzr trunk | 19:58 |
| jam | Most notably: /home/jameinel/.bazaar/plugins/qbzr/lib/subprocess.py:600: DeprecationWarning: bzrlib.plugins.qbzr.lib.subprocess.SubprocessUIFactory was deprecated in version 1.18. | 20:00 |
| jam | Presumably bzr.dev started deprecating using CLIUIFactory directly | 20:00 |
| jam | and qbzr inherits from it? | 20:00 |
| jam | garyvdm: so you *are* around, just not responding :) | 20:27 |
| garyvdm | jam - I just signed on now | 20:27 |
| jam | np | 20:27 |
| jam | I just submitted a bunch of qbzr bugs so that you can feel loved | 20:28 |
| jam | mostly, I'm doing a demo, and ran into a bunch of niggles | 20:28 |
| garyvdm | Thanks | 20:28 |
| jam | The SubprocessUIFactory being the one I'd like to see fixed first | 20:28 |
| jam | bug #404269 | 20:29 |
| ubottu | Launchpad bug 404269 in qbzr "SubprocessUIFactory inherits from deprecated CLIUIFactory" [Undecided,New] https://launchpad.net/bugs/404269 | 20:29 |
| garyvdm | jam - I like your suggestion for bug 404276 | 20:30 |
| ubottu | Launchpad bug 404276 in qbzr "qannotate double clicking in per file graph gives diff rather than changing the annotation" [Undecided,New] https://launchpad.net/bugs/404276 | 20:30 |
| jam | \o/ | 20:30 |
| jam | Mostly it is just changing the default action | 20:30 |
| garyvdm | Yes | 20:30 |
| jam | Oh, I meant to submit another one | 20:30 |
| jam | which is that when you annotate to a new rev, it keeps the same line num | 20:31 |
| jam | but likely lines have moved | 20:31 |
| fullermd | jam: BTW, can you comment on my mail about that comment? It's your rev (though to be sure your memory is 3 years cold on it) | 20:32 |
| jam | fullermd: "comment on my mail about that comment" | 20:32 |
| jam | that is the 0.10 thing? | 20:32 |
| fullermd | Yah. | 20:32 |
| fullermd | (not necessarily right this second of course, just in general) | 20:33 |
| garyvdm | Right now - I'm feeling a overwhelmed. Lots of attention to qbzr lately has result in lots of good ideas and bug, and too few hours to work on them. :-~ | 20:33 |
| jam | fullermd: responded | 20:34 |
| jam | garyvdm: yeah, mostly just wanting to record ideas right now | 20:34 |
| jam | i had some thoughts to work on qannotate for what I've been doing | 20:34 |
| jam | and then i found that you implemented the things I was most pressed to add :) | 20:34 |
| garyvdm | Annotate old revision? | 20:34 |
| jam | garyvdm: per file graph being displayed, and moving around the revision graph | 20:35 |
| jam | I'd still like to get things hooked into the new Annotator code, and get caching working | 20:35 |
| jam | which would make jumping around *much* faster | 20:35 |
| jam | Working on 2a polish etc bugs right now, thoug | 20:35 |
| garyvdm | That would be cool | 20:35 |
| garyvdm | And I want to get it to annotate the wt | 20:36 |
| LarstiQ | polish? | 20:36 |
| flvr8 | hey guys, one of our developers is getting: ERROR: exceptions.KeyError: 'pop(): dictionary is empty' on his branch. are there steps he can take to fix that other than completely getting a new checkout? | 20:38 |
| jam | LarstiQ: well, stuff like making "bundles" work | 20:39 |
| jam | :) | 20:39 |
| flvr8 | he can't do a bzr diff to see his changes, because that gives the same error. | 20:39 |
| LarstiQ | jam: pfew :) | 20:39 |
| SamB | jam: that's called "fix" ;-P | 20:39 |
| jam | flvr8: a bigger traceback is usually helpful to understand what is going on | 20:39 |
| LarstiQ | jam: any idea how far to comletion that is? | 20:39 |
| jam | in the short term, things like this are often caused by plugins | 20:40 |
| jam | so doing "bzr --no-plugins XXXX" might work around it. | 20:40 |
| jam | LarstiQ: I have a branch, it has 2 tests failing that I know of | 20:40 |
| jam | got side-tracked into a meeting today | 20:40 |
| flvr8 | jam: https://bugs.launchpad.net/bzr/+bug/235407 - same stacktrace, he says | 20:40 |
| ubottu | Ubuntu bug 235407 in bzr "'pop(): dictionary is empty' in tsort when showing pending merges" [High,Fix released] | 20:40 |
| flvr8 | he was on 1.5 until very recently | 20:40 |
| jam | flvr8: see the comments | 20:41 |
| jam | The current workaround is to 'bzr revert' and re-do whatever merge got you into this situation. (As new bzr's won't let you get back into the same situation.) | 20:41 |
| SamB | flvr8: what's he on now ? | 20:41 |
| jam | or try applying the patch | 20:41 |
| flvr8 | 1.16 | 20:41 |
| flvr8 | er, 1.16.1 | 20:41 |
| flvr8 | macports doesn't have 1.17 yet | 20:41 |
| jam | flvr8: according to the bug, the problem is older revs of bzr wrote down bogus data | 20:42 |
| agrippa | :( | 20:42 |
| jam | there is a patch that tells bzr to ignore it | 20:42 |
| jam | as part of the bug | 20:42 |
| LarstiQ | agrippa: ? | 20:42 |
| jam | alternatively, "bzr revert; bzr merge" | 20:42 |
| agrippa | LarstiQ: 1.17 not being available on OS X | 20:42 |
| agrippa | LarstiQ: I can't get around this dirstate thing | 20:43 |
| LarstiQ | agrippa: I feel I'm missing something, dirstate thing? | 20:43 |
| jam | agrippa: as of 1:45am this morning (about 13 hours ago) someone posted to the list saying that they made a 1.17 installer. | 20:43 |
| jam | just not macports, I guess | 20:43 |
| agrippa | LarstiQ: Problem I was talking about earlier, I've been getting "Could not acquire lock" when doing bzr status | 20:45 |
| agrippa | jam: I saw the 10.4 installer, but not sure if that will work for 10.5 | 20:45 |
| flvr8 | jam: thanks, let him know that | 20:46 |
| jam | agrippa: new versions probably don't help, as you are probably running "bzr commit" in the other window | 20:46 |
| jam | and if the lock is taken, status can't aquire it | 20:46 |
| SamB | oh, yeah, that's in launchpad | 20:47 |
| SamB | as what, I don't remember ;-). | 20:47 |
| agrippa | jam: Not the case here | 20:48 |
| SamB | but it's sure a pain that when you do a bzr commit and it puts you in an editor, you can't interrogate your working directory+repo | 20:48 |
| agrippa | SamB: Just use bzr commit -m "message" | 20:48 |
| jam | SamB: pretty sure it is bug #98836 | 20:48 |
| ubottu | Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836 | 20:48 |
| LarstiQ | agrippa: ah, didn't realise it was that | 20:49 |
| agrippa | Yeah, this is what I'm dealing with basically: https://bugs.launchpad.net/bzr/+bug/31006 | 20:50 |
| ubottu | Ubuntu bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed] | 20:50 |
| ubottu | Ubuntu bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] | 20:50 |
| agrippa | ubottu's link includes that link | 20:50 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 20:50 |
| Tak | is bzrlib gpl or lgpl? | 20:51 |
| LarstiQ | flvr8: it was verterok who uploaded the OSX installers, but didn't update the wiki yet because he wanted testers, volunteer? :) | 20:51 |
| LarstiQ | Tak: gpl | 20:51 |
| === agrippa is now known as IHateErrno45 | ||
| === IHateErrno45 is now known as agrippa | ||
| Tak | kthx | 20:51 |
| LarstiQ | flvr8: http://edge.launchpad.net/bzr/1.17/1.17/+download/Bazaar-1.17-OSX10.5.dmg | 20:51 |
| agrippa | LarstiQ: I'll volunteer | 20:51 |
| flvr8 | LarstiQ - heh no, i'm on a sane operating system. but i'll pass that on to my colleague | 20:52 |
| LarstiQ | agrippa: cool! | 20:52 |
| verterok | agrippa, LarstiQ: thanks! | 20:52 |
| agrippa | verterok: I've got 8 procs you can crash :p | 20:53 |
| verterok | heh | 20:53 |
| LarstiQ | verterok: np, thanks for building it. And the config.py! | 20:54 |
| verterok | LarstiQ: heh, sure! it stills needs a lot of work, but at least isn't a 100% manual build anymore ;) | 20:56 |
| LarstiQ | verterok: very very nice | 20:56 |
| agrippa | verterok: So, is there someplace I can download the installer? | 20:57 |
| verterok | agrippa: http://edge.launchpad.net/bzr/1.17/1.17/+download/Bazaar-1.17-OSX10.5.dmg | 20:57 |
| flvr8 | ok, he reports that revert/merge doesn't work. he's committed some changes to his local repository but apparently is blocked from pushing to launchpad. noob question, since I haven't come across this before, how can he see which files he committed locally? | 21:00 |
| agrippa | Halp! All my files are deleted! | 21:00 |
| LarstiQ | flvr8: bzr st -r -3..-1 ? | 21:01 |
| LarstiQ | agrippa: hmm? | 21:01 |
| agrippa | LarstiQ: kidding | 21:02 |
| LarstiQ | agrippa: tsk :P | 21:02 |
| agrippa | Well, the installer seemed to work just fine. bzr --version gives 1.17 | 21:02 |
| verterok | agrippa: cool! | 21:02 |
| * verterok updates the wiki | 21:02 | |
| agrippa | verterok: I looked at your launchpad page. So you work on the Eclipse plugin? | 21:03 |
| verterok | agrippa: yes trying to get some spare time to get things moving) | 21:03 |
| agrippa | verterok: Is there a way to get the Eclipse plugin to work with filesystem links? | 21:04 |
| verterok | agrippa: filesystem links? | 21:04 |
| flvr8 | Larstiq - thanks. this is probably the revision that caused him grief fwiw. http://bazaar.launchpad.net/~daisyextension/daisyextension/main/revision/714 ... i tried uncommitting it, but bzr wants me to commit the uncommit, so i'm not sure if that'll help him out at all. (somehow my pull of his changes required a merge, which then required a commit before bzr was happy, which was why it's there) | 21:04 |
| flvr8 | Larstiq - so if i understand the problem fully, his 1.5 client dumped bad data in there, which confused my client, which then screwed the pooch for him(?) | 21:05 |
| agrippa | verterok: Yeah, I've got a linked folder in Eclipse and can't seem to get the Team menu to come up | 21:05 |
| LarstiQ | flvr8: uh, I haven't been fully following along | 21:05 |
| LarstiQ | agrippa: symlink? | 21:05 |
| LarstiQ | agrippa: or something more exotic? | 21:06 |
| flvr8 | oh well, that's a general question then. how do we fix the branch's metadata? | 21:06 |
| agrippa | LarstiQ: It's in Eclipse, but not a real symlink. | 21:06 |
| LarstiQ | agrippa: aah | 21:06 |
| verterok | agrippa: ooh, linked resources! the support is *experimental* I need to chase down all the places where resource checks are done and also check for links | 21:06 |
| LarstiQ | flvr8: I'm a bit overloaded to go check backlog fully, but for me to get what is going on I'd need some more debugging information | 21:07 |
| flvr8 | Larstiq: ok, i can just file a bug. but yeah, let me know what else would be useful to include? | 21:08 |
| LarstiQ | flvr8: not necessarily a bug | 21:08 |
| LarstiQ | flvr8: pastebinning the command and traceback (you may have already done so?) as a start | 21:09 |
| agrippa | verterok: Yeah, was trying that on this machine to see if I liked using a linked folder better for my source | 21:09 |
| LarstiQ | flvr8: but I'm going back to bug 390502 for a bit now | 21:09 |
| ubottu | Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502 | 21:09 |
| verterok | agrippa: btw, linked resources are (or are going to be) ignored by bzr-eclipse, at least regarding Team menu | 21:10 |
| verterok | agrippa: as the Eclipse team framework don't allow to do much with them (I must to check 3.5 to see if something changed related to this) | 21:11 |
| agrippa | verterok: Ah, ok. Thanks for the info. | 21:16 |
| verterok | agrippa: np | 21:17 |
| poolie1 | hi all | 21:23 |
| poolie1 | hi jam | 21:23 |
| garyvdm | jam: Bug will take me a while, because I need to try take advantage of the new apis (e.g. I can now override make_progress_view, rather than setting _progress_view) | 21:46 |
| garyvdm | bug 404269 | 21:46 |
| ubottu | Launchpad bug 404269 in qbzr "SubprocessUIFactory inherits from deprecated CLIUIFactory" [Medium,Confirmed] https://launchpad.net/bugs/404269 | 21:46 |
| garyvdm | jam: while still staying compatible with older versions of bzr | 21:47 |
| garyvdm | jam: so I need to check if make_progress_view is not there, if not, I need to set _progress_view... | 21:48 |
| garyvdm | jam: I would like to stay compatible with bzr 1.16 | 21:49 |
| garyvdm | poolie1: Hi - Maybe I have the wrong approach here. Any recommendations here to make things easier for me? | 21:50 |
| poolie1 | hi gary | 21:51 |
| poolie1 | garyvdm: possibly you need to inherit from different classes depending on the bzr version? | 21:57 |
| garyvdm | poolie1: I guess I'm looking for a silver bullet. The changes that you have made are good. It's just really hard to take advantage of them, while staying backward compatible. | 22:00 |
| garyvdm | bbl | 22:00 |
| poolie1 | garyvdm: do you actually need to override the progress methods? | 22:00 |
| poolie1 | you don't seem to do anything with them | 22:00 |
| poolie1 | sure, cheers | 22:00 |
| LarstiQ | don't they get called by pbs? | 22:00 |
| garyvdm | poolie1: We implement a custom TextProgressView | 22:01 |
| poolie1 | oh of course | 22:02 |
| poolie1 | it's also unfortunate that you need to deal with stacking | 22:02 |
| poolie1 | that should maybe be in the view or something | 22:02 |
| jam | hi poolie1 you're up early | 22:38 |
| poolie1 | i am | 22:38 |
| lifeless | heh | 22:38 |
| jam | hi lifeless | 22:38 |
| jam | especially given that it is poolie1 nad lifeless 's weekend :) | 22:39 |
| poolie1 | i woke up too early, i'm trying to be quiet | 22:39 |
| lifeless | paaaaaaa | 22:40 |
| lifeless | tay | 22:40 |
| jam | luulllaabby and goooodniiitee | 22:40 |
| jam | goooo to sleeep now, dear poooliee | 22:40 |
| LarstiQ | hah | 22:40 |
| * LarstiQ is about to crash | 22:40 | |
| lifeless | night | 22:41 |
| LarstiQ | lifeless: thanks for the reply | 22:42 |
| LarstiQ | lifeless: did subunit actually have any stacked branches? | 22:42 |
| lifeless | yes | 22:46 |
| lifeless | your problems are real | 22:46 |
| LarstiQ | ok | 22:46 |
| lifeless | by they aren't intrinsic to upgrade | 22:46 |
| pygi | hi folks | 22:46 |
| LarstiQ | lifeless: sure, I'm not claiming that there is no situation in which it would work | 22:47 |
| LarstiQ | lifeless: this question I specifically asked because I upgraded everything before I noticed it was 0.92 and no stacking was going on | 22:47 |
| LarstiQ | and I'll expand it into bugs tomorrow | 22:48 |
| LarstiQ | night | 22:49 |
| === jkakar_ is now known as jkakar | ||
| lifeless | LarstiQ: thanks | 22:51 |
| garyvdm | Hi pygi | 22:53 |
| garyvdm | poolie1: I like to make a change to the ui factory, and I just want to run the idea by you first. | 22:54 |
| garyvdm | I would like to split TextProgressView up into ProgressView and TextProgressView | 22:55 |
| poolie1 | sure | 22:55 |
| poolie1 | that sounds good | 22:55 |
| garyvdm | The code which keeps track of the last task message, the transport activity rate and formats the transport activity - that would go into ProgressView | 22:57 |
| garyvdm | All the terminal rendering code would stay in TextProgressView. | 22:57 |
| jam | garyvdm: 'formatting the activity rate' sounds like a higher level activity (IMO) | 22:58 |
| garyvdm | That would make it easier for qbzr to implementing a ProgressView | 22:58 |
| poolie1 | garyvdm: that sounds ok | 22:59 |
| poolie1 | if all the time-dependent or stateful stuff is localized that will help with testing too | 22:59 |
| garyvdm | jam: this line? msg = ("%6dKB %5dKB/s" % (self._total_byte_count>>10, int(rate)>>10,)) | 23:00 |
| garyvdm | jam: I doubt that gui's would want to ever format it differently. | 23:00 |
| jam | garyvdm: that looks like something where you'd want the total byte count, and could put it on separate lines, or etc. | 23:00 |
| jam | certainly I think of rendering as formatting from logical information (bytes) to a string | 23:01 |
| poolie1 | i think there should be a class that accumulates this | 23:01 |
| poolie1 | it's almost an ActivityModel | 23:01 |
| poolie1 | or a little state machine separate from rendering | 23:01 |
| garyvdm | jam, poolie1: Ok - I'll keep the formatting in TextProgressView. ProgressView will just keep state, and conduct. | 23:04 |
| poolie1 | garyvdm: you could make the formatting available in a higher class | 23:05 |
| poolie1 | but not assume it'll be used | 23:05 |
| poolie1 | then guis could use it if they want to | 23:05 |
| garyvdm | poolie1: Yes | 23:06 |
| poolie1 | well in that case i might go and have a saturday :) | 23:13 |
| * SamB wishes "bzr viz" supported ^revid like git ... | 23:17 | |
| jelmer___ | SamB: what does ^revid do? | 23:17 |
| jelmer___ | SamB: also, file a wishlist bug :-) | 23:18 |
| SamB | jelmer___: not show revid and it's ancestors | 23:18 |
| SamB | of course, first it would be important to allow revision specs ... | 23:18 |
| SamB | not just branches | 23:18 |
| * SamB thinks ... | 23:18 | |
| garyvdm | SamB - I assume this is when looking at multiple branches? | 23:23 |
| SamB | garyvdm: well, actually it's also useful if you want to see what's changed between bzr ppa builds ;-) | 23:24 |
| garyvdm | So you are using ^ revid as a stop revision? | 23:25 |
| SamB | no, I'm wishing I could | 23:25 |
| ali_ | Hi, what does asterisk "*" mean in bzr status? One guy reported a bug about it, lovely enough he didn't put the answer there. Sad. https://bugs.launchpad.net/bzr/+bug/74333 | 23:36 |
| ubottu | Ubuntu bug 74333 in bzr "Asterisk in status not documented (dup-of: 46636)" [Wishlist,Confirmed] | 23:36 |
| ubottu | Ubuntu bug 46636 in bzr "meaning of '*' in bzr status is undocumented and unverbose" [Low,Confirmed] | 23:36 |
| ali_ | thank you | 23:40 |
| sender | can anyone tell me what's the diff between workbooks.Open() and workbooks._Open() - or the "_" notation in general? | 23:43 |
| sender | _Workbook workbook = workbooks.Open() and Workbook workbook = workbooks.Open() ... | 23:43 |
| SamB | jelmer___: https://bugs.launchpad.net/bzr-gtk/+bug/404358 | 23:45 |
| ubottu | Ubuntu bug 404358 in bzr-gtk "support a revision-graph-specification language like that of git-rev-parse(1)" [Undecided,New] | 23:45 |
| SamB | now I know what you're probably going to say -- why should this be in bzr-gtk ? -- and you're right ;-) | 23:46 |
| sender | apologies.. wrong window :( | 23:46 |
| SamB | oh, what was the bug for "bzr send" not working with 2a? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!