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