[00:10] Is there a "maintain /etc using bzr" wiki page somewhere around already? [00:13] etckeeper? [00:15] 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] Odd_Bloke: yeah, he replied [00:20] mwhudson: Aw, lag. :) [00:20] Odd_Bloke: thanks for trying though :) [00:23] mwhudson: No worries. [00:23] 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] jelmer: o/ [00:24] Peng: etckeeper for bzr? [00:24] 'evening Odd_Bloke :-) [00:24] blueyed: yes, there's etckeeper support for bzr [00:25] although it's not entirely finished yet because bzr doesn't have a start-commit hook [00:25] jelmer: i think I've set it up manually now, except for the metathingy.. found http://kitenet.net/~joey/code/etckeeper/ [00:25] sounds great though. [00:27] does it make sense to lock a branch for 33+ hours? (like bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/) [00:43] blueyed: probably an accident. [00:43] blueyed: e.g. someone getting disconnected while trying to do a commit. [00:48] spiv: sure, but there should be amore sensible timeout.. e.g. like "no data received in 2 minutes" => revert [00:50] jelmer: thanks [00:59] blueyed: Perhaps, or for connection-oriented smart server sessions it could unlock after the connection drops. [02:54] 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] awmcclain: maybe http://www.sorn.net/projects/wildcat-bzr/? I haven't tried it myself. [02:56] * spiv -> lunch [02:57] awmcclain: did you tried qbzr? [02:57] Nope. [03:02] jam: You don't mean having the ancestry *only* in the content objects, do you? [03:23] * igc lunch === dscherge1 is now known as dscherger [05:14] * jdong cries [05:14] git doesn't care bout empty directories [05:15] Git doesn't care about sanity, either :P [05:15] directories are a myth! or something [05:15] * mwhudson leaves [05:31] jdong: empty directories are not files, so are not important [05:32] in fact, directories aren't files, so it doesn't consider them to be important [05:37] jdong: I'm kinda surprised, considering git's equivalent to inventory is a stack of nested trees. [05:38] So their data model explicitly includes directories, and it should be easy for them to support empty ones. [06:26] hi, could anyone help with bzr? i am a bit confused about checkout vs merges vs branches [06:28] ask away [06:29] I was trying to follow https://wiki.ubuntu.com/DocumentationTeam/Repository (Advanced Methods -> Downloading a tarball of the revision history) [06:29] then, i did a checkout of a working tree of one branch [06:30] using bzr checkout . [06:30] then i did a bzr merge of the documentation tree that I am supposed to be working on from the website. [06:31] 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] no [06:32] 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] (but do not make any other changes after merging but before committing - except fixing conflicts or fixing errors from the merge) [06:33] robotgeek: if you want your checkout to be an exact copy of the URL, use "bzr pull" [06:33] spiv: will it override the merge command? [06:34] robotgeek: no, you'd need to revert the merge [06:34] robotgeek: a merge is an edit to the checkout, like editing the files with your text editor [06:34] spiv: am i looking for remerge? [06:35] robotgeek: no, remerge reapplies the merge you just did in a slightly different way [06:35] robotgeek: but it doesn't sound like you want a merge at all [06:35] 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] robotgeek: Merging is a way to combine the changes in two different branches [06:35] robotgeek: "bzr revert" [06:35] robotgeek: sorry, I should have been more explicit about what I meant by reverting :) [06:36] hmm, similiar to svn. [06:36] Right. [06:36] "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] spiv: thanks. it now crashes on ssh key. [06:37] Can you pastebin the error? [06:38] spiv: http://pastebin.com/m5a342010 [06:39] robotgeek: ah, two problems there [06:39] 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] robotgeek: the other is right up the top: "Launchpad user 'venkat' doesn't have a registered SSH key" [06:40] spiv: why would i need a ssh key to "pull" ? its a read only action, correct? [06:40] robotgeek: you can add SSH keys to your Launchpad account at https://launchpad.net/~venkat/+editsshkeys [06:40] robotgeek: it is, but you're trying to access a bzr+ssh:// URL, which requires SSH, which requires authentication. [06:41] spiv: i did not know that i was accessing with ssh :) alrite, one more thing to do! [06:41] Was the launchpad plugin introduced to bzr after version 0.90? [06:41] robotgeek: you could use "http://..." instead of "bzr+ssh://..." as the URL. [06:41] why did bzr/lp redirect the http url give to bzr+ssh? [06:41] s/give/given/ [06:42] 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] spiv: but i did use http:// [06:42] robotgeek: what does "bzr info -v" say in that directory? (pastebin again) [06:42] spiv: hrm, robotgeek's paste started with "bzr pull http..." [06:43] spiv: http://pastebin.com/m6b5c8a9 you were right :) [06:44] robotgeek: ok [06:44] robotgeek: so you probably don't want to be doing that pull into that checkout, anyway. [06:44] robotgeek: let's step back a moment [06:44] robotgeek: what do you want to do? [06:44] duh, missed that it was a co [06:45] 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] spiv: https://wiki.ubuntu.com/DocumentationTeam/Repository , Advanced Methods -> Downloading a tarball of the revision history. [06:46] robotgeek: if you upgrade your bzr to 1.2, and use bzr+ssh, the initial branch will be *much* faster. [06:46] spiv: okay, will do. [06:47] robotgeek: I also suggest not using --dirstate-with-subtrees if you do upgrade to 1.2 [06:47] robotgeek: that said, 420MB is a lot of history, so it's going to take some time :) [06:47] robotgeek: Ah, I see what's going on. [06:48] robotgeek: ok, the instructions on the wiki are ok, but perhaps not complete. [06:49] 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] spiv: exactly [06:49] robotgeek: Ok, so after "bzr checkout .", you should use "bzr update". [06:50] spiv: okay, lemme add ssh key and come back. [06:50] 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] 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] 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] spiv: okay. so if i did something radically new and wanted to merge my changes, i would use that. ok [06:54] robotgeek: so basically, the tarball hack there is a shortcut that is equivalent to doing "bzr checkout bzr+ssh://..." [06:54] spiv: how do i change what bzr thinks is my launchpad name (lp name is venkatvc [06:54] 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] it is trying to find my name under venkat, my lpname is venkatvc [06:55] robotgeek: "bzr launchpad-login" [06:55] robotgeek: "bzr launchpad-login venkat", to be precise [06:57] spiv: if i am trying to make it venkatvc, it should be bzr launchpad-login venkatvc . [06:57] bzr update still looks under venkat [06:59] spiv: "bzr lp-login" displays venkatvc, but bzr update looks for ssh keys with venkat [07:00] what does bzr info say? Does it have a login in the URL? ("bzr+ssh://venkat@..." ?) [07:01] spiv: it does not, so i am guessing it is using the shell name venkat. [07:01] "bzr lp-login" only affects "lp:" URLs, not "bzr+ssh:" URLs. [07:01] Right, that would be what's going on. [07:01] for the ssh part [07:01] So either include a "venkatvc@" in the URL, or create a .ssh/config [07:08] spiv: thanks, that worked. i will probably save a log of our conversation, and update that page! [07:11] spiv, bob2 : thanks for you help! [07:39] robotgeek: glad I could help. [10:37] awilkins: no, fast-import and bzr-svn aren't compatible (and shouldn't ever be) [10:41] jelmer: Bah, never mind.. I'm going to look at fast-import anyway for a nasty MKS repository. [10:41] ho jelmer [10:42] hola lifeless [10:42] jam: hi, in London now, chat at your convenience [10:44] jelmer: g'morn [10:44] jelmer: who is bulding the bzr-svn ubuntu packages on launchpad ? [10:44] I am [10:45] can you trigger a build for gutsy ? [10:45] of 0.4.7 [10:45] gutsy is only 0.4.6, hardy has 0.4.7 === weigon__ is now known as weigon [10:51] I'll have a look at releasing 0.4.8 now [10:51] weigon__: Or is there a specific reason you need 0.4.7 ? [10:54] nope, just that the 0.4.6 release requires bzr < 1.2 [10:55] so 0.4.8 is fine too [10:57] 0.4.7 does too, there's nothing compatible with 1.2 out yet [10:58] jelmer: is the strict version checking worthwhile, do you think? [10:58] spiv: yes, as we've had a lot of breakages in the past [10:58] I guess I track the development branch too much to notice :) [10:58] In particular because upstream bzr started passing new arguments that bzr-svn didn't support yet [10:59] It's a shame, because it seems to cause as much hassle as it avoids :/ [11:00] spiv: maybe bzr should include a list of which versions of bzr-svn it is compatible with :0 [11:00] jamesh: heh [11:00] then you wouldn't need a new bzr-svn release for every bzr release [11:01] 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] (and only if the version of bzr isn't a known good version, so real bug reports aren't discouraged) [11:02] spiv: heh, that would be a neat hack [11:03] bzr svn-import --im-feeling-lucky [11:03] jelmer: It extends "easier to ask forgiveness than ask permission" right to the user :) [11:07] yup [11:07] I guess we can just have a generic variable somewhere with extra text that should be in the traceback [11:09] jelmer: hmm, you could possibly do it entirely in the plugin [11:10] 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] Or re-raise a slightly modified/wrapped exception. [11:11] spiv: that means injecting that try/except in a lot of places [11:11] It'd probably be nice to have proper support in bzrlib. [11:11] pretty much every function of the bzr-svn Repository implementation, etc. [11:11] yeah [11:12] jelmer: Possibly just in a single Command subclass? [11:12] spiv: bzr-svn provides more than just commands [11:12] Oh, right, it's not just Commands [11:12] Yeah, that's tough. [11:13] You could monkey-patch trace.report_bug ;) [11:13] james_w: ping [11:14] spiv: Too much trouble :-) [11:14] spiv: of course, the only danger is poisoning your repository with incorrectly converted revisions. [11:15] 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] 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] well [11:23] we advertise an API compatability version [11:23] and a current API version [11:23] the two should be sufficient to massively reduce surprises [11:24] in particular, depending on the minimum API version rather than the current version would be a big improvement [11:24] (and slap us if we don't reset it appropriately) [11:24] lifeless: in practice, bzr tends to break backwards compatibility sometimes without deprecating first [11:25] I'm not sure the extra work for deprecation is worth the effort in all cases though [11:25] jelmer: if we break compatibility we are meant to raise api_minimum_version [11:26] Maybe we should be regularly running the bzr-svn test suite around the time we make release candidates. [11:26] jelmer: thats the point of that export, to signal when we have broken api's without deprecating [11:26] lifeless: Would there ever be a release without that variable changing though? [11:27] jelmer: yes, there have been several [11:28] lifeless: 1.1 has been the only one so far I think (ignoring rc's) [11:29] jelmer: even so :) [11:29] jelmer: existence proof FTW [11:31] 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] which is not that much of a problem imo [11:32] jelmer: it does cause some friction [11:33] jelmer: you might like to play with my hsallow-branch branch [11:33] jelmer: it works :) [11:34] lifeless: I know, the current situation is not perfect but there are more important issues imho [11:35] 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] lifeless: did you ever get the patch review you were looking for? [11:37] jelmer: http://bazaar.launchpad.net/~lifeless/bzr/shallow-branch/ [11:38] AfC: I have about 10 branches needing revie wnow :) = plane trip -- hacking :> [11:38] I used to get so much done on flights. Now it is a bit more hit and miss. [11:39] I've been making progress on a number of things, though, and that's always a nice feeling. [11:47] AfC: hi, are you up? [11:47] I'm in Londo [11:47] n [11:48] poolie: hey Martin. [11:49] poolie: I hope you had a good trip up. [11:49] < poolie> I'm in Londo <- eww, Babylon 5 character action [11:50] http://en.wikipedia.org/wiki/Londo_Mollari [11:55] awilkins: dude. [11:56] AfC: poolie just had 24 hours sitting next to yours truely :> === AnMaster_ is now known as AnMaster === mrevell is now known as mrevell-lunch [12:12] lifeless: Shallow branching ... that would super-great for bzr-svn :- [12:13] awilkins: try it out [12:13] awilkins: it probably will break with bzr-svn, but jelmer will want patches :> [12:14] in fact, it *will* break with bzr-svn because the current stacking code looks for an exact repository match [12:14] lifeless: Speaking of API compatibility, bzr.dev just broke bzr-svn :-) [12:14] what we need is more generic stacking, which is aseparate refactoring that aaron and John and I have been working on/towards [12:14] jelmer: ok, we should bump the api version then :) [12:14] jelmer: what it did break? [12:15] BzrDir.sprout() now takes a hardlink argument [12:15] jelmer: ah yes; I wonder if it would be nicer to only pass that when its not the default value [12:16] well, even if it would be passed only in some situations it would still be API breakage [12:17] there doesn't appear to be anything in NEWS about this, btw [12:21] Maybe there should be some kind of API breakage monitoring tool :-) [12:22] Are the bzr-eclipse guys in here? [12:22] awilkins: hi :-) [12:23] jelmer: there is hard-link as a feature, but indeed not as a internals change [12:23] 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] awilkins: Oh, great!, I'm working in the client right now :D [12:24] Verterok: I've added some of the commands hidden from the help because they are useful for my current project [12:24] nice! [12:24] 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] awilkins: I'm currently working in passing relative paths (to the branch root) instead of full paths, and adding some tests [12:26] Verterok: I've just added find-merge-base and revisioninfo because they are useful for automating my current stuff [12:27] No tests as yet, I'm too busy just using it :-) [12:27] awilkins: I tried to start the Jepp version, but the distribution requiremnts of that client is quite troublesome [12:27] awilkins: there is always time to write them ;) [12:28] awilkins: I'm hoping the jython guys put a 2.5 aplha out after the PyCon sprint [12:29] awilkins: did you tried using bzr service plugin to improve the performance of spawning multiple bzr commands? [12:29] Verterok: Not yet.. but thanks for the heads up, I shall look at it if performance becomes very bad [12:30] awilkins: are you using the bzrClient outside bzr-eclipse? [12:30] 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] Verterok: Yes, I'm using it for VCS operations in a publishing system (they want very thorough change reports) [12:31] nice :) [12:32] awilkins: that sounds ok for me, in regards of bzr-eclipse it's only matter of a simple refactor [12:32] 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] lifeless: There's only "bzr push --shallow", not "bzr branch --shallow" ? [12:35] 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] awilkins: I think there is no problem of API changes, I'm not aware of any other using the bzrClient [12:36] Verterok: That's good. [12:37] awilkins: maybe a warning in the wiki-page will suffice. [12:40] jelmer: bzr branch --shallow works [12:40] jelmer: go to the master copy not the mirror; the mirror is probably out of date [12:43] awilkins: are you going to implement the RevisionRange class? (so, we don't duplicate work :)) [12:50] Verterok: Yeah, I might do at that :-) [12:51] Verterok: I'll probably make a branch just for that and merge it to my current stuff [12:52] awilkins: Oh, great! thanks! then I'll merge that with trunk :) [13:16] Is anyone else experiencing high Bazaar CPU usage on Windows XP when using the Eclipse plugin? === mrevell-lunch is now known as mrevell [13:30] Prodoc: that should be expected, because bzr-eclipse uses bzr executable under the hood [13:31] Prodoc: this is caused by the calculation of the status to decorate the tree [13:35] Verterok: sorry about that, lost connection [13:35] can high CPU usage (80%+) for a period of sometimes minutes be expected? [13:36] this happens after saving a file [13:37] it's a know issue, this is cause because after each save bzr-eclipse run status to update the decorators [13:38] Prodoc81: sorry, I musst leave for a while [13:39] np, ok, at least it's a know issue, I'll just disbale the decorators for the time being [13:39] ok [13:39] * Verterok bbl [13:39] disable [13:42] hm. but why would 'bzr st' take minutes? [13:42] * awilkins has a feeling it probably runs it once for each file [13:42] oof [13:43] The "Eclipsey" way is probably to have a "FileDecorationListener" that gets called for each file [13:43] bzr-eclipse probably needs a status cache server [13:46] It might work better with the bzr service plugin that Verterok mentioned earlier [13:47] The bulk of the CPU time bzr eats for small operations on win32 is process creation, loading, etc. [13:48] 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. === Prodoc81 is now known as Prodoc [14:14] :( why is git using almost 1.5x the space of bzr for the same sized project.... [14:14] and that's after git-gc. I won't flatter git with the number from before. [14:18] Hello all [14:18] I have a question about something that looks like magic... [14:18] edreamleo: Shoot. :) [14:19] Leo has a trunk at: https://code.launchpad.net/leo-editor/ [14:20] And the comment with the trunk (I didn't write it, an expert did), says... [14:20] To get a copy of this branch, use the command: bzr branch lp:leo-editor [14:21] This works, and creates a new folder called leo-editor [14:21] bzr has support for launchpad URL's [14:21] it's a bundled plugin with bzr that makes lp: stuff look like URL [14:21] Ah, so lp: means launchpad? [14:21] yep [14:21] lp:product-name picks the trunk of that project [14:22] And it's not documented because? [14:22] edreamleo: see bzr help launchpad [14:22] it's often documented but not in an obvious spot ;-) [14:23] I see. Thanks very much. === pmezard_ is now known as pmezard [14:57] who's maintaining trac-bzr these days? [15:03] lp: should really be listed in "bzr help urlspec", because failing to list it implies it's not supported. [15:05] While we're (vaguely) on the subject, there are commands like find-merge-base and revision-info that are very useful [15:05] But not listed in the help [15:05] hello [15:06] (ok, they're useful from a low-level perspective) [15:06] I think I've done something stupid with a repos [15:07] http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated [15:07] I don't manage to 'co' it anymore [15:07] 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] the branch is in dirstate-with-subtree format, which is not compatible with the default format you get after "bzr init-repo" [15:11] ok [15:11] probably converted by older bzr-svn, today you would probably use rich-root-pack or rick-root for that [15:11] hum... [15:11] branching without a shared repository should work fine [15:12] luks: Weird, I get that error with "bzr co" too, even without a shared repo (i.e. making a standalone checkout) [15:12] or create/update the repository with --dirstate-with-subtree [15:12] But I don't get it with "bzr branch" [15:12] oh, branch worked fine for me [15:12] bzr co seems to work fine here [15:13] lukas@nemo:/tmp$ bzr co http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated [15:13] lukas@nemo:/tmp$ cd handle-deprecated/ [15:13] lukas@nemo:/tmp/handle-deprecated$ ls [15:13] basic.tac bin doc LICENSE.txt nevow.cfg pydoctor README.txt server.tac setup.py twisted.cfg www zibasic.tac [15:13] luks: try with bzr+ssh:// rather than http:// [15:13] are you sure you are not in a shared repo? :) [15:13] luks: certain :) [15:14] well, I can't use bzr+ssh on that branch obviously [15:14] luks: why not? [15:14] Permission denied (publickey) [15:15] luks: you can read any branch on launchpad via bzr+ssh://, you just need to give it a public SSH key. [15:15] luks: oh, you haven't got a launchpad account with an SSH key? [15:15] I do [15:15] New bug: #196607 in bzr "Export command improvements (status, speed)" [Undecided,New] https://launchpad.net/bugs/196607 [15:16] but I realized I need to specify username@bazaar.... [15:16] Then you shouldn't be getting "Permission denied (publickey)", that's an authentication error. [15:16] therve: I fear you might be hitting something like https://bugs.edge.launchpad.net/bzr/+bug/173002 [15:16] Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,New] [15:17] therve: although the "bzr co" vs. "bzr branch" part is weird. [15:17] therve: a workaround would be to use sftp:// vs. bzr+ssh:// [15:17] therve: this is definitely a bug in bzr, rather than user error [15:17] therve: please file a bug about this, I need to sleep [15:17] spiv: it looks like 'co http:' and then 'switch bzr+ssh' worked [15:18] but good night [15:18] therve: right, that'd be an equivalent workaround [15:31] Hello all [15:32] This newbie just found another way to crash bzr :-) [15:32] The bug report is at: https://bugs.launchpad.net/bzr/+bug/196618 [15:32] Launchpad bug 196618 in bzr "bzr push lp: crashes" [Undecided,New] [15:33] This all comes of the bzr branch lp:leo-editor magic [15:33] Previously, that is, when checking out from a url, bzr remembered the url, so... [15:33] bzr push "just worked" [15:34] But somehow bzr didn't remember the url when using lp:leo-editor [15:34] So when I tried bzr push I got... [15:34] bzr: ERROR: No push location known or specified. [15:35] In typical newbie fashion, I just tried something :-) [15:35] bzr push lp: [15:35] And got a traceback [15:36] The output from bzr info is given in the bug report. [15:36] As you can see, there is no push bzr+ssh entry in the info output [15:36] it never sets the push location on 'bzr branch' [15:37] edreamleo: bzr push lp: is interesting; its not valid but it would be good if it gave help :) [15:37] So my newbie question is, how do I tell bzr the push location? [15:37] bzr push URL [15:38] URL might be lp:something [15:38] depends where do you want to push it [15:38] So the natural thing would be to create an alias? [15:38] alias? [15:38] why? [15:39] So I can just say bzr push rather than bzr push lp:leo-editor [15:39] it will remember it once you it for the first time [15:39] Ahh... [15:39] *do it [15:39] That's nice. [15:40] or you can use push --remember to change the location [15:40] bzr push lp:leo-editor doesn't work... [15:40] Let me try the real url... [15:41] I think you need bzr launchpad-login or something to make push over lp:XXX work [15:41] New bug: #196618 in bzr "bzr push lp: crashes" [Undecided,New] https://launchpad.net/bugs/196618 [15:47] I think I'm getting close, but... [15:48] I tried this: bzr push bzr+ssh://bazaar.launchpad.net/~edreamleo/leo-editor/trunk [15:48] A connection was started... [15:49] But it said Auth banner: No such Launchpad account: HP_Administrator [15:49] bzr+ssh://@bazaar.launchpad.net/~edreamleo/leo-editor/trunk [15:50] Ah. [15:50] but you will need to setup also the putty ssh agent, if you want to use it on windows [15:50] Lots of false highlights for me here lately :) [15:50] because launchpad only uses SSH key authentification [15:50] But why is the message about HP_adminitrator when bzr whoami give my correct id? [15:50] Yes, I am running pagent [15:51] Let me try the corrected url now... [15:51] edreamleo: it's the ssh transport. ssh defaults to using your current username for remote logins, unless explicitly stated otherwise [15:51] I guess the code that determines the username for ssh is outside of bzr [15:51] edreamleo: and whoami has nothing at all to do with authentication, only what to record as the author of commits [15:51] Thx radix [15:52] The push is cranking away nicely now... [15:52] Clearly, I am the fool that your 'foolproof' code must guard against... [15:53] I'd just blame launchpad :) [15:54] luks: what, because it requires specifying a username? [15:54] luks: unfortunately, adding AI to launchpad has been delayed to version 3.0 :-) [15:55] * radix looks forward to it :) [15:56] radix: it wasn't really serious [15:56] but I still don't like how bzr works with LP [15:56] ok. [15:56] e.g. that bzr push lp:something works differently based on bzr lp-login [15:56] but it doesn't tell you so [15:57] too many options, just using real URLs would be less consfusing [15:57] Wow, the push is really slow. [16:03] Hmm. After getting to step 5/5, the ===== line went away but the xp terminal appears hung. [16:05] just opened another console. bzr status prints nothing, so maybe the bzr push worked... [16:06] edreamle1: "bzr missing " will tell you if the branches are out of sync [16:06] I'm assuming hanging a console isn't the default bzr push 'success' notification :-) [16:06] indeed : [16:06] ) [16:08] drat. Killing the console resulted in the wrong push location being remembered. [16:10] 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]