=== saullawl is now known as david8732 === david8732 is now known as saullawl [02:58] new to bzr and have a few questions [02:59] anyone there? [03:00] uhh [03:00] I can try to help, lol [03:00] very basic questions [03:00] Alright, shoot [03:00] :) [03:01] I'm running lamp but want want to run Bazaar Explore for Mac, can I connect via ssh to my server? [03:02] It should be possible [03:03] So long as Bazaar Explore is an X11 app on the mac [03:03] You'd have to set up X11 forwarding on the SSH server and the SSH daemon. [03:03] lost me, sorry what's x11 [03:03] RyNy_: Why do you want to connect to the server? Is the branch there? [03:03] Xorg [03:04] Yes, I'm using bzr to version control an install of LAMP running drupal [03:06] RyNy_: In Bazaar Explorer, try checking out a path like bzr+ssh://user@server/path/to/branch [03:07] wgrant: my LAMP install is on AWS EC2 and uses a private key. Does Bazaar Explorer support ssh + private keys? [03:08] RyNy_: It relies on Bazaar, which relies on your operating system's SSH stack. [03:09] wgrant: sounds like it's possible then? Is there any documentation for my needs? [03:10] RyNy_: http://wiki.bazaar.canonical.com/Bzr_and_SSH [03:11] wgrant: cool. Let me try. Much appreciated! [03:12] wgrant: do I need to have both Bazaar and Bazaar Explorer installed on both my server (LAMP) and my desktop (Mac)? [03:14] RyNy_: You need Bazaar on both ends, but Bazaar Explorer need only be on the desktop. [03:15] wgrant: thanks again [03:35] stuck here. trying to install QBzr but the help doc is rather vague: http://wiki.bazaar.canonical.com/QBzr [03:37] Am I missing something on this page? There's the source tarball and a universal Windows installer. No Mac installer. [03:42] If i want to acces the 'bzr info' and 'bzr status' of a repo from a python script, should i import bzr libs and call them, or is a system() call going to wokr just as well? [03:42] something tells me its a silly question. oh well [04:16] Kamping_Kaiser: Why not import bzrlib? That's surely going to be easier. [04:25] wgrant: thats what i suspected, thanks. [04:27] Kamping_Kaiser: they provide different interfaces; using the lib should be pretty easy. [04:28] oh right. I'll go and have a look at what goodies bzrlib can do. thanks both :) [06:12] annotate is lieing to me. [06:18] you started it [06:19] :( [08:58] wgrant: how so? [09:47] lifeless: In lp:~wgrant/launchpad/sprb-new-model-columns, annotate says that lib/lp/soyuz/model/sourcepackagerecipedata.py:130 was added by me in r8911. But the 8910->8911 diff doesn't show that. [10:26] aieeee [10:27] ran out of disk space and bzr dropped my commit message on the floor [10:27] subversion would've at least left a svn-commit.tmp lying around [10:27] * mgedmin hates being forced to re-type things [13:10] hey [13:14] Hello all... [13:44] who wrote update -r ? [13:44] I don't really get it [13:48] What's not to get? [13:48] Err, does that sound rude? [13:48] It's for updating to a particular revision instead of the tip. [13:49] yeah, but normally update performs a merge... [13:49] so when you specify a revision, I expect it to merge with that revision [13:49] and merging with something in your own history shouldnt have any effect [13:49] :p [13:50] But that wouldn't be useful, so it doesn't do that. :P [13:50] that's not really a reason... [13:51] it doen't feel like it should be part of the update command [13:51] I don't feel like thinking about merging, but it probably makes sense. :P [13:51] what you'd want is pull . --local -r 1 --overwrite [13:51] merging with something in your own history should have an effect, afaict. [13:51] it should? [13:51] yeah, I think you want pull. [13:51] what if I make a change, decide it's stupid, and want to commit a new revision with the change reverted? [13:52] bzr revert? [13:52] then again, it's not like I use update often. [13:52] oh, not [13:53] and I can't think of a use case for update -r off the top of my head at all. [13:53] what do you guys use for working with several people with a central repository? [13:53] just merge & push? [13:58] gerard_: That's what I use, but it's not a super-busy project. [13:59] what I dislike from the merge & push is that the merge should have it's parents swapped somehow [13:59] because you otherwise have to summarize other peoples changes [13:59] also, i like to be able to review all the changes I'm going to commit [14:00] Wait, how does it prevent you from reviewing changes? [14:01] hmm [14:01] well, if you only want to have one branch on your own computer [14:02] you'd have to merge the new changes from the master into your own, and then push [14:02] so you'll see then changes the other people made [14:02] the* [14:02] and when you commit & push you mess up the history [14:03] it won't be as nicely linear with sidetracks [14:18] gerard_: Yeah...you shouldn't do that. [14:21] for a pretty history I suspect it's preferable to merge your own changes into a separate "trunk" branch than vice versa. [14:22] you *can* do crisscross merging like you're suggesting but the resulting history tree won't be quite as pretty. [14:25] in fact update does what I like it to do [14:26] the only problem is the double merge bug, and the fact that update; revert will lose all local changes [14:27] I spotted another duplicate for that bug #113809 btw [14:27] Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809 [14:28] yeah, I'll keep spamming that until it's fixed ;) === khmarbaise_ is now known as khmarbaise [15:22] hi, I have a user with hardy and making a branch says: bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n' [15:22] how to fix it? [15:27] shakaran: What version of bzr is the user running? [15:27] shakaran: If it's something really old (in this case, pre-1.6), the user could install a more recent version from the PPA, https://launchpad.net/~bzr/+archive/ppa [15:32] the user says that it have: Bazaar (bzr) 1.3.1 [15:33] I send the ppa, I am waiting his answer [15:36] *yawn* [16:07] Peng: yep, it works for the user. Thanks [17:14] Hey mwhudson. [17:23] the Bazaar site seems to be unreachable, do you guys know that? [17:30] okay, and now it works again :P [18:04] Hi all [18:05] when I want push I got this error: [18:05] zr: ERROR: Cannot lock LockDir(lp-64863248:///~alamati/opencd/opencd/.bzr/branchlock): Transport operation not possible: readonly transport [18:05] can you help me? [18:05] what do I do? [18:06] alamati: It's an svn import. It's read-only. [18:06] ya, its svn import, [18:06] what do i do? [18:07] I switch from SF to launchpad [18:07] What are you trying to do? Do you want your revisions to wind up in https://opencd-fa.svn.sourceforge.net/svnroot/opencd-fa? Are you gong to get rid of the svn repo, and want the Launchpad branch to be the main location? [18:08] alamati: You can push to another location on Launchpad. [18:10] I want to wind up my project in SF, I want to continue developing in launchpad, I imported it to launchpad [18:10] peng: where I push? what mean another location? [18:11] Wherever. lp:~alamati/opencd/pengismyhero or whatever you want. [18:12] you mean that I enter this command: [18:12] bzr push lp:~alamati/opencd/ [18:12] ? [18:13] No. [18:13] Well, almost. [18:13] bzr push lp:~alamati/opencd/something [18:14] what is something? [18:14] Whatever you want. [18:14] So I must create new branch in launchpad? [18:14] That's what I'm suggesting. [18:15] It's possible there are other options, like turning the import into a regular branch, but I don't know how, and this is easy. [18:15] You could even rename the other branch out of the way and then give the new one the same name. [18:16] alamati@ThinkPad:~/opencd$ bzr push lp:~alamati/opencd/OpenCD [18:16] Using default stacking branch /~alamati/opencd/opencd at lp-64863248:///~alamati/opencd [18:16] Created new stacked branch referring to /~alamati/opencd/opencd. [18:16] Is this true? [18:18] Yes? [18:19] It's not lying. :P [18:19] :D [18:20] The new branch will probably catch on fire if you rename or, worse, delete lp:~alamati/opencd/opencd. [18:20] If it's just a rename, it might not break, and it's fixable. If it's a delete, ehh, hope you've got another copy of the data. [18:21] I dunno if Launchpad prevents you from doing dangerous things or fixes them. [18:22] this was my first push, after this any one can obtain new revisions? [18:23] alamati: What do you mean? Anyone can obtain a copy of it, yes. [18:23] alamati: You can even set it as the development focus branch so "lp:opencd" will redirect to it instead of hte old branch. [18:23] alamati: Although people who already have a copy will need to "bzr pull --remember lp:opencd". [18:25] Oh, where is my new rev? there are not in changes http://bazaar.launchpad.net/%7Ealamati/opencd/opencd/changes. why? [18:26] alamati: Because that's not where you pushed. [18:26] alamati: http://bazaar.launchpad.net/%7Ealamati/opencd/OpenCD/changes [18:26] I confused [18:27] I tend to cause that, yes. [18:27] really thanks, dear peng, but how I can merge this two branches? [18:28] I don't know. [18:28] hummm [19:21] Is there a way to change branch options like append-revisions-only on remote branches? [19:22] mkanat: hitchhiker [19:22] :/ [19:22] hitchhiker? [19:23] mkanat: abentley's thing that allows you to poke around at the vfs layer [19:23] Oh ugh. [19:23] It's like a basic sftp client, only for bzr's vfs. [19:23] There's no method in the API to change append-revisions-only? [19:23] s/the API/bzrlib/? [19:24] oh i guess you can use .set_config_option or something [19:28] Oh, hitchhiker is actually pretty cool! :-) [19:29] Indeed. :D [19:30] This is particularly handy because I can't get a prompt on this server. [19:33] mwhudson: Did you see my questions on the memory leak bug? [19:34] mkanat: not sure i saw the most recent ones [19:35] reconfigure should do this to [19:35] patches needed ;P [19:36] Yeah, just a generic --set-option or something for reconfigure would be nice. [19:38] Is there a way to differentiate a "bzr up" from a "bzr co" or "bzr push" in pre_change_branch_tip? [19:39] Maybe I should just use pre_commit instead. [19:44] mkanat: what are you trying to do [19:44] lifeless: I'm trying to make sure that on the server, when somebody commits a change, the "committer" is always set to the logged-in SSH user. [19:44] an no, pre_change_branch_tip doesn't know about user level operations like up/co/push [19:44] mkanat: pre_change_branch_tip is what you need for that [19:45] lifeless: Yeah, the problem is that if somebody tries to do "bzr up" on the server itself, it fails. [19:45] mkanat: so, perhaps 'don't do that' ? [19:45] lifeless: Yeah, that's possible. The problem was actually updating the plugin itself on the server. :-) [19:45] mkanat: I generally suggest plugins look for a config option to enable them [19:46] Yeah. [19:46] I was considering that as a possibility, too. [19:46] or you could look at the branch path [19:46] Oh, that's a good idea, if it's going to stay just a mozilla.org plugin. [19:46] it will get userspace-chrooted but you can map to the local path [20:35] oh, I found the bug entry. I can't figure out how to configure authorization for smartserver because smartserver has no auth mechanisms. [20:35] that explains it. [20:49] Is there an easy way to change a commit message a few revisions back? I started working with redmine and if I say bug "#n" it will mark it, but if I leave off the hash mark ('#'), it doesn't. I accidentally left it off a few revs back. It's not a big deal, but it would be nice to have it look right. [20:50] EdWyse_Mobile: No. [20:50] There are ways, but not very easy, and it would change the ID of the revision and its descendants. [20:52] Ok, thanks. [20:54] I know I could just make diffs for each rev, uncommit to the one before the one I want to change, check out, patch, commit... Way too much work for aesthetics. [20:54] Yeah...it's possible to automate it more, but that's basically the end result. [21:12] Made a nice little bzr-to-cvs sync script here, if anybody ever wants it: http://bzr.mozilla.org/bzr-plugins/bzr-to-cvs/files