[01:11] morning all [01:13] hello igc1 [01:14] igc1, maybe we could do a blog post together about news in explorer some time? === igc1 is now known as igc [01:15] hi poolie [01:16] poolie: that would be good. I'm pretty close to calling it 1.0beta fwiw [01:18] igc: re the 'evaluation' thread, how about if i make init warn you when it's making a standalone repository? [01:18] or maybe even fail, would that be too harsh? [01:18] i guess init and branch would need to do this [01:19] I believe init-repo reports the format of what it made today. [01:19] making init do the same wouldn't be horrible; and you could fold that in reasonably tastefully I suspect [01:20] poolie: I'm yet to see that email sorry. Ask me again later today :-) [01:42] np [02:04] poolie: another example of the project-priority != dev priority mismatch: for doc folk, sorting some doc bugs to high and low may be very useful, even if for the project all doc bugs are low. [02:04] poolie: I'm starting to think personal[inc teams]-annotation of bugs would be a really useful feature. [02:04] mm [02:04] yes [02:05] e.g. the launchpad-bazaar folk could annotate the bugs they care about as critical etc; bzr devs could choose to see that, or ignore it. [02:05] yes i see [02:06] it would give you the 'I care about this bug' thing you like to do too. mmm could perhaps trial by having the doc team tag with doc-high, doc-low etc [02:57] * igc lunch [03:14] time to pickup my passport [03:15] :) [03:50] Is the diff utility that is called by qdiff specific to bzr? It's an excellent tool, and I'd love to use it elsewhere besides bzr repos. [03:52] distatica: to be precise, it's part of the qbzr plugin for bzr. [03:52] Yeah, that's what I'm thinking.. is there any way to run it on it's own? [03:53] distatica: I haven't looked closely at the source, but it's probably not too hard to take that part and make a standalone program of it. [03:53] What language is that stuff written in? do you know? [03:53] distatica: although for non-bzr diffing I'd probably use an existing graphical diff tool like meld. [03:53] The part i would probably be working with. [03:53] distatica: Python [03:53] oh, then I have a hope in hell. :) [03:54] never tried meld, will check it out. So far the best tool I have used is the qbzr one. [03:54] distatica: basically all of bzr and its plugins are Python. (There are some optional C and Pyrex extensions for speed, but you wouldn't need to touch those for this.) [03:55] I had heard that it was python, but wasn't sure. I'm glad for that, Python is a good language. [03:55] meld looks pretty good too, thanks [03:58] spiv: Ooo. Ta! meld is *nice*. been using kompare myself, meld looks that little bit better. ta x 2. [03:59] spm: heh :) [04:00] the big win was the in each line highlight of the differences. some of our changes in configs can have (not pointing fingers at PQM, much) horrible regexs. and picking up the diff can be... hard. :-) [04:00] Pretty decent, I don't know if it's quite up to the qbzr version, but it's good anyways. [04:29] Hi, how I can count the added/removed lines between 2 commits? [04:30] “bzr diff -r$OLD..$NEW | diffstat” would work. [04:33] RAOF: thanks, works perfect! [05:16] spiv, igc, lifeless, hi [05:16] (and anyone else) can you please test installation of bzr from karmic-proposed [05:16] if it works ok, please comment on https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626 [05:17] Launchpad bug 437626 in bzr "[sru] exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,Fix committed] [05:28] poolie: done [05:36] thanks [05:58] spiv, excuse my bad memory, but did you do something generic about hiding exceptions during cleanup [05:58] and if so what? [05:58] i'd like to use it in bug 423015 [05:58] Launchpad bug 423015 in bzr-svn "svn-import raises KeyError on large repository" [Undecided,New] https://launchpad.net/bugs/423015 [05:58] poolie: see the bzrlib.cleanup module [05:59] thanks [05:59] poolie: also either one of my unreviewed merge proposals ;) [05:59] :) [05:59] * spiv -> afk for 10 minutes [06:46] I created my branches in a shared repository, but now I'm into another problem; I have branches for [company].[module] and [company].clients.[whatever], but I really need a basic one for just [company] so I can put my __init__.py file in there - can I do that without causing trouble determining which branch things belong to? [06:51] ChrisMorgan: sure [06:52] How about if I create a new file in one of the subdirectories which has its own branch - will it show up as 'unknown' in the parent branch? [06:53] It's saying 'unknown' for the sub-branches... ignore? [07:03] igc: I really wish you could explain how heavyweight checkouts != bound branches - it confuses the hell out of me when you say that [07:03] ChrisMorgan: up to you [07:03] Or can I do something with join/split stuff? [07:04] I'm confused :-) [07:04] ChrisMorgan: what are you trying to do [07:05] I have a parent directory squiggle. There is a repository in it. There are lots of branches in subdirectories, squiggle/foo, squiggle/bar, etc. There would be no need to have a branch in squiggle, except for the fact that Python requires a file __init__.py... so I need another branch in squiggle. [07:05] However, bzr status squiggle then goes not knowning about foo and bar [07:06] Upps, got to go now, I'll stay in the room though if you can help me? :-) [07:06] if foo and bar are branches bzr st shouldn't mention them. [07:06] are you sure they are branches? [07:06] you might try pastebinnning the command + output. [07:08] lifeless: well I did try to explain the differences in https://lists.ubuntu.com/archives/bazaar/2010q1/065891.html [07:12] spiv: big one approved [07:12] poolie: thanks! [07:13] poolie, lifeless, vila: wrt my disable plugin patch, should I remove support for an explicit path and just support 'disable' (or '') for disabling them? [07:13] igc: I would be happiest if you just did disable for now [07:14] vila and I can try to get what poolie is concerned about in strasbourg [07:14] (phone) [07:15] lifeless: so the feature you and vila are working on will miss 2.1? [07:15] igc: I'm a) sick, and b) working on dx-team stuff, and then lca and then strassbourg [07:16] lifeless: I really don't need the path stuff but my patch might be a stop gap until your stuff lands? [07:16] lifeless: but I personally only care about disabled vs otherwise [07:16] igc: I know that your path stuff won't help any of the use cases I've seen for automated stuff in this area [07:16] igc: so I'm not sure who it would be stop-gapping for [07:17] lifeless: only someone with a plugin both system installed and locally installed - picking the former over the latter [07:20] * vila needs to bring his car to the garage and will be afk for ~1 hour [07:22] igc: but regarding plugin stuff, as said in my mail, 1) using config vars is not a good idea, 2) using PZR_PLUGIN_PATH to disable is not trivial and I'm not working on it right now [07:26] igc, i don't have any strong objection to being able to set the path there [07:26] i'll look at the patch again [07:27] spiv, how about just always logging cleanup failures? [07:27] oh [07:27] nm, i misread it [07:28] poolie: vila and I have concerns though. Can we land igcs disable-only version of the patch ? [07:30] does that exist now? [07:30] i think vila's final comments in https://code.edge.launchpad.net/~ian-clatworthy/bzr/411413-plugin-disable/+merge/16719 are reasonable [07:30] however incremental improvements are also good [07:30] igc has implied that it did in the past or is at least trivial to get to. [07:32] poolie, lifeless: I don't have a version yet that does disable only. It's a one line code change I suspect. [07:33] poolie, lifeless: tweaks the doc changes in my patch is the larger part if that's the direction to go [07:33] tweaking [07:34] poolie: quick call? [07:34] poolie, lifeless: the broader Q was a conceptual one: should I 'remove' functionality from the patch given there's no alternative likely soon? [07:35] wrt specifying an explicit plugin when multiple are installed [07:35] lifeless: yep, they're branches alright, but with no commits yet - should I commit to them? [07:37] lifeless: sure [07:38] lifeless: bzr init-repo foo, bzr init foo/bar, bzr init foo, bzr st foo: unknown: bar/ [07:39] Commit an unchanged revision to foo/bar and st foo still shows unknown bar [07:44] I also tried the split / join --reference stuff as at http://wiki.bazaar.canonical.com/NestedTreesDesign#creating-a-nested-tree and I'm still getting the unknown status on bar [07:45] ChrisMorgan: don't touch split/join [07:45] ChrisMorgan: its not production ready [07:45] OK, I was just testing it as that was what was detailed in the page. [07:45] I figured it wasn't ready seeing as it didn't work :P [07:47] ChrisMorgan: you probably want to do bzr ignore ./bar [07:48] OK then. Or I could resort my structure... thinking about it more I don't need the clients stuff in the main branch... I'm not going to want to be able to `import myproj.clients.whatever`... [07:48] So I think I'll actually separate it one level more in the repository. [07:48] Thanks. [07:49] Uh... can I "uninit"? [07:49] poolie, vila, lifeless: I've replied to vila's comment on my patch now [07:50] I've run init-repo and init in the same directory, can I go back to just the repo rather than the branch as well, or should I just scrap all my .bzr directories and start clean again? [08:09] ChrisMorgan: if you delete .bzr/branch and .bzr/checkout then you'll have what bzr init-repo created [08:19] * vila back [08:26] * igc dinner [08:28] hello all [08:28] igc is here? [08:32] 19:26 * igc dinner [08:32] 19:28 -!- bialix [n=chatzill@163-106-113-92.pool.ukrtel.net] has joined #bzr [08:32] thanks lifeless, and hi [08:34] hi :) [09:40] hiya, I have a repo (my thesis) where I started some work (library bindings) which I now want to split out into a standalone branch. But I don't want the intial commits to the thesis files to show up in the bindings' history [09:40] the commits look like that: 1..3 thesis, 4.. bindings [09:41] so in essence I want to remove commits 1..3 from the history [09:41] what's the best way to do that? [09:41] the changes are textually independent, and all bindings work happened in a subdir I bzr split out [09:55] fast-import-filter [10:08] bialix: thanks, lemme try that [10:15] lifeless: thanks, I got my repository and branches all set up properly again... I think I'm happy with it this time and think it'll do all that I want :-) (Though if I could version the contents of a SQLite, MySQL or PostgreSQL database with Bazaar I'd be even happier...) [10:15] bialix: that worked fine, cheers [10:31] ChrisMorgan: bzr can do it; doesn't make it a good idea :) [10:31] How can it do it? [10:31] bzr add foo.db; bzr commit. [10:31] The /contents/ of the database... not the database! [10:32] sqlite foo.db dump > foo.dump; bzr add foo.dump; bzr commit [10:33] Still not automatic :-) [10:33] I suppose SQLite can have hooks... I wonder what that would really do to performance. [10:33] Ghastly idea, isn't it :D [10:37] ChrisMorgan: that's why people invented backups [10:37] do a periodic snapshot and version that [10:37] I know... it really would simplify my task though if I could use Bazaar to version the contents of a database... [10:37] Ah well, I'll sort it out somehow :-) [10:48] ChrisMorgan: you could make a hook that took a snapshot before commits, but it'd presumably make commits slow [10:50] Problem is it's the other way round I want it - someone does something on the website (something that matters, i.e. in the admin section) and it goes and exports that and commits to bzr, and a way then to do the converse with pulling, take a diff and apply it somehow to the database. [10:50] I think I'm dreaming a rather far-fetched dream. I think I'll have to be satisfied with django-reversion at the moment. [10:50] ChrisMorgan: in this case, what you really want is a full-fledged plugin [10:50] Something like that. [10:51] A way to version the contents of a database. [10:51] Clearly every table being versioned would need to have a primary key. [10:53] How hard do you think it'd be? [10:54] Do you think it'd be reasonable and possible? [10:54] I imagine I'd need to learn a lot about Bazaar first. For the moment I think I'll get on with other facets of my product. [11:02] I'm sure it would be fascinating to do. I'll see if I ever get to it :-) [11:02] Goodnight now. === mrevell is now known as mrevell-lunch [13:16] ok, I know this is easy, but I can't seem to find it. I branched from a machine on my LAN, but now I want it to pull from lp:bzr. How do I change the parent branch? [13:17] pull --remember [13:18] cool, thanks. I knew it was something rediculously easy === mrevell-lunch is now known as mrevell [15:11] Hi kids. Using the 2.01 Mac package from the website, fresh install, I try to bzr branch or init and score "bzr: ERROR: '/Volumes/Data' is not a working copy [15:11] So what went wrong? [15:11] Ick, the most recent revision of bzr.dev caused conflicts with 2.0. [15:12] It was labelled as "stable". [15:12] fullermd: ping [15:14] squeeky: Pend refers to the dev version, not related to your problem, can you pastebin your $HOME/.bzr.log ? [15:14] any pastebin of choice? [15:14] !paste [15:14] For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [15:16] http://ubuntu.pastebin.com/m5a8c668e [15:18] What the hell, pastebin.com? Why not paste.ubuntu.com? [15:18] I should empasise that /Volumes/Data is the working parent directory to the one I was trying to bzr init/branch [15:19] squeeky: I suspect you have an .svn directory sitting somewhere. [15:19] squeeky: ls /Volumes/Data/.svn and /Volumes/data/whatever/.svn [15:19] What does this have to do with the price of tea in china? [15:20] squeeky: bzr-svn [15:20] ummm, okay, wasn't using that. Can't bzr just not pay attention to .svn folders in a parent? [15:20] How else would it know you were in a svn checkout, though? [15:20] squeeky: You are using bzr-svn. [15:21] bzr implements a prettymuch-complete frontend to working on svn checkouts/WCs/etc... [15:21] what [15:21] so... it's a piggyback scm? [15:21] No... [15:21] bzr has its own native formats of course. [15:21] It -can- use svn -as well- [15:21] You can use the bzr command as a frontend to a number of different repository/wc formats, including svn, git,... [15:22] Since you have the bzr-svn plugin loaded, it's looking for .svn directories, in case you're trying to use it on a svn checkout [15:22] ugh. [15:22] I find it very useful... Being able to bzr log10 in a svn checkout, or bzr shelve it [15:22] It actually makes svn almost useable [15:23] I generally don't mix scm's. But whatever, it's fixed now, thanks Peng. [15:23] If you're not wanting to use the bzr-svn stuff.. then.. uh.. just don't load the bzr-svn plugin :) [15:23] Heh.. we have a bizarre mix of cvs/svn/bzr at work.. I like not needing to remember which command is which. I just type "bzr whatever".. and it all works out [15:24] meh, it's fossil for internals, git for stuff that tentatively gets public OS release, svn/cvs/bzr for patching other people's stuff. [15:45] I find it pretty annoying when bzr-svn kicks in when I'm not actually in a svn wc [15:46] It would be better if it didn't search up for .svn, since .svn doesn't require that === weigon__ is now known as weigon === beuno is now known as beuno-lunch [17:38] vila: Hmmwhat? I didn't do it, I swear. [17:49] abentley: are you around? [17:49] I'm trying to sort out bug #494269 [17:49] Launchpad bug 494269 in bzr "tree transform cannot change root id" [Medium,Confirmed] https://launchpad.net/bugs/494269 [17:49] And trying to understand what TT should be doing [17:50] I *think* it should be allowing the tree root to be added, but at apply time it should verify that there is only one [17:51] (the delta I'm looking at shows the new root added at the beginning, then all paths are renamed into that new location, then the old one is removed.) === deryck is now known as deryck[lunch] === kfogel is now known as kfogel-lunch === beuno-lunch is now known as beuno [18:36] hey there [18:36] say I have a tree that contains as a subdirectory a copy of bzr [18:36] is there a way of updating that subdirectory to a more recent version of bzr and retaining some commit history information? [18:37] a copy of the bzr source IYSWIM [18:37] that question doesn't make sense to me [18:37] kiko: so you have a tree, such that in one subdir you also have a version of the bzr source [18:37] how it updating bzr in conflict with retaining history? [18:37] Could you elucidate "retaining some commit history information" ? [18:37] is that correct? [18:37] luks, let me trivialize it [18:38] if you used stuff like "bzr merge-into" [18:38] to create it [18:38] launchpad contains a subdirectory called lp-buildd [18:38] then in the future you should be able to "bzr merge $BZR" [18:38] and it should mostly JustWork [18:38] lp-buildd is actually managed as a separate branch [18:38] by lamont [18:38] (lp:bzr-merge-into, btw) [18:39] can I merge the changes in lp-buildd into the launchpad tree [18:39] with bzr-merge-into? [18:39] kiko: I assume you want to bring the lp-buildd code into the launchpad codebase in a subdir [18:39] I think you're asking the other way around from what merge-info is for. [18:39] bzr-merge-into should do a decent job of that, IIRC [18:39] IIUC, yes if they already share ancestry. Otherwise, an initial delete and re-merge would be required. [18:39] If you are trying to split it out [18:40] jam: they don't share any history [18:40] then you can split it out and play tricks with 'bzr add --file-ids-from" [18:40] kiko: unfortunately, *today*, without the same file ids, we can't link up the changes [18:40] gotcha [18:42] jam: I believe that was one of the things my proposed changes to nested trees fixed. [18:43] jam: I agree that TreeTransform should delay tree shape sanity checking until the transform has been completely specified. [18:44] I get the following bug: bzr: ERROR: exceptions.AttributeError: 'tuple' object has no attribute 'encode' [18:44] any idea? [18:44] jam: I would do that in find_conflicts [18:44] C-S: any backtrace? [18:44] C-S: Something is getting a tuple that is expecting a string [18:44] yes there is quite some backtrace, can I post it somewhere? [18:44] !paste [18:44] For posting multi-line texts into the channel, please use http://ubuntu.pastebin.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [18:46] jam: http://ubuntu.pastebin.com/d7752a537 [18:46] ubottu: thank you [18:46] You're welcome! But keep in mind I'm just a bot ;-) [18:47] jam: see fixup_new_roots in transform.py in http://bazaar.launchpad.net/~abentley/bzr/nested-trees [18:48] abentley: thanks for the pointer === deryck[lunch] is now known as deryck [18:56] jam: any ideas? [18:58] C-S: can you paste "bzr status" before the commit? [18:59] I'm wondering if it might have something to do with a symlink, et [18:59] etc [19:00] jam: http://ubuntu.pastebin.com/d125d8417 [19:00] jam: or with Umlauts in file names? [19:12] jam: I now deleted all .bzr directories and restarted. [19:12] jam: Even after adding one .tex file it crashes [19:27] C-S: what does "bzr plugins" list? [19:29] jam: http://ubuntu.pastebin.com/d5abcf59f [19:32] C-S: you could try "bzr commit --no-plugins" but that doesn't seem to be it [19:32] certainly this doesn't seem to happen to me, since I've been committing without probs for a long time [19:34] jam: that gives a different error: [19:35] jam: bzr: ERROR: No repository present: "file:///..." [19:35] C-S: so are you in a subdirectory of a git repo? [19:36] jam: hmm let me check [19:36] (I don't know that bzr-git implements proper commit [19:36] commit-to-git support) [19:38] jam: this was it! It works again after deleting the .git folder in the main directory. [19:38] jam: it would be could to give a nice bug report [19:39] C-S: so I think this is a bug in bzr-git, you can mention something about 'commit in git working dir fails', and include the traceback [19:40] I'm guessing that the GitCommitBuilder.record_iter_changes is working differently than we think it should [19:40] either that or GitTree.iter_changes() is working differently [19:41] what is weird is that it seems to be a mix of WorkingTree4 (which is a bzr regular tree) [19:41] so I don't really understand why it was confused [19:41] C-S: steps to reproduce would also be appreciated [19:47] jam: I'll file the bug. Thanks again. [19:57] Is there any way to hook bzr to discover all branch modifications? Such as might be needed to implement an automatic backup system? [19:58] In particular, I want to know about operations that don't change the tip of a branch - e.g. tags [20:13] abentley: are pipelines meant to provide a similar functionality to git rebase's patch reshaping, or is that different? [20:14] mathrick: No, they're meant to be an alternative to rebasing. For similar functionality, see bzr-rewrite. [20:14] jam, btw, you could provide the licensing information for bzr-merge-into.. ;-) [20:15] abentley: oh, I didn't see rewrite on the plugins page [20:16] kiko: __init__.py clearly states GPLv2, but I can add a COPYING.txt if it makes you feel better [20:16] abentley: but pipes can still result in retroactive history changes, right? [20:16] jam, no, I meant on launchpad :) [20:16] ah [20:16] how does that play together with published branches? [20:16] mathrick: bzr-rewrite was formerly called rebase, and that name is still used on the plugin page. [20:17] mathrick: pipes cannot result in retroactive history changes. [20:17] kiko: done [20:17] not entirely sure why it matters [20:18] abentley: so what's the result of adding a patch to an earlier pipe and pumping it? [20:18] mathrick: It's as though you did a merge and commit in the later pipe. [20:18] oh [20:19] so it'll be visible to someone reading patches? [20:20] abentley: the tests I can find in transform are about moving a root directory, I'm trying to test adding a new one and removing the old one completely [20:21] abentley: does this look valid: http://paste.ubuntu.com/355157/ [20:21] (It currently fails trying to rename the cwd, but I want to know that I'm on the right track first) [20:22] jam: That looks like a reasonable change. You're probably right that we haven't tried to handle that directly in the TT before. I'm pair programming at the moment. === kfogel-lunch is now known as kfogel [20:23] abentley: sure, I don't mean to bother you too much, but I don't really know how the TT code is supposed to hang together everywhere [20:24] abentley: I'm very interested in a tool that'd let me reshape changes logically for reviewers, but I sort of can't see how pipelines help with that if they're basically merges [20:25] (also, take your time if you're busy right now, it's not urgent) [20:31] mathrick: you may want to look at http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html [20:31] which doesn't explicitly use pipelines [20:32] though you could do something like that for the individual branches [20:33] jam: yeah, I don't want to lose the history if possible, but I'd like to be able to submit a logical view of the end result. Lemme just read through that [20:33] mathrick: it is how I did it, at least [20:33] basically, you could use threads/pipelines for each of the new branches created [20:34] however in *my* case, I wanted a DAG of branches, not a simple stack [20:34] loom was unusable for that scenario [20:34] though probably not critical [20:34] since the threads stack in the wrong direction [20:34] both pipelines and loom think in terms of a stack [20:34] though you can "up-thread; bzr revert" [20:34] or use "bzr switch" to change threads without merging [20:35] mathrick: wrong direction? [20:35] hmm, I might be mixing up two different scenarios [20:36] jam: I know I hit that at least once, when I wanted to keep a change that wouldn't get pushed upstream when merging, but which'd sit on top of other changes (ie. editing config files to match your local dev setup without touching the deployed config) [20:37] that doesn't work, because of how changes flow through the loom [20:37] IIRC, there were also similar issues when you tried to use looms for reshaping, but I'd have to rethink that from first princinples again, I'll read your post first [20:48] help question: when I run the command $ bzr branch lp:valo-cd [20:49] I get the error:Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.) [20:49] Server does not understand Bazaar network protocol 2, reconnecting. (Upgrade the server to avoid this.) [20:49] bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n" [20:49] otto_sange, hi [20:49] one guy at #launchpad suggested I'd ask here. Maybe it is a locale problem. [20:50] What is your local bzr version? [20:50] My system: plain Ubuntu 9.10, fresh bzr installation from main, clean conf, python 2.6 [20:50] Bzr version 2.0.0 [20:50] system locale Finnish [20:51] otto_sange: I can't reproduce the problem here - what is your locale set to? [20:51] LANG=fi_FI.UTF-8 to be specific [20:52] otto_sange: It seems to work fine with that locale as well [20:52] although the locale thing is just a guess. I'd expect there would be more about this on Google if all Finnish users suffered from it.. [20:53] Any other ideas? [20:53] running -v does not give any extra info [20:53] otto_sange: I'm out of ideas at the moment, but spiv might have more ideas - I think he should be around soon. [20:53] spiv: ^ [20:55] jelmer: About those bzr-svn "inconsistent details in skipped record" warnings - I had a look at what the code was actually comparing and it seems to be complaining about one side of the comparison being a tuple, the other a list. Does that mean anything to you? [20:57] maxb: We've had problems with that in the past as well [20:57] maxb: I guess bzr is a bit more strict now in various places [20:57] maxb: I'm happy to see bzr-svn adjusted to use whatever bzr uses [20:58] I should stick a "raise" in there and see where it explodes, I guess [20:59] On another matter, I don't suppose you have any magical debugging tips for figuring out why bzr-svn would go into an infinite loop trying to detect svn tags on a particular repo? [20:59] private, unfortunately [21:01] jelmer: I need to get some sleep now. If anybody comes up with ideas, drop me a line at otto (a) sange.fi so that I could start contributing to a Launchpad project some day... Thanks! [21:02] jam, hi, shall we chat? [21:02] sure poolie [21:02] otto_sange: Will do [21:02] maxb: -Dtransport is usually quite helpful [21:03] I'll give it a go [21:03] maxb: Also, SIGQUIT is your friend. [21:03] ah [21:03] jelmer: I think the check needs to be less strict. We can hit that internally as well [21:03] some apis return [] for parent_ids, some return () [21:03] both should be allowed [21:03] I don't know how I've triggered it before, but I most certainly have, without bzr-svn [21:04] jam: Most things seem to rely on tuples, e.g. knits will bail out if you try to add the same text twice with the parents as a list [21:04] ooi, what are the strings containing four numbers? --> ('21277 252 0 333', ((),)) ('76755 252 0 333', ([],)) [21:05] Indeed, it looks like the tuples are the "existing" and the lists the "new" in my case [21:14] Drat, missed otto_sange. [21:15] spiv: do you know? [21:15] spiv: I was talking to him on #launchpad [21:15] spiv: he did leave an email address :) [21:18] thumper: yeah, just sending mail now [21:18] thumper: but no, it's a mystery to me. [21:18] :( [21:21] Is there a document with a typical/recommended layout for working with a shared repository, multiple branches, and a lightweight checkout? [21:22] maxb: I don't think there is a document for that, but I'd say you could do this: [21:22] ./shared_repo/ [21:23] /branches/ [21:23] /branch_a/ [21:23] /branch_b/ [21:23] /lw_co/ [21:23] just an idea [21:27] I'll practice a bit :-) [21:49] rubbs, maxb: probably more common is ./repo/branch_{a,b,...} for the branches, and ./work (outside the repo) for the checkout. [21:49] I do [21:49] rubbs, maxb: that said, it'll just as well either way. [21:49] ah, that's a good point [21:49] ./project/branches [21:49] s/it'll/it'll work/ [21:49] ./project/working [21:49] ah... a good point, it had not occurred to me that it could be outside. [21:50] e.g. bzr/trunk, bzr/foo bzr/bar bzr/working [21:50] and working is a lw checkout of e.g. trunk [22:03] okay, so empirically, it seems that pipelines work sorta backwards if you want to use them to reshape changes: earlier pipes in the pipeline will have the logical view, whereas the last one will have the original changes [22:15] abentley: the way the code is written, if you add a new root but do *not* delete the old root, things still work (fixup_new_roots always removes the old root if there are any new ones.) [22:15] should I add a check that self._new_root in self._removed_content ? === mkanat_ is now known as mkanat [22:18] * mkanat is working on the final touches of the CVS->bzr migration for upstream Bugzilla, for the next few days. [22:19] jam: hmm, interesting post that, but what does submit: really mean in those branches? [22:19] more generally, how can I find out what branch is submit: for the given tree? [22:19] mathrick: Are you talking about the blog post? [22:19] yep [22:20] At *this* point, I would make submit: be the dev branch, and use launchpad's "this change depends on this other branch" [22:20] at the time I did that code [22:20] that feature was not present [22:20] mwhudson: Going to start on the loggerhead stuff today! :-) [22:20] jam: æh, I don't understand what you're talking about :) [22:20] mathrick: the submit branch is always 'trunk' [22:20] IMO [22:20] mkanat: woo [22:21] it just happens that one branch depends on another landing to get a nice diff of the changes [22:21]