[01:22] hi all [01:22] is there a Python bazaar module that I can use to check out code? [01:24] jono: import bzrlib. Aside from some build code and about 20 lines in the "bzr" executable, that's the entirety of bzr. [01:26] Peng so I can use it to check out code? [01:27] jono: I don't know what exactly you mean by "check out code", but probably. [01:28] Peng bzr branch lp:foo [01:29] peng are there docs anywhere for it [01:29] ? [01:29] ahaha found them [01:30] jono: That should be easy enough to do, but I honestly do not know how. You could check out bzrlib/builtins.py:cmd_branch to see how "bzr branch" does it, or maybe the docs give an example. [01:30] ok cool [01:30] I want to add an example to Acire :) [01:31] subprocess.call(['bzr', 'branch', 'lp:foo']) is cheating, right? ;D [01:31] (Sorry, I shouldn't encourage that.) [01:32] haha [01:32] that *is* cheating [01:32] :) [01:37] Peng any idea what the full qualified path of a branch on LP is? [01:37] remote_branch = Branch.open("lp:python-snippets") [01:37] does not work [01:39] Your code should ask the directory service, which I also do not know how to do. [01:43] s/should/might have to/ [01:43] can anyone else help me figure this out? [01:43] thanks Peng [01:43] * Peng inserts several *shrug*s [01:43] lol [01:44] lifeless, surely you must know :) [01:44] you are an expect among these parts :) [01:53] He's gone. :< [04:36] hey #bzr, can I revert/remove a specific commit from the history? [04:37] (a bad merge) [04:38] You can revert the changes it made -- "bzr merge . -r 50..49" or so -- but you can't remove the revision from history. [04:39] Well, if it's the most recent revision, you can use "bzr revert -r -2", or even "bzr uncommit" to remove it from history. (But the latter would be a pain for users if you've already pushed it.) [04:39] yeah -- it's already got commits on top of it [04:39] :( [04:39] best is to revert. I didn't know you could do a range backwards! [04:41] Peng: what exactly are the revnos I should pick for that example? [04:41] I want to get rid of revno 88, retaining 89 and 90 [04:42] chromakode: Should be 88..87, but try it and see. [04:42] You can always "bzr revert" if it goes horribly wrong. [04:43] neato! [04:44] Er, "revert -r-2" wouldn't remove anything from history... [04:45] he was saying uncommit would remove it from the history [04:45] I suppose you'd commit back the following 2 commits [04:45] this looks good. thanks. [04:46] Yeah, that was worded a bit badly. [04:47] Peng: so, if the revnos are in reversed order, it treats the diff in reverse? [04:47] that's really cool [04:50] Right. :D [04:50] hmm. it's giving me a lot of conflicts. [04:51] is there any way to tell it "use the merge-tree version!"? [04:52] "bzr resolve" can do it, at least if you're using a very recent version of bzr.dev. [04:53] checked there :( [04:53] Um, it shouldn't conflict too badly, unless, well, a lot of conflicting changes have been made since. [04:54] urgh. [04:55] yes. they have. to every header file [04:55] * chromakode slaps his teammates [09:49] If I'm using a lightweight checkout with a treeless repository, is there some way to store uncommitted changes before I switch, like switch-pipe does? Should I just shelve? [09:49] shelve should work. Whether unshelve will work well... [09:50] I'd guess it probably should, at least as well as e.g. an update across that pair of revs with local changes. [09:53] Hm, so the shelf is stored in the checkout. I seeeeee. [09:53] * wgrant checks how pipeline does it. [09:53] Yeah, shelf is WT-local. [09:54] Ah, it uses shelf but directs it to the branch. Hmm. [10:12] wgrant: bzr shelve; bzr switch; bzr unshelve - will work fine. [10:12] wgrant: as the checkout is constant in the environment you described [10:14] lifeless: Right, but is there a way to store uncommitted changes in the branch? [10:15] no [10:16] commit them to a new branch [10:16] or to a tag [10:16] or something [10:16] why though? [10:19] I thought I'd try lightweight checkouts, since Launchpad trees are huge and slow, and it seems to work well with pipeline. [10:23] sure [10:23] that doesn't answer the question [10:24] why do you need to stash the change, not commit it, and tie it to the branch [10:29] lifeless: I might have realised half-way through a change that it needs a change in a some other branch. [10:29] Although I guess that's more covered by the pipeline case. [10:29] wgrant: sure; shelve; switch; make change; commit; switch back; merge; commit; unshelve. [10:30] lifeless: I guess. It's just a bit different from the great workflow that pipeline gives. [10:30] wgrant: sure; you're working with the primitives. [10:30] wgrant: what I *don't* get is how that is different [10:31] as in, I don't see where the changes are stashed affecting your use case [10:32] I sort of like attaching the changes to their branch. [10:32] Makes it easy to keep track of them. [10:32] If they're attached to the branch I can be lazy and shelve without a message. [10:33] You can always commit them and uncommit them later. Unless you forget, of course. [10:33] True. [10:34] wgrant: changes to the core to make it better sought after [10:35] personally, in my pending dir I shelve everything to one space, no comments, and I don't get more or less confused [10:35] wgrant: we could though, when shelving default to attaching the nick as a comment [10:35] what do you think? [10:35] lifeless: That might be handy. [10:36] file a bug [10:36] Also, last time I tried this shelve didn't let me get a diff. It might be more usable now that it does. [10:51] Is there a repo: or similar branch alias? [10:51] what would that mean [10:51] hi, is there an example somewhere of how to use post_change_branch_tip [10:52] sure, theres a few plugins around now that use it [10:52] lifeless: It would be an alias for the repo of the current branch, so I could say bzr switch repo:somebranch [10:52] wgrant: just say 'bzr switch somebranch' [10:52] wgrant: it will dtrt [10:52] i.e. http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html?highlight=post_change_branch_tip [10:52] lifeless: ...oh. That is nice. [10:53] links to http://doc.bazaar-vcs.org/en/plugin-guide [10:53] which gives 404 [10:54] j^: hmm, not sure about that [10:54] anyhow [10:56] j^: http://doc.bazaar.canonical.com/plugins/en/ works [10:57] still confused about how post_change_branch_tip works [10:58] http://github.com/djmitche/buildbot/blob/06ce8e7e79b2ffa1a301ac45c7155899d6a0e6da/contrib/bzr_buildbot.py has an example of it [10:58] j^: the bzr-email plugin has an example of using it, see http://bazaar.launchpad.net/~bzr/bzr-email/trunk/annotate/head%3A/__init__.py#L106 [10:58] j^: but what are you confused about in particulalr [10:58] spiv: google for the hook name, its interesting on the 2nd and later pagers [11:00] i have a server where several people push changes to, i want to run a command on the server each time someone pushes new versions, post_change_branch_tip seamed to be the right hook, can not make out how to enable it on the server though [11:00] j^: install it on the server [11:00] e.g. if you have a setup.py, run setup.py so as to install it into bzrlib/plugins/ wherever that is in your python path [11:03] j^: as lifeless says, install the plugin with the hook on the server (and install it system-wide, so that it will be loaded by any user that runs 'bzr'), and make sure people push using the smart server (e.g. bzr+ssh, not sftp). [11:03] * spiv wanders off [11:16] hmm [11:16] I was sure I had writted a diff hook [11:28] spiv: I would love news_merge to use ReST parser [11:28] spiv: my other NEWS files use alternative section markers === j^ is now known as bot0x === bot0x is now known as j^ === salgado is now known as salgado-afk [12:40] spiv: lp:bzr-commitfromnews [12:40] was the darcs 2.4 release announcement just cross-posted to the bazaar and git lists? === jelmer__ is now known as jelmer [12:41] moin lifeless, spiv [12:41] lifeless: Happy birthday! [12:41] jelmer: thanks ;) [12:44] lifeless, will commitfromnews also use --fixes ? [12:44] jelmer: It wasn't cross-posted. The mails were just re-arranged after it was sent, allowing it to appear on any list that's convenient :p === radoe_ is now known as radoe === radoe_ is now known as radoe [20:13] and moin [21:03] jelmer: hi [21:03] lifeless: hello [21:03] jelmer: I'd like it to do --fixes automatically, haven't looked at what is needed yet. [21:04] jelmer: I filed a bug when I registered the project saying this; if you wanted to fixit :) [21:04] lifeless: Ah, sorry [21:04] lifeless: it works well, btw [21:05] thanks for publishing it [21:05] my pleasure [21:06] I'm trying to be a bit rougher on development friction [21:08] what do you mean with development friction? [21:10] I haven't heard friction being used in this context, only as something that exists between people. [21:13] I mean between me and machine [21:13] and me and tools [21:13] http://en.wikipedia.org/wiki/Friction [21:14] effort put into writing code = F [21:14] things that sap that effort and make it get less work done = Ff [21:15] I *think* the concept of interpersonal friction comes from the analogy between anger and heat [21:16] as the energy friction bleeds off is heat [21:18] lifeless: Ah, thanks. [21:23] jelmer: if you'd like to add fixes support that would be awesome [21:23] lifeless: I might have a look at that when I have a moment to spare. [21:24] :P [21:24] I'll probably look at it when I need to use a fixes clause [21:24] I just haven't so far [21:24] having --fixes might actually save me quite some time [21:25] I have a svn repository, with lots of legacy branches that are merged to trunk, but there's no metadata to say so. (Before svnmerge, or 1.5 merge tracking, and not svk). Is manually mangling in some bzr-svn bzr:merge revprops a neat trick or a terrible shoot-self-in-foot idea? [21:25] I usually forget to specify --fixes, then I uncommit, look up the bug number in NEWS and recommit with --fixes [21:25] jelmer: so, when I forget I ignore it ;P [21:25] jelmer: but you might want to just fix the process next time - to make time on the basis that you'll save time :> [21:25] heh [21:26] maxb: It's a good way to shoot yourself in the foot.. [21:26] hmm. It seemed so tempting [21:26] Anything in particular I'm liable to break? [21:26] maxb: if you're sure there are no branches out there that were created from that svn repo using bzr-svn you could attempt it [21:27] I can ensure that [21:27] maxb: the revids from bzr-svn are deterministic [21:27] which is indeed a great thing about it [21:27] maxb: so if anyone else, ever, runs bzr-svn, they wouldn't be able to merge with you [21:28] Presumably, yes, they will, if I've munged the svn repo before anyone ever bzr-svn's it [21:28] maxb: or perhaps it is 'if anyone else ever has, ...' [21:28] right [21:31] It's a company repository, and freshly cvs2svn-ed, so I can state confidently that there are no prior bzr-svn-ifications in the wild [21:32] maxb: ah, should indeed be possible in that case. [21:33] Unfortunately I couldn't sell a direct cvs2bzr to the powers that be :-) [21:33] maxb: please note that bzr-svn doesn't interpret svn:merge [21:33] oh. that's unfortunate. I may have to have a go at hacking on that, then [21:34] Presumably there's no reason why it couldn't, just no one's written the code? [21:35] Oh, except I'd be glibly ignoring subtree mergeinfo [21:36] maxb: There is a reason, bzr doesn't support tracking cherrypicks [21:37] maxb: So you have to do analysis of the svn:mergeinfo data to see if *all* revisions for a particular path are merged before you can add the last revision in svn:mergeinfo for that path as a parent [21:38] tricky, but doable [21:38] maxb: Expensive, performance-wise. [21:38] It also requires a mapping format change. [21:39] personally I'd rather see somebody investigate the possibility of tracking cherrypicks, even if we don't start doing smart things with that data yet. [21:41] Even if you did track cherrypicks, you'd still want to resolve them into full-ancestry merges when that was the actual case [21:41] yes, but that logic would be in bazaar, not bzr-svn [21:41] true [21:42] (.. and bzr-hg and bzr-git) [21:42] hg and git track cherrypicks ? [21:43] git does at least, on a revision level [21:43] whoa, I completely missed that [21:43] it does it (at least optionally) by simply putting the sha of the cherrypicked commit in the newly created commit [21:44] I'm not sure if it actually uses it do improve merge quality [21:44] AFAIK it doesn't [21:46] I think my next step is to spend some more time poring over bzr-svn's guts [21:55] I wish lp mailed me back saying 'your bug might be a dup, look at XYZ' [21:55] * lifeless files bugs [21:58] lifeless: Yes, me too. [21:59] maxb: tbh, I don't think that sort of analysis would belong in the default bzr-svn mapping. [22:00] maxb: I don't want to discourage you, but I think I should mention that upfront. [22:04] jelmer: It's a fair comment. It might be desirable only for people using bzr-svn for a onetime migration away from svn [22:05] maxb: it's also only a temporary solution, since it we would need another mapping change (and an upgrade path) when proper cherrypicking support in bzrlib would be added [22:12] The mapping issue is a hard one, but I'm already contemplating using a custom-hacked bzr-svn to migrate some slightly screwy history out of svn anyway [22:13] (The problem there is tags which don't show up in bzr because they were made from a mixed-revision working copy, so bzr-svn treats them as branches) [22:16] I guess I'll need to make sure I also change the revision-id generation so that they are different to what an unhacked bzr-svn expects [22:17] jelmer: bug 529227 bug 529226 [22:17] Launchpad bug 529227 in launchpad "wishlist: show candidate dups on all bugs / provide a way to scan for duplicates of a bug" [Undecided,New] https://launchpad.net/bugs/529227 [22:17] Launchpad bug 529226 in launchpad "wishlist: tell me about dupes when I file-by-email" [Undecided,New] https://launchpad.net/bugs/529226 [22:18] maxb: You can just create a new mapping format [22:18] maxb: That should change the revid as well [22:18] maxb: actually, you should be able to just use a vanilla bzr-svn plugin and provide your own plugin that registers a new mapping format that does what you need. [22:19] interesting. It's clear that I need to spend some more time learning about the internals :-) [22:22] can someone tell me what this python error means? bazaar quit working today at noon and returns this on every invocation. http://pastebin.com/wpgG4hsX [22:24] Demosthenes, I have no idea what that error is, but you are using a very old version of bzr [22:24] lenny standard [22:29] Demosthenes: I'm guessing it means that a .pyc file has been corrupted [22:30] i'm checking files now [22:30] I'd start wondering about the health of your hard disk :-( [22:31] I'd also strongly recommend upgrading bzr if you use it regularly. Debian stable is far too stable for an active project like Bazaar [22:32] lifeless: Thanks, subscribing [22:32] Presumably /usr/lib/python2.5/socket.pyc [22:32] maxb: i'm seriously concerned myself, as i haven't made changes in a bit... [22:32] i'm running a compare against my last backup for /usr [22:54] eww i'm having some files i'd never change not match...