[00:16] fuding [00:19] *funding === kiko is now known as kiko-afk [00:35] abentley: ping [00:36] Pieter: it was a reference to a cartoon, wherein a dog has written 'Cat fud' on the door of a tumble dryer [00:49] Another noob question: how do I get a list of files changed in a commit? With svn it's something like "svnlook changed MyRepo -r 123" [00:50] bzr st -c revno [00:50] or bzr st -r x..y for arbitrary ranges [00:50] lifeless: perfect, thanks! [00:53] how does bazaar show a diff with conflicts? [00:53] Pieter: I don't know what you mean by that [00:53] well, what does it look like? [00:53] (can I get an example somewhere) [00:54] do you mean 'if I run "bzr diff" when I have conflicts, what do I see?' ? [00:54] Pieter: you can only get them in your working tree, but it will just show the addition of the conflict markers and the "OTHER" block [00:54] lifeless: yes [00:54] james_w: ok, so no double +'s like git does? [00:54] Pieter: bzr diff doesn't report on conflicts at all, so as james_w says you just see the herringbone markers [00:55] Pieter: you mean with diff --c etc? [00:56] james_w: I guess.. git does it with --cc, which is a compacted version [00:56] james_w: like in http://pastie.org/291669 [00:57] I was wondering if bazaar did the same thing with triple @'s [00:57] there's --c and --cc I think [00:57] it doesn't currently [00:57] I played with adding it once [00:57] ok.. I want to use that to detect conflicting diffs in my app [00:57] so, it marks the whole region, not just one side? [00:58] So I thought I'd check other VCS's do that too [00:58] james_w: file a bug please :P [01:00] Pieter already did: bug 250783 [01:00] Launchpad bug 250783 in bzr "Add a combined diff view" [Wishlist,Confirmed] https://launchpad.net/bugs/250783 [01:01] Ah right, I thought bzr did the --c, but not the --cc [01:02] we have the code internally to do it [01:02] multiparent diffs [01:02] but we don't have a UI [01:03] ah, didn't think of that, I was trying to do it around SequenceMatcher === mwhudson_ is now known as mwhudson === mwhudson is now known as mwh === mwh is now known as mwhudson === mw is now known as mw|out [02:28] Does bazaar make it easy to collaborate with a co-worker on a lan the way git does? [02:29] akahn_: evenif they're 10k high and offline, yes [02:30] i'm thinking bazaar might be easier for the two of us to manage our work (web development) and put it online [02:30] bzr rocks. and i'm not just saying that because it's the #bzr chan [02:34] akahn_: yes; we have avahi integration, a built in server and other such things [02:35] avahi? [02:35] zeroconf [02:35] not familiar with that [02:35] its for completely adhoc networking [02:35] no servers at all sort of thing [02:36] i see [02:36] ah, what apple calls bonjour [02:40] thanks people [03:07] lifeless: pong [03:07] abentley: I had a weird revert failure [03:07] abentley: I suspect I did something to find a new corner case; so I filed a bug with the dirstate that caused it [03:07] lifeless: Okay. [03:10] lifeless: Is it possible reverting would have changed the root-id? [03:10] abentley: non-rich-root trees *as far as I know* [03:10] abentley: what I did was a parallel import of mysql, the pulled rev 1 of the import john did over that [03:11] abentley: (which conflicted on everything, moving them 'to the root'). Then a 'bzr revert' and boom. [03:12] lifeless: I don't know whether that importer would create unique root-ids. Can't say it wouldn't. [03:12] abentley: indeed. I know the parallel import didn't. [03:12] abentley: I can check one sec [03:13] lifeless: re your earlier question, if the previous job is still running the new one will just exit [03:13] abentley: the mysql import has a unique root id, even though its not a rich roots repo: [03:13] >>> r = b.last_revision() [03:13] >>> t = b.repository.revision_tree(r) [03:13] >>> t.path2id('') [03:13] 'sp1f-changeset-20000731191004-fzqw7vgyzfnpbmw6f5gziiclvgyq4nc4' [03:14] lifeless: Sounds like we have a corner case with root ids changing. I thought I had a test for that, but.. [03:15] abentley: yah [03:16] vila: ping [03:18] lifeless: Could you review http://bundlebuggy.aaronbentley.com/project/bzr/request/<48EFE285.7090402%40aaronbentley.com> please? [03:21] abentley: I think it needs a default on the if [03:21] in create_from_tree [03:21] else: [03:21] raise AssertionError("unknown kind %r" % kind) [03:22] all the rest has been reviewed by folk already [03:22] so I don't think you need a review of the other parts of the patch [03:24] lifeless: I'm not sure the rest has been reviewed by others. [03:25] abentley: poolie did the initial review saying that the iter_entries_by_dir hack was funky [03:25] lifeless: That was on another patch. [03:25] abentley: which lead through the iterations to where we are today; I'm happy with the rest of the branch anyhow [03:25] (well, i was just noticing that fairly long repeated expression) [03:26] lifeless: Thanks. I'll fix and submit. === Spaz is now known as {^} === timchen1` is now known as nasloc__ === {^} is now known as Spaz [05:51] poolie: ping [07:25] hi all [07:30] abentley: pong [08:06] Can one use the Intrepid APT repository for Debian Lenny systems? or is there a more suitable repository? [08:09] bazaar really can chew up memory when it wants too. [08:09] s/too/to/ [08:11] oh wow, it's greying out my terminal :) [08:17] poolie: ping [08:42] is TortoiseBZR included in bzr installer? [08:48] for windows, yes I believe so [08:48] poolie: on the off chance that you look at this tonight; usertest's in progress log has stopped at the set stage, the actual test run is progressing but not visible anywhere [08:50] I have download bzr-setup-1.8rc1.exe [08:50] but seems tortoisebzr not included.. [08:51] should I restart after install? [08:56] yo folks :) [08:58] (I was thinking of asking about PQM, but now I found the linuxfoundation.org article) [09:09] poolie: What's "Kerguelen"? [09:56] kerguelen is (a) an island in the southern ocean, and (b) a windows virtual server for testing and building packages [09:57] how is bzrbashprompt.sh supposed to work? [09:57] poolie: Ah, right. [09:57] speakman: do you mean what's it meant to do or how does it do it? [09:57] Google told me the former, but not the latter. :D [09:58] oh, I loaded it wrong, now it works :) [09:58] (god it makes bash slow though...) [09:59] are there any generic ways to speed up bzr? [10:00] first you should make sure you're using the compiled extensions [10:00] (ie are running from a package or have run make) [10:00] then there is 'bzr shell' (in bzrtools) and bzr-client (a plugin) [10:01] poolie: any thoughts on usertest ? [10:01] I'm running from ppa apt repo [10:03] bzr shell doesn't load my .bashrc or .bash_profile, and seems to lack tab completion :/ [10:04] speakman: in the last round of discussions folk were saying bzr is plenty fast for them; modulo really-big-trees [10:04] speakman: are you talking basic response time [10:04] speakman: or time to clone/do network stuff/etc ? [10:07] basic response time mostly, but the thought was more to make the bzrbashprompt.sh works a bit faster (it's a cool thing though!) [10:09] I do not have a problem with bzr in general (doing bzr commit and stuff), else I wouldn't promote it the way I do ;) [12:03] l [12:37] abentley: hello! I am reading [12:37] http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07 [12:37] and wondering: does 1.8rc1 include all of 1.7.1? [12:38] and is there a way to tell (for next time I wonder :) ? [12:38] To rephrase: 1.7.1 contained fixes to --weave, are they in 1.8rc1 too? [12:39] guilhembi: Yes, 1.8rc1 includes everything in 1.7.1. They always do. [12:39] abentley: thanks! [12:40] guilhembi: Anything in the NEWS file for a given release will pertain to that release. If 1.7.1 wasn't listed in the NEWS, you might wonder. [12:41] abentley: the NEWS file, you mean I should download the tar.gz of the release and read NEWS? [12:43] guilhembi: No, you can look at http://doc.bazaar-vcs.org/bzr.1.8/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07 [12:47] abentley: how did you arrive to the link above? I was able to find http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07 . [12:48] guilhembi: I went to http://doc.bazaar-vcs.org/ [12:49] abentley: thanks! === tchan1 is now known as tchan === kiko-afk is now known as kiko === mw|out is now known as mw [14:50] can I push/pull between server/debian bzr (0.11.0) together with laptop/ubuntu bzr (1.3.1) ... I guess not but how to solve this? [14:51] Help please: I emailed someone a bzr branch. They made changes and emailed me a merge-directive (MD). I merged the MD, made more changes, and I want to send back to them another MD. [14:52] oleavr, what's the problem? [14:52] If I create a copy of the branch I originally emailed them and "bzr pull" their MD, I can then do "bzr send ../original_plus_pulled_md" [14:52] But can I do this without creating a copy of what their branch looks like? [14:53] beuno: ? [14:53] e.g. something like "bzr send -r-2.. ." (which does not work by the way) [14:53] oleavr, misstyped, meant pysquared :) [14:54] beuno: ah :) [14:54] pysquared, so, you want to create a merge directive, without creating a branch? [14:55] I don't think you can do that, because you need to have his revisions in the ancestry [14:55] so you do actually have to create the branch [14:55] but abentley is the expert on the subject [14:57] pysquared: The only way to calculate which revisions need to be sent is using a branch that lacks the revisions they lack. [14:57] Or specifying which is the last revision of the current branch they have?? [14:57] (Or am I being dumb?) [14:57] pysquared: No, that's a way of specifying what merge you want them to perform, not which revisions need to be sent. [14:58] Sorry, please could you elaborate on "what merge" means. [15:00] Merge is a bzr command. It combines two lines of development. It can merge either from a branch or from a merge directive. When it uses a merge directive, it performs the merge that was specified in the merge directive. [15:01] So when you specify bzr send -r 53..54, you're saying "merge just the changes from 53..54, even if you haven't merged 52" [15:03] I have used merge before (just a beginner though). I'm just testing some merges now... [15:04] Is this correct: If I specify bzr send -r 10-30, and they are already at revision 20, then part of the merge directive is ignored, and they get the latest 10 revs? [15:05] That is true. [15:06] Good, so it seems like I can do what I want: generate a merge-directive without having access to their branch, as long as I know what is a common ancestor revid? [15:07] pysquared: Do they already have copies of your revisions? [15:08] Hmmm? I think that is what I am trying to send them in the merge directive no? [15:10] pysquared: No, you're telling them *what* to merge. [15:10] I basically want to find the most efficient way to generate the smallest merge directive which contains the work I have done since merging the work they did. [15:11] pysquared: In your example, if they already have revision 20, bzr only needs to send revisions 21..30. [15:11] Cool. What is the incantation? [15:11] pysquared: In my example, if they don't have 52, it needs to be sent, because it will be used indirectly. [15:12] pysquared: bzr send path/to/mirror/of/their/branch [15:12] I cannot find a way to produce a merge directive using a standalone branch which matches the one generated using a copy of their branch. [15:13] I think using path/to/mirror/of/their/branch should be unnecessary, but perhaps I am missing something important. [15:13] pysquared: If you use your own branch as the submit location, you will always get an empty bundle, and that will never be what you want. [15:13] pysquared: It is used to calculate which revisions need to be sent. [15:13] *Yes* that was what I was getting - empty bundles [15:14] pysquared: By default, it is also used to calculate the merge to be performed, though you can override this with -r. [15:15] Can I tell "bzr send" which revisions need to be sent and the merge to be performed, and therefore lose the dependency on path/to/mirror/of/their/branch? [15:15] pysquared: No. [15:16] Oh :-( [15:16] That felt strangely like chasing my own tail :-) [15:16] pysquared: I said that at the start. You need to use a branch that lacks the revisions they lack. [15:17] bzr is giving me a weird url to break a lock, does this look right? [15:17] bzr break-lock chroot--1217453396:///some/path/trunk/.bzr/branch/lock [15:17] ahasenack: No. Just use the normal URL for that branch. [15:18] abentley: Is it possible do you think to add this feature? [15:18] abadger1999: thanks [15:18] er [15:19] abentley: thanks. Known bug? Should I open one? [15:19] heh. I need to change the first two letters of my nick. [15:19] pysquared: It is possible, but pretty pointless. Branches are ~44k [15:20] pysquared: And the overhead of keeping track of their branch manually instead of letting bzr do it seems not worth it. [15:26] abentley: thanks for your patience and help. [15:40] vila: I'd like lp-login to set the username that is used whenever bzr+ssh://bazaar.launchpad.net is specified. It seems like the best way to achieve this is to use AuthenticationConfig. Does that make sense to you? [15:41] abentley: yes [15:42] vila: Where would be the best place for this? In the SSHVendor code, or the individual transports? [15:43] I didn't address it at times because... can't remember exactly, lack of test infra or shyness to touch the launchpad plugin code [15:43] Well, if you do declare bazaar.launchpad.net in the file, it should already work [15:44] That is the intent at least :) [15:44] vila: Really? I see that for paramiko, but I thought the rest didn't use it. [15:44] hmm, let me refresh my memory [15:48] Ha yes, only paramiko implement access to auth [15:49] The sub process ones are alien to me (I use only paramiko), but I guess the right place is in connect_[ssh_sftp] for SubprocessVendor, LoopbackVendor doesn't care [15:50] vila: Any suggestions how to test that? [15:51] Tricky :) [15:51] I think we lack the infrastructure for authenticating test servers [15:52] So... the closest existing code will be in test_http/http_utils/http_server I guess [15:54] I tested the AuthConfig in test_config.py and then there are some full stack tests in test_http (test_prompt_for_password, test_no_prompt_for_password_when_using_auth_config) [15:54] vila: do we actually use AuthenticationConfig for ssh ? [15:55] Only for paramiko apparently [15:55] scratch apparently [15:55] well, we would like it there [15:55] I'm not sure if we should be more consistent [15:55] but as paramiko doesn't have another way to configure it [15:55] jam: My motivating example is Launchpad. [15:55] that is at least a start [15:55] abentley: I understand what you are after, and I've read the bugs as well [15:55] jam: more consistent ? [15:56] I think that having a way to configure the username for paramiko is a good thing [15:56] and perhaps "launchpad-login" is good enough [15:56] vila: If we are going to use AuthConfig for paramiko, shouldn't we also use it for ssh and plink? [15:56] arguable either way [15:57] jam: launchpad-login doesn't do enough. It doesn't allow users to use "bzr+ssh://bazaar.launchpad.net" URLs that have no username. [15:57] jam: If we are going to insist that people specify their username via launchpad-login, not .ssh/config, we should ensure that it works all the time. [15:58] abentley: well, I'd argue that either you use lp: or you use bzr+ssh://user@bazaar.launchpad.net... No ? [15:58] vila: That's not a shareable URL, so it can't function as a public URL. [15:59] * vila should stop editing branch.conf and put lp: urls there ? :-) [15:59] vila: I think that forcing a username into bzr+ssh urls is a bad choice because the resulting URLs can't be shared with other users. [15:59] Haaa, misunderstood [16:00] but then use lp: ! [16:00] vila: That's not usable by people who don't have the launchpad plugin. [16:00] and propagate it to .conf files so I can stop editing them :) [16:00] And it's not a real URL. [16:01] there are people who don't have the lp plugin and want to use lp, oook. Fair enough :) [16:01] abentley: shaking the tree, don't take it personally :) [16:01] I've implemented lp as a directory service. This makes much more sense than implementing it as a transport. But it means that the canonical url is whatever lp resolves to. [16:01] abentley: the number of users that are going to be using launchpad with bzr but not have the launchpad plugin is roughly -10% at the moment [16:01] (yes negative) [16:01] :) [16:02] jam: Are you proposing to make it part of the core, not a plugin? [16:02] on the subject of AuthConfig with ssh, we decided to refuse to handle passwords, pointing people to agents instead (just a reminder) [16:02] abentley, vila: care to comment on bug #283123, I don't really want it to be just me versus bialix [16:02] Launchpad bug 283123 in bzr "Wrong result of cherrypicking merge" [Undecided,Won't fix] https://launchpad.net/bugs/283123 [16:03] abentley: well, how many installs *right now* don't have the plugin... 0 [16:03] how many installs in the future to we expect to not have it [16:03] roughly 0 [16:03] unless something changes dramatically [16:03] jam: If we're going to require it, it shouldn't be a plugin. If it's a plugin, we shouldn't require it. [16:03] abentley: I think requiring it for people using lp: urls is just fine [16:04] as private urls won't resolve for everyone anyway [16:04] some people won't be able to reach your server, etc. [16:04] and branches move from time to time, servers disappear [16:04] I think we can make a "reasonable effort" without having to turn the world around [16:04] Obviously you feel stronger about it, and you're welcome to feel that way [16:05] I think using "lp:" urls is a nice pretty way to do things [16:05] that actually helps more than hurts [16:05] that said, I agree that I'd rather not have "bzr+ssh://myuser@" [16:05] I really dislike lp urls, because they mask what's really happening. [16:05] Having a way to look up URLs is great. [16:05] Pretending it's the actual url... gross. [16:06] anyway bbiab, taking my son to day-care [16:12] mornin' all [16:18] jam: I think that if a user specifies a username in authentication.conf, Bazaar should respect that. I think it simplifies documentation and knowledge transfer to have this work for all SSH vendors. However, if they haven't specified something in authentication.conf and the SSH vendor has its own configuration mechanism, that should be respected. Do you disagree? === kiko is now known as kiko-phone [16:37] abentley: so I think it should be "URL username", "auth.conf", "ssh/config", in that order [16:37] I'm a bit concerned about "accidental" entries in authentication.conf [16:37] because we put them there, rather than just users [16:37] however, if we are careful, it should be finee [16:37] oh, and I wanted to point out an advantage of using lp:... [16:38] users who *don't* have an lp account or haven't issued 'lp-login' can still get the public branch [16:38] jam: I agree with your order. [16:38] (the only bug I know of is problems behind an http_proxy, because xmlrpc doesn't support it) [16:39] jam: We currently do add entries to auth.conf, or we would? [16:39] abentley: probably "we would", though I thought vila had some specs about adding things automatically when we connect to a server for the first time and prompt the user [16:40] I'm not sure what has been implemented [16:40] jam: Okay. [16:41] abentley: we currently don't add entries to auth.conf, but we would [16:42] jam: Certainly it would be possible supply credentials via AuthenticationConfig without touching auth.conf if we decided we wanted to. [16:44] Something like that would happen if we supported native keychains/seahorses anyway. But I doubt it's the right choice here. [16:44] jfroy is working on supporting OS X keychain [16:45] I made an attempt to accept pluggable credential stores at: lp:~bzr/bzr/pluggable-credential-stores [16:46] but that doesn't address your need which is to provide a *user* name (not a password) [16:48] And if we want to provide more public URLs, that may be needed === Verterok is now known as Verterok|lunch === Verterok|lunch is now known as Verterok [17:36] vila: I took a look at lp:~bzr/bzr/pluggable-credential-stores. I'm confused because it says "We don't use the netrc ability to provide a user since this is not handled by authentication.conf". AIUI, authentication.conf can provide users. [17:37] vila: Do you mean that only authentication.conf should provide users, not .netrc? [17:37] abentley: netrc can provide a default user, but we don't get it [17:37] abentley: yes [17:37] badly phrased, AuthConfig can't handle it, of course authentication.conf can [17:39] May be we should rename 'password_encoding' to 'credential_store' and allows the user to be provided :) [17:39] may be that 'we' is really an 'I' :) [17:39] I'm confused. AuthConfig has a get_username method. [17:40] * jfroy|work listens to the conversation [17:41] Maybe I don't understand the intended layering. [17:41] but it doesn't delegate to the credential stores so it can't get the user provided by netrc in that case [17:41] it just get the ones that are declared in authentication.conf [17:42] as described in the spec, only the password was intended to stored outside of authentication.conf [17:42] s/to/to be/ [17:42] vila: So I think you want authentication.conf to specify the user, and then to allow credential stores to provide credentials for that user. [17:44] Well, either the user is specified in authentication.conf or provided by the credential store, otherwise users would get confused [17:45] credentials are for user at a host, optionally at a path and so far is only a password [17:45] at a path or at a realm even [17:46] rephrasing: now, the user in authentication.conf only and credential stores can provides passwords === kiko-phone is now known as kiko [17:46] We can change that so that credential stores can provide user and password. But in that case the user shouldn't appear in authentication.conf (IMHO) [17:55] abentley: is the following clearer : [17:55] # We don't use the netrc ability to provide a user since there [17:55] # is no way to give it back to AuthConfig. So if the user [17:55] # doesn't match, we don't return a password. [17:57] vila: That's better. But it implies a flaw in AuthConfig, rather than a design decision. [17:58] abentley: agreed, especially with your new use case [18:01] vila: Oh. I thought you believed that AuthConfig should not allow a user to be specified. So I thought you should say something like "To reduce confusion, users are specified only on AuthConfig. So we don't use netrc to choose a default user." [18:02] vila: But if you now think it makes sense for credential providers to specify a user, then your revised comment is good. [18:04] It makes sense for credential stores to be able to provide user, in which case the user shouldn't be specified in authentication.conf. If the credential store doesn't provide user then it should be specified in .conf. [18:04] So I will work in that direction in that branch which is work-in-progress with a nick that perfectly fits :) [18:05] abentley: Thanks for the feedback [18:06] vila: No problem. === kiko is now known as kiko-fud === Verterok_ is now known as Verterok === kiko-fud is now known as kiko [19:03] hello [19:04] i am trying to use the bzrlib in my application [19:04] evening woutc__ === mw is now known as mw|food [19:05] but now i want to know the best function to check if a branch was changed by other people (somebody pushed the branch to a new rev) [19:05] so i would like the log and the new rev number [19:05] without pulling the branch [19:06] woutc__: are the two branches the same (same url), or do you have one local branch you want to check against a remote one? [19:06] woutc__: ala `bzr missing` [19:06] i want to check a local branch to a remote one [19:06] ok [19:06] jelmer: bzr-svn 0.4.13 is for bzr 1.7.x right? [19:07] rocky, also for 1.8 [19:07] ah cool [19:07] bzr missing does what i need? [19:07] rocky, I'll probably release a 0.4.14 that silences the compatibility warning at some point [19:07] jelmer: am i better off playing with bzr-svn 0.4.x branch (bzr 1.7.1 here) or bzr-svn 0.4.13 ? [19:08] woutc__: yes. Looking at that code, it seems to be find_unmerged(local_branch, remote_branch, ...) [19:08] the 0.4 branch is for bzr 1.9.x [19:08] woutc__: see bzrlib/builtins.py, search for cmd_missing [19:08] thank you so much! :) [19:08] woutc__: let me have a look at the IDE integration page btw [19:08] woutc__: if it isn't on there, it should be [19:08] jelmer: huh? so no more releases for bzr 1.7.x or 1.8.x ? [19:09] rocky, not for 1.7, maybe one for 1.8 that is 0.4.13 + silences the compatibility warning [19:09] LarstiQ: it seems that it isn't listed on the integration page [19:09] jelmer: i take that to mean bzr 1.8 is right around the corner? [19:09] woutc__: right. When you figure out exactly what to do, could you add it to http://bazaar-vcs.org/Integrating_with_Bazaar? [19:10] woutc__: I'm happy to review or help otherwise [19:11] ok, i am the developer from specto (http://specto.sf.net) and i am trying to create a watch that notifies you when somebody committed to a branch :) [19:15] woutc__: do you also support events instead of polling? Would need the help of the remote branch to work though, but would be less intensive. [19:18] the current specto design works only with polling [19:19] so if the refresh (or poll) time is not set too low, it is not really a problem [19:23] k [19:24] jelmer: looks like that ghost revision bug thing i talked to you about before is back (it went away there for a bit) .... http://cluebin.appspot.com/pasted/2401 [19:39] i found the function but i get an error [19:39] >>> local_branch = Branch.open_containing(u".")[0] [19:39] >>> parent = local_branch.get_parent() [19:39] >>> local_extra, remote_extra = find_unmerged(local_branch,parent) [19:39] Traceback (most recent call last): [19:39] File "", line 1, in [19:39] File "/usr/lib/python2.5/site-packages/bzrlib/missing.py", line 62, in find_unmerged [19:39] remote_branch.lock_read() [19:39] AttributeError: 'unicode' object has no attribute 'lock_read' === mw|food is now known as mw [19:47] woutc__: You have the location of a branch as a unicode string, and you're treating it like a Branch object. [19:49] but the variable local_branch is a Branch object, no? [19:49] >>> type(local_branch) [19:49] [19:50] woutc__: but 'parent' is not [19:50] Programming Python, O'Reilly, Mark Lutz, ISBN-10: 0-596-51398-4 [19:50] woutc__: the two first arguments to find_unmerged are the two branches you want to compare [19:50] woutc__: and branch.get_parent() returns a url, not a branch [19:51] haha so i have to create a branch object with the url :) [19:52] ok that did the trick [20:01] OSamaK: Learning Python is good when you don't know about the language, so I guess thath you find some a little more advanced [20:03] rocky, yeah, afaik 1.8 should be released soon [20:04] * rocky finds it odd that he's the only person in the world to have such a glaring problem [20:09] rocky, ? [20:10] jelmer: well this is preventing me from using bzr-svn (whether it's bzr's fault or not) ... just seems strange that this "showstopper" isn't severe enough to have fixed for bzr 1.7.1 [20:10] rocky, which showstopper? [20:10] jelmer: http://cluebin.appspot.com/pasted/2401 [20:10] jelmer: you didn't see my paste above? http://cluebin.appspot.com/pasted/2401 [20:10] * LarstiQ does drive by pasting and leaves the house [20:11] lol [20:11] LarstiQ, :-) [20:11] rocky, :-( [20:18] rocky, That's a bzr-svn bug primarily, unfortunately (IIRC caused by older versions of bzr-svn that wrote incorrect data) [20:19] jelmer: old data shouldn't be an issue... how do i get rid of old data? [20:22] rocky, the old data in the svn repository, if you do a fresh checkout (remove ~/.bazaar/svn-cache) outside of your existing shared repo it should work [20:34] james_w, ping [20:34] hey jearl [20:34] er, jelmer [20:34] how are you? [20:34] Very good, thanks (-: [20:34] james_w, You asked about bzr-notify crashes earlier [20:34] cool [20:35] I've uploaded a new snapshot of bzr-gtk that should fix those issues [20:35] yeah, apport has shown that it affects a few people [20:35] ah, great [20:35] to experimental? [20:35] bug 283294 arrived today, but I'm not sure why that only seems to affect Ted [20:35] Launchpad bug 283294 in bzr-gtk "bzr-notify crashed with RuntimeError in add_signal_receiver()" [Undecided,New] https://launchpad.net/bugs/283294 [20:36] yep, I uploaded to experimental [20:36] I'm not sure what Ted's bug is about either [20:37] I mean no mainloop is defined as far as I can see, so it's right [20:37] but why isn't that always a crash? [20:39] I think it (used to ?) creates a mainloop implicitly === thumper_laptop is now known as thumper [20:42] jelmer: I'd like to just cherry-pick the fixes out, as we're two days from RC freeze, and it will avoid a freeze exception request [20:43] james_w, One sec, I'll look up the relevant revnums [20:44] jelmer: there are a couple of fixes missing that I put in to the Ubuntu package, I'm sure I checked they were fixed in trunk though [20:44] http://paste.ubuntu.com/57563/ for a start [20:47] thanks for the heads up, I'm going to eat now, I'll work on it after that [20:47] james_w: http://people.samba.org/bzr/jelmer/bzr-gtk/trunk, revisions 607-611 [20:47] thanks [20:48] james_w, bon appetit [20:48] james_w, I think we may not have those changes, will check [21:07]