[01:05] <lifeless> james_w: whats the plugins/builder symlink for in 'lp:bzr-builder'
[01:06] <james_w> tests
[01:06] <james_w> see the top of __init__.py
[01:07] <lifeless> that seems awfully complex
[01:07] <lifeless> why not just 'bzr selftest builder'
[01:07] <james_w> because the directory you are in may not be in bzr's plugin path
[01:07] <lifeless> oh right
[01:08] <lifeless> I really need to get back to that
[01:08] <lifeless> sigh. ETIME>
[01:34] <lifeless> james_w: still up?
[01:35] <lifeless> james_w: for daily debs, how do you manage uploading to each ppa suite?
[01:35] <ScottK> If you find him, please ask him about uploading the updated qbzr too.
[01:35] <lifeless> ScottK: to debian or ubuntu?
[01:36] <lifeless> Debian has a maintenance team, and we're always happy for more uploaders :) JFDI :)
[01:36] <ScottK> lifeless: Ubuntu, AFAIK it's not in Debian (although it ought to be)
[01:36] <lifeless> ScottK: any reason you can't just upload it then? [Ubuntu]
[01:36] <ScottK> lifeless: It's not packaged and I'm not familiar with the package.
[01:37] <lifeless> oh, thats surprising
[01:37] <lifeless> is there a bug ?
[01:37]  * ScottK is just looking at the OMG, Kittens bugs being thrown at motu-release.
[01:37] <ScottK> Yes.
[01:38] <ScottK> lifeless: 455051 is the bug asking for the upgrade
[01:38] <garyvdm> Hi ScottK
[01:38] <ScottK> lifeless: 447214 is the reason it's important
[01:38] <ScottK> Hi garyvdm
[01:39] <lifeless> bug 455051
[01:39] <lifeless> bug 447214
[01:40] <lifeless> ScottK: so it is packaged, just needs an update?
[01:40] <ScottK> lifeless: Yes.
[01:40] <ScottK> james_w TIL, but it's fair game for anyone that wants it.
[01:41] <lifeless> ScottK: it should be straight forward
[01:41] <lifeless> debcheckout etc
[01:41] <ScottK> lifeless: I would guess so, but I've got about 7 other things on my personal list that would come first.
[01:41] <lifeless> I doubt I'll get to it today, was sick for a week, so backlogged
[01:41] <ScottK> Yuck.  Hope you're feeling better.
[01:42] <lifeless> over the hump
[01:42] <lifeless> not well yet
[01:45] <ScottK> Good luck.
[01:45]  * ScottK is off to put kids to bed.
[02:40]  * igc doctor appointment & lunch - bbl
[04:23] <mwhudson> jelmer: btw i tried bzr-svn on pypy again and got this:
[04:23] <mwhudson> bzr: ERROR: exceptions.AssertionError: Tried registering <CachingRevisionMetadata for revision 39426, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'> as parent while <CachingRevisionMetadata for revision 39456, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'> already was parent for <CachingRevisionMetadata for revision 39481, path pypy/dist in repository 'fd0d7bf2-dfb6-0310-8d31-b7ecfe96aada'>
[04:25] <mwhudson> looks like https://bugs.edge.launchpad.net/bzr-svn/+bug/343382, which is fix released though
[04:32] <lifeless> james_w: how do you tie bzr-builder <-> PPA's.
[04:48] <jkakar> 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] <jkakar> 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] <jkakar> I guess I could try it on staging.lp.net and see what happens...
[04:51] <lifeless> jkakar: the order shouldn't matter
[04:52] <jkakar> lifeless: Awesome, thanks.
[05:37] <igc> bbiab
[07:48] <vila> hi all
[08:18] <bialix> hello all
[09:00] <Kamping_Kaiser> 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] <bialix> Kamping_Kaiser: you have very old bzr-svn plugin
[09:31] <bialix> maybe your bug was already fixed
[09:31] <bialix> any reason why you don't upgrade?
[09:32] <Kamping_Kaiser> bialix: I've just installed this (debian-stable based) distro. Hadn't thought to find updated bzr repos
[09:33] <bialix> bzr v.1.5 is almost 1.5 years old
[09:33] <Kamping_Kaiser> blink. the websites changed.
[09:34] <Kamping_Kaiser> i'll have a look for the updated version, thanks.
[09:36]  * igc dinner
[10:23] <jelmer> mwhudson: There's an open bug about that error, I havent had time to look into it yet.
[10:42] <mwhudson> jelmer: oh, i only found a closed one
[10:42] <mwhudson> nm for now
[12:42] <gioele> hello
[12:44] <bialix> ask
[12:45] <gioele> is there a guide to bzr-git? Something that describe how to contribute to a project that uses git using bzr-git?
[12:45] <gioele> bialix: sometimes I just say hallo and idle :)
[12:46] <bialix> gioele: I don't jnow any guide
[12:46] <bialix> gioele: I don't know is there any guide
[12:46] <bialix> but you can use guide for bzr-svn to get idea how to work with foreign branches
[12:47] <bialix> and of course you can try to ping jelmer who is one of main authors of bzr-git for specific questions
[12:48] <bialix> 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] <bialix> it's a basic workflow as I know
[12:53] <gioele> 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] <bialix> no, push and dpush is two different beasts
[12:55] <luks> dpush works
[12:55] <luks> (it's significantly simpler to implement)
[12:56] <bialix> hi luks
[13:01] <luks> hi
[15:41] <jam> morning vila, I hope you had a good weekend
[15:41] <vila> jam: pretty good thanks, I hope yours was fine too and good morning !
[15:42] <vila> jam: any ID what a DuplicateID conflict is ?
[15:42] <jam> vila: offhand I would say it is trying to create 2 paths with the same file-id
[15:43] <vila> The doc string says: two files want the same file_id but the code creates the conflict with trans_ids instead...
[15:43] <vila> How can you create two paths with the same file_id ?
[15:43] <vila> If the two paths comes from different branches with the same file_id.... I hope it's a rename...
[15:45] <vila> ...but that they are indeed referring to the *same* file
[15:46] <jam> 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] <vila> jam: that would be  a bug to me, not something the user may encounter
[15:47] <jam> vila: I think you are tracking down something that was generated via bugs
[15:47] <jam> however, we have it (apparently)...
[15:47] <jam> generally any given tree should only have a file-id 1 time
[15:47] <jam> if that isn't true, there is a bug
[15:47] <vila> hmm, ok, punting for now then :-/
[15:47] <jam> dirstate can certainly hold multiple file-ids accidentally
[15:48] <jam> Inventory cannot, since it uses a dict of file_id => entry
[15:48] <jam> CHKInventory similarly keys off of file_id so can't really have that
[15:48] <jam> though I suppose if InventoryDirectory pointed to children that weren't in the _by_id dict, you could have trouble...
[15:53] <vila> 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] <jam> vila: no prob, though I'm wondering what made you ask in the first place
[15:54] <vila> 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] <vila> jam: also, it's not documented in conflicts.txt unlike the orther ones...
[15:55] <jam> ah, k
[15:56] <moldy> hi
[15:56] <moldy> can i merge changes by file?
[15:58] <jam> moldy: you *can* do 'bzr merge ../branch/single/file'
[15:58] <jam> however, it shows up as a 'cherrypick' and thus isn't recorded as a 'full merge'.
[16:15] <jam> 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] <moldy> jam: sounds ok, thank you
[16:25] <bialix> hello jam
[16:25] <jam> hi bialix
[16:26] <bialix> Gary and me prefer to have qbzr 0.15 bundled into both windows installers, pretty please
[16:27] <jelmer> jam: hi
[16:27] <jelmer> jam: I haven't seen any particular changes that would require a new release
[16:28] <jam> jelmer: we bumped 'api_minimum_version' wouldn't that be an issue?
[16:28] <jam> bialix: I thought 0.14.4 was the stable release?
[16:29] <jam> we certainly can, but I'd like to be conservative if possible
[16:29] <jelmer> jam: ah, hadn't seen that
[16:30] <bialix> jam: yes, 0.14.4 is stable and fine for bzr 2.0.1
[16:30] <bialix> jam: but qbzr 0.15 uses new improvements from 2.1.0b1
[16:30] <jam> sure
[16:30] <bialix> jam: if you prefer to bundle different versions in different installers it's ok
[16:30] <bialix> jam: because I've built and uploaded windows installer for 0.15
[16:31] <bialix> so in the end your choice will be final one
[16:32] <bialix> 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] <jam> 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] <jam> 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] <bialix> 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] <vila> Can PQM run on windows ?
[16:36] <bialix> I dunno what it means exactly but it seems he's away from his personal computer
[16:36] <bialix> vila: I dunno
[16:36] <vila> bialix: thanks
[16:36] <vila> Any other ?
[16:38] <bialix> 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] <mathepic> Nothing "really" works on Windows.
[16:40] <bialix> scary
[17:06] <jam> 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] <jam> However, I think it is configured to "run this command", which should be pretty platform agnostic
[17:07] <vila> jam, bialix: thanks, nothing urgent, I just wanted some feeling
[17:07] <jam> 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] <jam> (arg parsing versus executable path is often an issue on Windows)
[17:08] <jam> and needs explicit support, etc.
[17:20] <abgalphabet> is there any gitk equivalent in bzr?
[17:20] <dash> what's gitk do? :)
[17:20] <jam> abgalphabet: 'bzr qlog'
[17:20] <jam> or 'bzr viz'
[17:20] <dash> ah.
[17:20] <jam> dash: gitk is actually the adaptation of 'bzr viz' if I remember the timelines correctly
[17:20] <dash> heh
[17:21] <jam> qlog is now nicer, IMO
[17:21] <abgalphabet> i tried bzr viz or bzr vis..it's quite good
[17:21] <abgalphabet> but it doesn't show relationship btn branches
[17:21] <abgalphabet> qlog?
[17:22] <abgalphabet> bzr qlog?
[17:22] <dash> 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] <jam> abgalphabet: you need to supply multiple branches, or the base of a shared repo, iirc
[17:23] <jam> 'bzr qlog' is from the qbzr plugin
[17:23] <dash> I'm trying to undo this and merge both variants.
[17:23] <abgalphabet> i tried bzr vis branch1 branch2. but it only show branch2
[17:25] <dash> 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] <abgalphabet> oh. it actually shows in the message/text description. but not visually intuitvie than gitk
[17:26] <abgalphabet> how to use the bzr to interact with cvs?
[17:27] <abgalphabet> gitk cvsimport seems working in synchronize changes in cvs into the git mirror by git cvsimport
[17:32] <Milo-> sooo.. 'bzr server' has no password protection?
[17:32] <abgalphabet> any ideas in bzr cvs workflow?
[17:43] <jam> vila: how about another 200MB memory savings? https://code.edge.launchpad.net/~jameinel/bzr/2.1-peak-mem-tweak/+merge/13582
[17:43] <jam> I'm still not at 50% though... :(
[17:44] <vila> 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] <jam> 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] <fullermd> Be all like, "No, sorry, thanks, but now I have too much memory to run bzr..."
[17:45] <jam> finding the zlib stuff was a fluke
[17:45] <jam> fullermd: well he does have a 16GB machine :)
[17:45] <vila> 12GB.... don't exagerate
[17:45] <fullermd> Oh, really?  Hm.  You get his arms, I'll go for the kneecaps...
[17:45] <jam> vila: you went cheap on me... :)
[17:46] <jam> 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] <vila> hmm, fullermd will tell you that it will not work for 2.2....
[17:47] <jam> fullermd: old:new
[17:47] <fullermd> Pfft, ruin all my fun, why doncha...
[17:48] <vila> . o 0 (Why did I have to give "him" credit for a joke I found myself.... See how grateful "he" is now...)
[17:54] <Milo-> is there any future planning for password protected smart server over bzr-protocol?
[17:55] <fullermd> Milo-: In the vague sense that "someday we should".
[17:56] <fullermd> It punts on AAA pretty much completely now.
[17:57] <Milo-> last time I used sftp for centralized repo purposes, bzr messed up all permissions in the repo for some reason
[17:57] <Milo-> and friend can't connect using bzr+ssh, his windows fails for some reason.
[17:57] <LarstiQ> Milo-: you could try ClueBzrServer
[17:58] <Milo-> heh
[18:00]  * Tak commit ChangeLog in the conservatory, with the candlestick
[18:02] <vila> jam: I'm about to EOD so I won't review your patch today (just so you don't wait for me)
[18:51] <dash> Hmm
[18:51] <dash> is there a way to exclude files from the current view?
[18:51] <dash> or create a view that excludes stuff. all I see is inclusion
[18:53] <beuno> dash, I know there's filtered views
[18:53] <beuno> but I don't know any specifics
[19:03] <mfer> Pilky: ping
[19:15]  * rotty has a problem with repo corruption: http://pastebin.com/m5f16cba1
[19:16] <rotty> 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] <rotty> I've googled quite a bit, but couldn't turn up a solution
[19:16] <beuno> rotty, have you tried "bzr reconcile"?
[19:17] <rotty> beuno: "revision history ok", the what seems to be the same error.
[19:17] <rotty> s/the what/then what/
[19:17] <beuno> hrm
[19:17] <beuno> jfroy|work,
[19:17] <beuno> jam may know
[19:20] <rotty> beuno: btw, the branch is publically available: "bzr branch lp:~rotty/g-wrap/dev"
[19:20] <beuno> abentley, hi!
[19:20] <rotty> it's fine to branch, but "bzr check" and e.g. "bzr log" fail
[19:20] <abentley> beuno: hi
[19:21] <beuno> maybe you would know how (or id) it can be fixed ^
[19:23] <rotty> that would be awesome...
[19:23] <abentley> beuno, rotty: I don't know of an automatic way to fix that.
[19:24] <beuno> rotty, otherwise, try the mailing list, where all devs can walk you through it
[19:24] <rotty> abentley: I've seen some scripts floating in several bugs, but they seem only tangentially related
[19:25] <abentley> rotty: It looks like corruption at a pretty low level.
[19:30] <rotty> abentley, beuno: I'll drop a mail on the bazaar list
[19:30] <mfer> anyone familiar with the status of BazaarX?
[19:44] <Pilky> mfer: you rang?
[19:44] <mfer> Pilky: hey. I was wondering what's going on with BazaarX
[19:44] <mfer> 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] <Pilky> mfer: well I've reset it and when I finally get round to it I'll be releasing 0.1
[19:46] <Pilky> which is basically just packaging it up, what is in the repo atm is basically 0.1
[19:47] <mfer> Pilky: what is in the 0.1?
[19:47] <Pilky> basically it will show all the branches in a repo, the status of a branch and let you add, remove and commit
[19:47] <Pilky> but only locally
[19:47] <mfer> ok
[19:48] <Pilky> the next two versions are going to be log and then mv/push/pull
[19:48] <Pilky> 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] <mfer> Pilky: how much work will it take to bring these in? what kind of time table are you looking at?
[19:49] <mfer> ah
[19:49] <mfer> Pilky: are you thinking in terms of weeks or months?
[19:49] <Pilky> months
[19:49]  * mfer hopes its not years :)
[19:49] <mfer> ok
[19:49] <mfer> Pilky: are you working this alone?
[19:49] <Pilky> BazaarX is more a part time project really that I work on as and when I need it
[19:49] <Pilky> almost
[19:50] <Pilky> one or two people contribute a few bits of code, but mostly knowledge
[19:50] <mfer> are you looking for others to help with it?
[19:50] <mfer> 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] <Pilky> sure if you're interested in helping out
[19:51] <mfer> Pilky: i can't garuntee anything but i'll see if there's anything i can do or anyone i can ralley
[19:51] <mfer> thanks for the update
[19:52] <Pilky> do you have much Cocoa experience?
[19:53] <mfer> Pilky: nope. but, i'm a quick learner. :)
[19:54] <Pilky> 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] <mfer> ok
[19:55] <Pilky> 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] <mfer> 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] <mfer> that's better than me picking it up and having at it
[19:58] <Pilky> 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] <Pilky> but like I say, for me it is currently a side project I work on in my free time
[19:59] <Pilky> I might try to get 0.1 packaged up this week
[19:59] <Pilky> but at the moment my commercial software is taking precedent
[19:59] <mfer> Pilky: paying the bills is important. I understand that
[20:12] <Berge> 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] <Berge> I'd like to find out when and where this happened. The last diffs are all quite small.
[20:13] <Berge> Can bzr show me the size of a given revision, for instance?
[20:14] <Berge> This is bzr 1.5 from Debian lenny, using python 2.5.2.
[20:17] <Berge> Uhm, the repository grew from a couple of hundred KB to about 7GB.
[20:38] <lifeless> Berge: ouch
[20:39] <lifeless> Berge: there is a 'repository-details' plugin, but it doesn't have the ability to query by revision
[20:39] <lifeless> Berge: you could try:
[20:39] <lifeless> bzr push /tmp/measure -r 1
[20:39] <lifeless> du -sh /tmp/measure
[20:39] <lifeless> bzr push /tmp/measure -r 2
[20:39] <lifeless> du -sh /tmp/measure
[20:39] <lifeless> repeat
[20:39] <Berge> Hm, yes.
[20:39] <Berge> I'll try and see.
[20:43] <Berge> Aha. Somebody actually commited a few GB in a given revision, and managed to hide it in a large diff.
[20:43] <Berge> lifeless: Cheers, found it.
[20:44] <lifeless> Berge: 'ouch'
[20:45] <Berge> lifeless: Indeed.
[20:46] <Berge> But I'll happily nudge someone. Glad to find out.
[20:46] <Berge> Have a wonderful evening!
[20:57] <dash> Hmm
[20:58] <dash> in a lightweight checkout, how do I do something like svn's "svn up -r 123"?
[20:58] <LarstiQ> bzr revert -r 123 ?
[20:58] <dash> that registers as a change to the working copy though
[20:58] <dash> rather than just sucking in the revisions
[20:58] <dash> I was able to use "bzr co --lightweight -r 100" to create the checkout
[20:59] <dash> I could just delete it and do it again
[20:59] <LarstiQ> ah like so
[20:59] <dash> but i thought there might be a thing
[20:59] <LarstiQ> that would be `bzr up -r`, when implemented
[20:59] <dash> "when implemented". Right. :)
[20:59] <dash> okay then, guess i'll just repeat
[21:07] <bialix> hi garyvdm
[21:08] <lifeless> dash: hi
[21:08] <garyvdm> Hi bialix
[21:08] <lifeless> dash: update -r 123 is available in a patch in the bugtracker
[21:09] <dash> ok
[21:09] <dash> it's not a big deal
[21:09] <bialix> garyvdm: about your mail: about 1/3 of changes in 0.15 is good for me
[21:10] <bialix> garyvdm: some performance improvements, many bugfixes
[21:11] <garyvdm> bialix: You don't want to use bzr 2.1?
[21:12] <bialix> no
[21:12] <bialix> it's beta, right?
[21:14] <garyvdm> 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] <garyvdm> That dose not stop someone from using bzr 2.0.1 with qbzr 0.15.
[21:15] <bialix> how long we have to support 0.14 then?
[21:16] <garyvdm> As long as bzr 2.0.x is supported (I think 6 months)
[21:18] <garyvdm> bialix: We don't have to, but I think it would be good.
[21:19] <bialix> I'm a bit confused
[21:22] <bialix> see my answer
[21:23] <garyvdm> bialix: Yes - bug fixes should be in 0.14
[21:25] <bialix> 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] <jfroy|work> jelmer: ping?
[22:50] <mwhudson> hm
[22:50] <mwhudson> so on launchpad we have a branch that won't branch
[22:50] <mwhudson> but check is fine
[22:50] <mwhudson> and if i copy it using lftp locally, it's ok too
[22:51] <mwhudson> http://pastebin.ubuntu.com/297156/
[23:14] <james_w> mwhudson: bug 437626 has the same error message
[23:14] <james_w> probably not helpful though
[23:15] <james_w> though it does have some dupes
[23:15] <james_w> so it may not be just an error you hit in various situations
[23:15] <mwhudson> james_w: looks like the same problem indeed
[23:16] <mwhudson> spiv: i can help you reproduce 437626 right now
[23:16] <mwhudson> spiv: are you awake yet?
[23:19] <jelmer> jfroy|work: hi
[23:19] <jfroy|work> jelmer: hey. so I think I solved my problem, but I can ask anyways.
[23:20] <jfroy|work> As a best practice, how do you initialize a new Subversion repository from a Bazaar branch?
[23:20] <jfroy|work> What I did this particular time is use svn to mkdir trunk, branches and tags.
[23:20] <jelmer> jfroy|work: I don't mkdir trunk, I just push to trunk
[23:20] <jfroy|work> Then used push --overwrite from the bazaar branch to push to trunk.
[23:20] <dash> jfroy: don't you use bzr svn-serve instead? :)
[23:20] <jfroy|work> Just pushing correctly complained that the branches had diverged.
[23:20] <lifeless> mwhudson: spiv is usually another 40 minutes away or so
[23:20] <mwhudson> lifeless: ok
[23:21] <jelmer> jfroy|work: creating a branch with mkdir is the eqiuvalent of creating a branch with a single commit it in
[23:21] <lifeless> mornings<--------------------------->spiv
[23:21] <jelmer> jfroy|work: so it is correct that you get an error about diverged branches
[23:21] <jfroy|work> 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] <jelmer> moin lifeless
[23:21] <lifeless> hi jelmer
[23:21] <jfroy|work> jelmer: ah, I didn't you know you just push to a non-existing directory.
[23:21] <lifeless> your ignore patch - you'll need to explain more about it I think
[23:22] <jfroy|work> Particularly since the branch has several tags which I wanted to appear in /tags
[23:22] <jfroy|work> push --overwrite seemed to work pretty well though.
[23:23] <mwhudson> lifeless: yeah, i knew that much :)
[23:23] <jelmer> lifeless: did you see my email about supporting .hgignore,.gitignore and .bzrignore files?
[23:23] <jelmer> (an RFC to the list a couple of months ago)
[23:24] <lifeless> jelmer: i think I saw it go past
[23:24] <jelmer> 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] <lifeless> jelmer: would you want to support .hg files in Git trees?
[23:26] <jelmer> lifeless: sure, why not (if there is no .gitignore file)
[23:26] <lifeless> jelmer: do you mean to union these things together, or support one at a time?
[23:27] <lifeless> 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] <jelmer> lifeless: support one at a time
[23:28] <lifeless> jelmer: so, putting aside whether this sounds nice to me or not
[23:28] <lifeless> structurally
[23:28] <jelmer> lifeless: it seems to make most sense to use the matching global one (global hg ignore file if using .gignore)
[23:28] <lifeless> we have an existing interface on tree
[23:29] <lifeless> if you want to make that do indirection, select an implementation etc, then that would be ok
[23:29] <lifeless> 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] <lifeless> plus there is important state - the compiled matching rules - that tree maintains
[23:32] <lifeless> so for all those reasons, I really think that the interfaces to work with ignores should be on MutableTree
[23:32] <lifeless> and you can dispatch behind that layer to a registry or whatever.
[23:37] <jelmer> lifeless: having those interfaces on MutableTree seems to make sense to me
[23:39] <jelmer> 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] <jfroy|work> Urg, I think I self.shoot(self.foot)
[23:39] <jfroy|work> I have A -> B -> C (A is parent of B, is parent of C)
[23:40] <jfroy|work> oh, they're branches
[23:40] <jfroy|work> Unfortunately, C has nothing to do with B
[23:40] <jfroy|work> C should have been a child of A.
[23:40] <jfroy|work> 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] <jfroy|work> My ultimate goal is to land C on A.
[23:41] <jfroy|work> (but only C)
[23:45] <spiv> mwhudson: hey
[23:45] <lifeless> jelmer: well, 'are the ignore files versioned', for instance
[23:45] <mwhudson> spiv: hello
[23:46] <spiv> mwhudson: please capture a tarball of the repo if you haven't already
[23:46] <lifeless> 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] <mwhudson> spiv: which end?
[23:46] <spiv> mwhudson: local is probably more important
[23:46] <spiv> mwhudson: but both if you don't mind! :)
[23:46] <lifeless> jfroy|work: rebase yes
[23:46] <lifeless> jfroy|work: or a cherrypick merge
[23:47] <spiv> 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] <mwhudson> well i don't have a local repo so that part is easy
[23:48] <spiv> mwhudson: huh!
[23:48] <mwhudson> spiv: can you access devpad https urls?
[23:48] <spiv> I think so
[23:49] <mwhudson> spiv: https://devpad.canonical.com/~mwh/uk1.tgz is what i end up with in my local repo
[23:49] <mwhudson> (about 97 megs)
[23:49] <spiv> ok
[23:50] <jelmer> lifeless: hmm
[23:50] <jelmer> lifeless:  I was trying to avoid making this too broad
[23:50] <mwhudson> currently trying to grab the branch over sftp tpp
[23:50] <mwhudson> too
[23:50] <spiv> mwhudson: thanks
[23:50] <mwhudson> seems to be getting further, at a guess
[23:50] <lifeless> 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] <lifeless> jelmer: and as wt's *represent implementations* that doesn't make sense.
[23:51] <mwhudson> spiv: yeah, branch over sftp worked fine
[23:51] <lifeless> jelmer: on the tastefulness of this side, I think it will make debugging ignores harder
[23:52] <lifeless> 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] <igc> morning
[23:56] <jelmer> lifeless: hmm
[23:56] <igc> hi spiv, lifeless, mwhudson, jelmer
[23:56] <mwhudson> hello igc
[23:56] <jelmer> hi Ian, Michael, Andrew
[23:57] <garyvdm> Hi igc
[23:57] <igc> hi garyvdm