[02:17] <Rhamphoryncus> oi, busy day
[02:17] <Rhamphoryncus> <jelmer> Rhamphoryncus: you may be able to use rebase or replay to replay the changes your local branch has on top of the new upstream branch
[02:17] <Rhamphoryncus> no rebase or replay commands.. newer version only perhaps?
[02:18] <jelmer> Rhamphoryncus: plugin
[02:18] <Rhamphoryncus> ah
[02:24] <Rhamphoryncus> rebase --help hurts my brain.. and makes me paranoid that it'll mess with my original tree, not just my new tree
[02:26] <Rhamphoryncus> hrm.  Make a new branch of my old tree, cd into that, then rebase to my new upstream source?
[02:29] <jelmer> Rhamphoryncus: yeah
[02:29] <jelmer> you would have to specify what to rebase exactly and onto what revision
[03:09] <threeve> Is there any documentation for the cbranch feature of bzrtools other than `bzr help cbranch`?
[03:12] <ubotu> New bug: #201609 in paramiko "python-paramiko should support a shell alias for "ssh"" [Undecided,Invalid] https://launchpad.net/bugs/201609
[03:16] <Rhamphoryncus> jelmer: it's saying the knit repositories are not compatible
[03:22] <Rhamphoryncus> I should probably accept the loss of the history and just do a diff
[03:23] <jelmer> Rhamphoryncus: You probably need to upgrade one of the repositories to a newer format
[03:24] <jelmer> Rhamphoryncus: Probably your old one - try "bzr upgrade --rich-root-pack"
[03:24] <Rhamphoryncus> given that I only updated bzr a few days ago, that's quite possible :)
[03:28] <Rhamphoryncus> that failed too.  http://rafb.net/p/JSdbyl15.html
[03:34] <jelmer> Rhamphoryncus: Hmm, I'm not sure what could be causing that
[03:34] <jelmer> Rhamphoryncus: please file a bug
[03:36] <Rhamphoryncus> hum.. top of the list of most frequently reported bugs.. "upgrading to rich-root-pack fails"
[03:44] <Rhamphoryncus> heh, although that bug report has been idle for months, one of the bug reports has a link to a thread from 2 days ago
[05:16] <ubotu> New bug: #205416 in bzr "bzr del is missing.  Alias bzr del to bzr remove." [Undecided,New] https://launchpad.net/bugs/205416
[06:47] <NfNitLoop> del?  bah. :p
[08:06] <arnetheduck> hi, I just pushed a bzr branch I created with svn-import to launchpad, and now I wanted to branch it, but doing "bzr checkout bzr+ssh://arnetheduck@bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk dcplusplus -v" gives me bzr: ERROR: Repository KnitPackRepository('file:///home/arnetheduck/src/dcplusplus/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://arnetheduck@bazaar.launchpad.net/%7Edcplusplus-team/dcplusplus/trun
[08:06] <arnetheduck> k/.bzr/), any ideas?
[08:08] <Peng> arnetheduck: You're probably trying to branch it into a non-rich-root repo.
[08:09] <arnetheduck> Peng, I'm trying to branch it into a fresh directory
[08:10] <Peng> arnetheduck: Run "bzr info".
[08:10] <arnetheduck> bzr: ERROR: Not a branch: "/home/arnetheduck/src/".
[08:11] <bob2> bzr co of rich root branches is borked
[08:11] <Peng> Oh.
[08:11] <bob2> since it uses the bzr default branch format, which is non-rich-root-comparible
[08:11] <arnetheduck> Peng, and afaict, there's no way to specify repo format with co
[08:11] <bob2> bzr init-repo repo ; bzr co bzr+ssh://arnetheduck@bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk repo dcplusplus -v
[08:12] <bob2> er, bzr init-repo --rich-root-pack repo
[08:12] <arnetheduck> bob2, any way of avoiding the extra level of directories and avoid having a shared .bzr in /src/?
[08:14] <bob2> well, you could branch it then bzr reconfigure --checkout
[08:15] <arnetheduck> bob2, a checkout, that's a branch + bind, right?
[08:16] <bob2> think so
[08:17] <Peng> Yeah.
[08:17] <arnetheduck> should I report a bug?
[08:18] <bob2> if no one else has, but it is pretty well known
[08:44] <Peng> Nice, "bzr missing" doesn't use lots of RAM when the branch is missing 6000 revisions. :)
=== doko_ is now known as doko
[12:01] <ubotu> New bug: #180128 in bzr-svn "Cannot push to a branch `svn cp'ied` (dup-of: 145171)" [Undecided,New] https://launchpad.net/bugs/180128
[12:59] <thekorn> hi, if any moderator of the bazaar ML is around today, can you please moderate my last mail, thank you!
[15:15] <tca> New bug: https://bugs.launchpad.net/bzr/+bug/205564  Do you think it is safe to use bzr 1.3 on my repo?
[15:15] <ubotu> Launchpad bug 205564 in bzr "bzr log fails with KeyError: 'null:'" [Undecided,New]
[15:21] <ubotu> New bug: #205564 in bzr "bzr log fails with KeyError: 'null:'" [Undecided,New] https://launchpad.net/bugs/205564
[15:23] <andrea-bs> tca: it only fails to show the log, why shouldn't be safe?
[15:24] <tca> just asking :-)
[15:24] <andrea-bs> tca: it was to know if I was missing something ;)
[15:41] <ubotu> New bug: #205579 in bzr "bzr checkout doesn't work with rich-root-pack" [Undecided,New] https://launchpad.net/bugs/205579
[16:10] <grubber> anyone have any advice (beyond whats already in wiki) on getting bzr-svn working for Mac?
[16:11] <Odd_Bloke> grubber: Describing the problems you're having would probably help focus any such advice. :)
[16:12] <grubber> Odd_Bloke: well, i tried the instructions on the wiki (but had to change libtool to glibtool in the Makefile to get swig-py to compile), but when i ran 'bzr plugins', it crashed hard. killed my terminal session.
[16:20] <Odd_Bloke> grubber: Is there anything in ~/.bzr.log?
[16:23] <grubber> Odd_Bloke: No. 'bzr plugins' got to the svn plugin and tried to load it, and then killed my terminal session. it gave a message that suggested the python library was mismatched
[16:23] <grubber> im not really sure where to even begin on that
[16:24]  * Odd_Bloke doesn't know, sorry.
[16:24] <Odd_Bloke> jelmer might be able to help...
[16:26] <grubber> Odd_Bloke: Alright. Thanks anyway! im really excited about trying out bzr but i'll just have to wait until i get to my windows machine at work.
[16:27] <awilkins> grubber: You might want to grab the pyrex branch and see if you can get the bindings to build on Mac
[16:27] <awilkins> They aren't complete yet but they have promise
[16:30] <grubber> awilkins: ok. im not sure where that is, but i can try that next. im using fink to build the svn 1.4.3 bindings... and ill try the plugin against that. maybe that will work.
[16:31] <awilkins> grubber: you go into the plugin folder and execute setup.py with the build_ext argumnet
[16:31] <awilkins> On windows it's a pain in the butt :-)
[16:31] <awilkins> You have to really fiddle to get them building
[16:32] <awilkins> But I think posix style platforms are probably better off
[16:32] <grubber> the plugin folder of which source?
[16:32] <awilkins> The svn plugin
[16:33] <awilkins> Let me hunt out the branch
[16:33] <awilkins> Note that they arent finished but they will probably be better than the SWiG binding when they work
[16:34] <awilkins> http://people.samba.org/bzr/jelmer/bzr-svn/pyrex/
[16:34] <awilkins> Seeing how they build on Mac would be instructive
[16:35] <grubber> ok... im checking them out now
[16:40] <jelmer> awilkins,grubber: The pyrex bindings don't work yet
[16:40] <jelmer> So unless you're interested in bzr-svn development there's no point in trying them out at this point
[16:43] <grubber> jelmer: ok. well, ill try the svn 1.4.4 bindings. you think those will work with bzr-svn?
[16:47] <jelmer> grubber: Only if you apply the patches linked from the wiki
[16:49] <grubber> jelmer: I'll give them another shot. I tried the Mac instructions on the wiki, and it didnt work for me (for one, I had to change 'libtool' to 'glibtool' in the Makefile), but when i finally ran 'bzr plugins', it crashed the whole terminal session
[17:00] <arnetheduck> hi, assuming I have a shared repo with some branches under it, if I rm -rf the branch, will the shared repo be cleaned at some point? when?
[17:00] <james_w> arnetheduck: only when you branch the branches in to a new shared repo and then nuke the old one.
[17:07] <arnetheduck> james_w, so if I for example branch a remote repo, do some modifications, push them and remove the branch, my shared repo will grow and never recover?
[17:07] <james_w> arnetheduck: correct, unless you do some cleaning up.
[17:08] <arnetheduck> what I'm thinking about is whether to keep a single shared repo in my $HOME/src folder, or keep each project separately...
[17:08] <james_w> I keep each project separately, but I know that some people just have one.
[17:09] <arnetheduck> and there's no bzr zap equivalent that kills a branch and removes it from the storage (something like zap but for heavy branches)?
[17:09] <james_w> I think there was an experimental one written at some point.
[17:09] <james_w> it's a dangerous operation though.
[17:10] <arnetheduck> james_w, I have to similar projects that both keep a copy of boost (large c++ lib) so it would be beneficial to share the two, but I'm not sure how long the benefit would last space-wise...
[17:12] <arnetheduck> james_w, thanks for the help  anyway, I'll keep them separate until I learn the quirks of bzr better =)
[17:12] <james_w> no problem
[17:19] <grubber> jelmer: here is the exact error i get (after following the instructions on the wiki): "Fatal Python error: Interpreter not initialized (version mismatch?)
[17:19] <grubber> "Abort trap"
[17:20] <jelmer> grubber: I guess that could mean the python subversion bindings were linked against the wrong version of python
[17:22] <grubber> jelmer: ok.. ill see if i can narrow down which python it linked against. i installed 2.5.2 recently, and maybe its not resolving consistently
[17:40] <grubber> jelmer: well, i cant find it. thanks for your help. ill try again in the next version!
[17:54] <luislavena> does anyone have problems branching svn branch?
[17:55] <ubotu> New bug: #205636 in bzr "Can't add file in subdir if changing subdir from file to dir (traceback if entry.name in parent.children) " [Undecided,New] https://launchpad.net/bugs/205636
[17:57] <jelmer> luislavena: what problems are you seeing?
[17:58] <luislavena> jelmer: sorry for the noise, is a 1.3 vs bzr-svn 'hardlink' issue...
[17:58] <luislavena> (found that after looking at lauchpad).
[17:59] <jelmer> luislavena: bzr-svn should already be warning you it is out of date
[17:59] <luislavena> jelmer: yep, didn't noticed since was switching windows... it is fixed in trunk?
[17:59] <jelmer> luislavena: in the 0.4 branch
[18:01] <luislavena> jelmer: is safe to branch from it now? or is on state of flux? :)
[18:01] <jelmer> luislavena: it's always in flux - it may be safer to check out the 0.4.9 branch
[18:02] <luislavena> jelmer: wow, 0.4.9, and just installed 0.4.8 :-P
[18:02] <luislavena> ;-)
[18:02] <luislavena> just kidding, let me try.
[18:04] <luislavena> jelmer: bzr: ERROR: No such file: 'http://people.samba.org/bzr/jelmer/bzr-svn/.bzr/repository/packs/6fb82431054b11a5d628eeca64a8542c.pack'
[18:06] <jelmer> luislavena: please try again
[18:06] <jelmer> I was pushing to the repository
[18:06] <luislavena> oh, over dumb protocol or running bzr+ssh?
[18:07] <jelmer> bzr+ssh
[18:13] <luislavena> in case I want to create a shared repository for a svn branch, which format the repo must be?
[18:15] <dato> luislavena: rich-root or rich-root-pack
[18:16] <luislavena> dato: thank you, was thinking on it but wasn't sure.
[18:26] <wjl> In cvs, svn, and hg, if I want to update my working tree to a specific revision, I use 'cvs up -r REV' or 'svn up -rREV' or 'hg up -rREV'. In bzr, there is no way to do 'bzr up' to a specific revision (that I know of), so I have to do something much more awkward, like 'cd ..; bzr branch -rREV a b' plus manual copying files around, etc. I am I missing something? Is there a easy way to do the equivalent of 'up -rREV' in other VCSs in bzr?
[18:28] <dato> wjl: if you just want the working tree updated, revert -r REV
[18:32] <wjl> dato: well, that will work well most of the time, I suppose. One problem is that it then marks everything as modified. I'm used to being able to use 'up -rREV' from most other VCSs, and having it know the difference between files that are up-to-date to a specific revision, vs. local modifications...
[18:35] <dato> in that case, I think there's a bug about update not supporting -r
[18:36] <dato> there is also pull --overwrite ., but you can make revisions inaccessible for that, so be very very careful
[18:43] <wjl> dato: hmmm... just played with pull --overwrite and I don't think that's what I want. Maybe I will go ahead and file a wishlist bug about update -r. I think revert will work well enough in the meantime, and branch -r still has the right semantics, it just is harder to use
[18:45] <wjl> looks like it's already filed as #45719
[18:46] <wjl> although, according to the bug report, it was slated for inclusion for 0.13 (yikes!) but got dropped. =(
[18:46] <dato> ubotu: #45719
[18:46] <ubotu> Sorry, I don't know anything about 45719 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[18:46] <james_w> bug #45719
[18:46] <ubotu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719
[18:47] <dato> ah, thanks james_w
[18:47] <james_w> np
[18:48] <wjl> (the fix is only committed to an abandoned branch, unfortunately)
[18:52] <wjl> thanks for the discussion. I'll be content for now that it's a known bug and I have two workarounds (revert -r and branch -r).
[19:02] <arnetheduck> hi, anyone recognises why I'd get "  File "/usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/commit.py", line 510, in commit
[19:02] <arnetheduck>     assert self._new_revision_id is None or self._new_revision_id == revid
[19:02] <arnetheduck> " when pushing a change to an svn repo after importing that repo to bzr, making a bzr commit and then bzr push to the svn repo?
[19:18] <Peng> arnetheduck: Up-to-date bzr and bzr-svn?
[19:20] <arnetheduck> bzr 1.3, bzr-svn 0.4.8
[19:21] <arnetheduck> here's the full log: http://pastebin.ca/954209
[19:23] <Peng> jelmer: bzr-svn problem ^
[19:26] <arnetheduck> Peng, jelmer: more info: I imported the svn repository using svn-import, made a single commit to the bzr branch, made a single push back to the svn repository. looking at the svn repo, it seems that the push succeeded (at least partially) because the contents of the bzr commit are present in svn
[19:26]  * Peng shrugs.
[19:26] <Peng> I don't know bzr-svn.
[19:27] <Peng> Hopefully sorry-for-pinging-you-jelmer will be here soon.
[19:27] <arnetheduck> Peng, hehe, I've been on to him ever since I started my little experiment with bzr-svn yesterday =)
[19:28] <Peng> Me too, since I started importing random projects with bzr-svn last week. :P
[19:31] <awilkins> I also pester him a great deal
[19:31] <awilkins> Maybe we should club together and buy him a cake :-)
[19:34] <Peng> Sounds good to me. :)
[19:47] <mw-home> Hi -- I just started using olive and I really like it.  However, is there any way to get it to show side-by-side diffs?
[19:47] <mw-home> Is there some other visual diff program for linux that people like?
[19:51] <Peng> I think I found KDiff3 tolerable.
[19:55] <abentley> There's also Meld
[19:58] <mw-home> abentley: Meld?
[19:58] <Peng> Oh, right, Meld. I don't think I tried that.
[19:59] <abentley> mw-home: Yes.  Most distributions have it.
[20:01] <mw-home> anyone in here use anything but the command-line bzr tool?
[20:04] <mtaylor> nope
[20:04]  * mtaylor is helpful
[20:08] <mw-home> I don't really understand my options for sharing my branch with other people on the internet.  Is there a way to offer my repository over HTTP?
[20:10] <rexbron> hello, I am trying to work with a branch, but am getting this (http://pastebin.ca/954268) error. The thing that confuses me is that the branch is not in a repo
[20:11] <radix> rexbron: all bzr branches have a repository. you're probably thinking of *shared* repositories
[20:11] <rexbron> radix: ok, I suppose then I need to do what it says and lock the branch
[20:11] <radix> rexbron: if you don't create a branch inside of a shared repository, then the repository is just right next to the branch
[20:12] <radix> rexbron: I don't really know anything about that particular error. what operation are you trying to perform?
[20:12] <rexbron> I am using bzr-builddeb to automate the creation of debian source packages
[20:13] <andrea-bs> rexbron: could you please give the complete traceback and the command you used?
[20:13] <rexbron> andrea-bs: sure
[20:13] <Peng> mw-home: Push it to some web server (over sftp or bzr+ssh if bzr is installed on the server)?
[20:14] <Peng> mw-home: If it's an open source project, you could also host it in Launchpad. https://launchpad.net/
[20:17] <rexbron> andrea-bs: http://pastebin.ca/954275
[20:18] <andrea-bs> thanks rexbron
[20:18] <yacc> mw-home: just push it to a place that is accessible via http
[20:20] <rexbron> andrea-bs: It might be worth while to mention that I am using bzr 1.0
[20:20] <mw-home> Peng, yacc: I can't use launchpad.  I do have a webserver that I can make an ssh connection to.  Do I just run a checkout on the webserver?
[20:21] <Peng> mw-home: Just push to it.
[20:21] <andrea-bs> rexbron: are you sure the script is well formed?
[20:21] <Peng> mw-home: "bzr push --remember sftp://me@myserver/var/www/bzr/repo/branch" or whatever.
[20:23] <rexbron> andrea-bs: It was working several weeks ago
[20:23] <mw-home> Peng: am going to try this out
[20:23] <rexbron> and I have not made and significant changes to the code
[20:23] <Peng> mw-home: Why can't you use LP?
[20:23] <yacc> mw-home: No, you push via ssh to some place that happens to be accessible per http too.
[20:24] <andrea-bs> rexbron: maybe the output of `ls .bzr/repository/lock` would help
[20:24] <mw-home> I can't use LP because I'm not working on free software (GASP).
[20:25] <rexbron> andrea-bs: the lock dir is empty
[20:25] <rexbron> (which might make sense
[20:25] <andrea-bs> rexbron: hehe, right :)
[20:26] <Peng> mw-home: Oh, ok.
[20:26] <Peng> mw-home: (You traitor!) :P
[20:26] <rexbron> andrea-bs: I can try just running bd from the dir itself and see if I get the same traceback
[20:26] <mw-home> Peng: I'm running that push now.  Looks good so far.  Now will others be able to run a checkout by pointing to that http:// location?
[20:27] <Peng> mw-home: Yes.
[20:27] <Peng> mw-home: I hope you created a shared repo.
[20:27] <mw-home> Peng: what is a shared repo?
[20:29] <andrea-bs> rexbron: ok, could you tell me also when exactly is "blender-svn.py" called?
[20:30] <Peng> mw-home: All of a branch's data is stored in a repository (repo), in the same directory as the branch. But when you have two related branches, having two copies of the data wastes a lot of space. If you run "bzr init-repo" in the parent directory to create a shared repo, all of the branches below it will hold their data their, to prevent duplication and wasted space.
[20:30] <rexbron> andrea-bs: If I do not explicetly set the orig-dir option it will crash with the same traceback, therefore I must not be passing that option correctly in the script
[20:31] <radix> Peng: oh, cool, does "init-repo" now automatically relocate and merge data from branches in existing subdirectories
[20:31] <radix> ?
[20:31] <Peng> radix: No.
[20:31] <radix> oh, woops.
[20:31] <Peng> Yeah, I should've said *new* branches will put their data there.
[20:32] <Peng> Someone should add support for that to "bzr reconfigure" or something.
[20:33] <mw-home> Peng: OK, thanks for that explanation.  The time to make a shared repo would be way before I did the bzr push sftp:, right?  It would have been when I had set up my original repo?
[20:33] <Peng> mw-home: Yeah, it would've been before the push.
[20:33] <mw-home> So, since I probably didn't make a shared repo, both my local repo and the copy on the webserver have 100% of the history.
[20:34] <andrea-bs> rexbron: can you try using an absolute path?
[20:34] <Peng> mw-home: A shared repo is useful for multiple branches on the same machine, not different machines.
[20:35] <rexbron> andrea-bs: It was ulimately my fault, I was specifying the wrong dir. I am still intrgued as to why it crashes with that rather (Imo) non-obvous traceback
[20:35] <mw-home> Peng: so, why did you say you hoped I made a shared repo?
[20:35] <Peng> mw-home: In case you have multiple branches on the server in the future.
[20:35] <mw-home> 10-4
[20:36] <andrea-bs> rexbron: if you think the error can be improved (I think so), you can report a bug ;)
[20:36] <rexbron> Sure :)
[20:38] <andrea-bs> rexbron: when you have done, could you please give me its number so I'll try to make a patch for it, please?
[20:38] <rexbron> sure
[20:38] <lamalex> Hi, is there a way to see patches that have been submitted to a branch if you're not the branch owner?
[20:38] <andrea-bs> rexbron: thanks ;)
[20:39] <andrea-bs> lamalex: is it a question about launchpad?
[20:40] <lamalex> about bazaar
[20:40] <lamalex> I pushed a patch up to a bazaar branch
[20:40] <lamalex> but I reformatted my hd and didn't save the patch I wrote
[20:41] <lamalex> Can I pull that patch back down to apply it to the code on my pc
[20:42] <lamalex> The code is hosted from launchpad, so sort of
[20:42] <andrea-bs> lamalex: sorry but I can't understand: in bzr you can send commits (there are not distinctions with patches) and there are not branch owners
[20:42] <lamalex> sorry, I'm new to bzr, used to svn
[20:43] <lamalex> I did a brz push of a patch to a bzr mirror on launchpad
[20:43] <lamalex> I lost my local copy of the patch I pushed
[20:43] <lamalex> can I pull down what was pushed somehow?
[20:43] <lamalex> the .patch file I pushed
[20:43] <andrea-bs> there's "bzr pull"
[20:44] <lamalex> will that pull down patches and whatnot?
[20:44] <mw-home> when to use bzr checkout vs bzr branch when making a new working copy of a project?
[20:44] <andrea-bs> lamalex: I didn't understand well your situation so I'm not sure this will help you
[20:44] <radix> mw-home: use checkout when you want commits to immediately be sent to the remote branch.
[20:45] <andrea-bs> lamalex: you can try with this command, if it doesn't work, give me some links ;)
[20:45] <radix> lamalex: "bzr pull" will pull revisions to another branch into your branch. It only works if the branches haven't diverged in development.
[20:45] <radix> erg, I meant "pull revisions *from* another branch"
[20:45] <mw-home> radix: that makes sense.  so, bzr branch will let me commit locally, and then use bzr push to commit to the remote repo?
[20:46] <radix> mw-home: right.
[20:46] <thekorn> hi, if any moderator of the bazaar ML is around today, can you please moderate my last mail (send yesterday), thank you!
[20:47] <mw-home> I just ran a bzr checkout, and I want to know the revision number of the branch.  bzr info doesn't show it.  How do I find that out?  bzr log --limit 1?
[20:47] <radix> mw-home: bzr revno
[20:48] <mw-home> by the way, i just read about bzr aliases.  Those are a really nice trick that are sorely missing from svn.
[20:48] <mw-home> radix: thanks for the tip.
[20:50] <rexbron> andrea-bs: small point that I just encountered. builddeb should raise an exception (during the run() method) when there are changes to the working tree. It prints an error message to stdout but that is not useful for if one is trying to use it in a script
[20:58] <mw-home> can anyone tell me how to use vimdiff with bzr diff?
[20:59] <jelmer> re
[20:59] <jelmer> arnetheduck: still there?
[21:29] <mw-home> How do I push stuff back into my parent branch without having to type out the whole URL?
[21:30] <rexbron> mw-home: if you have pushed to it before, you do not need a url
[21:30] <Peng> mw-home: You use "push --remember $url", then you won't have to supply it in the future.
[21:41] <mw-home> Peng, rexbron: thanks.
[21:42] <mw-home> So, anyone in here running ubuntu?  I can't find the 1.3 bzr package for ubuntu on that LP site.
[21:44] <Peng> mw-home: Yeah, the PPA takes a few days to get updated.
[21:52] <mw-home> anybody in here use bzr-svn? it seems that after putting a bzr tag on my bzr repository, i can't push it back into svn.  I'm using bzr 1.0, though, so maybe this is old news.
[21:53] <jelmer> mw-home: bzr-svn won't set tags in svn yet, if that's what you mean
[21:53] <jelmer> mw-home: bzr-svn 0.5 will hopefully support this
[21:54] <mw-home> jelmer: bzr-svn is a really useful tool though.
[22:03] <arnetheduck> jelmer, I'm here for a minute now...
[22:04] <jelmer> mw-home: thanks
[22:04] <jelmer> arnetheduck: you were having trouble with bzr-svn earlier?
[22:04] <mw-home> when should I use bzr merge to update my branch and when should I use bzr pull to update my local branch?
[22:05] <Peng> mw-home: Use merge when the branches have diverged.
[22:05] <arnetheduck> jelmer, yes, did you see my posts?
[22:06] <Peng> mw-home: Don't worry, bzr will do the right thing when you try the wrong one.
[22:06] <Peng> mw-home: (Say the history of your branch is A -> B -> C, and the remote branch committed something new, so it's A -> B -> C -> D. You'd use "pull" to get D.)
[22:07] <mw-home> Peng: thanks!
[22:07] <Peng> mw-home: (But if you've both committed things, so you have A -> B -> C and the remote has A -> B -> D, the branches have diverges, and you'll need to merge.)
[22:08] <Peng> diverged*
[22:09] <jelmer> arnetheduck: looking at them now
[22:09] <jelmer> arnetheduck: this may be a timing issue
[22:09] <jelmer> arnetheduck: please file a bug
[22:31] <arnetheduck> jelmer, I will...sf.net servers are notoriously slow, for the record
[22:32] <arnetheduck> jelmer, should I worry about the consistency of either of my repositories (svn, bzr)?
[22:32] <jelmer> arnetheduck: sf.net? You mean launchpad?
[22:33] <jelmer> arnetheduck: no, this should have no consequences for the consistency
[22:33] <arnetheduck> jelmer, no, I was pushing my changes from my bzr branch to an svn repo on sf.net
[22:34] <arnetheduck> jelmer, the bzr branch being on my hard drive, no launchpad involved...
[22:38] <Peng> jelmer: (Out-of-date by a day or two, but..) if I try to do an svn-import and a branch of the same svn repo at the same time, SQLite tracebacks with an OperationalError about the database being locked. That could be handled better..
[22:41] <Peng> jelmer: Traceback: http://paste.pocoo.org/show/35178/
[22:41] <arnetheduck> jelmer, bug 159538
[22:41] <ubotu> Launchpad bug 159538 in bzr-svn "crashes when pushing changes on top of base revision that's present twice" [Undecided,Incomplete] https://launchpad.net/bugs/159538
[22:44] <jelmer> Peng: There's an open bug about that
[22:44] <Peng> jelmer: Ok.
[22:44] <jelmer> Peng: There's not much we can do about other than not use sqlite I think
[22:45] <Peng> jelmer: Yeah, it could happen at any time, right?
[22:45]  * Peng notices that he's like 30 revisions behind on bzr-svn.
[22:46] <jelmer> Peng: if you have two processes using the same svn repository it's very likely to happen, yes
[22:46] <Peng> Oops, traceback.
[22:47] <Peng> jelmer: Yeah, I was hoping it would wait for a bzr lock.
[22:47] <Peng> Maybe I shouldn't update bzr-svn's source code while it's running, eh?
[22:49] <jelmer> Peng: There is no bzr lock that could be used here
[22:49] <jelmer> Peng: you could be pulling from a subversion repository into two independent bzr branch
[22:50] <Peng> This time it was the same bzr repo, so I was hoping that would kick in first.
[22:50] <Peng> You could implement your own locking, I suppose.
[22:50] <Peng> But I guess SQLite's works well enough; it's just ugly.
[23:05] <Peng> jelmer: Wait, if you removed the on-disk branch property cache, that means there's useless data in the database now, right?
[23:06] <jelmer> Peng: yep
[23:06] <Peng> ...Ok. :)
[23:26] <ubotu> New bug: #159538 in bzr-svn "crashes when pushing changes on top of base revision that's present twice" [Undecided,New] https://launchpad.net/bugs/159538