[00:00] there are a few others. Glosi, volapuk, ido, interlingua... [00:00] Klingon. ;) [00:01] I was thinking you should learn Arabic, because then people can't pretend that they can read what you write [00:01] Or have the characters installed on their system (yet) [00:01] Pfft, Elvish is just as good for that. [00:01] Odd_Bloke: can you type it in chat, so I can see? [00:02] No, because neither of us have the appropriate fonts installed (and I'm using irssi). :p [00:02] Odd_Bloke: well, I probably have the right fonts installed, irssi might get tricky [00:03] Well, http://www.kevnet.com:9000/LOTR%20TEXT/images/tengwar.jpg has an example of some of the characters. [00:03] عرابي [00:03] But those are all consonants, because the vowels in a word are expressed using what are essentially accents. === epsy is now known as rolf_mao [00:04] Odd_Bloke: that is the system used in Arabic [00:04] Only they *usually* leave the accents off [00:04] (Except for in super special texts like the Qur'an) [00:05] http://www.geocities.com/tengwar2001/pubs.htm has font packs for the Tengwar at the bottom. [00:05] And examples of its use above that. [00:05] Anyhow, I'm going to return to watching Doctor Who. [00:06] does Tengwar have a unicode character mapping? : ) [00:06] last I heard, fonts for it just mapped to ascii (english) letters. [00:09] NfNitLoop: I don't know anything more than the abstracts of a Google search told me, but its not in the official standard. [00:12] Esperanto characters are within the Latin-3 charset. (and thus, unicode, too.) And I think I read that Klingon speakers have an unofficial unicode range. [00:13] Last I knew, Klingon used the private use area of Unicode in fonts that support it. [00:13] ah, that's right, "private use area". [00:13] my unicode knowledge is a bit rusty. :) [00:14] jam: oh, and thanks for all those reviews [00:15] spiv: happy to, sorry I didn't get to all of them. [00:16] I'm off for the night, *babytime*, see you all around [00:18] Stop! *babytime* [00:34] i'd like to merge two repositories that were totally independent. trying bzr merge asked for a base, and i'm not really sure what it's getting at [00:35] hi dberkholz [00:35] bzr merge -r0..-1 will allow you to do that, it specifies that you want revision 0 as the base, i.e. the null revision that all branches have in common. [00:35] and with that I'm off to bed. Night all. [00:39] night james [00:44] abentley: pong [00:45] james_w: hi [00:45] hello lifeless [00:45] Man, cliffhangers suck. [00:45] james_w: thanks! [00:45] lifeless: I'd like to make an optimized fetcher for pack-0.92 to rich-root-pack. [00:46] Can you suggest an approach? [00:46] Pack.pack seems a little too granular... [00:47] abentley: I think VersionedFiles will correct the performance of plain to rich roots with packs [00:48] Okay. You're planning to get that in this cycle anyhow, right? [00:48] yes [00:48] this week I hope [00:48] Okay, so I'll reassess whether that's necessary then. [00:49] if you do want to do one, I would subclass Packer [00:50] you'd need to change the main driver function [00:50] as you won't be able to copy the revisions blind, nor the inventories [00:58] bbiab [01:31] poolie: one_five is missing [01:33] just add it if you want to use it... [01:43] ok === i386_ is now known as i386 [02:12] poolie: abentley: jam: think its tasteful to expose the transactional ability of a repository? [02:12] e.g. packs can safely request unordered streams [02:12] but knit repos need ordered streams [02:15] lifeless: My gut reaction is that it's not tasteful, but I could be convinced. [02:16] ok [02:16] so in requesting from a smart server [02:16] unordered will perform better because it can linear-scan the pack files into the stream [02:17] but unordered requires much more IO and buffering when inserting into a knit style repository [02:18] also with direct access the same difference will show up [02:33] abentley: so the problem I need to solve is how to get the right ordering flag in the requests [02:34] abentley: without duplicating all the fetch logic [02:36] For what purpose? Not fetch? [02:39] It has to be insertion, or else atomicity or the lack of it in the target is irrelevant. [02:40] Which in most cases is fetch. So I don't understand what "without duplicating all the fetch logic" means. [02:43] for fetch [02:43] well [02:43] for the same model/serialisation fetching between two repositories [02:44] if both are knits/weaves we need topological ordering [02:44] if the target is packs we want unordered [02:44] which lets the source optimise reads [02:47] lifeless: I'm willing to break abstractions when necessary [02:47] as long as there are tangible benefits [02:48] jam: I've been thinking about find_difference [02:49] jam: I think a profitable avenue is to consider reframing the halting problem as 'determine the relative graph height' [02:50] lifeless: well, I have code now that performs fairly reasonable on bzr.dev [02:50] for find_unique, talking <100ms for all merge nodes [02:50] well, on average [02:59] jam: that seems slow to me [02:59] jam: and I bet it is doing more work than needed if it is essentially tracking all the nodes independently [03:00] lifeless: only interesting tips [03:00] but sure [03:00] I can't say that there is a lot less you could genuinely do [03:00] lifeless: I understand the benefit of optimizing read order. I don't understand the problem with doing that via Interrepository. [03:01] abentley: RemoteRepository [03:02] abentley: for pushing into a RemoteRepository the selected RemoteRepository will be the same regardless of the actual disk format [03:03] gotcha. [03:07] Well, like I said, it was a gut instinct. If that's the most practical way to proceed, go ahead. [03:07] But the way RemoteRepository masks the real repository is a continuing problem. [03:09] * AfC waves to jam [03:18] abentley: my instinct isn't to do so either; but I do need to solve the problem eventually; using topological ordering everywhere will impair pack performance [03:18] ok full test run with join() out of use [03:19] Well, we could just always do unordered and make the luddites suffer :-) [03:20] I seriously considered that [03:20] however the pathological cases for that really are pathological [04:28] reviewing abentley's patches now === RAOF_ is now known as RAOF [06:30] spiv: my versioned_files branch on lp/puc [06:32] lifeless: ta [06:32] puc will obviously be more up to date [06:45] * mtaylor is away: I'm not here right now [06:58] lifeless: hi, want to talk when you're done? [07:00] lets talk now [08:57] night all [10:57] hello [10:57] I'm new to bazaar [10:57] I have made a local copy of the emacs bzr repos and made some changes [10:58] how do I get the diff between my local branch and the emacs repos? [10:58] I tried for instance: bzr diff --old HEAD --new emacs-winprop [11:00] jave: does "bzr diff -r submit:" do what you want? [11:01] ill try, its rather slow [11:02] I'm using bzr 1.3.1 dsitributed with fc8 [11:02] Hi, I'm about to embark on some Linux kernel development work and I need to revision control it. While 'git' is the obvious choice, I'd prefer bzr if possible since i'm used to it. How well does bzr cope with linux-kernel size trees and will loom cope with it too? [11:04] james_w: submit: seems to do the thing, Thanks ! [11:05] hi Kinnison [11:05] I've never tried bzr on a kernel size tree, so I can't say for sure I'm afraid. [11:10] :-( [11:10] I hate git [11:36] Kinnison: well, people have imported emacs and openoffice into bzr, so it at least doesn't explode out-right. [11:36] I don't have any actual numbers for you though. [11:38] do the autotest tests include the kernel? [11:47] james_w: the usertest ones do (if that's what you mean) [11:47] hi igc [11:48] hi [11:48] yes, that's what I meant. [11:49] Kinnison: we currently include a snapshot of the kernel in our performance testing but it's a historyless repo [11:50] Kinnison: if you get a copy of the kernel (with history) imported into Bazaar, please let us know and we'll then start including that in the testing we do [11:51] for details on the tests I run, see the bzr-usertest plugin [11:52] you should also find bzr-fastimport useful for doing the migration, though it might be have a few bugs [11:52] james_w: have did your OpenWeek session go? [11:52] s/have/how/ [11:54] it was ok thanks. Not many questions though. [12:00] igc: I don't care about the kernel's history, it's more for managing a series of patches I need to write [12:00] igc: I figured loom made sense for that [12:01] Kinnison: I would imagine that bzr add in the tarball and then loom would probably be ok. [12:02] james_w: That's what I'm hoping, but I'm making a copy of the git repo just in case [12:04] One thing git has going for it is that it filled my 10Mbps pipe [12:04] I've never seen bzr manage that [12:05] igc's usertest results show all tested commands taking under a minute, with only 4 taking over 30 seconds, and only 5 over 11 seconds. [12:11] Well, I have a crappy slow HDD so we'll see :-) [12:12] OTOH, 4GiB of RAM helps [12:13] Hmm, if bzr st takes too long I'll have to remove it from my prompt [12:14] 4GiB will definitely help with bzr st... [12:20] http://domscripting.com/blog/display/41 [12:22] It's merrily committing and thus chewwwing all my CPU and disk :-( [12:22] Oh, updatedb is running [12:24] grr, that took 5 minutes, thanks updatedb [12:24] otoh, bzt st takes around 1.5s, so kudos to the team [12:27] Okay, can I reconfigure a branch into a repository, or do I have to pull/branch it into one? [12:27] i think maybe bzr.dev can reconfigure it [12:27] i can't remember if that bit landed [12:28] * Kinnison updates then, my bzr.dev mirror is at r3334 === mwhudson_ is now known as mwhudson [13:38] night all === bigdo3 is now known as bigdog [15:26] Hi, any opinions or work-arounds for https://bugs.launchpad.net/bzr/+bug/214894 ? [15:27] bug #214894 [15:27] Where is ubotu? [15:27] fbond: you can do "bzr pull . --overwrite" [15:27] and after that "bzr push" should work [15:28] jam: and a fix is forthcoming? [15:28] jam: have my repos/branches suffered any permanent damage (I assume not)? [15:29] fbond: nothing serious, you just used an older version of bzr (probably a *long* time ago) [15:29] which allowed the history to wander [15:29] see bug #177855 [15:29] https://bugs.edge.launchpad.net/bzr/+bug/177855 [15:30] jam: So is it enough to run bzr check on the remote branch and then push to it again? [15:31] fbond: you shouldn't need to run bzr check even [15:31] upgrading the remote branch would also fix it, though. [15:31] jam: Okay, `bzr pull . --overwrite' should be run on the remote branch, then? [15:32] fbond: I think so [15:32] It has been a while since I worked on this [15:32] if you want, please post your results to bug #177855 [15:32] I assume that `bzr pull . --overwrite' just rewrites the branch's revision history... [15:33] fbond: correct [15:33] it just needs to be regenerated so that it is "canonical" [15:33] jam: Hmm, that didn't seem to work. I'm trying `bzr reconcile' (as is mentioned in #177855). [15:34] Or maybe I need to be running these on the local branch (not the remote one)... [15:37] fbond: just as a help, can you run "bzr info" on both branches and pastebin the results? [15:39] Which pastebin? [15:41] jam: Should I use pastebin.ubuntu.com? [15:44] fbond: that is fine [15:49] http://pastebin.ubuntu.com/8758/ [15:50] jam: I cleansed some URLs and paths and things, hopefully I didn't screw that up. [15:50] So the remote branch is bzr+ssh://user1@host1/home/user1/project/ [15:51] fbond: yeah, no problems with the urls [15:51] I wanted to see the other info [15:51] namely the "format:" lines [15:51] jam: That's what I figured. [15:52] fbond: just a sec, phone call [15:52] jam: Take your time. [15:56] jam: AFAIK, reconcile doesn't currently adjust revision history. [15:57] abentley: no it doesn't, I was going to work on that right now [15:57] :) [15:57] Since we have 4+ bugs reporting the same thing [15:57] Cool [15:57] we probably need to fix it [15:58] your bug comment about reconcile is a bit misleading, though. [15:58] abentley: well I thought I wrote "we need to do X" [15:58] not that "X" works [15:59] abentley: but I can see how my comment is misleading [15:59] I'll post a followup [16:00] abentley: where do tests for "check" go? There isn't a 'test_check.py' [16:00] or maybe this is a branch impl test? [16:01] I don't know. [16:01] I haven't worked in the check/reconcile code for a while [16:01] And I know Odd_Bloke was sticking his fingers in there recently [16:02] jam: You don't actually advocate forbidding http://host/branch/subbranch, right? [16:02] Peng: I actually *like* it, but if you are going to forbid "http://host/repo" being a branch, then it seems the other should be gone as well [16:02] jam: Hmm, so I guess I can just push over sftp:// and things will work, eh? (`bzr pull . --overwrite' doesn't seem to do anything useful for me). [16:03] fbond: can you do "bzr push --overwrite" and see if that works? [16:03] I'm thinking the code path may not anymore [16:03] jam: Sure thing... [16:03] The problem is it detects "nothing changed" and then doesn't actually fix things up [16:03] abentley: "knit or dirstate" is Branch5, right? [16:03] Branch6 would report "dirstate-tags" [16:03] IIRC [16:04] jam: I get the same AssertionError with push --overwrite [16:04] Right. [16:04] jam: Well, I think having "http://host/repo" be a branch makes it hard to discover when you're just browsing the web server, but there's no need to bother banning it, especially at the cost of nested branches. [16:04] fbond: you're on a Linux machine, right? [16:04] jam: yep, RHEL on the server, Hardy on my workstation. [16:04] Peng: mostly just for "consistency", if people want to disallow nesting branches, etc [16:05] fbond: ok, I'll give you a snippet of code that will get things working again, and then I'll go try to fix reconcile and check [16:05] jam: okay, thanks! [16:07] lifeless: BTW, I am holding off on any loom workflow docs until some enhanced automation is in place to support the "quilt replacement"-style workflow. [16:07] lifeless: It would just feel a little silly to recommend that people do so much manual work to move around the loom after committing new changes to a low thread. [16:08] lifeless: So, please do keep my posted if anything changes with this, and I'll be happy to document how I use things. [16:09] fbond: http://pastebin.ubuntu.com/8766/ [16:09] save it as a "cleanup.py" [16:09] and then run it in your local branch [16:09] afterwards, bzr push should work [16:12] fbond: let me know if it works/doesn't work [16:12] we can attach it to the bug as a current workaround [16:13] jam: no, didn't do anything (and didn't produce any output)... [16:13] fbond: hmm.... [16:15] fbond: just to make sure things are valid: from bzrlib import branch b = branch.Branch.open('.') b.lock_read() try: orig_revno, last_rev = b.last_revision_info() real_revno = len(list(b.repository.iter_reverse_revision_history(last_rev))) if orig_revno != real_revno: print "Changing revno from %s => %s" % (orig_revno, real_revno) b.set_last_revision_info(real_revno, last_rev) finally: b.unlock() [16:15] sorry [16:15] http://pastebin.ubuntu.com/8768/ [16:16] fbond: also, can you try running that and replacing '.' with the url of the branch you are pushing to? [16:18] jam: local: not changing revno, both match at 404 [16:18] fbond: ok, that is a bit odd [16:18] fbond: and 'bzr push' still fails with the assertion error? [16:19] jam: remote: not changing revno, both match at 381 [16:20] fbond: ah, at least local and remote disagree on the revno [16:20] something weird is happening, though [16:20] jam: yep, push gives: AssertionError: 403 != 404 [16:20] ok, that is, at least, a little bit different [16:20] jam: local and remote disagree because I have ~20 revisions I'm trying to push out :) [16:21] fbond: any chance I could see these branches directly? [16:21] They are not publicly accessible at the moment (and contain some amount of proprietary code). [16:22] I don't think folks would be happy with me if I shared them. [16:22] fbond: well, something weird is happening, I guess I can write some more python code for it [16:22] (I certainly wouldn't ask for making them public, just personal access) [16:22] but I won't push [16:22] jam: Yeah, I follow you. [16:23] support by remote is just a pain [16:23] jam: I've done it myself, I know what you're talking about.. [16:23] fbond: I just realized I was lock_read() the branch, the set_last_revision_info would fail anyway :) [16:24] jam: Ah. [16:24] that wasn't the problem, but it would have been [16:31] fbond: http://pastebin.ubuntu.com/8775/ [16:31] fbond: give that a shot, and tell me what it spits out [16:36] jam: okay, I'm dealing with an unrelated crisis, be right back with you ;) [16:36] fbond: np [17:01] jam: I get bzrlib.errors.NotBranchError; it complains about the parent branch (which differs from the push branch). [17:02] fbond: ah, I noticed that, I thought it was a bit weird that one had a '.' and the other had a '-' [17:02] Looks like this: [17:02] fbond: change the line "get_parent()" to "get_push_location()" [17:02] Okay, that's what I thought. [17:06] jam: it's running; I'll let you know when it finishes. [17:09] jam: Now I'm getting LockContention [17:10] fbond: ...? can you paste the traceback [17:10] that seems weird [17:10] fbond: but you can change the "lock_write()" to "lock_read()" [17:10] since I don't actually mutate any data [17:10] jam: okie dokie [17:10] jam: It ran for a while before reporting this. === TFKyle_ is now known as TFKyle [17:33] * mtaylor is back (gone 10:47:19) [17:35] welcome back mtaylor [17:35] jam: thanks! === BasicPRO is now known as BasicOSX [18:31] jam: now I only see No handlers could be found for logger "bzr" (no other output) [18:31] jam: This was running the script against my local branch. [18:32] If it modified the branch, it would've printed something, right? [18:54] fbond: I think so, you might try adding a "from bzrlib import trace; trace.enable_default_logging()" at the top [18:54] just to see what it wants to log [18:55] fbond: otherwise I'm pretty confused. It seems the two repositories disagree on something, but so far I haven't found anything that they disagree on :) === Necoro_dM is now known as Necoro [19:06] jam: That makes me think that the two repositories don't disagree so much as 1.3.1 may be backwards incompatible with the remote server or repository. [19:06] Is it possible? [19:07] How do I merge two branches with no shared history? [19:08] david_kofsky: generally " bzr merge -r 0..-1 ../other/branch" [19:08] it sort of depends what you are trying to do, but that at least forces the merge to finish [19:09] jam: would it help to have the repositories to look at? [19:09] jam: they are each >200M (I assume they can't be compressed much) [19:11] fbond: well, simple ssh access would be sufficient [19:11] you can even run 'screen' so that you can track everything I do [19:11] It would make things a bit easier for me to debug. [19:13] jam: Which screen feature allows that? [19:14] fbond: me being on the same screen page as you [19:14] -x [19:14] allows multiple connections to the same screen [19:14] You can even follow along as I go [19:16] Hang on. I'll admit I'm uncomfortable with the idea; nothing personal, of course. Using screen doesn't prevent you from opening another connection, of course. [19:16] In any case, give me just a minute... [19:16] fbond: of course [19:17] though you can set up ssh so that I can only connect to "screen -xRR" [19:17] or something [19:17] I believe you can do: [19:17] jam: yeah, that's what I figured. [19:19] command="/usr/bin/screen -xRR" ssh-rsa ... [19:19] in the .ssh/authorized_keys file [19:20] You can use my public keys from launchpad, and then remove access when we're done [19:20] or whatever [19:21] Just letting you know what makes it easiest for me [19:21] We can try to keep going back and forth, but certainly something weird is going no [19:21] on [19:25] fbond: I did put together a branch which implements 'bzr reconcile' in case you want to try it [19:25] I would ask that you start from bzr.dev and then bzr pull --overwrite from http://bzr.arbash-meinel.com/branches/bzr/1.5-dev/reconcile_rev_history_177855 [19:25] hmm, why exactly doesn't bzr revert ask for confirmation? [19:25] mathrick: in general, you can't lose modifications with revert [19:26] howso? [19:26] as it saves backups for files which are modified [19:26] ah [19:26] I didn't know that [19:26] ~ files [19:26] It doesn't do it for all files, if it believes you could regenerate it. [19:26] So, for example, if you 'bzr merge ../other/branch; bzr revert' [19:27] it will just revert without a backup [19:27] because it assumes you can just merge again [19:27] jam: but if the files had any other changes besides the merge, it'll back up? [19:27] mathrick: yes [19:29] jam: also, as I'm working on that script for syncing, I have two questions: 1) it does fast_host.push(mainline), shouldn't it also push in the other direction? [19:30] jam: and 2) do you want copyright on the initial code you gave me? (I will be publishing it once it's a bit more mature and featureful) [19:31] mathrick: not a big deal [19:31] ok, cool [19:31] you probably want to "fast_host.pull()" [19:31] Just because there are assumptions about which side is "fast" to access [19:32] jam: yeah, but I was right about it being only a one-way sync? [19:32] push only syncs in one direction, yes [19:33] are there any specific recommendations as to which should go first (push or pull)? [19:33] mathrick: shouldn't really matter. I would tend to favor the one you expect to change the most [19:35] jam: hmm, actually, pull will only incorporate changes that can be committed directly onto the current tip, which means that _any_ situations in which there are independent commits on both between syncs results in a conflict, no? [19:35] jam: do you recon it'd be beneficial to have it attempt a merge automatically? [19:36] or just resolve every such case manually? [19:36] I intend it to run every 5 or so minutes, so I don't really expect the periods between syncs to be very long, but it could still happen [19:37] push and pull will both error for diverged branches, yes [19:37] the only problem is if one side is technically a merge of the other [19:37] but I wouldn't expect that to be a specific problem for you [19:37] as you sort of *want* that to happen :) [19:38] yeah, manually or not, I still need the tree to be merged in the end :) [19:38] mathrick: as for auto-merging.... [19:38] you need an actually tree on disk to do a merge [19:38] actual [19:38] I just need to work out which of them is "the" tree [19:38] jam: yeah, that might be a problem [19:38] and it seems like these are mostly just branches in a repository [19:38] you could always create one in /tmp, tec. [19:38] etc. [19:38] I'm not a huge fan of auto-merging [19:39] okay, so I won't do that for now at least, and will decide how to tackle that later [19:40] and you'll still need to 'bzr pull' on the client [19:40] yeah [19:41] the issue of having a canonical tree is kinda icky, let's not think about it just yet :) [19:41] jam: btw, here's a sort-of current snapshot of it at work: http://sei.meidokon.net/ :) [19:42] I'm currently reworking the table weaver to yield more aesthetically pleasing results [19:44] mathrick: pretty, planning on releasing this publicly? [19:44] jam: yep [19:44] that's why I asked about copyrights [19:44] heck, if you want to give me credit, go ahead [19:45] :D [19:45] But for something like this, I don't really care [19:45] okay, I will credit you in AUTHORS [19:46] btw, taking LogFormatter and making it into something that can output multiple-column HTML tables is not exactly trivial [19:47] it might make sense to release HtmlTableWeaver as a separate plugin on its own [20:01] hi all! [20:03] would someone be able to help me out with a weird problem? [20:03] I played around with pagaent today and can't get my windows box to connect anymore .. to any bzr location [20:04] re-installing bzr and clearing away all files in ..my profile/application/data/bazaar also didn't help [20:08] SeWPKiP: did you clear pageant's files? [20:08] in particular, stored keys / locations? [20:08] also, did you try connecting to any locations manually (ie. with putty)? [20:13] mathrick: that's for responding! [20:13] i didn't know i had to. any idea where those files are? [20:16] SeWPKiP: I dunno if you have to, but that's what I'd suspect off-hand [20:16] SeWPKiP: look in my profile/application/data/pageant or similar [20:16] possibly in my profile/ssh or so [20:17] still looking but can't find anything like that [20:19] SeWPKiP: okay, do you still have pageant running? [20:19] no i don't [20:19] also, restarted the computer [20:20] SeWPKiP: did it help? [20:20] well, i tried all that before coming here [20:21] ah [20:21] well then, try launching pageant again, and see if it has any keys remembered [20:21] nope,didn't work either [20:21] it hasn't remembered a thing [20:21] i'm just guessing that pageant is the problem - because that's the most recent thing i did [20:21] SeWPKiP: hmm, odd, and yeah, it seems so [20:21] well, that and branching between local folders [20:22] SeWPKiP: try connecting with putty first [20:22] that works [20:22] plink works as well [20:22] SeWPKiP: okay, does bzr give you any error? [20:23] yep [20:23] it's ERROR: Conection Closed: please check connectivity and permissions [20:23] ah [20:23] and try -Dhpss if further diagnosis is required [20:23] so, pulled up the log [20:23] SeWPKiP: okay, open cmd.exe, and do what it tells you to [20:23] ok [20:24] ie. run bzr -Dhpss ls ssh://foo@bar/baz/ [20:25] i sent you the result [20:25] oops [20:25] i sent you the result [20:26] huh [20:26] SeWPKiP: yeah, I got it [20:26] it *should* work [20:26] SeWPKiP: please give me the exact line you gave it [20:26] bzr -Dhpss ln bzr+ssh://name@location/foo [20:26] just ssh:// wouldn't work [20:27] ah, right [20:27] SeWPKiP: is the location public? [20:27] no it isn't .. [20:27] but other people can access it, no problem [20:28] SeWPKiP: I meant I wanted to try precisely the line you used, to see why it was complaining about bad arguments [20:28] thanks for that, but that's not possible [20:29] bzr -Dhpss ls bzr+ssh://bzrserve@megumi.local/home/bzrserve/repo/faktoid/ <-- that works just fine for me [20:30] (and no, it's not public either) [20:31] SeWPKiP: hmm, is what you pasted me *all* it outputs? [20:31] yes, it's not helpful at all [20:31] ah, I guess not, you quit with excess flood [20:31] SeWPKiP: please use pastebin.com or similar [20:32] to make sure I can see it all [20:32] ok, brb [20:38] trying to use the --serve comand now [20:38] to pinpoint ssh as the problem [20:42] yeah it clearly is ssh .. i mean, just using --serve works [20:42] really really odd [20:48] SeWPKiP: okay, what happens if you uninstall pageant? [20:51] that's not an option [20:51] it's just a single binary [20:51] seems like there are some weird ssh certificates lying around or something.. just can't find them [20:51] and bzr won't tell me what it's doing === cprov is now known as cprov-afk === ja2 is now known as jam [22:39] abentley: Do you still know how the trac-bzr plugin works or have you purged all knowledge from your memory? [22:49] abadger1999: I have some foggy recollections. [22:50] is bzr-svn compatible with bzr 0.4? [22:50] i mean ... the latest bzr? 1.4? [22:51] abentley: In class BzrRepository(versioncontrol.Repository) there are some references to self.repo [22:52] but I dont see that self.repo is created anywhere. [22:52] Do you remember what was going on with that? [22:58] abadger1999: No, I don't remember. I had a look at the file and I couldn't see how it would have worked. [22:58] abentley: Okay. At least I don't feel like I'm missing some special trick :-/ [22:58] Thanks for looking. [22:59] You're thinking of the line in parse_rev? [23:00] That line is probably a fossil-- it was introduced by Marien Zwart, which was before I worked on it. [23:00] yeah, parse_rev(), next_rev(), and rev_older_than() [23:01] Okay. I'll just cut that logic out of parse_rev(). [23:22] i'm trying to push a bzr branch into an svn repo with the bzr-svn plugin, but i need to be able to specify the username to use in svn. is that possible? [23:24] put it in the url? [23:24] * tro headdesks [23:24] of course! [23:24] thanks [23:29] hello [23:31] morning poolie [23:36] hello beuno [23:47] morning all [23:48] mornin' igc [23:53] >hate my isp atm< [23:53] aaaaand good morning lifeless :) [23:58] javierder, ping [23:59] abentley: bb is down again for me - 550 Internal Server Error