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