[00:03] spiv: so am I booking for 3, 4 or 5? [00:04] jml: ping me when you leave home [00:06] lifeless: will do [00:06] if i merge in some changes from the parent branch, and they all come in smoothly and their own commit messages are sufficient to describe the changes, and then i want to commit them to my branch without my own log comments, is there slick/standard way to do this, or must i type "merging in some changes" [00:07] lifeless: good question, just a sec [00:09] johnjosephbachir: Well, I think it's good practice to give a short (one-line) description in the merge commit. [00:09] Okay. [00:11] You can always copy and paste it from one of the revisions you're merging. :D [00:25] lifeless: 5, I think [00:45] I'm getting an error in some qbzr code that I'm working on - that I just can't figgure [00:45] http://pastebin.com/d98bbf0e [00:46] I'm expecting a InvalidRevisionSpec to be raised, but I get the TypeError displayed ing the pastebin [00:47] Please can someone help me out [00:48] garyvdm: TypeError: 'NoSuchRevisionSpec' object is not callable === mario_ is now known as pygi [00:49] garyvdm: you have something called NoSuchRevisionSpec which isn't a class (callable) or function(callable) [00:49] there is errors.NoSuchRevisionSpec - but I'm not calling it [00:50] It's not getting called anywhere [00:50] run with BZR_PDB=1 [00:50] then you can debug [00:50] ok [00:50] export BZR_PDB=1 ? [00:51] or just BZR_PDB=1 ./bzr foo [01:01] lifeless: I just get the same traceback written to the console. [01:01] garyvdm: uhm [01:01] put a pdb import and trace at the point its raised then, perhaps [01:02] ok [01:07] lifeless: fixed :-) [01:07] I had except errors.NoSuchRevisionSpec, errors.InvalidRevisionSpec: [01:08] changed to [01:08] except errors.NoSuchRevisionSpec: [01:08] ... [01:08] except errors.InvalidRevisionSpec: [01:08] ... [01:08] thanks [01:11] hi [01:23] meoblast001: hi [01:23] lifeless: I've started on the process of preparing brisbane-core patches for landing into bzr.dev [01:24] igc: cool [01:24] lifeless: I just want to check how you want it done ... [01:24] igc: theres nearly 800 commits in bbc, I was thinking we might want to just cherrypick bits [01:24] me too [01:24] until the branch has no content [01:24] so my plan is ... [01:24] merge bzr.dev into bbc (done) [01:24] branch bzr.dev xxx [01:24] and iterate [01:24] sure [01:25] lets start with chk_map [01:25] actually [01:25] merge ../brisbane-core/x ../brisbane-core/y ../brisbane-core/z ... [01:25] right [01:25] lets start with the knit changes to support autogenerating the keys from the sha [01:25] 1 [01:25] that will lead into chk_map [01:25] which leads into the inventory changes [01:25] so first patch with be gc + chk as that's all new stuff + some tweaks to setup.py & tests/__init__.py [01:26] knit stuff is knit.py + what else? [01:26] gc and chk are separate things [01:26] I'm not sure you should land them together if you want to be doing specific patches [01:26] ok [01:27] knit stuff is knit.py/weave.py/versionedfiles.py and their tests [01:27] ok, I'll do that one first, then gc, then chk_map [01:28] lifeless: and you can review/approve them :-) [01:29] sure thing [01:30] I'd be inclined to do knit stuff, chk_map, chk_inventory, gc, new-format. With anything not covered by that list as soon as it can be done topologically. [01:46] Peng_: ping [02:05] lifeless: pong [02:05] Peng_: did you send a bundle to the list or just push your branch [02:06] lifeless: Both. [02:06] hmm, I can't see the bundle [02:06] lifeless: Although my email client and/or IMAP server are screwy, so I can't *read* the list. [02:06] I'll merge your branch to another branch fleshing out the config stuff I have [02:06] Oh, really? [02:06] Well, according to the list archive, there's *something* attached to my message. [02:07] hmm [02:07] anyhow, I'll incorporate it :) [02:07] though your pushed branch is missing the test changes [02:07] Oh, really? [02:07] yes [02:07] lifeless: BundleBuggy found it fine. [02:08] lifeless: Oh, LP is, since it won't mirror the branch for a couple more hours. My server has them, though. [02:08] http://bazaar.launchpad.net/~mnordhoff/bzr/fix_get_config_file/revision/4242 [02:08] ah k [02:14] Hey, I think that's the first bug that got assigned to me. :D [02:31] lifeless: hmm, actually, just 4 for dinner; Mary can't make it after all. Sorry about the late notice. I'm still in. [02:32] k [02:33] * lifeless books [03:50] * igc lunch [04:03] spiv: your books are here [04:04] lifeless: funny you should say that, I was just about to head out the door to join them :) [04:04] lifeless: see you soon! [04:40] Is there a reason that stacked branches require access to the stacked-on branch, even for operations that don't involve history prior to the branching? [04:40] For example, I can't commit locally without access to the stacked-on branch. This seems really weird to me. [04:41] I'm wondering if there is a rationale for this, or if it's just something that hasn't been gotten to yet. [04:42] Cessen: stacked branches federate the bzr database; they are not intended for disconnected operation. [04:43] Cessen: We plan to have a thing called'history horizons' which would permit that, but its not in any developers current todo list that I know of [04:44] Cessen: we're bringing in a massive improvement to history size though - a 60% reduction in disk and network utilisation, over the next few releases. [04:44] Cessen: which should make the need for '--stacked' when making local branches a lot less [04:45] lifeless: so are stacked branches mainly intended as an alternative to shared repos, then? [04:45] yes. [04:46] Okay. Thanks. That's where my misunderstaning was, then. [04:46] also for publishing branches, so you don't have to upload a lot of data when giving someone your branch [04:46] as uplinks are usually even smaller than downlinks [04:46] Okay. [04:47] When I read descriptions of it I thought it was like "history horizons" that you mentioned above. So I was very confused when I tested removing the branch I branched from, and then couldn't do anything. [04:47] Cessen: ah yes, I can understand that [04:47] Anyway, thanks for your help. :-) [04:49] I like to abuse bzr for revision control of media files. History horizons would make it viable for collaborative online media projects, too, which would be cool. [04:49] I can always dream. :-) [04:51] I suppose bzr dev is focused more on code vcs, though. Which makes sense. [04:52] we're certainly open for improvements for all history needing projects [04:52] but yes, code is the primary goal :) [04:54] lifeless: thanks very much for your time. :-) === spiv_ is now known as spiv [05:12] I just pulled bzr.dev [05:12] and, erm... I can't seem to be able to pull anything :p [05:13] jfroy: bug 354036? [05:13] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036 [05:13] bzr just errors out with "bzr: ERROR: Not a branch" giving me the path of the cwd. [05:13] Oh, something different :) [05:13] No matter which protocol I give it :p [05:13] spiv: yeah, was trying to do the http pull. [05:14] revno 4241 on bzr.dev [05:14] anyone else seeing something similar? [05:14] Getting something like [05:14] jfroy:Projects bahamut$ bzr pull lp:rivenx [05:14] bzr: ERROR: Not a branch: "/Volumes/Crossroads/bahamut/Documents/Projects/". [05:14] jfroy: things seem normal for me so far [05:15] mmmm [05:15] jfroy: what's the traceback in ~/.bzr.log? (pastebin it) [05:16] http://pastebin.com/dfe6d1a1 [05:17] It makes no sense to me :p [05:18] jfroy: do you mean s/pull/branch/ ? [05:18] jfroy: or is /Volumes/Crossroads/bahamut/Documents/Projects/ meant to be a branch of lp:rivenx already? [05:19] ahhhhhhhhhh [05:19] * jfroy rams head in wall [05:19] :) [05:19] You are, of course, right on. [05:20] http puling is sooooo slow [05:20] well, slower [05:23] OK, the pull worked fine through http. === jfroy is now known as DUUUUUUU === DUUUUUUU is now known as jfroy [06:42] whew. Python PEP 0374 ended up on O'Reilly Radar blog. [07:33] hi all [07:33] Good morning. [07:34] Peng: good morning :) Did your quota get restored ? :-P [07:35] Yes, but then I traded it for some cold pizza. [07:55] hi vila [07:58] lifeless: shall I land the chk_map code into bzr.dev or leave that bit to a proper merge of the main bits? [08:02] Wait. I can get cold pizza just for handing over my quota? [08:10] spiv: can I get a quick review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D59D2E.50500%40internode.on.net%3E [08:11] spiv: vila wrote this code so he could approve it (given I think it's ok) but if you're still around, it will only take a minute or two [08:25] vila: I think spiv and lifeless might be offline for a few hours [08:25] vila: can I request a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D5B919.9090700%40internode.on.net%3E please? [08:26] I'm landing all the trivial, next-to-zero risk stuff out of brisbane and I need a vote to keep pqm busy :-) [09:00] igc: the diff by itself doesn't make much sense, I'm a bit concerned that landing pieces like that screw the annotations badly and will make debugging harder :-/ [09:00] igc... oh wait ! [09:01] igc: may be there is a way to still merge the bbc branch once everything has landed... [09:09] igc: regarding your request above, I approved it, but that doesn't carry much weight, except that I remember having seen that modifications and I'd say they come from at least 3 different sources [09:25] igc: the one that got approved is good to land [09:45] * awilkins is interested in this "cold pizza" that is spoken of [09:48] when I merge from a branch do I need to put a insigniful comment in the commit after the merde ? [09:48] merge [09:55] visik7: was there anything interesting brought in by that merge ? That's what *readers* want to know [09:57] I mean I usually merge instead of update [09:57] 'couse I can see and revert if something goes wrong (usually I forgot at which revision I was) [09:58] but if I would commit I need to put a meaningless message [09:59] nevermind I run a revert and update === LenzGr|dinner is now known as LenzGr [11:04] Hi - I'm moving over from baz to bzr (gradually) and reading a lot about cherry picking changes, and how bzr doesn't support such things as "skip present" and so on, that baz did. I was wondering if there had been any improvements in this area in recent times (the discussions I've found about it are rather old). Ta! [11:07] joie: no improvements, but a bit more discussion recently [11:08] I'm not sure how close anyone is to working on it right now [11:10] I essentially have a situation identical to this one as discussed some time ago "Cherrypicking workflows with bzr": https://lists.ubuntu.com/archives/bazaar/2006q1/007591.html [11:11] So looks like for the forseeable future I'll have to live with more conflicts between branches/trunk, unfortunately. It's not all bad news - bzr is better in lots of other ways, I'll just have to be careful with merging! [11:18] Even if we can't track cherrypicks, one thing that would be really useful is to be able to "pretend" to have merged all the changes from one branch to another - rather like baz sync-tree - do you know if something like this is possible in bzr? Thanks again! [11:23] joie: I'm not familiar with baz, so I don't know what the command does [11:24] in bzr it's possible to merge in all the changes from a branch, without actually making any of the changes [11:24] so that a further merge would not do anything, but your branch content hasn't changed ata ll [11:28] hello [11:28] i have some local commits, how can i push them upstream? [11:28] bzr up shows them as local merges and asks me to commit again [11:28] james_w: that sounds perfect! [11:28] Stavros: if you commit they will be committed upstream as well [11:29] joie: to do that you do the merge and then run "bzr revert ." [11:29] but i have already committed them locally, i just want to push them [11:29] the "." means just revert the tree changes, not the pending merges [11:29] james_w: I'll try that - thanks for the tip! [11:30] if you then run "bzr status" you will see no files changed, but there will be pending merges [11:30] you then commit [11:30] and then try "bzr merge" again and it will say "Nothing to do" [11:30] james_w: is that for me? === LenZGr_ is now known as LenZGr [11:31] Stavros: it's not possible to "just push" as upstream had also done some work, so you had diverged [11:31] james_w: i don't think it had, as i'm the only person working on this [11:31] how can i check? [11:31] ah, then perhaps "bzr up" with local commits and no changes to the master branch does something different to what I expect [11:32] run "bzr log -r -10.." and see what those revisions are [11:32] if they are things that were already there when you did your local commit then I am confused [11:32] there were, all i see is my changes [11:33] i committed revision 50, then 51 locally, and tried to commit 52 upstream [11:33] but now i get odd messages about pending merges and inability to do select-file commits [11:33] I'm pretty sure update with local commits always turns them into pending merges. [11:34] probably, yes [11:34] but what do i do? [11:35] Commit. [11:35] i can't commit, i have pending file changes [11:36] can you stash? [11:36] hmm, yes [11:36] bzr shelve? [11:36] Well, there's not much point in committing if you DON'T have pending file changes ;p [11:37] i have changes i don't want to commit [11:37] i only want to commit a file [11:37] but it doesn't support it, apparently [11:37] Yes, if you have pending merges, you can only commit the whole tree. [11:37] No way to record a partial-tree merge. [11:37] bzr: ERROR: Selected-file commit of merges is not supported yet [11:37] hmm [11:37] okay, i'll shelve then [11:39] why does bzr up do that without asking for any kind of okay ? [11:39] bzr merge requires --force to get you into this sort of mess ... [11:42] I'm not the guy to ask ;p [11:45] hmm [11:46] hmm [11:46] bzr log in a svn workdir is painfull [11:47] at least the initial one [11:55] I do that sort of thing in CVS workdirs sometimes. That's not painful. Just depressing. [12:01] isn't using CVS painful though? [12:02] * SamB remembers CVS getting stuck on his old 56k connection ... having to abort with only half of the files updated ... [12:52] Hey I am trying to revert a branch to exactly how it was at revno 9. I added a whole load of files to do an upgrade, but now want to go back. I did bzr revert and all the files that were versioned have been reverted. Great! But there are a whole load of unknown files when I do bzr st. Can I issue a command to remove all these new unknown files so I am completely back at revno 9 as if I did a checkout? === bac` is now known as bac [12:55] just wondering before I go off an do a long rm session [12:57] abentley: can you poke BB soon please? Seems to be down [12:57] hi igc [12:57] OllieR: bzr clean-tree can do that [12:57] rm $(bzr unknowns) as well [12:58] clean tree is not a core command right? [12:58] only recently === mario_ is now known as pygi [12:59] hi james_w: how was your holiday btw? [12:59] so i will go for the command substitued rm route [12:59] igc: very nice thanks [13:00] your city is very pleasant :-) [13:00] james_w: thanks a lot [13:01] james_w: it is. Did you get to see much outside the city? [13:24] jelmer: sup? does dulwich have a own api for building commits by now? [13:29] hi jelmer, I just wanted to tell you that everything went fine after your last commit [13:29] thanks a lot for the help [13:47] igc: I didn't unfortunately, but I had a very relaxing time. [13:51] ronny: hi [13:51] ronny: You can build and serialize the various objects and add them to a git repo [13:52] ronny: but there's no function yet that you can tell "please go and do a commit in this working tree" yet [13:52] jelmer: but it should just work via bzr's workingtree for now? [13:53] (i want an reasonable way to build in-memory commits in memory) [13:53] ronny: no, bzr's workingtree doesn't work on git indexes yet [13:54] ronny: you can commit in bzr working trees and dpush into git though [13:54] jelmer: i dont need an index, just commit [13:54] ronny: So you need to do in-memory commits? [13:54] well, more something like a commitbuilder [13:55] ronny: and you have a tree in memory that you'd like to commit? [13:56] jelmer: yeah, this is supposed to be a simple backend for a cms/wiki - i want simple support for all dvc's, and no possibility of concurrent fuck up in workdirs [13:57] ronny: so, while we don't have a commit builder it's trivially possible to create one yourself in a few lines of code [13:58] and specific to your problem [13:58] I'm happy to help, but it's hard to comment without looking at the code [13:59] hmm, ok, then i'll just try to do one in anyvc [13:59] bascially build blobs, build trees, build commit [13:59] well, and update refs ^^ [14:07] igc: restarted. [14:09] abentley: thanks [14:27] night all [14:32] ronny: cool [14:38] jelmer: btw, is subvertpy able to do commits without workdir? [14:38] (and is there a simple example ican steal) [14:40] ronny: yes, it can [14:41] ronny: I'll add an example to examples/ [14:44] igc: really gone ? [14:48] jelmer: btw, do you see any way to have the svn log as iterator instead of callback? [14:48] ronny: not really [14:48] ronny: in C it's a callback [14:48] ronny: so the only way to do that is to use threads [14:48] ronny: bzr-svn has a wrapper that does that [14:49] so threads + queue [14:49] sad [14:49] i wonder if greenlets could do [14:50] ronny: yeah, that's a limitation of the svn unfortunately [14:50] SVN *API* I mean [14:50] ronny: I've committed an example of using ra.get_commit_editor() [14:52] ok, looks like a bearable startingpoint [14:53] jelmer: btw, does svn actually have anything to reliable figure branches/tags ? last time i asked the svn people about the actual structure they told me random gibberish about a dag and needing to read the api [14:54] * maxb wonders what it means to "figure branches/tags" [14:56] maxb: well, in svn branches/tags are bascialy copy's [14:56] Indeed. [14:56] so one needs to figure whats a normal copy,and whats a branch/tag [14:56] Well, the only way to do that is by conventions / naming scheme [14:57] ronny: yeah, conventions are the only way [14:57] i know of projects that break them awfully nasty [14:58] Most svn users accept the advised trunk,tags,branches idea, some..... really don't :-) [14:58] ronny: yeah, there's no way around that [14:58] well, i know of people that switched around conventsions various time in the early days of svn [14:58] ronny: bzr-svn looks at the changes in the last 2k revisions and uses that to determine if one of the standard layouts is being used [14:59] that seems to work pretty well [14:59] i'd like to take a look at the usual complete graph of copy's + deletes to see whats up in my absraction [15:47] jelmer: do i understand it right, that editor.close generates the commit? [15:49] ronny: yeah [15:50] any exceptions for remote commits? [15:50] hmm, and i should figure how to deal with workdir status [15:50] ronny: no, just specify a different URL to RemoteAccess() :-) [15:51] jelmer: sorry, bad workding, i mean what exceptions may it throw when i do conflicts [15:51] im preparing for a anyvc sprint over the weekend, parital history view + branches support + creating history [15:52] then later maybe merges and deal with local branches [15:53] since im not going for isomorph mappings, but just access its damn much more easy than bzr's stuff [15:55] ronny: SubversionException [15:55] ronny: is the only class of exception it will raise, with different error numbers [15:58] jelmer: so its bascially just a errno alike? [16:02] fwiw bbc pass the full test suite under python 2.[456] [16:03] ronny: yeah; "pydoc subvertpy" has the most common ones [16:03] ronny: it also includes a (localized) error message [16:10] jelmer: how would i get the workdir status via subvertpy? [16:13] ronny: subvertpy.wc.WorkingCopy [16:14] allows you to open and inspect the working copy [16:15] hmm, looks weird, lets see if i can get it usefull in anyvc [16:55] awesome! I'm in the middle of an editor writing a message for bzr commit, but I can run bzr log in a different window [16:56] I didn't expect I could do that [17:10] hmm, can we use --parallel on the PQM machine ? (-: === kiko is now known as kiko-phone [17:19] jelmer: hmmm, I don't think so :) Did you use it locally ? [17:19] vila: no, I haven't tried it yet [17:20] A lovely side-effect, IMHO, is that traceback for failing or erroring tests is now displayed as soon as it occurs [17:21] unfortunately it's a bug that we should fix :) [17:21] I confess that I'm not very motivated to fix it [17:23] ahh [17:51] vila: Hmm, it looks like lp:testtools doesn't export the right objects; do I need to use something else? [18:04] ah, I was using the wrong branch [18:04] --parallel is pretty quick compared to serial.. === kiko-phone is now known as kiko === kiko is now known as kiko-fud [18:41] Guys! [18:41] I need some help === kiko-fud is now known as kiko [18:41] after having imported from a git (imported from svn, by the way), I ended up with no room in my home [18:42] there I had two directories: git-svn and master [18:42] so I deleted them [18:42] I moved .bzr to another partition, I "packed" the repo [18:42] and now I want to see those two branches [18:42] how can I "rebuild" them? [18:43] antoranz: I'm not sure I understand completely what you mean [18:43] but I think "bzr heads --all" is what you are looking for [18:43] let's see [18:44] I imported from git [18:44] that, ok?, right? [18:44] at the end of the import, I was told I had two branches: git-svn and master [18:44] there were two directories with those names in the sahed repo [18:44] sure [18:44] but I had no room left in the partition [18:45] so I moved .bzr (nothing else) no another partition [18:45] to, I mean [18:45] I packed it [18:45] and now I want to be able to recreate those two branches in the shared repo [18:45] how can I do that? [18:45] just copy them over [18:45] I deleted them [18:45] run "bzr heads --all" [18:46] ok [18:46] and then you should be able to recreate them [18:46] how about just a branch? [18:46] heads is not in the bzr commands [18:47] bzr: ERROR: unknown command "heads" [18:47] I think you need bzrtools [18:49] installing.... [18:50] I can see the last revision (I think). What's next? [18:57] jelmer: ok... so how do i recreate them? [18:58] bzr init trunk [18:58] bzr pull -d trunk -rrevid: [18:58] from the base of the shared repo? [18:58] yeah [18:59] at least I think that's how you do it, I've never done this before [19:00] abentley: I see your patches still use the dirstate-with-subtree format rather than something newer, is that intentional? [19:01] jelmer: No, that's just what they've always used. [19:02] jelmer: doesn't work [19:02] so, I'm going crazy here. I have a specific revision deep down in history, that does a bunch of changes to a bunch of files, that I want to revert [19:02] bzr: ERROR: No pull location known or specified. [19:02] antoranz: perhaps try this: [19:02] antoranz: bzr pull -d trunk -rrevid: trunk [19:03] just in case.. the <> are your remaks or they are necessary? [19:03] antoranz: they're my remarks [19:04] how would I do that? [19:06] ok [19:06] beuno: reverse merge ? [19:06] jelmer: Could not determine revno for {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62} because its ancestry shows a ghost at {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62} [19:06] jelmer, bzr merge -r $oldrevno? [19:07] it says "nothing to do" [19:08] you need $oldrevno..$oldrevno-1 [19:08] or 0..oldrevno? [19:08] hrm, this gets complicated because the revno is burried inside a merge [19:09] we could do with a "parent:" revspec [19:09] james_w: We have one. [19:09] ah [19:09] even better [19:09] james_w: It's "before:" [19:09] so, what do I do? Slash my wrists with a sharpless spoon? :-D [19:10] one that also allowed you to select which parent would be peachy, but that covers 99% of cases, thanks [19:10] so: bzr merge -r:before:..7578 ? [19:10] bzr merge -r 7578..before:7578 [19:11] beuno: "bzr merge -r:before:7578..7578 ." Remember the . [19:11] won't that try and make the same changes again? [19:11] bzr: ERROR: No namespace registered for string: u':before:7578' [19:12] beuno: Sorry, should be "bzr merge -r 7578..before:7578 ." [19:12] new error! [19:12] bzr: ERROR: No namespace registered for string: u':7578' [19:13] beuno: Are you sure you didn't put an extra colon? [19:14] beuno@dell-desktop:~/canonical/lp-branches/blueprints_kill_portlet$ bzr merge -r:7578..before:7578 . [19:14] ah [19:14] antoranz: probably easiest to redo the import [19:14] * beuno hides [19:14] oh, man... don't say that... not even playing. :-) [19:14] abentley, jelmer, james_w, thanks [19:15]