[00:05] <pickscrape> Is bzr-svn capable of coping with nested branches?
[00:05] <pickscrape> Actually, let me clarify that
[00:06] <pickscrape> A /branches directory that contains directories that contain branches.
[00:07] <Odd_Bloke> pickscrape: I'd be surprised if it weren't.  Try it and see?
[00:08] <pickscrape> I just did. It seems to pick up the directories as branches.
[00:08] <Odd_Bloke> pickscrape: You may need to do some config-fu.
[00:09] <pickscrape> The trouble is, early in the life of this repo branches were done the 'traditional' way. Then when we realised we had far too many we broke them down into categories. So over time the branch scheme has changed.
[00:09] <pickscrape> Where is the branch management config set up?
[00:10] <Odd_Bloke> ~/.bazaar/<something>.conf
[00:10] <pickscrape> Thanks, I'll check it out.
[00:10]  * Odd_Bloke isn't on a machine with bzr-svn installed, else he'd be more specific.
[00:10] <fullermd> There's some command for it, I think.  branching-scheme or something?
[00:10] <pickscrape> Thanks, I'll check it out after dinner :)
[00:11] <pickscrape> Would I be right in thinking you can just tell bzr to import trunk only by pointing it at /trunk instead of the repository root?
[00:29] <Verterok> moin
[00:30] <bob2> pickscrape: I think you'd just use bzr branch for that, so yes
[00:35] <mthaddon_> is there a way to specifiy an ssh key (identity file) for a one time bzr+ssh command?
[00:35] <mthaddon_> or is that something that just has to be set for the user environment that's executing the command
[00:36] <schierbeck> asabil: ping
[00:37] <asabil> schierbeck: pong ?
[00:37] <schierbeck> :)
[00:37] <fullermd> Space Invaders?
[00:37] <schierbeck> asabil: i've found a bug in the fancy-tags implementation
[00:38] <asabil> oh ?
[00:38] <asabil> can you elaborate please ?
[00:38] <schierbeck> the size of the cell renderer isn't reported correctly when a revision is tagged
[00:38] <asabil> you mean the height ? or width ?
[00:38] <schierbeck> so if you have a branch with a single line of development, the tags will not fit on the allocated space
[00:39] <schierbeck> width
[00:39] <schierbeck> i'm not sure how to fix it
[00:39] <fullermd> That's user error; not branching enough   ;>
[00:39] <asabil> but you can resize the column
[00:39] <schierbeck> nope
[00:39] <asabil> I am not sure I see the problem
[00:39] <asabil> let me try
[00:39] <schierbeck> fullermd: :)
[00:40] <schierbeck> create a branch with just one revision, and tag that revision
[00:40] <schierbeck> perhaps sum up the widths of the labels as we create them
[00:41] <asabil> ah ok I see
[00:41] <asabil> yep, that would be the solution
[00:42] <asabil> sorry, I didn't think about this possibility
[00:42] <schierbeck> np, i'll try fixing it
[00:47] <schierbeck> fuck
[00:47] <schierbeck> the size is requested before the widget is drawn
[00:48] <asabil> :/, that's something I hate about Gtk cell renders
[00:49] <asabil> sorry I got to go to bed now
[00:49] <schierbeck> okay, i'll see what i can do about it
[00:49] <asabil> got to wakeup early tomorrow
[00:49] <schierbeck> *myself
[00:50] <schierbeck> good night
[00:50] <asabil> good night to you too, thanks, and sorry for the trouble :/
=== mw is now known as mw|out
[03:34] <j1mc> hi all - simple question.  if i have several updated files being tracked by bzr, but just want to commit updates to one of them.  should i enter 'bzr commit -m "my message about my commit" /path/to/file.xml'  ....  or should i do 'bzr commit /path/to/file.xml -m "message about my commit"'
[03:35] <Odd_Bloke> j1mc: AFAIK, either should work.
[03:35] <spiv> j1mc: either way is fine
[03:35] <j1mc> thanks...
[03:36] <AfC> j1mc: although both will work given a competent option parsing implementation, the former is more likely to work in general (given the 4 billion different getopt implementations out there). I probably don't need to be so gunshy, but old habits die hard, I guess.
[03:37] <jamesh> AfC: well, it only has to work with the getopt variant that bzr uses ...
[03:37] <jamesh> look on the bright side: it could be using tla's getopt variant
[03:43] <AfC> jamesh: sure
[03:47] <j1mc> AfC: i went ahead with the second one because it seemed more straightforward to me.  "commit this patch, and here's the message to go with it"  it seems to have worked ok.
[03:49] <AfC> j1mc: oh, once a Bazaar hacker said it was ok in their application, it was all good. I just mention this because I have been burned by (for instance) tools like ls on BSD systems not parsing options liberally.
[03:52] <j1mc> thanks, AfC ... i'll keep it in mind.  :)
[03:52]  * fullermd considers it Only Proper to give options before arguments.
[03:56] <AfC> fullermd: lndeed :)
[03:57] <j1mc> fullermd: well explained.  thanks.
[04:03] <AfC> poolie: are you going to be at LCA next week?
[04:33] <poolie> AfC, no, but jamesh, jml and spiv will be
[04:33] <poolie> afc, i mailed you about london
[04:33] <AfC> poolie: No, I just thought it would be easier to conclude that conversation in person.
[04:34] <AfC> I'm about to reply; I just had to have a word with our Advisory Board first.
[08:19] <lifeless> moin
[08:38] <lifeless> http://ozlabs.org/~rusty/index.cgi/2008/01/07#2008-01-07 <- heh
[09:17] <speakman> hi ppl :) Whats the --rich-root exactly? Is it default when init-repo >= 1.0?
[09:19] <minghua> speakman: I don't think it's default.  You can read "bzr help formats" to know more.
[09:21] <speakman> ok, according to "help formats" rich-root isn't experimental? can I use it in production then?
[09:22] <speakman> or I think i'll stick to pack-0.92..
[09:24] <speakman> Another question; on the "Centralized workflow" guide, the "Recommended branching" says mainline should go into /project and branches should go into /projects/branch (sort of)
[09:24] <speakman> is the webviewer able to show it correctly then?
[09:25] <speakman> anyone tried that with Trac?
[09:29] <speakman> I can't get the logics in this...
[09:31] <lifeless> speakman: stick with pack-0.92
[09:31] <speakman> lifeless: thanks I will...
[09:31] <lifeless> speakman: yes web viewers should be able to show it; I can't speakto trac - don't use it myself
[09:31] <speakman> ok, but I can't get the logics about branching
[09:32] <speakman> i'd like something like /myproject/trunk
[09:32] <speakman> and for new features; /myproject/feature1
[09:32] <speakman> and so on.. where is the "trunk" supposed to go using the recommended branching?
[09:33] <speakman> I've setup bzr smart server (through inetd) on my server, and it's all reachable trhoung bzr://server/
[09:34] <lifeless> jamesh: ping
[09:34] <speakman> And now I'd like to make up a "policy" for projects and branches, but I can't figure out how the "Recommended Branching" works.
[09:34] <lifeless> speakman: what is confusing about it
[09:34] <speakman> where is the "trunk" supposed to go?
[09:35] <speakman> directly under bzr://server/myproject ?
[09:35] <speakman> and my feature branch under bzr://server/myproject/newfeature ?
[09:35] <speakman> (I've made a init-repo --no-trees bzr://server)
[09:37] <speakman> lifeless: any clue?
[09:37] <lifeless> speakman: sure, you can do that
[09:37] <speakman> can? what would you prefer?
[09:38] <lifeless> I tend to do .../trunk and .../branch1 etc
[09:38] <lifeless> because people know to look for trunk/MAIN/HEAD and similar names
[09:38] <speakman> ok, same as me then... how do you init your repos then?
[09:38] <speakman> yes, and I can see more logic in that too...
[09:39] <lifeless> well the init-repo command you've already run is all you need to init the repo  - the repo is just a storage database; 'bzr init' makes a new project, and ('bzr push' and 'bzr branch') are how you make new branches of that project
[09:41] <speakman> so, an "bzr init-repo --no-trees bzr://server" and then "bzr init bzr://server/myproject/trunk" makes /myproject/trunk using no-trees as well?
[09:45] <lifeless> speakman: do this:
[09:45] <lifeless> bzr init somewhere-on-local-disk
[09:45] <lifeless> cd $somewhere-on-local-disk
[09:46] <lifeless> import your code  - e.g. 'bzr import mysource.tar.gz'
[09:46] <lifeless> or if you have the files on disk, just bzr add && bzr commit
[09:46] <lifeless> then when you are ready, 'bzr push bzr://server/myproject/trunk'
[09:47] <speakman> thanks, seems like a great option :)
[10:06] <jamesh> lifeless: pong
[10:30] <ubotu> New bug: #185869 in bzr-gtk "gcommit fails with central bzr smart server" [Undecided,New] https://launchpad.net/bugs/185869
[10:41] <ubotu> New bug: #185875 in trac-bzr "no support for utf-8 in source files" [Undecided,New] https://launchpad.net/bugs/185875
[10:43] <acuster> jelmer, hello. We are trying to undo a commit I made yesterday with bzr-svn onto an svn directory. The commit started by doing a full replace of trunk/ back to the revision from which I did the initial bzr checkout (I have been bzr pull'ing since then). Do you have any pointers for how we can figure out how to do this kind of Replace in a single svn commit?
[10:43] <lifeless> jamesh: hi two things
[10:43] <jelmer> acuster: Did you try to push a commit that contained a merge of trunk ?
[10:43] <jamesh> okay
[10:44] <jelmer> acuster: That would explain the replace of trunk/
[10:44] <acuster> yes, possibly
[10:44] <lifeless> jamesh: bzr register-branch is broken (bug 185861) and gnome-gpg is broken on hardy (I'm testing a fix now)
[10:44] <ubotu> Launchpad bug 185861 in launchpad-bazaar "bzr register-branch command broken?" [Undecided,New] https://launchpad.net/bugs/185861
[10:44] <acuster> what's a 'merge of trunk' ?
[10:45] <lifeless> jamesh: where should I send a patch for the latter; and can you confirm the bug ?
[10:45] <acuster> what commands do you hit svn with to do the 'replace' ?
[10:45] <jamesh> lifeless: file a bug in launchpad (the source of gnome-gpg is maintained with Bazaar these days)
[10:46] <jelmer> acuster: If you had a local branch that descended from svn and then merged some revisions from trunk later and then pushed that branch back into svn
[10:46] <acuster> yes, that sounds exactly right
[10:47] <lifeless> jamesh: k, it works for me, but I'm not sure about tests etc - need to generate a GNOME_KEYRING_RESULT_NO_MATCH value
[10:47] <jamesh> lifeless: I've marked your register-branch bug as a dup
[10:47] <acuster> (1) I branched svn to br1 (2) I branched br1 to br2 (3) I pulled lots of updates from svn into br1 and then pulled those into br2
[10:48] <acuster> (4) I modified one file in br2
[10:48] <jamesh> lifeless: it is a bad interaction between the code that redirects beta testers to edge.launchpad.net and the xmlrpc server
[10:48] <acuster> (5) I pushed that change into br1
[10:48] <acuster> at which point bzr complained and I did some merges I didn't fully understand
[10:49] <speakman> jelmer: about gcommit - there is no backtrace (as told in the report). How can I make one?
[10:49] <acuster> (6) then I pushed the change from br2 to br1 and from br1 back to svn
[10:49] <jamesh> I'm glad I got xml-rpc to report OOPS numbers ...
[10:50] <lifeless> jamesh: are we able to fix this? Seems rather bad to be broken in production
[10:50] <lifeless> jamesh: if we could even work around it in bzr (by using edge always) that would be sufficient
[10:50] <jamesh> lifeless: bug 181156 is about the underlying cause
[10:50] <ubotu> Bug 181156 on http://launchpad.net/bugs/181156 is private
[10:50] <acuster> jelmer, the question is how to do the replace in the same way that bzr-svn did it so we can fix things. ARe you using svn replace for that command?
[10:50] <jamesh> and it can't be worked around in Bazaar
[10:51] <jamesh> actually, using xmlrpc.edge.launchpad.net would probably work
[10:51] <jamesh> assuming it is hooked up
[10:51] <jelmer> speakman: Hmm, that's actually a good point. We may have to stop handling exceptions automatically in all cases
[10:52] <speakman> jelmer: Yes, tracebacks aren't that bad.. :)
[10:52] <jelmer> acuster: What exactly are trying to achieve?
[10:52] <jelmer> acuster: Trying to undo what bzr-svn did?
[10:53] <balor>  I've forgotten how to do a bzr diff during a bzr ci.  Could someone remind me of the command?  I think it was similar to bzr ci --diff but bzr ci --help does not document that.
[10:53] <balor> bzr version 0.90
[10:54] <jelmer> A diff inside of the commit message you mean?
[10:54] <dato> balor: --show-diff, not sure if 0.90 has it
[10:54] <balor> jelmer: no, a diff whilst I'm writing the changelof
[10:54] <balor> dato: 0.90 seems to be missing that feature
[10:54] <balor> dato: guess it's time to upgrade
[10:55] <dato> balor: oh
[10:55] <dato> if it's not what jelmer said
[10:55] <dato> the answer is "you can't"
[10:55] <dato> (and quite frankly it sucks)
[10:55] <balor> dato: hmmm....I had thought there was a workaround
[10:55] <acuster> jelmer, yes
[10:56] <lifeless> jamesh: I'll test that shortly
[10:56] <acuster> we are trying to get svn back to where it was keeping the history of all the files over the past three weeks
[10:56] <acuster> not merely getting the files back to a good state
[10:56] <jelmer> acuster: Replace can be done by removing a directory and copying an older version of it into the same place in the same commit
[10:57] <jelmer> acuster: This is one of the reasons some people use rebase rather than merge when pushing to svn
[10:59] <acuster> thanks
[10:59] <acuster> 'removing a directory' is a svn remove or a filesystem remove?
[11:00] <jelmer> svn remove I think
[11:00] <jelmer> Maybe followed by a file system removed
[11:00] <jelmer> bzr-svn does this without a working tree
[11:00]  * acuster is not allowed to touch the svn with bzr any longer :-)
[11:00] <acuster> thanks
[11:03] <jelmer> sorry to hear that
[11:03] <lifeless> jamesh: edge works
[11:04] <speakman> Why is the Debian/Ubuntu repos unmaintained lately?
[11:04] <jelmer> lifeless: Do packs handle the lhs parent being a ghost ?
[11:04] <lifeless> jelmer: yes
[11:04] <lifeless> jelmer: what happened to acuster ?
[11:04] <lifeless> speakman: they are eing maintained; just differently
[11:05] <jelmer> lifeless: bzr-svn preserves lhs history
[11:06] <jelmer> lifeless: "bzr branch trunk foo; <hack-hack>; bzr merge trunk && bzr commit; bzr push" will alter lhs history
[11:07] <jelmer> lifeless: bzr-svn will properly preserve that lhs history when pushing by committing on top of an older revision of trunk
[11:09] <lifeless> jamesh: patch is on lp for you
[11:10]  * jelmer adds an entry to the bzr-svn FAQ
[11:13] <speakman> lifeless: currently no repo is touched since 9 jan. bzr-gtk is still at 0.90 and requires bzr < 1.0.
[11:14] <lifeless> jelmer: ah, and because svn doesn't track merges folk get confused
[11:14] <jelmer> lifless: yeah, exactly
[11:14] <lifeless> jelmer: so we should really recommend they use 'bzr checkout' for svn branches they are going to commit to
[11:14] <lifeless> for 'compatibility'
[11:15] <jelmer> lifeless: Yeah, that may be a good idea
[11:16] <lifeless> jamesh: we should add an xmlrpc call to say 'I have pushed to <X> branch'
[11:16] <dato> riiight. and one of the main pluses of bzr-svn, offline workflow, goes to... the bin.
[11:16] <dato> (as commit --local will end doing the same with the lhs history afaik?)
[11:17] <lifeless> dato: not at all; commit --local will not do the same thing
[11:17] <dato> no?
[11:17] <lifeless> dato: when you are on line again, you get the new changes from trunk by doing 'bzr update'
[11:17] <lifeless> dato: that will pivot your local work into a merge, preserving LHS
[11:17] <jelmer> lifeless: The alternative would be to not necessarily always push on top of the lhs parent
[11:18] <jelmer> lifeless: But then bzr needs to handle diff against non-lhs parents properly, otherwise pulling from that branch later will be problematic
[11:19] <lifeless> jelmer: not sure what you mean; what does bzr not handle correctly?
[11:20] <speakman> btw, how can I add suggestions to bzr on launchpad?
[11:20] <speakman> Blueprints?
[11:23] <jelmer> lifeless: storing diffs for a revision where the lhs parent is a ghost but one of the other parents is not
[11:24] <jelmer> afaik weaves at least had problems with it, I'm not sure what the status of that is these days
[11:24] <lifeless> speakman: we like suggestions to be sent to the mailing list; or you could use the answers.launchpad.net/bzr forum
[11:24] <lifeless> jelmer: in packs that will degrade to a fulltext at the moment
[11:25] <lifeless> jelmer: but anyway, its not needed - because a heavy checkout will DTRT
[11:32] <jelmer> lifeless: sure, but people will still use push and it would be nice to do the right thing when we add support for svn:merge-info
[11:33] <speakman> ok, just one more simple question right here; is it possible to *easily* make an "alias" as "lp:project" but to our local server "ourserver:myproject"?
[11:34] <speakman> I've tried to read the source code for launchpad plugin, but it seemed really complex for this "simple" issue.
[11:34] <lifeless> jelmer: patches to core appreciated :) - packs have two fields (compression tree, ancestry graph), but enforce the same rules on them that knits had
[11:35] <jelmer> speakman: the launchpad plugin does more than register the "lp" namespace
[11:36] <speakman> jelmer: yes I know, thats why it was hard to me (pretty new to python) to just pick out the "lp:" part...
[11:36] <speakman> i'd like a "alias" feature for it, or simular
[11:37] <lifeless> speakman: we'd like to add a url alias facility
[11:37] <lifeless> speakman: but noone has contributed it yet.
[11:37] <speakman> lifeless: exactly! thanks!
[11:38] <speakman> I'm afraid i'm too much of a newbie python programmer yet to make one myself. :/
=== Mez_ is now known as Mez
[12:40] <ubotu> New bug: #185907 in bzr ""bzr pull --quiet" should not say "Using saved location ..."" [Undecided,New] https://launchpad.net/bugs/185907
=== mw|out is now known as mw
=== mrevell is now known as mrevell-lunch
=== kiko-afk is now known as kiko
[14:15] <antares> Hi! Does anyone know if I can make bzr follow symlinks?
[14:17] <lifeless> for versioing files?
[14:17] <lifeless> no, bzr versions the symlink, not what is linked to - sorry
[14:17] <antares> no way to make it work?
[14:18] <lifeless> well it works as designed :) - if you have a link to /foo, we record that you have a link to /foo :)
[14:18] <lifeless> I don't know what you are trying to do that that is s aproblem for, but I'm happy to try and help
[14:19] <antares> Thanks! I buld my projects (websites) using several modules that I store in a special directory, I link those modules to the project when I need them
[14:20] <antares> and if I add a feature in one module, autoomatically is added to all the projects that use that module
[14:21] <antares> The problem is that I need to version these changes without having to start a bzr repo in all of them
[14:23] <lifeless> well, I think using bzr is probably a better fit :)
[14:24] <antares> using bzr for all the modules?
[14:25] <lifeless> yah
[14:27] <antares> ok, thank you for your help, but I can't do that, it would give more headaches
[14:31] <mtaylor> w00t. I just actually upgraded bzr, bzr-svn and bzrtools from apt. Thanks guys!
[14:31] <lifeless> mtaylor: :)
[14:33]  * lamont wants a bzr option to have it chdir before doing anything.
[14:33] <lifeless> lamont: why?
[14:34] <lamont> so I can say 'bzr --chdir /foo/bar status'
[14:34] <lamont> alternatively, a bzr status where the user running bzr doesn't have read access to some of the unignored _directories_ would be even more lovely
[14:35] <lamont> although status wouldn't notice the changes there if that were true. hrm.
[14:39] <Kinnison> lamont: bzr status /path/to/branch
[14:39] <Kinnison> lamont: not good enough?
[14:40] <lamont> Kinnison: that would do, I believe,  as long as it looks at /path/to/branch/.bzr, and not $CWD at all
[14:41] <lamont> Kinnison: works well, I do believe
[14:41] <lifeless> lamont: 'bzr st /foo/bar' kthxbye
[14:41] <lifeless> lamont: always try the obvious thing first :)
[14:42] <lamont> lifeless: give me a break... I'm still working on figuring out your^Wbzr's definition of "obvious"
=== mrevell-lunch is now known as mrevell
[14:42] <lifeless> lamont: thats because you've been using a nasty system :)
[14:43] <lamont> lifeless: expect bugs to show up for things that don't behave correctly... bzrk for example... :)
[14:43] <lamont> s/correctly/like I want/
[14:43] <brink_> Is it possible to split a branch into two separate branches?
[14:47] <mtaylor> brink_: what do you mean?
[14:48] <brink_> I have two unrelated projects in the same branch.  One of them is getting big.  I'd like to have to separate smaller branches.   Is this possible?
[14:48] <brink_> I meant "two separate smaller branches"
[14:48] <mtaylor> brink_: yes
[14:48] <mtaylor> brink_: see bzr split
[14:50] <brink_> Thanks.   Is that the reason for the new rich-root-pack format?
[14:50] <mtaylor> ahearo,.. dunno... but I will say the new rich-root-pack is teh r0xr
=== kiko is now known as kiko-phone
[14:51] <brink_> r0xr?
[14:52] <mtaylor> brink_: :) it's good
=== kiko-phone is now known as kiko-afk
[15:15] <brink_> I get a " bzr: command not found" when I try to create a branch on a remote repository.  I think it's because bzr isn't on the path of the remote machine.  The remote machine is a Macintosh.   Does anyone have any idea how to add bzr to the path that ssh uses?
[15:18] <james_w> brink_, what protocol are you using?
[15:18] <brink_> ssh+bzr
[15:19] <james_w> brink_, so you need to get it so that 'ssh bzr rocks' works.
[15:20] <asabil> brink_: you can use sftp:// (but that's suboptimal)
[15:21] <brink_> No, I can't use that.  It always screws up the file and directory permissions.
[15:21] <brink_> It seems that ssh doesn't pay attention to /etc/profile.    I don't know where ssh looks for the path.
[15:24] <asabil> brink_: can't you just edit the ~/.profile of the user you are using to push ?
[15:24] <mtaylor> IncompatibleRepositories: Repository KnitPackRepository('file:///var/www/bundlebuggy/ndb-connectors/.bzr/repository/') is not compatible with repository KnitPackRepository('http://bazaar.launchpad.net/%7Endb-connectors/ndb-connectors/devel/.bzr/repository/')
[15:24] <mtaylor> _I_ know what the problem is here
[15:25] <mtaylor> I upgraded http://bazaar.launchpad.net/%7Endb-connectors/ndb-connectors/devel to rich-root-packs and did not do that to file:///var/www/bundlebuggy/ndb-connectors yet
[15:25] <mtaylor> but I must say, that error message really sucks
[15:25] <brink_> I need to make bzr available to everyone who is going to use the server.
[15:25] <brink_> I'm not sure how to make it so ssh can find it.
[15:26] <lifeless> lamont: file bugs please!
[15:28] <asabil> brink_: it uses the PATH env var of the user, the PATH is generally defined in /etc/environment , /etc/profile and ~/.profile
[15:29] <brink_> It seems to not be responding to /etc/profile although that works for login shells.   Maybe I should try /etc/environment
[15:30] <quicksilver> If bzr is interrupted by SIGINT (i.e. ctrl-C) it needs to sanitise the terminal again before terminatng.
[15:30] <quicksilver> Otherwise if you C-C a password prompt you end up with a broken terminal.
[15:32] <lifeless> mtaylor: indeed; sorry
[15:33] <mtaylor> lifeless: that's ok.
[15:33] <james_w> quicksilver, I believe there is a bug about that already.
[15:33] <mtaylor> lifeless: it can't _all_ be perfect :)
[15:33] <quicksilver> james_w: ah well, I thought I'd mention it while it was on my mind :P
[15:34] <james_w> !bug 78379
[15:34] <ubotu> Launchpad bug 78379 in bzr "When bzr (or subprocess) disables terminal echo, Ctrl+C should re-enable it" [Low,Confirmed] https://launchpad.net/bugs/78379
[15:34] <james_w> quicksilver, yeah, thanks anyway, it's always good to check.
[17:19] <brink_> Anyone know how to make the bzr+ssh protocol available to users of a Macintosh server?  ssh says it can't find bzr on the path.
[17:23] <lifeless> brink_: you can set BZR_REMOTE_PATH; you can simulate what bzr does byL:
[17:23] <lifeless> 'ssh host bzr help'
[17:24] <lifeless> if that works, bzr should work with it
[17:26] <brink_> It doesn't.  It gives me this:  bash: bzr: command not found
[17:35] <mtaylor> anybody running hardy already?
[17:35] <lifeless> mtaylor: yes
[17:35] <mtaylor> lifeless: usable?
[17:35] <lifeless> brink_: then 'bzr' is not in your path. or it is but python isn't so its not executable
[17:35] <lifeless> mtaylor: mostly
[17:35] <mtaylor> heh
[17:35]  * mtaylor is stupidly upgrading his laptop right now
[17:36] <lifeless> ;)
[17:36] <lifeless> I'm writing an update to the index layer - more speed++
=== PainBank is now known as RichElswick
=== kiko-afk is now known as kiko
[18:05] <brink_> Yes bzr isn't on my path.  The question is, how do I get bzr on my path.   The bzr+ssh protocol doesn't seem to pay attention to /etc/profile on osx.  Any thoughts?
[18:08] <lifeless> brink_: ln -s bzr /usr/bin/ ?
[18:09] <brink_> Hmm.   I suppose I could do that.    Will there be any other dependency issues?
[18:09] <brink_> What do people typically do on osx?
[18:12] <lifeless> brink_: no idea:)
[18:13] <brink_> It seems like there should be some documentation on how to setup bazaar in addition to just using it.   If I figure it out maybe I'll send it in.
[18:13] <lifeless> that would be awesome
[18:13] <brink_> Assuming I figure it out correctly.
[18:18] <mtaylor> do we have any sort of osx disk image installer thing ?
[18:21] <lifeless> there is a dmg image I believe
[18:51] <brink_> Is there a way to merge two separate (no common parent) branches kind of like the opposite of bzr split?
[19:02] <dato> brink_: yes. bzr merge -r 0..-1 /path/to/other/branch
[19:05] <brink_> Thanks.  I didn't realize merge could work with unrelated branches.
=== kiko is now known as kiko-phone
[19:20] <laga> hello
[19:21] <laga> i was just working on something and wanted to bzrcommit/diff and i got the following error message: http://www.pastebin.ca/872417
[19:22] <laga> i don't remember changing anything wrt my bzr setup. does anyone have a hint?
[19:29] <laga> when will there be debs for 1.1?
[19:30] <beuno> laga, there already are
[19:30] <beuno> are you using ubuntu or debian?
[19:31] <beuno> laga, https://launchpad.net/~bzr/+archive   for Ubuntu
[19:31] <laga> i'm using ubuntu gutsy and i have the bzr repo in my sources list
[19:31] <beuno> laga, the PPA archive has 1.1
[19:31] <laga> thanks, i'll try those
[19:32] <beuno> welcome'
[19:36] <ubotu> New bug: #186005 in bzr "adding iso-8859-1 paths on a UTF8 file system gives a harsh error	message" [Undecided,New] https://launchpad.net/bugs/186005
[19:36] <laga> i still get the same error message even after the update. i guess i'll file a bug in launchpad and try to get some work done afterwards
[19:38] <beuno> laga, can you paste the error message on pastebin?
[19:38] <beuno> maybe we can help you out
[19:38] <laga> http://www.pastebin.ca/872417
[19:38] <laga> it's there
[19:39] <laga> just found a bug report on launchpad which might be related
[19:39] <laga> https://bugs.launchpad.net/bzr/+bug/109114
[19:39] <ubotu> Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed]
[19:39]  * laga has no clue what he's talking about, though :)
[19:39] <laga> beuno: it happens whenever i commit or diff. i don't think i#ve changed anything in the brnach (except for changing a few files of course)
[19:40] <beuno> laga, does it have many files or big ones?
[19:41] <laga> 1359 files, 7.5M size
[19:41] <beuno> doesn't make sense for bzr to run out of memory with that little
[19:41] <laga> yes
[19:42] <laga> especially since i have 615M free
[19:42] <beuno> at least for committing, diff's can vary I guess
[19:42] <laga> it happens almost immediately, too
[19:43] <beuno> laga, this seems like something different
[19:43] <beuno> could you file a bug in Launchpad?
[19:43] <laga> sure
[19:44] <beuno> thanks  :D
=== kiko-phone is now known as kiko
[19:53] <laga> done
[19:53]  * laga gets a fresh checkout and ports missing changes ;)
[19:54] <beuno> laga, great, thanks for that. I'll try and catch another dev and see if he can take a look at it
[19:54] <laga> beuno: great. thanks for the support :)
[19:59] <laga> yay. i have just accidentally reverted my changes using meld because i mixed up directory order. i must be having a metaphorical bad hair day
[20:00] <beuno> laga, ouch. And you hadn't committed?
[20:00] <ubotu> New bug: #186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014
[20:01] <laga> no. i was using meld because i couldn't commit in the first place :)
[20:01] <laga> oh well, that's what i get for not paying attention. not much was lost
[20:03] <beuno> laga, what about branching that repo locally and trying to work on a fresh branch?
[20:04] <beuno> (fully local branch)
[20:04] <laga> beuno: i've got a fresh branch already
[20:04] <beuno> laga, but it's a checkout, no?
[20:04] <beuno> checkouts are bound to their parents
[20:04] <laga> well, i was using "bzr branch" i think
[20:04] <beuno> oh, then you do have a fully local branch
[20:04] <laga> hum
[20:05] <laga> i'm not sure actually. i created this branch locally, then pushed to launchpad..
[20:06] <laga> i need to polish my VCS skills. :) am i supposed to merge from launchpad or pull from there? or is there no difference at all?
[20:06] <laga> in case someone else modified the branch on launchpad
[20:08] <beuno> laga, if someone else modified, you'd have to merge
[20:08] <beuno> I tend to try and pull first though, or do  merge --pull
[20:08] <laga> oh, it'll error if someone else has done any modifications?
[20:09] <beuno> laga, yeap, it will say you need to merge
[20:09] <beuno> if there aren't any conflicts, you just commit the merge
[20:09] <beuno> and you're up-to-date
[20:09] <laga> i was just curious because i'm working on this branch from my laptop and from my desktop and i usually just push on both
[20:09] <laga> yeah, right.
[20:10] <laga> ah, now i remember. i didn't see the merge in the commit message at first and that's what confused me. in the end, everything turned out to be alright :)
[20:10] <beuno> laga, things tend to work themselves out a lot with computers  :p
[20:10] <laga> yes
[20:11] <laga> that's why i has hoping bzr 1.1 would solve my weird error message. ;)
[20:12] <beuno> laga, it's really odd that you would get that error, I have much larger branches in file sizes and quantity, even on some PCs with 512mb ram, and still don't hit the RAM hard enough to traceback
=== kiko is now known as kiko-afk
[20:14] <laga> beuno: i'm just glad that bzr itself is still working on my box
[20:15] <beuno> laga, do you have a grumpy box?
[20:15] <laga> beuno: it's usually working fine. including RAM :)
[20:16] <laga> if that's what you meant
[20:17] <beuno> ah, bzr usually works fine on all enviroments, that's why I asked if you had a particularly grumpy box
[20:18] <laga> i've just compiled mythtv three times in a row without errors while running virtualbox at the same time. it's fairly stable :)
[20:18] <beuno> good, then we'll see if we can nail down that traceback as soon as possible
[20:23] <laga> it's 100% reproducable as well. unless there's a bad block on the hard disk i don't see what could have broken it hardware-wise
=== kiko-afk is now known as kiko
[22:11] <Lo-lan-do> Hi all
[22:12] <Lo-lan-do> Is there a way to inject missing revisions into a repository?
[22:12] <Lo-lan-do> I converted a baz archive to bzr, but some of the branches in there were based on branches in other baz archives, and apparently the baz-import didn't create the revisions in bzr
[22:13] <Lo-lan-do> bzr check says:
[22:13] <Lo-lan-do>     12 ghost revisions
[22:13] <Lo-lan-do>     11 revisions missing parents in ancestry
[22:13] <Lo-lan-do>     85 inconsistent parents
[22:13] <Lo-lan-do> Is that fixable (I have the other baz archives at hand), or should I redo the conversion?
[22:21]  * Lo-lan-do tries cloning all these branches into a single repository, which should then have all revisions
[22:32] <Lo-lan-do> Hm.  bzr reconcile seems to help
[23:29] <batoms> is there a way to set the ssh client in bazaar.conf
[23:29] <batoms> something similar to export BZR_SSH=paramiko