[00:10] <blueyed> Is there a "maintain /etc using bzr" wiki page somewhere around already?
[00:13] <Peng> etckeeper?
[00:15] <Odd_Bloke> mwhudson: Regarding your list email(s), you wrote "It produces rather a for bzrlib currently".  I believe jam was wondering what it produces for bzrlib. :)
[00:16] <mwhudson> Odd_Bloke: yeah, he replied
[00:20] <Odd_Bloke> mwhudson: Aw, lag. :)
[00:20] <mwhudson> Odd_Bloke: thanks for trying though :)
[00:23] <Odd_Bloke> mwhudson: No worries.
[00:23] <jelmer> mtaylor: yes, you can svn-import everything and remove what you don't need or run bzr branch on the things you are interested in
[00:23] <Odd_Bloke> jelmer: o/
[00:24] <blueyed> Peng: etckeeper for bzr?
[00:24] <jelmer> 'evening Odd_Bloke :-)
[00:24] <jelmer> blueyed: yes, there's etckeeper support for bzr
[00:25] <jelmer> although it's not entirely finished yet because bzr doesn't have a start-commit hook
[00:25] <blueyed> jelmer: i think I've set it up manually now, except for the metathingy.. found http://kitenet.net/~joey/code/etckeeper/
[00:25] <blueyed> sounds great though.
[00:27] <blueyed> does it make sense to lock a branch for 33+ hours? (like bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/)
[00:43] <spiv> blueyed: probably an accident.
[00:43] <spiv> blueyed: e.g. someone getting disconnected while trying to do a commit.
[00:48] <blueyed> spiv: sure, but there should be amore sensible timeout.. e.g. like "no data received in 2 minutes" => revert
[00:50] <mtaylor> jelmer: thanks
[00:59] <spiv> blueyed: Perhaps, or for connection-oriented smart server sessions it could unlock after the connection drops.
[02:54] <awmcclain> I'm looking for a GUI for OS X that will just let me see which files have changed/added/coflicts (bzr st), allow me to merge side-by-side, and allow me to resolve conflicts and mark files as resolved. Some combination of apple's diff or vimdiff? Any thoughts?
[02:56] <spiv> awmcclain: maybe http://www.sorn.net/projects/wildcat-bzr/?  I haven't tried it myself.
[02:56]  * spiv -> lunch
[02:57] <Verterok> awmcclain: did you tried qbzr?
[02:57] <awmcclain> Nope.
[03:02] <abentley> jam: You don't mean having the ancestry *only* in the content objects, do you?
[03:23]  * igc lunch
[05:14]  * jdong cries
[05:14] <jdong> git doesn't care bout empty directories
[05:15] <RAOF> Git doesn't care about sanity, either :P
[05:15] <mwhudson> directories are a myth!  or something
[05:15]  * mwhudson leaves
[05:31] <jamesh> jdong: empty directories are not files, so are not important
[05:32] <jamesh> in fact, directories aren't files, so it doesn't consider them to be important
[05:37] <abentley> jdong: I'm kinda surprised, considering git's equivalent to inventory is a stack of nested trees.
[05:38] <abentley> So their data model explicitly includes directories, and it should be easy for them to support empty ones.
[06:26] <robotgeek> hi, could anyone help with bzr? i am a bit confused about checkout vs merges vs branches
[06:28] <bob2> ask away
[06:29] <robotgeek> I was trying to follow https://wiki.ubuntu.com/DocumentationTeam/Repository (Advanced Methods -> Downloading a tarball of the revision history)
[06:29] <robotgeek> then, i did a checkout of a working tree of one branch
[06:30] <robotgeek> using bzr checkout .
[06:30] <robotgeek> then i did a bzr merge of the documentation tree that I am supposed to be working on from the website.
[06:31] <robotgeek> now "bzr status" shows pending merges, which I don't follow (i tht after the merge, i am supposed to have a exact copy of what is on the url )
[06:31] <bob2> no
[06:32] <bob2> merging A into B pulls all the changes from A into the checkout of B.  you need to commit after merging to make those changes part of the B branch.
[06:32] <bob2> (but do not make any other changes after merging but before committing - except fixing conflicts or fixing errors from the merge)
[06:33] <spiv> robotgeek: if you want your checkout to be an exact copy of the URL, use "bzr pull"
[06:33] <robotgeek> spiv: will it override the merge command?
[06:34] <spiv> robotgeek: no, you'd need to revert the merge
[06:34] <spiv> robotgeek: a merge is an edit to the checkout, like editing the files with your text editor
[06:34] <robotgeek> spiv: am i looking for remerge?
[06:35] <spiv> robotgeek: no, remerge reapplies the merge you just did in a slightly different way
[06:35] <spiv> robotgeek: but it doesn't sound like you want a merge at all
[06:35] <robotgeek> heh, is there a single command i can use to undo the merge? or do i need to repeat my process all over again?
[06:35] <spiv> robotgeek: Merging is a way to combine the changes in two different branches
[06:35] <spiv> robotgeek: "bzr revert"
[06:35] <spiv> robotgeek: sorry, I should have been more explicit about what I meant by reverting :)
[06:36] <robotgeek> hmm, similiar to svn.
[06:36] <spiv> Right.
[06:36] <spiv> "bzr revert" undoes any uncommitted changes.  And merging changes from another branch are changes like anything else, so you can revert them if you don't want them.
[06:37] <robotgeek> spiv: thanks. it now crashes on ssh key.
[06:37] <spiv> Can you pastebin the error?
[06:38] <robotgeek> spiv: http://pastebin.com/m5a342010
[06:39] <spiv> robotgeek: ah, two problems there
[06:39] <spiv> robotgeek: one is that you have an old-ish version of bzr that crashes rather than gives a friendly error message when this happens
[06:39] <spiv> robotgeek: the other is right up the top: "Launchpad user 'venkat' doesn't have a registered SSH key"
[06:40] <robotgeek> spiv: why would i need a ssh key to "pull" ? its a read only action, correct?
[06:40] <spiv> robotgeek: you can add SSH keys to your Launchpad account at https://launchpad.net/~venkat/+editsshkeys
[06:40] <spiv> robotgeek: it is, but you're trying to access a bzr+ssh:// URL, which requires SSH, which requires authentication.
[06:41] <robotgeek> spiv: i did not know that i was accessing with ssh :) alrite, one more thing to do!
[06:41] <RAOF> Was the launchpad plugin introduced to bzr after version 0.90?
[06:41] <spiv> robotgeek: you could use "http://..." instead of "bzr+ssh://..." as the URL.
[06:41] <bob2> why did bzr/lp redirect the http url give to bzr+ssh?
[06:41] <bob2> s/give/given/
[06:42] <spiv> bob2: It didn't, but I'm guessing that the current working directory is a checkout claiming to be bound to bzr+ssh://...
[06:42] <robotgeek> spiv: but i did use http://
[06:42] <spiv> robotgeek: what does "bzr info -v" say in that directory?  (pastebin again)
[06:42] <bob2> spiv: hrm, robotgeek's paste started with "bzr pull http..."
[06:43] <robotgeek> spiv: http://pastebin.com/m6b5c8a9 you were right :)
[06:44] <spiv> robotgeek: ok
[06:44] <spiv> robotgeek: so you probably don't want to be doing that pull into that checkout, anyway.
[06:44] <spiv> robotgeek: let's step back a moment
[06:44] <spiv> robotgeek: what do you want to do?
[06:44] <bob2> duh, missed that it was a co
[06:45] <robotgeek> i essentially want to work on some kubuntu docs, but the initial branch command was taking so long, i decided to use a tarball of the revision history that was linked to from the documentation site
[06:45] <robotgeek> spiv: https://wiki.ubuntu.com/DocumentationTeam/Repository , Advanced Methods -> Downloading a tarball of the revision history.
[06:46] <spiv> robotgeek: if you upgrade your bzr to 1.2, and use bzr+ssh, the initial branch will be *much* faster.
[06:46] <robotgeek> spiv: okay, will do.
[06:47] <spiv> robotgeek: I also suggest not using --dirstate-with-subtrees if you do upgrade to 1.2
[06:47] <spiv> robotgeek: that said, 420MB is a lot of history, so it's going to take some time :)
[06:47] <spiv> robotgeek: Ah, I see what's going on.
[06:48] <spiv> robotgeek: ok, the instructions on the wiki are ok, but perhaps not complete.
[06:49] <spiv> robotgeek: so, you want to unpack the tarball, make a checkout from the history in it, and make sure it's up to date with the live version, right?
[06:49] <robotgeek> spiv: exactly
[06:49] <spiv> robotgeek: Ok, so after "bzr checkout .", you should use "bzr update".
[06:50] <robotgeek> spiv: okay, lemme add ssh key and come back.
[06:50] <spiv> robotgeek: "bzr merge" on that wiki page is bad advice.  There's one branch involved, so "bzr merge" doesn't make sense, because it's for combining changes from multiple branches.
[06:51] <robotgeek> spiv: heh, i guess it was written way back, and most of us are still confuzzled with the bzr stuff. plus, i am getting back into this after a long long time!
[06:52] <spiv> robotgeek: (If you had a separate branch of this project with your own changes, and wanted to merge in new changes from the original branch, that's when you'd use "bzr merge")
[06:53] <robotgeek> spiv: okay. so if i did something radically new and wanted to merge my changes, i would use that. ok
[06:54] <spiv> robotgeek: so basically, the tarball hack there is a shortcut that is equivalent to doing "bzr checkout bzr+ssh://..."
[06:54] <robotgeek> spiv: how do i change what bzr thinks is my launchpad name (lp name is venkatvc
[06:54] <spiv> robotgeek: which like SVN gives you a checkout of a branch hosted elsewhere.  When you make commits, they are committed back to the central branch.
[06:55] <robotgeek> it is trying to find my name under venkat, my lpname is venkatvc
[06:55] <spiv> robotgeek: "bzr launchpad-login"
[06:55] <spiv> robotgeek: "bzr launchpad-login venkat", to be precise
[06:57] <robotgeek> spiv: if i am trying to make it venkatvc, it should be bzr launchpad-login venkatvc .
[06:57] <robotgeek> bzr update still looks under venkat
[06:59] <robotgeek> spiv: "bzr lp-login" displays venkatvc, but bzr update looks for ssh keys with venkat
[07:00] <spiv> what does bzr info say?  Does it have a login in the URL?  ("bzr+ssh://venkat@..." ?)
[07:01] <robotgeek> spiv: it does not, so i am guessing it is using the shell name venkat.
[07:01] <spiv> "bzr lp-login" only affects "lp:" URLs, not "bzr+ssh:" URLs.
[07:01] <spiv> Right, that would be what's going on.
[07:01] <robotgeek> for the ssh part
[07:01] <spiv> So either include a "venkatvc@" in the URL, or create a .ssh/config
[07:08] <robotgeek> spiv: thanks, that worked. i will probably save a log of our conversation, and update that page!
[07:11] <robotgeek> spiv, bob2 : thanks for you help!
[07:39] <spiv> robotgeek: glad I could help.
[10:37] <jelmer> awilkins: no, fast-import and bzr-svn aren't compatible (and shouldn't ever be)
[10:41] <awilkins> jelmer: Bah, never mind.. I'm going to look at fast-import anyway for a nasty MKS repository.
[10:41] <lifeless> ho jelmer
[10:42] <jelmer> hola lifeless
[10:42] <lifeless> jam: hi, in London now, chat at your convenience
[10:44] <weigon__> jelmer: g'morn
[10:44] <weigon__> jelmer: who is bulding the bzr-svn ubuntu packages on launchpad ?
[10:44] <jelmer> I am
[10:45] <weigon__> can you trigger a build for gutsy ?
[10:45] <weigon__> of 0.4.7
[10:45] <weigon__> gutsy is only 0.4.6, hardy has 0.4.7
[10:51] <jelmer> I'll have a look at releasing 0.4.8 now
[10:51] <jelmer> weigon__: Or is there a specific reason you need 0.4.7 ?
[10:54] <weigon> nope, just that the 0.4.6 release requires bzr < 1.2
[10:55] <weigon> so 0.4.8 is fine too
[10:57] <jelmer> 0.4.7 does too, there's nothing compatible with 1.2 out yet
[10:58] <spiv> jelmer: is the strict version checking worthwhile, do you think?
[10:58] <jelmer> spiv: yes, as we've had a lot of breakages in the past
[10:58] <spiv> I guess I track the development branch too much to notice :)
[10:58] <jelmer> In particular because upstream bzr started passing new arguments that bzr-svn didn't support yet
[10:59] <spiv> It's a shame, because it seems to cause as much hassle as it avoids :/
[11:00] <jamesh> spiv: maybe bzr should include a list of which versions of bzr-svn it is compatible with :0
[11:00] <spiv> jamesh: heh
[11:00] <jamesh> then you wouldn't need a new bzr-svn release for every bzr release
[11:01] <spiv> Hmm, I wonder if bzr-svn could try to run with a new version, and then only if an internal error occurs, give a "please upgrade bzr-svn" message with the traceback?
[11:02] <spiv> (and only if the version of bzr isn't a known good version, so real bug reports aren't discouraged)
[11:02] <jelmer> spiv: heh, that would be a neat hack
[11:03] <mwhudson> bzr svn-import --im-feeling-lucky
[11:03] <spiv> jelmer: It extends "easier to ask forgiveness than ask permission" right to the user :)
[11:07] <jelmer> yup
[11:07] <jelmer> I guess we can just have a generic variable somewhere with extra text that should be in the traceback
[11:09] <spiv> jelmer: hmm, you could possibly do it entirely in the plugin
[11:10] <spiv> jelmer: with a big try/except around your command implementation that inspects the exception, and if it's an internal error *and* bzr-svn is possibly too old, then emit the warning and re-raise the exception.
[11:11] <spiv> Or re-raise a slightly modified/wrapped exception.
[11:11] <jelmer> spiv: that means injecting that try/except in a lot of places
[11:11] <spiv> It'd probably be nice to have proper support in bzrlib.
[11:11] <jelmer> pretty much every function of the bzr-svn Repository implementation, etc.
[11:11] <jelmer> yeah
[11:12] <spiv> jelmer: Possibly just in a single Command subclass?
[11:12] <jelmer> spiv: bzr-svn provides more than just commands
[11:12] <spiv> Oh, right, it's not just Commands
[11:12] <spiv> Yeah, that's tough.
[11:13] <spiv> You could monkey-patch trace.report_bug ;)
[11:13] <jelmer> james_w: ping
[11:14] <jelmer> spiv: Too much trouble :-)
[11:14] <jamesh> spiv: of course, the only danger is poisoning your repository with incorrectly converted revisions.
[11:15] <spiv> jamesh: technically true, but I think the sort of errors you'd like have would be unlikely to fail in that sort of way.
[11:18] <spiv> jamesh: bzrlib tries to be backwards compatible, and even where it fails I think an API change that would cause old code to suddenly start making broken data would be rejected.
[11:23] <lifeless> well
[11:23] <lifeless> we advertise an API compatability version
[11:23] <lifeless> and a current API version
[11:23] <lifeless> the two should be sufficient to massively reduce surprises
[11:24] <lifeless> in particular, depending on the minimum API version rather than the current version would be a big improvement
[11:24] <lifeless> (and slap us if we don't reset it appropriately)
[11:24] <jelmer> lifeless: in practice, bzr tends to break backwards compatibility sometimes without deprecating first
[11:25] <jelmer> I'm not sure the extra work for deprecation is worth the effort in all cases though
[11:25] <lifeless> jelmer: if we break compatibility we are meant to raise api_minimum_version
[11:26] <spiv> Maybe we should be regularly running the bzr-svn test suite around the time we make release candidates.
[11:26] <lifeless> jelmer: thats the point of that export, to signal when we have broken api's without deprecating
[11:26] <jelmer> lifeless: Would there ever be a release without that variable changing though?
[11:27] <lifeless> jelmer: yes, there have been several
[11:28] <jelmer> lifeless: 1.1 has been the only one so far I think (ignoring rc's)
[11:29] <lifeless> jelmer: even so :)
[11:29] <lifeless> jelmer: existence proof FTW
[11:31] <jelmer> true, though it would still mean that in pretty much all cases you have to have a matching bzr-svn release for your bzr release
[11:32] <jelmer> which is not that much of a problem imo
[11:32] <lifeless> jelmer: it does cause some friction
[11:33] <lifeless> jelmer:  you might like to play with my hsallow-branch branch
[11:33] <lifeless> jelmer: it works :)
[11:34] <jelmer> lifeless: I know, the current situation is not perfect but there are more important issues imho
[11:35] <jelmer> lifeless: Cool, I'll check it out. What's the branch URL or is there some mailing list post I should look at?
[11:36] <AfC> lifeless: did you ever get the patch review you were looking for?
[11:37] <lifeless> jelmer: http://bazaar.launchpad.net/~lifeless/bzr/shallow-branch/
[11:38] <lifeless> AfC: I have about 10 branches needing revie wnow :) = plane trip -- hacking :>
[11:38] <AfC> I used to get so much done on flights. Now it is a bit more hit and miss.
[11:39] <AfC> I've been making progress on a number of things, though, and that's always a nice feeling.
[11:47] <poolie> AfC: hi, are you up?
[11:47] <poolie> I'm in Londo
[11:47] <poolie> n
[11:48] <AfC> poolie: hey Martin.
[11:49] <AfC> poolie: I hope you had a good trip up.
[11:49] <awilkins>  < poolie> I'm in Londo <-   eww, Babylon 5 character action
[11:50] <awilkins> http://en.wikipedia.org/wiki/Londo_Mollari
[11:55] <lifeless> awilkins: dude.
[11:56] <lifeless> AfC: poolie just had 24 hours sitting next to yours truely :>
[12:12] <awilkins> lifeless: Shallow branching ... that would super-great for bzr-svn :-
[12:13] <lifeless> awilkins: try it out
[12:13] <lifeless> awilkins: it probably will break with bzr-svn, but jelmer will want patches :>
[12:14] <lifeless> in fact, it *will* break with bzr-svn because the current stacking code looks for an exact repository match
[12:14] <jelmer> lifeless: Speaking of API compatibility, bzr.dev just broke bzr-svn :-)
[12:14] <lifeless> what we need is more generic stacking, which is  aseparate refactoring that aaron and John and I have been working on/towards
[12:14] <lifeless> jelmer: ok, we should bump the api version then :)
[12:14] <lifeless> jelmer: what it did break?
[12:15] <jelmer> BzrDir.sprout() now takes a hardlink argument
[12:15] <lifeless> jelmer: ah yes; I wonder if it would be nicer to only pass that when its not the default value
[12:16] <jelmer> well, even if it would be passed only in some situations it would still be API breakage
[12:17] <jelmer> there doesn't appear to be anything in NEWS about this, btw
[12:21] <awilkins> Maybe there should be some kind of API breakage monitoring tool :-)
[12:22] <awilkins> Are the bzr-eclipse guys in here?
[12:22] <Verterok> awilkins: hi :-)
[12:23] <lifeless> jelmer: there is hard-link as a feature, but indeed not as a internals change
[12:23] <awilkins> Verterok: Hi there ; I'm running with a branch of bzr-eclipse for my purposes, I've been making changes to BzrClient and I have some more ideas for API changes.
[12:24] <Verterok> awilkins: Oh, great!, I'm working in the client right now :D
[12:24] <awilkins> Verterok: I've added some of the commands hidden from the help because they are useful for my current project
[12:24] <Verterok> nice!
[12:24] <awilkins> Verterok: I'd also really love to see a Jepp version of the client (something that holds the libraries loaded) because the process spawning time is significant.
[12:25] <Verterok> awilkins: I'm currently working in passing relative paths (to the branch root) instead of full paths, and adding some tests
[12:26] <awilkins> Verterok: I've just added find-merge-base and revisioninfo because they are useful for automating my current stuff
[12:27] <awilkins> No tests as yet, I'm too busy just using it :-)
[12:27] <Verterok> awilkins: I tried to start the Jepp version, but the distribution requiremnts of that client is quite troublesome
[12:27] <Verterok> awilkins: there is always time to write them ;)
[12:28] <Verterok> awilkins: I'm hoping the jython guys put a 2.5 aplha out after the PyCon sprint
[12:29] <Verterok> awilkins: did you tried using bzr service plugin to improve the performance of spawning multiple bzr commands?
[12:29] <awilkins> Verterok: Not yet.. but thanks for the heads up, I shall look at it if performance becomes very bad
[12:30] <Verterok> awilkins: are you using the bzrClient outside bzr-eclipse?
[12:30] <awilkins> Verterok: My principal wish for the API is for all the places that take Revision to take RevisionRange instead. (and make Revision a special case of RevisionRange. And write RevisionRange in the first place)
[12:31] <awilkins> Verterok: Yes, I'm using it for VCS operations in a publishing system (they want very thorough change reports)
[12:31] <Verterok> nice :)
[12:32] <Verterok> awilkins: that sounds ok for me, in regards of bzr-eclipse it's only matter of a simple refactor
[12:32] <awilkins> Verterok: I was planning on using SVN but their requirements are so heinous I'm abstracting it all and using bzr ; I'll either rewrite the abstractions for SVN, or just use bzr / bzr-svn instead. Or if it's politically OK, just change the underlying repo to bzr anyway.
[12:33] <jelmer> lifeless: There's only "bzr push --shallow", not "bzr branch --shallow" ?
[12:35] <awilkins> Verterok: If bzr is ever to run well on IronPython it needs a service plugin because IronPython doesn't cache it's compilation products to disk
[12:35] <Verterok> awilkins: I think there is no problem of API changes, I'm not aware of any other using the bzrClient
[12:36] <awilkins> Verterok: That's good.
[12:37] <Verterok> awilkins: maybe a warning in the wiki-page will suffice.
[12:40] <lifeless> jelmer: bzr branch --shallow works
[12:40] <lifeless> jelmer: go to the master copy not the mirror; the mirror is probably out of date
[12:43] <Verterok> awilkins: are you going to implement the RevisionRange class? (so, we don't duplicate work :))
[12:50] <awilkins> Verterok: Yeah, I might do at that :-)
[12:51] <awilkins> Verterok: I'll probably make a branch just for that and merge it to my current stuff
[12:52] <Verterok> awilkins: Oh, great! thanks! then I'll merge that with trunk :)
[13:16] <Prodoc> Is anyone else experiencing high Bazaar CPU usage on Windows XP when using the Eclipse plugin?
[13:30] <Verterok> Prodoc: that should be expected, because bzr-eclipse uses bzr executable under the hood
[13:31] <Verterok> Prodoc: this is caused by the calculation of the status to decorate the tree
[13:35] <Prodoc81> Verterok: sorry about that, lost connection
[13:35] <Prodoc81> can high CPU usage (80%+) for a period of sometimes minutes be expected?
[13:36] <Prodoc81> this happens after saving a file
[13:37] <Verterok> it's a know issue, this is cause because after each save bzr-eclipse run status to update the decorators
[13:38] <Verterok> Prodoc81: sorry, I musst leave for a while
[13:39] <Prodoc81> np, ok, at least it's a know issue, I'll just disbale the decorators for the time being
[13:39] <Verterok> ok
[13:39]  * Verterok bbl
[13:39] <Prodoc81> disable
[13:42] <radix> hm. but why would 'bzr st' take minutes?
[13:42]  * awilkins has a feeling it probably runs it once for each file
[13:42] <radix> oof
[13:43] <awilkins> The "Eclipsey" way is probably to have a "FileDecorationListener" that gets called for each file
[13:43] <awilkins> bzr-eclipse probably needs a status cache server
[13:46] <awilkins> It might work better with the bzr service plugin that Verterok mentioned earlier
[13:47] <awilkins> The bulk of the CPU time bzr eats for small operations on win32 is process creation, loading, etc.
[13:48] <awilkins> It's probably still going to suck though, until there is a way of hosting bzrlib inside the JVM along with the rest of the code.
[14:14] <jdong> :( why is git using almost 1.5x the space of bzr for the same sized project....
[14:14] <jdong> and that's after git-gc. I won't flatter git with the number from before.
[14:18] <edreamleo> Hello all
[14:18] <edreamleo> I have a question about something that looks like magic...
[14:18] <Odd_Bloke> edreamleo: Shoot. :)
[14:19] <edreamleo> Leo has a trunk at: https://code.launchpad.net/leo-editor/
[14:20] <edreamleo> And the comment with the trunk (I didn't write it, an expert did), says...
[14:20] <edreamleo> To get a copy of this branch, use the command:  bzr branch lp:leo-editor
[14:21] <edreamleo> This works, and creates a new folder called leo-editor
[14:21] <jdong> bzr has support for launchpad URL's
[14:21] <jdong> it's a bundled plugin with bzr that makes lp: stuff look like URL
[14:21] <edreamleo> Ah, so lp: means launchpad?
[14:21] <jdong> yep
[14:21] <jdong> lp:product-name picks the trunk of that project
[14:22] <edreamleo> And it's not documented because?
[14:22] <jdong> edreamleo: see bzr help launchpad
[14:22] <jdong> it's often documented but not in an obvious spot ;-)
[14:23] <edreamleo> I see.  Thanks very much.
[14:57] <jrydberg_> who's maintaining trac-bzr these days?
[15:03] <abentley> lp: should really be listed in "bzr help urlspec", because failing to list it implies it's not supported.
[15:05] <awilkins> While we're (vaguely) on the subject, there are commands like find-merge-base and revision-info that are very useful
[15:05] <awilkins> But not listed in the help
[15:05] <therve> hello
[15:06] <awilkins> (ok, they're useful from a low-level perspective)
[15:06] <therve> I think I've done something stupid with a repos
[15:07] <therve> http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated
[15:07] <therve> I don't manage to 'co' it anymore
[15:07] <therve> if fails with: bzr: ERROR: Repository KnitPackRepository('file:///XXXX/handle-deprecated/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://therve@bazaar.launchpad.net/%7Etherve/pydoctor/handle-deprecated/.bzr/)
[15:10] <luks> the branch is in dirstate-with-subtree format, which is not compatible with the default format you get after "bzr init-repo"
[15:11] <therve> ok
[15:11] <luks> probably converted by older bzr-svn, today you would probably use rich-root-pack or rick-root for that
[15:11] <therve> hum...
[15:11] <luks> branching without a shared repository should work fine
[15:12] <spiv> luks: Weird, I get that error with "bzr co" too, even without a shared repo (i.e. making a standalone checkout)
[15:12] <luks> or create/update the repository with --dirstate-with-subtree
[15:12] <spiv> But I don't get it with "bzr branch"
[15:12] <luks> oh, branch worked fine for me
[15:12] <luks> bzr co seems to work fine here
[15:13] <luks> lukas@nemo:/tmp$ bzr co http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated
[15:13] <luks> lukas@nemo:/tmp$ cd handle-deprecated/
[15:13] <luks> lukas@nemo:/tmp/handle-deprecated$ ls
[15:13] <luks> basic.tac  bin  doc  LICENSE.txt  nevow.cfg  pydoctor  README.txt  server.tac  setup.py  twisted.cfg  www  zibasic.tac
[15:13] <spiv> luks: try with bzr+ssh:// rather than http://
[15:13] <luks> are you sure you are not in a shared repo? :)
[15:13] <spiv> luks: certain :)
[15:14] <luks> well, I can't use bzr+ssh on that branch obviously
[15:14] <spiv> luks: why not?
[15:14] <luks> Permission denied (publickey)
[15:15] <spiv> luks: you can read any branch on launchpad via bzr+ssh://, you just need to give it a public SSH key.
[15:15] <spiv> luks: oh, you haven't got a launchpad account with an SSH key?
[15:15] <luks> I do
[15:15] <ubotu> New bug: #196607 in bzr "Export command improvements (status, speed)" [Undecided,New] https://launchpad.net/bugs/196607
[15:16] <luks> but I realized I need to specify username@bazaar....
[15:16] <spiv> Then you shouldn't be getting "Permission denied (publickey)", that's an authentication error.
[15:16] <spiv> therve: I fear you might be hitting something like https://bugs.edge.launchpad.net/bzr/+bug/173002
[15:16] <ubotu> Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,New]
[15:17] <spiv> therve: although the "bzr co" vs. "bzr branch" part is weird.
[15:17] <spiv> therve: a workaround would be to use sftp:// vs. bzr+ssh://
[15:17] <spiv> therve: this is definitely a bug in bzr, rather than user error
[15:17] <spiv> therve: please file a bug about this, I need to sleep
[15:17] <therve> spiv: it looks like 'co http:' and then 'switch bzr+ssh' worked
[15:18] <therve> but good night
[15:18] <spiv> therve: right, that'd be an equivalent workaround
[15:31] <edreamleo> Hello all
[15:32] <edreamleo> This newbie just found another way to crash bzr :-)
[15:32] <edreamleo> The bug report is at: https://bugs.launchpad.net/bzr/+bug/196618
[15:32] <ubotu> Launchpad bug 196618 in bzr "bzr push lp: crashes" [Undecided,New]
[15:33] <edreamleo> This all comes of the bzr branch lp:leo-editor magic
[15:33] <edreamleo> Previously, that is, when checking out from a url, bzr remembered the url, so...
[15:33] <edreamleo> bzr push "just worked"
[15:34] <edreamleo> But somehow bzr didn't remember the url when using lp:leo-editor
[15:34] <edreamleo> So when I tried bzr push I got...
[15:34] <edreamleo> bzr: ERROR: No push location known or specified.
[15:35] <edreamleo> In typical newbie fashion, I just tried something :-)
[15:35] <edreamleo> bzr push lp:
[15:35] <edreamleo> And got a traceback
[15:36] <edreamleo> The output from bzr info is given in the bug report.
[15:36] <edreamleo> As you can see, there is no push bzr+ssh entry in the info output
[15:36] <luks> it never sets the push location on 'bzr branch'
[15:37] <lifeless> edreamleo: bzr push lp: is interesting; its not valid but it would be good if it gave help :)
[15:37] <edreamleo> So my newbie question is, how do I tell bzr the push location?
[15:37] <luks> bzr push URL
[15:38] <luks> URL might be lp:something
[15:38] <luks> depends where do you want to push it
[15:38] <edreamleo> So the natural thing would be to create an alias?
[15:38] <luks> alias?
[15:38] <luks> why?
[15:39] <edreamleo> So I can just say bzr push rather than bzr push lp:leo-editor
[15:39] <luks> it will remember it once you it for the first time
[15:39] <edreamleo> Ahh...
[15:39] <luks> *do it
[15:39] <edreamleo> That's nice.
[15:40] <luks> or you can use push --remember to change the location
[15:40] <edreamleo> bzr push lp:leo-editor doesn't work...
[15:40] <edreamleo> Let me try the real url...
[15:41] <luks> I think you need bzr launchpad-login or something to make push over lp:XXX work
[15:41] <ubotu> New bug: #196618 in bzr "bzr push lp: crashes" [Undecided,New] https://launchpad.net/bugs/196618
[15:47] <edreamleo> I think I'm getting close, but...
[15:48] <edreamleo> I tried this: bzr push bzr+ssh://bazaar.launchpad.net/~edreamleo/leo-editor/trunk
[15:48] <edreamleo> A connection was started...
[15:49] <edreamleo> But it said Auth banner: No such Launchpad account: HP_Administrator
[15:49] <luks> bzr+ssh://<username>@bazaar.launchpad.net/~edreamleo/leo-editor/trunk
[15:50] <edreamleo> Ah.  <username>
[15:50] <luks> but you will need to setup also the putty ssh agent, if you want to use it on windows
[15:50] <LeoNerd> Lots of false highlights for me here lately :)
[15:50] <luks> because launchpad only uses SSH key authentification
[15:50] <edreamleo> But why is the message about HP_adminitrator when bzr whoami give my correct id?
[15:50] <edreamleo> Yes, I am running pagent
[15:51] <edreamleo> Let me try the corrected url now...
[15:51] <radix> edreamleo: it's the ssh transport. ssh defaults to using your current username for remote logins, unless explicitly stated otherwise
[15:51] <luks> I guess the code that determines the username for ssh is outside of bzr
[15:51] <radix> edreamleo: and whoami has nothing at all to do with authentication, only what to record as the author of commits
[15:51] <edreamleo> Thx radix
[15:52] <edreamleo> The push is cranking away nicely now...
[15:52] <edreamleo> Clearly, I am the fool that your 'foolproof' code must guard against...
[15:53] <luks> I'd just blame launchpad :)
[15:54] <radix> luks: what, because it requires specifying a username?
[15:54] <abentley> luks: unfortunately, adding AI to launchpad has been delayed to version 3.0 :-)
[15:55]  * radix looks forward to it :)
[15:56] <luks> radix: it wasn't really serious
[15:56] <luks> but I still don't like how bzr works with LP
[15:56] <radix> ok.
[15:56] <luks> e.g. that bzr push lp:something works differently based on bzr lp-login
[15:56] <luks> but it doesn't tell you so
[15:57] <luks> too many options, just using real URLs would be less consfusing
[15:57] <edreamleo> Wow, the push is really slow.
[16:03] <edreamle1> Hmm.  After getting to step 5/5, the [16:05] <edreamle1> just opened another console.  bzr status prints nothing, so maybe the bzr push worked...
[16:06] <radix> edreamle1: "bzr missing <remote_url>" will tell you if the branches are out of sync
[16:06] <edreamle1> I'm assuming hanging a console isn't the default bzr push 'success' notification :-)
[16:06] <radix> indeed :
[16:06] <radix> )
[16:08] <edreamle1> drat.  Killing the console resulted in the wrong push location being remembered.
[16:10] <edreamle1> The push location isn't in the main bazaar.conf file in C:\Documents and Settings\HP_Administrator\Application Data\bazaar\2.0
[16:10] <edreamle1> Where would the remembered push loc be?
[16:10] <radix> edreamle1: hmm. it would be in locations.conf, unless I'm out date
[16:10] <lifeless> radix: you are out of date
[16:10] <lifeless> edreamle1: just run the push again, with --remember
[16:11] <radix> ok, my bad :)
[16:11] <edreamle1> That assumes *I* remember what the url was :-)
[16:14] <edreamle1> Ok, just opened the Secsh channel 1, so all looks good.
[16:18] <edreamle1> Once again, the console appears to be hung.
[16:19] <edreamle1> Maybe it's time for a reboot.  I probably should have done so after installing the bzr upgrade...
[16:19] <edreamle1> Never mind: I got the can not acquire lock message.  I'll kill the console and break the lock
[16:25] <madduck> so if i just want to track a repo and update it every day
[16:25] <madduck> bzr merge is apparently the wrong tool
[16:25] <madduck> Merging from remembered location http://liw.iki.fi/bzr/unperish2/trunk/
[16:25] <madduck> bzr: ERROR: Working tree "/home/madduck/code/unperish/" has uncommitted changes.
[16:25] <madduck> i never made any changes to the working tree
[16:25] <madduck> what's the command to use instead?
[16:26] <luks> pull
[16:27] <madduck> okay, and another question: how do i reset the worktree to a given revision?
[16:27] <luks> (and revert to clear the merge)
[16:27] <luks> revert -r XX, but that will really reset only the working tree
[16:28] <madduck> hm.
[16:28] <luks> what do you want it for?
[16:28] <madduck> play around/test the bzr integration into the mr tool
[16:40] <andrea-bs> you can [temporary] commit the current workingtree, use "bzr revert -r old_revision" and finally "bzr revert -r latest_revision"
[16:53] <madduck> thanks
[16:57] <lifeless> marianom: mr tool ?
[16:58] <LarstiQ> lifeless: a tool by joeyh iirc
[17:00] <LarstiQ> lifeless: http://kitenet.net/~joey/code/mr/
[17:01] <lifeless> LarstiQ: hi dude
[17:02] <jelmer> wow, yet another vcs-related tool by joey
[17:03] <LarstiQ> jelmer: others being?
[17:03] <LarstiQ> lifeless: hey
[17:03] <jelmer> LarstiQ: etckeeper and ikiwiki
[17:04] <LarstiQ> jelmer: ah, related in that way
[17:04] <LarstiQ> jelmer: did you catch the stomach flu aswell at fosdem?
[17:05] <jelmer> LarstiQ: Nope, I'm fine. Were there more people that caught it?
[17:07] <LarstiQ> jelmer: nattie, Womble2 and murb at least.
[17:09] <jelmer> LarstiQ: Ah, not anybody I met then. I think all of the other flooders are ok too
[17:12] <LarstiQ> jelmer: meh, I blame it on nattie then.
[17:42] <james_w> Hi all.
[17:43] <james_w> LarstiQ: hi. Did I see that you will be there next week?
[17:44] <LarstiQ> james_w: that is the planning, yes
[17:45] <james_w> LarstiQ: fantastic.
[17:46] <jelmer> LarstiQ: btw, when are you flying?
[17:47] <jelmer> Apologies if I've already asked this weekend
[17:47] <james_w> jelmer: pong. Sorry, it dropped off my traceback, so I had to look up who pinged me.
[17:47] <jelmer> james_w: no worries. Hi!
[17:47] <james_w> Hi jelmer. How are you?
[17:47] <LarstiQ> jelmer: sunday
[17:47] <jelmer> james_w: Basically, I keep hitting an import error when running the bzr selftest
[17:48] <james_w> jelmer: on builddeb?
[17:48] <jelmer> james_w: yep - "from errors import DebianError"
[17:48] <jelmer> LarstiQ: morning or afternoon?
[17:48] <lifeless> dont use relative imports PLEASE
[17:48] <lifeless> jelmer: I filed a bug on this already :)
[17:49] <lifeless> jelmer: you're in a directory with errors.py :>
[17:49] <jelmer> james_w: I've got a patch for this if you're interested
[17:49] <james_w> lifeless: yeah, I'm going to fix it soon, I promise.
[17:49] <jelmer> lifeless: I'm probably the worst violator of this myself..
[17:50] <james_w> jelmer: I'll happily take a patch for it.
[17:50] <jelmer> cool
[17:50] <LarstiQ> jelmer: 16:55 at AMS
[17:52] <jelmer> LarstIQ: ah, ok. I'm leaving at 10 or something in the morning
[18:45] <TeijoIhmiskilpi> yo
[18:45] <TeijoIhmiskilpi> is there a solution for getting a warning/whatever when checking in cr/lf stuff?
[18:46] <TeijoIhmiskilpi> short of running a verification script manually on checkin
[18:47] <mwhudson> there are pre-commit hooks
[18:48] <TeijoIhmiskilpi> ah, ok. something you can use out of the box or do you have to custom-make such a thing?
[18:49] <mwhudson> well, you'd have to write some python i think
[18:50] <mwhudson> but i don't think it's very complicated
[18:50] <mwhudson> i have no experience of it myself though, let me see if i can find some documentation :)
[18:51] <mwhudson> TeijoIhmiskilpi: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-hooks
[18:51] <TeijoIhmiskilpi> well, python is not a problem ;-)
[18:51] <TeijoIhmiskilpi> just as long as it's easy to config for our project
[18:52] <TeijoIhmiskilpi> ok, seems easy enough
[18:53] <TeijoIhmiskilpi> btw, it would be a good idea to have some "ready" hooks for checking sources for crlf
[18:53] <TeijoIhmiskilpi> (because, typically, you don't want those and bzr does no translation on them)
[18:55] <mwhudson> perhaps
[18:55] <mwhudson> my life is blissfully windows-free these days, so i'm not the best person to talk to about this :)
[18:56] <TeijoIhmiskilpi> yeah, I can understand that. However, when part of the developers in on windows... it can become painfull
[18:56] <TeijoIhmiskilpi> like with symlinks
[18:56] <TeijoIhmiskilpi> current approach (repos with symlinks are unaccessible) is unbearable
[18:58] <TeijoIhmiskilpi> or at least a history-fixing NUKE_ALL_SYMLINKS would be quite swell ;-)
[18:59] <TeijoIhmiskilpi> case in point - we had IPython imported to launchpad, but had to start a new project from scratch because it had single symlink
[19:01] <mwhudson> TeijoIhmiskilpi: you should perhaps email the list about this stuff
[19:01] <luks> I think just removing the symlink would be enough
[19:01] <mwhudson> mark hammond is going to be working on windows support soon
[19:01] <luks> it only fails if it has to create it on the disk
[19:01] <TeijoIhmiskilpi> ah
[19:02] <TeijoIhmiskilpi> so removing it from svn will suffice?
[19:02] <luks> and there is a plugin to support fake cygwin-like symlinks
[19:02] <luks> no, I meant from bzr
[19:02] <TeijoIhmiskilpi> well, the svn is being imported to bzr in launchpad so it will disappear from bzr as well
[19:02] <luks> ah, then yes
[19:03] <TeijoIhmiskilpi> ok, perhaps I'll join bzr mailing list
[19:09] <TeTeT> how do I copy a shared repository from one place to another? I have a shared repo on a usb stick and want to know copy it to the HD of the system
[19:10] <TeijoIhmiskilpi> just copy it?
[19:10] <TeijoIhmiskilpi> drag & drop?
[19:10] <TeTeT> won't the push/pull references be wrong?
[19:10] <TeijoIhmiskilpi> they are not absolute, I think
[19:10] <TeijoIhmiskilpi> did you test it
[19:10] <TeijoIhmiskilpi> ?
[19:10] <TeTeT> no, not yet, can do
[19:16] <james_w> TeTeT: there's no repository copy operation at the UI level, but a normal copy should work.
[19:17] <TeTeT> james_w: thx
[19:17] <TeijoIhmiskilpi> regarding shared repos btw
[19:17] <TeijoIhmiskilpi> anyone know whether launchpad has project repos as shared repos by default?
[19:17] <TeijoIhmiskilpi> or should those be created by user?
[19:17] <james_w> TeijoIhmiskilpi: no, it doesn't
[19:18] <james_w> TeijoIhmiskilpi: and I don't think you can.
[19:18] <TeijoIhmiskilpi> ok. well, it's their disk space ;-)
[19:18] <jdong> TeijoIhmiskilpi: not just that, it's your push time too
[19:18] <mwhudson> well, it's also your bandwidth
[19:18] <mwhudson> it's being worked on though
[19:19] <TeijoIhmiskilpi> but as I understand it, I can have the same branches as shared repos locally, even if they are not shared on LP?
[19:19] <mwhudson> (for various reasons "one shared repo per project" would be a bit simplistic)
[19:19] <TeijoIhmiskilpi> the bzr reference was not all the explecit on this issue
[19:19] <jdong> TeijoIhmiskilpi: correct
[19:19] <jdong> TeijoIhmiskilpi: but the problem will come when you push your branch to launchpad, pushing a new branch always means uploading the entire revision history
[19:20] <TeijoIhmiskilpi> ok. that kind of sucks
[19:20] <TeijoIhmiskilpi> why would shared repo / project be too simplistic?
[19:20] <TeijoIhmiskilpi> are there space/performance for having shared repos?
[19:20] <TeijoIhmiskilpi> tradeoffs I meant to say
[19:20] <jdong> TeijoIhmiskilpi: probably beacuse nobody's gotten around to implement it
[19:21] <jdong> TeijoIhmiskilpi: from what I understand manpower is tight for bzr-launchpad folks
[19:21] <TeijoIhmiskilpi> but wouldn't it be enough to create one shared repo for the project upload area?
[19:21] <TeijoIhmiskilpi> i.e. no actual implementation to be done
[19:22] <TeijoIhmiskilpi> for all its worth, it should be possible to create one shared repo far my c:/prj folder that has all my projects :-)
[19:22] <mwhudson> TeijoIhmiskilpi: well, there are problems with locking for one thing
[19:23] <mwhudson> bear in mind that anyone can upload code for your project
[19:23] <TeijoIhmiskilpi> it bzr backtracks the directory tree to find shared repo, it should work automatically
[19:23] <TeijoIhmiskilpi> hmm, ok
[19:23] <TeijoIhmiskilpi> still... why would it need to lock stuff?
[19:24] <TeijoIhmiskilpi> if they just created a series of "images" on shared repo
[19:24] <TeijoIhmiskilpi> i.e. if user foo uploads snapshot 123ffdfbbb21212, it should not lock anything else
[19:24] <TeijoIhmiskilpi> to shared repo I mean
[19:24] <TeijoIhmiskilpi> though I have to admin I'm a total newcomer to bzr....
[19:25] <TeijoIhmiskilpi> but assuming it works like hg/git... just create the snapshots in the shared repo, and the rest in own branches
[19:25] <ubotu> New bug: #196702 in bzr "qlog fails to run with or with parameter" [Undecided,New] https://launchpad.net/bugs/196702
[19:26] <TeijoIhmiskilpi> ah, bugbot, sexy
[19:30] <Toksyuryel> with or with?
[19:31] <emilis_info> what wiki is used for bzr website?
[19:32] <Toksyuryel> http://bazaar-vcs.org/MoinMoin
[19:32] <Toksyuryel> I think it's called "Moin
[19:32] <Toksyuryel> I think it's called "MoinMoin"
[19:33] <emilis_info> aha
[19:33] <emilis_info> thanks
[19:48] <Lo-lan-do> Hello
[19:48] <jelmer> hey Lo-lan-do
[19:48] <Lo-lan-do> I tried to "bzr pack" a repository of mine, and that doubled its size...  Is this supposed to happen?
[19:49] <fullermd> Yes, the old packs are kept aroudn in obsolete-packs
[19:50] <Lo-lan-do> Hm.  So I can safely remove that dir?
[19:51] <abentley> No, the directory is required.  The contents will be deleted automatically next commit.  You can delete the contents manually, but there's not real point.
[19:51] <abentley> s/not/no
[19:53] <Lo-lan-do> There's the point that it won't use resources for the next backup.
[20:14] <dato> abentley: not in the next commit, but in the next repack, IME... :-?
[20:15] <abentley> That might be.
[20:19] <abentley> Lo-lan-do: Anytime you manually manipulate the contents of .bzr, you risk shooting your foot off.
[20:21] <Lo-lan-do> I know, but 80 MB of wasted space is... suboptimal.
[20:21] <Lo-lan-do> And surprising, when you're told that "bzr pack" compresses a repo.
[20:23] <abentley> Lo-lan-do: destroying your repository is of course your prerogative.
[20:24] <Lo-lan-do> Thanks :-)
[20:25] <Lo-lan-do> Hence my need for backups, and my need for them to be as useful as possible (and no bigger than needed).
[22:03] <Lo-lan-do> Hi again
[22:03] <Lo-lan-do> I seem to have encountered a bug :-(
[22:03] <Lo-lan-do> http://paste.debian.net/50128
[22:04] <Lo-lan-do> Does that ring a bell?
[22:09] <james_w> Lo-lan-do: I've not seen that one before. Please file a bug.
[22:09] <james_w> Lo-lan-do: does it depend on --lca?
[22:09] <Lo-lan-do> I'll try to reproduce in a clean environment first.
[22:10] <Lo-lan-do> I don't see the bug with --diff3
[22:11] <Lo-lan-do> And --weave takes forever so I don't know yet :-)
[22:11] <james_w> Yeah, I suspect --lca is a rarely used codepath, so it wouldn't surprise me.
[22:12] <Lo-lan-do> I can reproduce with --lca in a clean env (bzr 1.1).  I'll check with bzr 1.2 in a cowbuilder.
[22:14] <james_w> Lo-lan-do: do you have a launchpad account?
[22:14] <Lo-lan-do> No
[22:15] <james_w> that's fine. If you want to file in Debian I'll happily relay it.
[22:18] <Lo-lan-do> Yay, I can reproduce that even with bzr 1.2.
[22:18] <Lo-lan-do> (Not sure it really makes me happy though :-)
[22:18] <Lo-lan-do> bzr get http://bzr.debian.org/~lolando/bzr/f-spot/patches/superpatch/ ; cd superpatch ; bzr merge --lca http://bzr.debian.org/~lolando/bzr/f-spot/patches/bz-329174/
[22:22] <bob2> reproducible with bzr.dev
[22:23] <mwhudson> looks like an abentley bug to me!
[22:25] <abentley> mwhudson: agreed.
[22:25] <abentley> I'll grab those branches now.
[22:26] <Lo-lan-do> I copied them to http://bzr.debian.org/~lolando/tmp/bzrbug-20080228/
[22:27] <Lo-lan-do> Since --weave seems to have worked, I'll probably continue evolving them.
[22:27] <Lo-lan-do> Shall I submit the bug nevertheless?
[22:33]  * Lo-lan-do goes ahead
[22:45]  * Lo-lan-do goes to bed, too
[22:46] <james_w> night Lo-lan-do.
[22:56] <ubotu> New bug: #196780 in bzr "Exception during merge --lca" [Undecided,New] https://launchpad.net/bugs/196780
[22:59] <ja1> spiv: ping
[23:00] <spiv> jam: pong
[23:37] <macogw> why does "bzr break-lock" then make bzr commit tell me that 1) it's still locked 2) i'm locking it
[23:38] <beuno> macogw, are you sure the lock got broke?
[23:38] <macogw> dont know.  it asked "do you want to break ....? [y/n]" and i hit y
[23:39] <macogw> is there supposed to be some sort of "lock broken" message afterward?
[23:39] <beuno> macogw, maybe it couldn't break the lock due to permissions?  can you run it again and check it doesn't spit out anything odd
[23:40] <beuno> I don't recall if it confirms it, but it sure would tell you if it failed
[23:40] <macogw> it never said it failed
[23:40] <macogw> it works now....maybe waiting a few minutes does....something?
[23:41] <macogw> i tried it like 5 times before, but less than a minute apart
[23:41] <beuno> macogw, is this on launchpad?
[23:41] <beuno> still, locks should be broken immediatley
[23:42] <macogw> yes
[23:42] <macogw> i was trying to add myself to Planet Ubuntu, since i never got around to it before
[23:43] <beuno> macogw, LP might be a bit weird about it, yes
[23:44] <macogw> ok
[23:53] <spiv> Generally repeated break-lock means there were multiple smart server processes on the server waiting to take the lock.
[23:54] <spiv> So you need to break-lock repeatedly to get through the backlog.   (Although I also thought bzr 1.2, which is on Launchpad, would be better about leaving those processes hanging around indefinitely.)
[23:56] <beuno> spiv, ah, good to know. Maybe that should be added as a FAQ somewhere?
[23:57] <spiv> beuno: it doesn't seem to come up very often.  I'd like to get more information from the next person that reports it, too, because I thought it should be largely fixed by now for servers running 1.2.
[23:58] <beuno> spiv, I've seen this come up many times before. I'll make sure to grab on to the next one and send a ping your way
[23:59] <spiv> beuno: thanks