=== davidstrauss_ is now known as davidstrauss [01:05] james_w: whats the plugins/builder symlink for in 'lp:bzr-builder' [01:06] tests [01:06] see the top of __init__.py [01:07] that seems awfully complex [01:07] why not just 'bzr selftest builder' [01:07] because the directory you are in may not be in bzr's plugin path [01:07] oh right [01:08] I really need to get back to that [01:08] sigh. ETIME> === davidstrauss_ is now known as davidstrauss [01:34] james_w: still up? [01:35] james_w: for daily debs, how do you manage uploading to each ppa suite? [01:35] If you find him, please ask him about uploading the updated qbzr too. [01:35] ScottK: to debian or ubuntu? [01:36] Debian has a maintenance team, and we're always happy for more uploaders :) JFDI :) [01:36] lifeless: Ubuntu, AFAIK it's not in Debian (although it ought to be) [01:36] ScottK: any reason you can't just upload it then? [Ubuntu] [01:36] lifeless: It's not packaged and I'm not familiar with the package. [01:37] oh, thats surprising [01:37] is there a bug ? [01:37] * ScottK is just looking at the OMG, Kittens bugs being thrown at motu-release. [01:37] Yes. [01:38] lifeless: 455051 is the bug asking for the upgrade [01:38] Hi ScottK [01:38] lifeless: 447214 is the reason it's important [01:38] Hi garyvdm [01:39] bug 455051 [01:39] Launchpad bug 455051 in qbzr "Update qbzr to 0.14.4" [Undecided,New] https://launchpad.net/bugs/455051 [01:39] bug 447214 [01:39] Launchpad bug 447214 in qbzr/trunk "Segmentation fault during startup" [Critical,Fix released] https://launchpad.net/bugs/447214 [01:40] ScottK: so it is packaged, just needs an update? [01:40] lifeless: Yes. [01:40] james_w TIL, but it's fair game for anyone that wants it. [01:41] ScottK: it should be straight forward [01:41] debcheckout etc [01:41] lifeless: I would guess so, but I've got about 7 other things on my personal list that would come first. [01:41] I doubt I'll get to it today, was sick for a week, so backlogged [01:41] Yuck. Hope you're feeling better. [01:42] over the hump [01:42] not well yet [01:45] Good luck. [01:45] * ScottK is off to put kids to bed. [02:40] * igc doctor appointment & lunch - bbl === oubiwann_ is now known as oubiwann === davidstrauss__ is now known as davidstrauss === timchen1` is now known as nasloc__ === _Jill_ is now known as Nephyrin [04:23] jelmer: btw i tried bzr-svn on pypy again and got this: [04:23] bzr: ERROR: exceptions.AssertionError: Tried registering as parent while already was parent for [04:25] looks like https://bugs.edge.launchpad.net/bzr-svn/+bug/343382, which is fix released though [04:25] Launchpad bug 343382 in bzr-svn "svn-import fails: “Tried registering %r as parent while %r already was parent for %r”" [High,Fix released] [04:32] james_w: how do you tie bzr-builder <-> PPA's. === davidstrauss__ is now known as davidstrauss [04:48] lifeless: I'm writing a command to run bzrlib.upgrade.upgrade on all the branches in a project on Launchpad, like you suggested a few days ago. [04:49] lifeless: Can I just get a list of branches and upgrade them all in whatever order I get them, or do I need to upgrade the stacked-on branch first (or last)...? [04:49] I guess I could try it on staging.lp.net and see what happens... [04:51] jkakar: the order shouldn't matter [04:52] lifeless: Awesome, thanks. === mwhudson_ is now known as mwhudson [05:37] bbiab [07:48] hi all [08:18] hello all [09:00] hi all. can someone look at http://pastebin.ca/1629067 ? Its bzr exploding after trying to branch a bzr repo thats been moved. I ntoe an svn error on oline 2, and wondering if its involved [09:31] Kamping_Kaiser: you have very old bzr-svn plugin [09:31] maybe your bug was already fixed [09:31] any reason why you don't upgrade? [09:32] bialix: I've just installed this (debian-stable based) distro. Hadn't thought to find updated bzr repos [09:33] bzr v.1.5 is almost 1.5 years old [09:33] blink. the websites changed. [09:34] i'll have a look for the updated version, thanks. [09:36] * igc dinner [10:23] mwhudson: There's an open bug about that error, I havent had time to look into it yet. [10:42] jelmer: oh, i only found a closed one [10:42] nm for now === JaredWigmore is now known as JaredW [12:42] hello [12:44] ask [12:45] is there a guide to bzr-git? Something that describe how to contribute to a project that uses git using bzr-git? [12:45] bialix: sometimes I just say hallo and idle :) [12:46] gioele: I don't jnow any guide [12:46] gioele: I don't know is there any guide [12:46] but you can use guide for bzr-svn to get idea how to work with foreign branches [12:47] and of course you can try to ping jelmer who is one of main authors of bzr-git for specific questions [12:48] so, basically you need to get HEAD of git repo locally, then branch from it to work and commit, then either send patch to core devs or use merge+dpush command to push your patch into git repo [12:48] it's a basic workflow as I know [12:53] bialix: but I fear that dpush is not working with bzr-git (the site states that push is not supported, I think this includes dpush) [12:55] no, push and dpush is two different beasts [12:55] dpush works [12:55] (it's significantly simpler to implement) [12:56] hi luks [13:01] hi === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === thunderstruck is now known as gnomefreak === fenris__ is now known as ejat === thunderstruck is now known as gnomefreak [15:41] morning vila, I hope you had a good weekend [15:41] jam: pretty good thanks, I hope yours was fine too and good morning ! [15:42] jam: any ID what a DuplicateID conflict is ? [15:42] vila: offhand I would say it is trying to create 2 paths with the same file-id [15:43] The doc string says: two files want the same file_id but the code creates the conflict with trans_ids instead... [15:43] How can you create two paths with the same file_id ? [15:43] If the two paths comes from different branches with the same file_id.... I hope it's a rename... [15:45] ...but that they are indeed referring to the *same* file [15:46] vila: I don't know the internals of how to get there, but something like telling TreeTransform.add(path, file_id) 2 times would probably trigger it [15:46] jam: that would be a bug to me, not something the user may encounter [15:47] vila: I think you are tracking down something that was generated via bugs [15:47] however, we have it (apparently)... [15:47] generally any given tree should only have a file-id 1 time [15:47] if that isn't true, there is a bug [15:47] hmm, ok, punting for now then :-/ [15:47] dirstate can certainly hold multiple file-ids accidentally [15:48] Inventory cannot, since it uses a dict of file_id => entry [15:48] CHKInventory similarly keys off of file_id so can't really have that [15:48] though I suppose if InventoryDirectory pointed to children that weren't in the _by_id dict, you could have trouble... [15:53] jam: I can see it occurring under weird nested trees configs... with files trying to cross the nest boundary, but I'm not going to think more about it for now [15:53] vila: no prob, though I'm wondering what made you ask in the first place [15:54] jam: working on resolve --interactive and writing tests for each kind of conflict, I came across that one and was wondering if it was legitimate or not (which is always harder than recognizing a known pattern :) [15:55] jam: also, it's not documented in conflicts.txt unlike the orther ones... [15:55] ah, k [15:56] hi [15:56] can i merge changes by file? [15:58] moldy: you *can* do 'bzr merge ../branch/single/file' [15:58] however, it shows up as a 'cherrypick' and thus isn't recorded as a 'full merge'. [16:15] jelmer: are you around? I'm trying to figure out if we need a new bzr-svn for the 2.1.0* series. [16:20] jam: sounds ok, thank you [16:25] hello jam [16:25] hi bialix [16:26] Gary and me prefer to have qbzr 0.15 bundled into both windows installers, pretty please [16:27] jam: hi [16:27] jam: I haven't seen any particular changes that would require a new release [16:28] jelmer: we bumped 'api_minimum_version' wouldn't that be an issue? [16:28] bialix: I thought 0.14.4 was the stable release? [16:29] we certainly can, but I'd like to be conservative if possible [16:29] jam: ah, hadn't seen that [16:30] jam: yes, 0.14.4 is stable and fine for bzr 2.0.1 [16:30] jam: but qbzr 0.15 uses new improvements from 2.1.0b1 [16:30] sure [16:30] jam: if you prefer to bundle different versions in different installers it's ok [16:30] jam: because I've built and uploaded windows installer for 0.15 [16:31] so in the end your choice will be final one [16:32] but AIUI, Gary want to see 0.15 in 2.1.0b1 [16:33] * bialix hopes Gary on vacations somewhere near warm sea or ocean, because he appears in i-net very sporadically [16:34] bialix: well, he is in South Africa, and as I understand it, his internet connection is pretty spotty. I know he's ran into issues with upload caps, etc. [16:34] I forget what he said exactly, but something like. "For large downloads, it is cheaper to fly to AU, download, and then fly back." [16:35] in his last e-mail he wrote: Sorry - computer access is a bit of a problem for me at the moment (I feel like I'm in the dark ages....) I'm currently borrowing someone laptop (luckily I had previously installed ubuntu for this person...) Once again - sorry for my inactivity. [16:36] Can PQM run on windows ? [16:36] I dunno what it means exactly but it seems he's away from his personal computer [16:36] vila: I dunno [16:36] bialix: thanks [16:36] Any other ? [16:38] last time I've heard it's non-trivial to install and setup it even on Linux, so I have big doubts that anybody managed to run it on Windows [16:39] Nothing "really" works on Windows. [16:40] scary [17:06] vila: I would guess that it can, as it is written in python. I'm not sure about the setup difficulties as bialix mentioned. [17:07] However, I think it is configured to "run this command", which should be pretty platform agnostic [17:07] jam, bialix: thanks, nothing urgent, I just wanted some feeling [17:07] I would guess you'd run into problem with "C:\Program Files\Foo\foo.exe" having a space in it versus wanting to run "make check" [17:08] (arg parsing versus executable path is often an issue on Windows) [17:08] and needs explicit support, etc. [17:20] is there any gitk equivalent in bzr? [17:20] what's gitk do? :) [17:20] abgalphabet: 'bzr qlog' [17:20] or 'bzr viz' [17:20] ah. [17:20] dash: gitk is actually the adaptation of 'bzr viz' if I remember the timelines correctly [17:20] heh [17:21] qlog is now nicer, IMO [17:21] i tried bzr viz or bzr vis..it's quite good [17:21] but it doesn't show relationship btn branches [17:21] qlog? [17:22] bzr qlog? [17:22] So. I've got a project in a bzr branch, and a separate project that chose to copy the contents of the working tree at some revision into its branch. both projects have made a lot of changes to the once-shared code. [17:23] abgalphabet: you need to supply multiple branches, or the base of a shared repo, iirc [17:23] 'bzr qlog' is from the qbzr plugin === beuno is now known as beuno-lunch [17:23] I'm trying to undo this and merge both variants. [17:23] i tried bzr vis branch1 branch2. but it only show branch2 [17:25] I'm wondering if there's a better way than shuttling diffs back and forth; some way to replay the revisions from the second project into the first? [17:25] oh. it actually shows in the message/text description. but not visually intuitvie than gitk [17:26] how to use the bzr to interact with cvs? [17:27] gitk cvsimport seems working in synchronize changes in cvs into the git mirror by git cvsimport [17:32] sooo.. 'bzr server' has no password protection? [17:32] any ideas in bzr cvs workflow? === deryck is now known as deryck[lunch] [17:43] vila: how about another 200MB memory savings? https://code.edge.launchpad.net/~jameinel/bzr/2.1-peak-mem-tweak/+merge/13582 [17:43] I'm still not at 50% though... :( [17:44] jam: that's already very good news, don't be too hard with yourself :) [17:44] * fullermd wonders what the chances are vila will say "No thanks"... [17:45] vila: my biggest concern right now is the 'dark memory'.... I haven't figured out how I'm going to find that yet [17:45] Be all like, "No, sorry, thanks, but now I have too much memory to run bzr..." [17:45] finding the zlib stuff was a fluke [17:45] fullermd: well he does have a 16GB machine :) [17:45] 12GB.... don't exagerate [17:45] Oh, really? Hm. You get his arms, I'll go for the kneecaps... [17:45] vila: you went cheap on me... :) [17:46] anyway, I've set myself a goal of getting to 2:1 memory size for 2.1.0b2, so I'm trying hard to get there [17:47] * fullermd hopes you mean "1:2" ;> [17:47] hmm, fullermd will tell you that it will not work for 2.2.... [17:47] fullermd: old:new [17:47] Pfft, ruin all my fun, why doncha... [17:48] . o 0 (Why did I have to give "him" credit for a joke I found myself.... See how grateful "he" is now...) [17:54] is there any future planning for password protected smart server over bzr-protocol? [17:55] Milo-: In the vague sense that "someday we should". [17:56] It punts on AAA pretty much completely now. [17:57] last time I used sftp for centralized repo purposes, bzr messed up all permissions in the repo for some reason [17:57] and friend can't connect using bzr+ssh, his windows fails for some reason. [17:57] Milo-: you could try ClueBzrServer [17:58] heh [18:00] * Tak commit ChangeLog in the conservatory, with the candlestick [18:02] jam: I'm about to EOD so I won't review your patch today (just so you don't wait for me) === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno === abentley is now known as abentley-lunch [18:51] Hmm [18:51] is there a way to exclude files from the current view? [18:51] or create a view that excludes stuff. all I see is inclusion [18:53] dash, I know there's filtered views [18:53] but I don't know any specifics [19:03] Pilky: ping [19:15] * rotty has a problem with repo corruption: http://pastebin.com/m5f16cba1 [19:16] this repository used to work fine, but fails with newer bzr:s. I assume it was borked from the beginning (Arch import several years ago), but bzr started to notice just now. [19:16] I've googled quite a bit, but couldn't turn up a solution [19:16] rotty, have you tried "bzr reconcile"? [19:17] beuno: "revision history ok", the what seems to be the same error. [19:17] s/the what/then what/ [19:17] hrm [19:17] jfroy|work, [19:17] jam may know [19:20] beuno: btw, the branch is publically available: "bzr branch lp:~rotty/g-wrap/dev" === abentley-lunch is now known as abentley [19:20] abentley, hi! [19:20] it's fine to branch, but "bzr check" and e.g. "bzr log" fail [19:20] beuno: hi [19:21] maybe you would know how (or id) it can be fixed ^ [19:23] that would be awesome... [19:23] beuno, rotty: I don't know of an automatic way to fix that. [19:24] rotty, otherwise, try the mailing list, where all devs can walk you through it [19:24] abentley: I've seen some scripts floating in several bugs, but they seem only tangentially related [19:25] rotty: It looks like corruption at a pretty low level. [19:30] abentley, beuno: I'll drop a mail on the bazaar list [19:30] anyone familiar with the status of BazaarX? [19:44] mfer: you rang? [19:44] Pilky: hey. I was wondering what's going on with BazaarX [19:44] Pilky: I have hope for a usable OS X ui. there isn't anything at the moment and I think that's a big deal [19:45] mfer: well I've reset it and when I finally get round to it I'll be releasing 0.1 [19:46] which is basically just packaging it up, what is in the repo atm is basically 0.1 [19:47] Pilky: what is in the 0.1? [19:47] basically it will show all the branches in a repo, the status of a branch and let you add, remove and commit [19:47] but only locally [19:47] ok [19:48] the next two versions are going to be log and then mv/push/pull [19:48] though I'm not sure which will be 0.2 or 0.3 and have no time frame for when I'll work on them [19:49] Pilky: how much work will it take to bring these in? what kind of time table are you looking at? [19:49] ah [19:49] Pilky: are you thinking in terms of weeks or months? [19:49] months [19:49] * mfer hopes its not years :) [19:49] ok [19:49] Pilky: are you working this alone? [19:49] BazaarX is more a part time project really that I work on as and when I need it [19:49] almost [19:50] one or two people contribute a few bits of code, but mostly knowledge [19:50] are you looking for others to help with it? [19:50] The lack of a good mac gui is going to stop bazaar from getting into a lot of places and one that i'm interested in. [19:51] sure if you're interested in helping out [19:51] Pilky: i can't garuntee anything but i'll see if there's anything i can do or anyone i can ralley [19:51] thanks for the update [19:52] do you have much Cocoa experience? [19:53] Pilky: nope. but, i'm a quick learner. :) [19:54] heh, well BazaarX is 100% Cocoa/Obj-C and Objective-bzr (the API that BazaarX uses which is being developed along with it) is about 80% Cocoa/Obj-C and 20% Python [19:54] ok [19:55] but yeah, even if it's only putting forward ideas for how a feature should work or filing bugs it'd help a lot [19:57] I'd rather start by getting some others in on it. Like a UX person for the gui/features, some Cocoa codes to help there, etc [19:57] that's better than me picking it up and having at it [19:58] well sure, I mean I've quite good at UX stuff but I have been struggling with BazaarX so any help in that area would be great [19:58] but like I say, for me it is currently a side project I work on in my free time [19:59] I might try to get 0.1 packaged up this week [19:59] but at the moment my commercial software is taking precedent [19:59] Pilky: paying the bills is important. I understand that [20:12] Cheers! I've got a bzr repository which suddenly grew from a couple of GB. It's supposed to contain relativly small XML files. [20:13] I'd like to find out when and where this happened. The last diffs are all quite small. [20:13] Can bzr show me the size of a given revision, for instance? [20:14] This is bzr 1.5 from Debian lenny, using python 2.5.2. [20:17] Uhm, the repository grew from a couple of hundred KB to about 7GB. [20:38] Berge: ouch [20:39] Berge: there is a 'repository-details' plugin, but it doesn't have the ability to query by revision [20:39] Berge: you could try: [20:39] bzr push /tmp/measure -r 1 [20:39] du -sh /tmp/measure [20:39] bzr push /tmp/measure -r 2 [20:39] du -sh /tmp/measure [20:39] repeat [20:39] Hm, yes. [20:39] I'll try and see. [20:43] Aha. Somebody actually commited a few GB in a given revision, and managed to hide it in a large diff. [20:43] lifeless: Cheers, found it. [20:44] Berge: 'ouch' [20:45] lifeless: Indeed. [20:46] But I'll happily nudge someone. Glad to find out. [20:46] Have a wonderful evening! [20:57] Hmm [20:58] in a lightweight checkout, how do I do something like svn's "svn up -r 123"? [20:58] bzr revert -r 123 ? [20:58] that registers as a change to the working copy though [20:58] rather than just sucking in the revisions [20:58] I was able to use "bzr co --lightweight -r 100" to create the checkout [20:59] I could just delete it and do it again [20:59] ah like so [20:59] but i thought there might be a thing [20:59] that would be `bzr up -r`, when implemented [20:59] "when implemented". Right. :) [20:59] okay then, guess i'll just repeat [21:07] hi garyvdm [21:08] dash: hi [21:08] Hi bialix [21:08] dash: update -r 123 is available in a patch in the bugtracker [21:09] ok [21:09] it's not a big deal [21:09] garyvdm: about your mail: about 1/3 of changes in 0.15 is good for me [21:10] garyvdm: some performance improvements, many bugfixes [21:11] bialix: You don't want to use bzr 2.1? [21:12] no [21:12] it's beta, right? [21:14] bialix: 2.0.0 release with 0.14. And the idea for 2.0 it is ment to only have bug fixes. If bzr 2.0.1 has qbzr 0.15, then it has new features... [21:15] That dose not stop someone from using bzr 2.0.1 with qbzr 0.15. [21:15] how long we have to support 0.14 then? [21:16] As long as bzr 2.0.x is supported (I think 6 months) [21:18] bialix: We don't have to, but I think it would be good. [21:19] I'm a bit confused [21:22] see my answer [21:23] bialix: Yes - bug fixes should be in 0.14 [21:25] if you so strong about supporting 0.14 then I'll better to switch to it as my main qbzr version and will start to backport fixes [21:32] jelmer: ping? === flacoste is now known as flacoste_afk [22:50] hm [22:50] so on launchpad we have a branch that won't branch [22:50] but check is fine [22:50] and if i copy it using lftp locally, it's ok too [22:51] http://pastebin.ubuntu.com/297156/ [23:14] mwhudson: bug 437626 has the same error message [23:14] Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Undecided,New] https://launchpad.net/bugs/437626 [23:14] probably not helpful though [23:15] though it does have some dupes [23:15] so it may not be just an error you hit in various situations [23:15] james_w: looks like the same problem indeed [23:16] spiv: i can help you reproduce 437626 right now [23:16] spiv: are you awake yet? [23:19] jfroy|work: hi [23:19] jelmer: hey. so I think I solved my problem, but I can ask anyways. [23:20] As a best practice, how do you initialize a new Subversion repository from a Bazaar branch? [23:20] What I did this particular time is use svn to mkdir trunk, branches and tags. [23:20] jfroy|work: I don't mkdir trunk, I just push to trunk [23:20] Then used push --overwrite from the bazaar branch to push to trunk. [23:20] jfroy: don't you use bzr svn-serve instead? :) [23:20] Just pushing correctly complained that the branches had diverged. [23:20] mwhudson: spiv is usually another 40 minutes away or so [23:20] lifeless: ok [23:21] jfroy|work: creating a branch with mkdir is the eqiuvalent of creating a branch with a single commit it in [23:21] mornings<--------------------------->spiv [23:21] jfroy|work: so it is correct that you get an error about diverged branches [23:21] dash: eh, no, the source does need to go in that svn server, it's backed up offsite and integrated into the build system, etc etc. [23:21] moin lifeless [23:21] hi jelmer [23:21] jelmer: ah, I didn't you know you just push to a non-existing directory. [23:21] your ignore patch - you'll need to explain more about it I think [23:22] Particularly since the branch has several tags which I wanted to appear in /tags [23:22] push --overwrite seemed to work pretty well though. [23:23] lifeless: yeah, i knew that much :) [23:23] lifeless: did you see my email about supporting .hgignore,.gitignore and .bzrignore files? [23:23] (an RFC to the list a couple of months ago) [23:24] jelmer: i think I saw it go past [23:24] lifeless: Basically I'd like to add a mechanism to support the use of .hgignore and .gitignore files in native bazaar working trees [23:25] jelmer: would you want to support .hg files in Git trees? [23:26] lifeless: sure, why not (if there is no .gitignore file) [23:26] jelmer: do you mean to union these things together, or support one at a time? [23:27] jelmer: and what about globals? do you mean to union all the git hg bzr global/default ignores, or take each systems one? [23:27] lifeless: support one at a time [23:28] jelmer: so, putting aside whether this sounds nice to me or not [23:28] structurally [23:28] lifeless: it seems to make most sense to use the matching global one (global hg ignore file if using .gignore) [23:28] we have an existing interface on tree [23:29] if you want to make that do indirection, select an implementation etc, then that would be ok [23:29] I don't think a separate 'ignores' module is very discoverable, and having different bits of the code base talk to that rather than tree would allow skew and confusion [23:31] plus there is important state - the compiled matching rules - that tree maintains [23:32] so for all those reasons, I really think that the interfaces to work with ignores should be on MutableTree [23:32] and you can dispatch behind that layer to a registry or whatever. [23:37] lifeless: having those interfaces on MutableTree seems to make sense to me [23:39] lifeless: What value does get_ignore_files() have though? Its return value is highly dependent on the underlying .*ignore file that is being used [23:39] Urg, I think I self.shoot(self.foot) [23:39] I have A -> B -> C (A is parent of B, is parent of C) [23:40] oh, they're branches [23:40] Unfortunately, C has nothing to do with B [23:40] C should have been a child of A. [23:40] Is there a way to rebase (I guess that's what I want?) C unto A at the point C was branched from B? [23:41] My ultimate goal is to land C on A. [23:41] (but only C) [23:45] mwhudson: hey [23:45] jelmer: well, 'are the ignore files versioned', for instance [23:45] spiv: hello [23:46] mwhudson: please capture a tarball of the repo if you haven't already [23:46] jelmer: I'm not trying to defend that particular interface; but I think we need the patches to be clearer about how they fit into the overall structure. [23:46] spiv: which end? [23:46] mwhudson: local is probably more important [23:46] mwhudson: but both if you don't mind! :) [23:46] jfroy|work: rebase yes [23:46] jfroy|work: or a cherrypick merge [23:47] mwhudson: but it seems to be pretty easy lose the ability to reproduce by doing other things to your local repo, so taking a copy is good start [23:48] well i don't have a local repo so that part is easy [23:48] mwhudson: huh! [23:48] spiv: can you access devpad https urls? [23:48] I think so [23:49] spiv: https://devpad.canonical.com/~mwh/uk1.tgz is what i end up with in my local repo [23:49] (about 97 megs) [23:49] ok [23:50] lifeless: hmm [23:50] lifeless: I was trying to avoid making this too broad [23:50] currently trying to grab the branch over sftp tpp [23:50] too [23:50] mwhudson: thanks [23:50] seems to be getting further, at a guess [23:50] jelmer: because from your description of the patch I got 'move a function from wt to the ignore module because its implementation specific' [23:50] jelmer: and as wt's *represent implementations* that doesn't make sense. [23:51] spiv: yeah, branch over sftp worked fine [23:51] jelmer: on the tastefulness of this side, I think it will make debugging ignores harder [23:52] jelmer: so I think you need to spend some time thinking about how this polymorphism will be shown in the UI, - and all the docs that will need to be updated to tell people about it [23:55] morning [23:56]