[00:00] <james_w> exporting from the content of the branch doesn't provide you that, so merge-upstream uses pristine-tar to make it possible
[00:00] <GaryvdM> james_w: Oh - ok
[00:00] <AfC> Weird. bzr branch lp:ubuntu/<package> downloads *tarballs*?
[00:02] <AfC> They're versioned! What the hell?
[00:03] <GaryvdM> james_w: Thanks for the help.
[00:03] <GaryvdM> beta-ppa now building new bzr-svn
[00:04] <AfC> james_w: so, er, I must admit I'm surprised to see you tracking binary tarballs with bazaar, instead of sources. Doesn't that defeat the whole point?
[00:05] <james_w> AfC: we aren't
[00:05] <AfC> james_w: of branches to be shared between distros?
[00:05] <james_w> you may have picked a package where the packager decided that tarballs is what they wish to put in their source packages
[00:06] <AfC> james_w: um
[00:06] <AfC> james_w: so it's freetype [->libfreetype6]
[00:06] <AfC> james_w: and it says
[00:06] <AfC> Committer: Bazaar Package Importer <james.westby@ubuntu.com>
[00:07] <AfC> each time it merges a series of tarballs, and then replaces them
[00:07] <AfC> That you?
[00:07] <james_w> yes, so you chose one such package
[00:07] <james_w> it's a script run by me
[00:08] <AfC> I guess I don't understand why there are any such packages.
[00:08] <spiv> Because we didn't invent packaging branches years ago ;)
[00:08] <AfC> I really thought I'd be getting a branch full of sources, not full of tarballs.
[00:09] <AfC> spiv: right, but someone did invent the idea of using Bazaar to manipulate Debian packages in the not to recent past. You remember, when Bazaar was started, right?
[00:09] <james_w> O HAI, I see you have packaging that is designed to work with tarballs, I'm going to automatically rewrite it to work with unpacked tarballs so that you get a nice surprise next time you look at it!
[00:09] <AfC> spiv: My understanding [clearly wrong] was that the whole point was to have a branch of upstream that you would then apply revisions to to make a debian package.
[00:09] <spiv> AfC: If I'm understanding correctly, in this case the 'source' package contains a tarball.  The bzr import of that is just reflecting that reality.
[00:10] <AfC> spiv: ah
[00:10] <AfC> spiv: I see
[00:11] <AfC> spiv, james_w: I didn't know such things existed, actually.
[00:11] <AfC> I'm from the Gentoo world, where the first thing that happens with a released tarball is that it is unpacked, so that people can then diff and patch against it.
[00:11] <RAOF> It's probably because they wanted to merge the three separate .tar.bz2's into a single source package.
[00:12] <RAOF> That would now be supported with the new 3.0 deb-src format, but that's very new.
[00:12] <AfC> Anyway, I guess this isn't what I was hoping for. My understanding from years ago was that we would have bzr revisions showing the packaging changes to a baseline of (upstream's) sources [which would be either upstream vcs or upstream tarball unpacked[
[00:13] <GaryvdM> bla: Rejected: bzr-svn_1.0.2-2~bazaar1~karmic1.dsc: format '3.0 (quilt)' is not permitted in karmic.
[00:13] <poolie> hello igc
[00:13] <spiv> AfC: and packages like this are why we didn't already have those bzr revisions years ago ;)
[00:14] <james_w> AfC: you do for the majority of package
[00:14] <AfC> So can you suggest a package that does behave properly (so I can compare, and not go away with the wrong idea)?
[00:17] <james_w> bzr?
[00:19] <GaryvdM> james_w: There must be non bzr related packages for which we have a  branch that shares the history with upstream?
[00:22] <james_w> there aren't many at the moment
[00:22] <james_w> we are focusing on getting every package available in some form first, then looking to improve the history of ones where we can
[00:28] <GaryvdM> james_w: lp:ubuntu/qbzr dose not share its history. Can I fix that?
[00:28] <james_w> GaryvdM: yes and no
[00:29] <james_w> it's straightforward to join the history, but the file-ids also differ, so when you do everything in the tree conflicts
[00:29] <james_w> there isn't really a neat way to deal with that right now
[00:31] <GaryvdM> james_w: So I can't give launchpad an instruction to can that branch, and start fresh using file
[00:31] <james_w> not easily
[00:31] <GaryvdM> ... file-ids from branch x
[00:32] <GaryvdM> Will that become easier in the future?
[00:35] <james_w> yes
[00:35] <GaryvdM> james_w: :-)
[00:36] <mkanat> I ran into that problem a few times in the past, too.
[00:37] <mkanat> And yeah, hopefully it will become easy (read: possible for mere mortals) in the future. :-)
[01:08] <poolie> spiv, is the news auto-merger installed in pqm now?
[01:08] <jelmer> GaryvdM, re
[01:08] <poolie> hi jelmer
[01:08] <GaryvdM> Hi jelmer.
[01:08] <jelmer> GaryvdM, you need a new entry for the ppa anyway because of the version string
[01:09] <jelmer> GaryvdM, but generally you would keep the debian entries as well
[01:09] <jelmer> hi poolie
[01:09] <jelmer> poolie, does the pqm run 2.1 yet?
[01:10] <spiv> poolie: I don't know, but it would be nice to have :)
[01:10] <GaryvdM> jelmer: Oh ok - need to re do them because I messed up the debian/control files. :-(
[01:11] <spiv> poolie: it would require bzr 2.1 and a small config tweak in bazaar.conf I guess.
[01:11] <spiv> poolie: do you know if someone was already looking into arranging that, or should I file an RT?
[01:11] <poolie> i don't know that anyone else is
[01:11] <poolie> it might be nice
[01:12] <poolie> the upgrade will probably be easier when 2.1 is packaged and available
[01:12] <poolie> at least in lucid
[01:12] <jam> morning poolie and spiv
[01:12] <poolie> hello jam, and no, it's just after midday
[01:12] <jam> I guess that's what I get for coming back late
[01:13] <jam> anyway, just stopping by to say hello, I'll probably be back with the family in a couple mins
[01:13] <poolie> k
[01:13] <poolie> thanks for the reviews
[01:13] <spiv> jam: early afternoon :)
[01:18] <spiv> Ok, I'll wait until there's a 2.1 package then.
[01:33] <spiv> Drat, I sent a branch to PQM with the commit message for a different branch (both approved for 2.1, thankfully).
[01:34] <spiv> I'm definitely looking forward to a command that take an lp merge proposal and send it to PQM with the source branch, target branch and commit message in that proposal.
[01:40] <Kilroo> I'm mostly looking forward to the fix for bug 109114.
[01:42] <poolie> spiv, you can ask spm to kill the job
[01:42] <spiv> Hmm, that's a thought
[01:42] <spiv> spm: ping?  Would you mind killing my "now playing" job on bzr's pqm?
[01:43] <poolie> good thing the tests aren't too fast ;)
[02:07] <GaryvdM> Night all
[02:19] <lifeless> Kilroo: noone is working on that at the moment.
[02:19] <Kilroo> I had gathered that.
[02:20] <Kilroo> Fact remains, it's the only thing not directly concerning either bzr-eclipse or bzr-svn that is having a negative effect on me. And the problems with them I can work around.
[02:20] <lifeless> Kilroo: do you have multi-GB files?
[02:20] <Kilroo> Yes.
[02:21] <Kilroo> Not by choice, but until they stop piling projects on me long enough for me to propose a solid plan for moving to a more reasonable versioning plan, I have to work with the subversion repositories we have.
[02:23] <Kilroo> Two of those I can't pull the revision where they added the whole blasted main site at once. And one that otherwise ought to be pretty clean I can't work with because my supervisor had to get a file to an accessible location while he was at a convention and the only way he could think of to do it at the time was to commit a 1.5gb zip archive to a subversion repository.
[02:24] <Kilroo> I'm not even sure exactly how he accomplished it or why.
[02:24] <Kilroo> I'm actually kind of hoping that the hassle of purging it from the history of the repository helps my case for redoing our system.
[02:27] <lifeless> :)
[03:46] <RenatoSilva> Is there how to merge only certain revisions?
[03:50] <RAOF> You mean to cherry pick?  You pass -rfrom..to
[03:51] <RAOF> This won't keep the log history though.
[03:52] <RenatoSilva> what does it mean keep log history? that's the intention
[03:53] <RAOF> It squashes down to a single commit, which contains the diff.
[03:53] <RenatoSilva> I have uncommitted a few revisions, so the old history in the feature branch became outdated and pointless
[03:53] <RenatoSilva> single commit? but I said certain revision*S*
[03:53]  * RenatoSilva is using rebase
[03:54] <RAOF> Yes.  It'll take the changes from certain revisions and apply them as a diff.
[03:54] <RAOF> As far as I'm aware there's no way to (easily) take a sequence of commits for which the first commit does not have its parent in the branch and merge them as a series of commits.
[03:55] <RenatoSilva>  You pass -rfrom..to to what?
[03:56] <RenatoSilva> bzr merge -r -1 didn't work, the other revs are there
[03:56] <spiv> RenatoSilva: -rSTART_REV..END_REV
[03:56] <spiv> RenatoSilva: it's a range
[03:56] <lifeless> jelmer: don't suppose you want to package a newer bzr-search? we're getting  lots of dups for fixed bugs
[03:58] <RenatoSilva> spiv: ah ok, but bzr merge d -r -2..-1 gives no pending merge in bzr qlog
[03:59] <RenatoSilva> spiv: maybe the conflicts? lms
[03:59] <spiv> RenatoSilva: if you're trying to merge the changes of just one revision, try -c REV rather than -r.
[03:59] <spiv> RenatoSilva: just because it's more convenient
[04:01] <spiv> RenatoSilva: but if merge of -2..-1 gives "Nothing to do.", then I that revision is already part of the branch
[04:01] <RenatoSilva> spiv: ok, but will it also --forget-merges automatically like in -r?
[04:01]  * RenatoSilva trying
[04:01] <spiv> RenatoSilva: yes
[04:01] <lifeless> RenatoSilva: if -2 isn't already merged, in your example, then there won't be pending merges.
[04:01] <lifeless> because you are doing a cherrypick, it lives outside the merge graph.
[04:04] <RenatoSilva> cherrypick? anyway, I have checked, it does forget the merge in both cases, this seems fine as I would --forget them anyway
[04:04]  * RenatoSilva realizes how uncommit may be annoying sometimes
[04:05] <spiv> "cherrypick" basically means "take just part of a branch's history, not the full branch"
[04:06] <spiv> i.e. what you're doing here.
[04:09] <RenatoSilva> so, I will make a hack (fb = feature branch): cp -r trunk fb_new; cd fb_new; bzr merge ../fb -c -1; bzr commit -m "Same message."; rm -r ../fb
[04:09]  * igc lunch
[04:09] <RenatoSilva> it's like a rebase :)
[04:10] <spiv> RenatoSilva: in the sense that the original history is generally no longer part of the new history, yes.
[04:15] <RenatoSilva> spiv: did I told you about the bzr search bug? I realized that it's all about inspecting bzr log -p, so I wrote a tool for that. I'm pretty satisfied.
[04:16] <RenatoSilva> spiv: usage is something like bzr log -p | greprev why_this_method_was_deleted, I used it today, very nice
[04:16] <RenatoSilva> * helpful
[04:17] <lifeless> RenatoSilva: about bzr-search
[04:17] <lifeless> RenatoSilva: it doesn't do log -p internally, it prebuilds indices to answer questions much faster than log -p
[04:18] <lifeless> RenatoSilva: so I'm glad you're happy, and the bug is there in case someone chooses to implement it.
[04:18] <RenatoSilva> lifeless: I understand that bzr-search may be much more faster specially for big trees, but I'm pretty satisfied, specially because I can use a free regex, and because I get the revnos not ids
[04:19] <RenatoSilva> lifeless: I think implementing that bug would be just about replacing non-friendly the rev ids with the numbers.
[04:19] <lifeless> RenatoSilva: well the unique thing I got out of your comments was seeing a diff
[04:20] <RenatoSilva> (of course there are the search string issue, but that's registered at another bug as you have reported there) (I just did not get the new title 'show hits as diffs')
[04:20] <lifeless> I'm fairly sure there is a bug, or TODO at least, to show numbers (but that is also pending a revno oracle, something bzr branches need in general)
[04:20] <lifeless> RenatoSilva: your script shows a diff doesn't it ?
[04:22] <RenatoSilva> lifeless: it gives you a clue. It shows the line of the rev's diff containing a match, and the file name, and the rev number. With this last, you bzr qlog and look at that rev to get more details (specially, read the commit comment)
[04:23] <RenatoSilva> revno oracle? you mean you cant just pick up the revno? ok
[04:23] <lifeless> thats correct, calculating revnos means accessing all the information for the branch, and is often quite slow
[04:24] <spiv> RenatoSilva: ah cool, I'm glad that you found a way to do what you wanted :)
[04:24] <RenatoSilva> all info == loop the commits? oO
[04:24] <lifeless> RenatoSilva: I'm fine with showing a diff, I'm just noting that bzr-search does not show a diff, and you want it to.
[04:25] <RenatoSilva> I thought revnos were stored as commit metadata, along with the long ids
[04:26] <lifeless> nope
[04:26] <lifeless> they are dynamic and can potentially change completely
[04:26] <RenatoSilva> lifeless: iirc it does the same, it shows the line of the diff containing the match, the problem is that the output is a bit weird (just a matter of formatting), and mainly, that we don't have the revnos
[04:26] <lifeless> e.g. 'uncommit', 'push --overwrite' do this
[04:26] <lifeless> RenatoSilva: no, bzr-search does *not* show a diff
[04:26] <RenatoSilva> lifeless: ah ok I didn't know that
[04:27] <RenatoSilva> lifeless: not the entire diff
[04:27] <lifeless> not a diff at all, it doesn't access the old version of the file.
[04:27] <RenatoSilva> lifeless: weird, I was pretty sure I got some matches like +  sadasdaad  match
[04:28] <RenatoSilva> lifeless: I linked an example in the bug, let me check
[04:28] <lifeless> it shows the first line in the new version of the file that matches any search term searched for
[04:29] <RenatoSilva> http://pastie.org/815629.txt
[04:30] <lifeless> yes, not diffs
[04:30] <lifeless> just lines extracted from the files
[04:30] <RenatoSilva> they're all from current revision for all files?
[04:31] <RenatoSilva> or from old revisions? maybe I misunderstood this comment? "bzr search searches the diff between revisions already."
[04:31] <lifeless> what it searches and what it shows are separate
[04:32] <lifeless> it builds an index from the file diffs. the index points at (revision, file)
[04:32] <lifeless> it shows by reading in (revision, file) and looking in that for what you searched for
[04:33] <RenatoSilva> hence it shows matches in old file versions?
[04:34] <lifeless> yes
[04:34] <lifeless> the revision is printed at the left of the output
[04:34] <spiv> lifeless: there's possibly a valid bug here along the lines of "document what bzr-search indexes in a way that end users will comprehend"?
[04:34] <lifeless> spiv: perhaps. Or make it more powerful so it doesn't matter.
[04:34] <spiv> or perhaps just s/comprehend/discover/ ;)
[04:34] <spiv> lifeless: right
[04:35] <spiv> lifeless: but in the meantime while it's not quite as awesome as google, document it ;P
[04:35] <lifeless> spiv: I mean, this conversation is about it a) not searching via literal strings (a subset of full regex) and b) the output being fugly
[04:35] <lifeless> s/conversation/bug report/
[04:36] <spiv> (I'm not trying to imply anything much about the priority of documenting the status quo vs. improving it)
[04:36] <spiv> FWIW, I generally consider bug reports to be conversations  :)
[04:36] <lifeless> vs the conversation on IRC :)
[04:37] <RenatoSilva> lifeless: well I'm very sorry but I can't really understand you pretty well. It simply seems to me that, if there was a revno rather than that rev id (and besides the output being a bit weird), it would give me the info I want. If not, then I'm sorry
[04:38] <lifeless> RenatoSilva: it can currently show a line that was not altered by the commit
[04:38] <RenatoSilva> lifeless: I'm jsut lost with that bug at the moment. I have no idea what 'hits as diffs' mean :(
[04:38] <lifeless> it means show the results as diffs
[04:38] <lifeless> not as summaries from the committed documents
[04:38] <lifeless> I don't know how to phrase that differently I guess.
[04:38] <lifeless> a hit is a search hit, its something returned from your search.
[04:38] <lifeless> a diff is a description of a change between two things
[04:39] <lifeless> bzr-search currently shows hits as summaries *of the new things*, not as *a difference between things*
[04:39] <RenatoSilva> lifeless: ok just know that I'm confused, and I'll probably leave that bug, I'm sorry :(
[04:40] <lifeless> I'm satisfied that I know what you want.
[04:40] <lifeless> And I've described it in a way that I and other bzr-search devs will understand.
[04:40] <lifeless> I think you'd need to read the code to understand whats going on ><
[04:40] <RenatoSilva> lifeless: so if one wants more details in the future from the bug reporter, I'll not be there because I don't get the bug idea anymore :(
[04:41] <RenatoSilva> lifeless: ok ok thanks, it's just to let you know in case if you find it weird that I unsubscribe or so
[04:41] <lifeless> thats fine
[04:41] <lifeless> you've communicated what you wanted well using the filter script you wrote
[04:42] <RenatoSilva> ok
[04:45] <RenatoSilva> thank you very much guys
[05:09] <poolie> spiv is https://bugs.edge.launchpad.net/bzr/+bug/421845 really high?
[05:10] <poolie> actually nm, i already downgraded it
[05:10] <poolie> revert that if you disagree
[05:14] <spiv> poolie: hmm
[05:14] <spiv> poolie: I don'
[05:14] <spiv> I don't feel strongly about it, but I tend to think that bugs that stop 'bzr check' from being a reliable way to determine the health of a repo are serious.
[05:15] <spiv> But at the same time, it is a bit of a niche situation.
[05:16] <poolie> ok
[05:16] <poolie> i'm doing a bit of a roundup of bugs with patches
[05:16] <poolie> you could turn yours into a known failure
[05:16] <poolie> but...
[05:16] <poolie> that doesn't actually fix it
[05:16] <poolie> so it's probably not worthwhile
[05:17] <spiv> But it would shift it off the "bugs with patches" queue ;)
[05:18] <poolie> :)
[05:19] <poolie> spiv do you think the malloc patch is safe for 2.0?
[05:19] <spiv> I think so, but it might be nice to give it some time in trunk first, just in case.
[05:20] <poolie> ok
[05:24] <poolie> there's some potential for waste in letting things age in trunk
[05:24] <poolie> though i also kind of like the ieda
[05:24] <poolie> idea
[05:39] <poolie> jelmer: are you awake perchance?
[07:31] <poolie> spiv, still here?
[07:43] <vila> hi all !
[07:44] <vila> wow, I was about to nudge core devs to land their approved patches and... https://code.edge.launchpad.net/bzr/+activereviews is almost empty, yeah for telepathy !
[07:47] <poolie> hi vila
[07:47] <poolie> yeah!
[07:47] <poolie> and, i think
[07:47] <poolie> less +patches bugs than when we started
[07:47] <poolie> maybe no +high ones?
[07:48] <vila> I haven't looked at +patches yet, but +workinprogress is reasonably short too
[07:50] <poolie> those aren't real urls
[07:50] <poolie> yet
[07:50] <poolie> they should be
[07:50] <vila> poolie: sure, but we understand each other here
[07:51] <poolie> yes
[07:58] <lifeless> jelmer: ping
[07:58] <lifeless> poolie: actually, there is a +patches one now Ithink
[07:58] <lifeless> it was announced at portland
[07:59] <lifeless> maybe its only for ubuntu, in which case a nudge to Jorge might be useful
[07:59] <poolie> not deployed yet i believe
[07:59] <poolie> continuous deployments come on down
[08:01]  * igc dinner
[08:08] <poolie> k, i need to finish https://bugs.edge.launchpad.net/bzr/+bug/368931 then stop
[08:18] <vila> poolie, lifeless : I replied on  https://code.edge.launchpad.net/~vila/bzr/move-test-servers/+merge/18960 , we can discuss it here and now if you will
[08:19] <vila> spiv, igc, jam, everybody who is interested too ^
[08:20] <vila> mwhudson: ping
[08:25] <poolie> vila, can you summarize where it's actually up to?
[08:25] <poolie> i'm broadly + on just merging it before perfecting it
[08:26] <spiv> hey vila
[08:26] <vila> poolie: test servers are out of the bzrlib.transport hierarchy, tests are passing
[08:26] <spiv> Does that include MemoryServer?
[08:27] <vila> spiv: hey happy father ! :D
[08:27] <spiv> It would be a shame to move that twice, and thus cause Launchpad to have to update their code to match twice.
[08:27] <vila> spiv: yes, but not ChrootServer and PathFilteringServer which *are* used are true servers (MemoryServer isn't)
[08:27] <spiv> MemoryServer is a real server.
[08:28] <poolie> they do use MemoryServer
[08:28] <poolie> in lib/lp/codehosting/vfs/branchfs.py
[08:29] <vila> poolie: outside of tests ?
[08:29] <spiv> Yes.
[08:29] <vila> hmm
[08:29] <poolie> it seems strange but they do call it
[08:29] <poolie> vila istm that if you import transport.memory it is reasonable to get MemoryServer too
[08:30] <poolie> we mostly want to avoid it for real protocols
[08:30] <vila> poolie: that was the root cause of needing testools when using sftp...
[08:30] <vila> let me try
[08:30] <poolie> memoryserver was?
[08:31] <vila> poolie: no, leaving a test server in the bzrlib.transport hierarchy
[08:31] <poolie> right
[08:31] <spiv> MemoryServer doesn't have much risk of depending on external dependencies.
[08:31] <poolie> i think we should move that one
[08:32] <poolie> right
[08:32] <poolie> and also, if you are using a memorytransport you must necessarily also use an in process memory server
[08:34] <vila> poolie: nice catch, let me look at the fallouts
[08:48] <poolie> well it was spiv really
[08:48] <poolie> i would not have guessed lp used it
[08:49] <vila> spiv: nice catch to you then ;)
[08:51] <vila> spiv: By the way, Marie an I noticed that your Vincent's mother is called Mary while her (Marie's) father is called Vincent, which kind of make sense since we leave roughly at the other side of the planet... but I wonder how *they* will name their children (except I think I just don't want to know, that's far too close to playing with the quantum universe equilibrium)) )) (just to be sure)
[08:52] <poolie> vila, can you send a pp mail before you go?
[08:52] <fullermd> Pah, lousy quantumn universe equilibrium.  What'd it ever do for me?
[08:53] <vila> poolie: Some sort of summary you mean ?
[08:53] <vila> poolie: or a 'I'm done, next is poolie' kind of ?
[08:54] <lifeless> vila: I've made my case for names on the bug, whatever poolie goes with is pragmatically fine.
[08:54] <vila> lifeless: ok
[08:54] <lifeless> vila: (But I'm not convinced by .git and .ftp being siblings :))
[08:55] <vila> well, I'm not convinced we need to reserve for .git until we implement it ;)
[08:55] <lifeless> we have .smart.server
[08:55] <bialix> heya all
[08:55] <lifeless> I'd rather see .git.server
[08:55] <bialix> hi lifeless
[08:55] <lifeless> and similar for CVS etc, than have it adjavent to the VFS servers
[08:55] <lifeless> hi bialix
[08:55] <bialix> lifeless: IIUC you're admin of bzr ML
[08:55] <lifeless> bialix: one of manyt
[08:55] <bialix> I have problems posting to ML via gmane
[08:55] <lifeless> bialix: hmm
[08:56] <bialix> at least it was true yesterday
[08:56] <lifeless> we're not that sort of admin really. what sort of symptoms do you see?
[08:56] <lifeless> (we only have web UI clicky clicky admin access)
[08:56] <bialix> yesterday my mails were not reach ML.
[08:56] <poolie> vila: "I'm done, we got lots of things finished, please keep the balls in the air"
[08:57] <vila> poolie: k
[08:57] <bialix> okay, it seems jam fixed something yesterday when I'm whinning about this
[08:57] <poolie> bialix: your mails are not in the clicky admin interface :-(
[08:57] <poolie> unless they now got through
[08:57] <bialix> hi poolie, vila
[08:57] <poolie> vila, say something inspiring/exciting
[08:57] <vila> poolie: :D
[08:57] <poolie> it is really good that we're getting on top of these things :)
[08:57] <vila> bialix: hello spammer
[08:57]  * vila hides
[08:57] <bialix> ok, today is better day, at least couple of my answers reached ML actually
[08:58] <bialix> lifeless: poolie: sorry for disturb, I hope now it's sorted
[08:58] <poolie> np
[08:58] <poolie> let us know
[08:58] <poolie> if you have troubles
[08:58] <bialix> vila: :-D
[08:58] <poolie> i should really go
[08:59]  * bialix likes jokes of vila, no need to hide
[09:10] <gerard_> hey
[09:10] <vila> hi gerard_
[09:13] <bialix> igc: ping?
[14:06] <Tak> nice lp/bzr article on ars
[14:10] <vila> Tak: url ?
[14:12] <rubbs> http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
[14:12] <vila> hmm, fresh :D
[14:13] <vila> rubbs, Tak : thanks
[14:13] <rubbs> np
[14:14] <rubbs> I haven't read it all, but it seems pretty good
[14:15] <bialix> hi abentley, today I've encountered strange problem with shelving part of hunk with the editor
[14:15] <bialix> bug https://bugs.launchpad.net/bugs/520461
[14:15] <bialix> abentley: am I'm doing something really wrong this is just unsupported use case?
[14:16] <bialix> abentley: am I'm doing something really wrong *or* this is just unsupported use case?
[14:16] <bialix> rubbs: there is qbzr! :-)
[14:16] <vila> bialix: have a break, read the above url, there talking about you :D
[14:16] <vila> rats, too slow
[14:17] <bialix> vila: I saw the pictures
[14:17] <abentley> bialix, I don't understand.
[14:17] <jam> bialix: I pushed your emails through the admin, yes they were trapped as potential spam
[14:17] <jam> morning vila
[14:17] <abentley> bialix, you are actually editing a patch?
[14:17] <bialix> abentley: what exactly
[14:17] <vila> morning jam !
[14:17] <bialix> abentley: yes
[14:17] <bialix> morning jam! thanks!
[14:18] <rubbs> that article links to "quickly" i didn't know that existed. That's pretty nice.
[14:18] <bialix> abentley: if you will look on my files in the zip you can see the end result of new file which I've edited and saved
[14:19] <bialix> I've tried several attempts with no luck
[14:19] <abentley> bialix, it doesn't sound like an unsupported use case.  As long as you're saving the new version, not the old version.
[14:20] <abentley> bialix, I don't really have time to investigate right now.
[14:20] <bialix> the old version is read-only, I can't edit it
[14:20] <bialix> ok
[14:27] <Tak> hahaha - "Please stop working on this. You could be taking the jobs of programmers by offering this for free."
[14:32] <rubbs> Tak: where is that from?
[14:32] <Tak> oh, it's one of the comments on the article: http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars/3?comments=1&comment_id=156008433041
[14:34] <rubbs> ah... obviously a troll
[14:51] <thread_au> Hi there, I'm going to struggle to make my question concise, but I'll have a go...
[14:51] <jcastro> lifeless, ends up the db changes needed for +patches won't land until 1 March.
[14:51] <thread_au> i have a no-tree repository, which I'm endeavoring to use via light-weight checkouts when necessary.
[14:52] <thread_au> however, 1 or two folders that I would consider "branches" (have the .bzr directory in them, and happily support checking out, with revisions then showing up in bzr-explorer) don't seem to want to merge
[14:54] <thread_au> bzr: ERROR: No WorkingTree exists for "file:///H:/My%20Documents/Projects/FreescaleMPCCA/trunk/.bzr/checkout/".
[14:54] <thread_au> I feel I haven't given quite enough information to make a proper question but I'm not sure what to give...
[14:56] <rubbs> I don't know if I can help solve, but I can help clarify for others here. (help get to the bottom of the problem).
[14:57] <thread_au> sure thing
[14:57] <maxb> thread_au: When in doubt, pastebin a copy/paste of a terminal window showing exact commands that you ran and what they printed
[14:57] <rubbs> so you are using bzr-explorer with two tree less branches you wish to merge.
[14:57] <thread_au> I'm mainly using tortoise-bzr with bzr-explorer just to keep an eye on what it considers in the shared repo
[14:59] <rubbs> at the time of the merge are their working trees present?
[15:00] <thread_au> only in the checkout
[15:00] <thread_au> (trunk at this point contains no revisions however)
[15:01] <thread_au> well, it has one now, as I added one in case that was the problem
[15:01] <thread_au> I have one treeless repo, within which I created a folder "trunk", which I ran "init" on. Then used "branch" to create a branch called "beginning".  To perform work I created a lightweight checkout from beginning, which seems to commit fine. bzr-explorer reports that there are "changes not in parent branch" (as expected)
[15:02] <thread_au> in my head I should then run "merge" from trunk folder to propagate teh changes there.
[15:02] <fullermd> You run 'merge' from inside the/a working tree for the branch you want to merge into.
[15:02] <thread_au> so lightweight checkout from trunk
[15:02] <thread_au> and then merge to there?
[15:03] <thread_au> sounds reasonable
[15:04] <thread_au> it seems i was led astray by a bugreport i was just reading if that's the case
[15:04] <fullermd> Being as how merge sets up information to be committed, it would be difficult to do it without a WT  ;)
[15:04] <thread_au> but bzr is magic! :P
[15:04] <thread_au> (I was reading this https://bugs.launchpad.net/bzr/+bug/91614)
[15:05] <thread_au> which seemed to say that trees were not necessary, but that was for a pull
[15:05] <thread_au> nice bot function btw
[15:06] <fullermd> Right, pull just moves existing revisions around, so there's no need for a tree.
[15:06] <fullermd> Merge set up pending info to be committed, so that has to go SOMEwhere.
[15:11] <thread_au> (just squirrelling away...)
[15:20] <guilhembi> jam: thanks a lot for your answers re: annotate, re:push/pull/1.9/1.14, lots of food for thought!
[15:32] <thread_au> thanks fullermd and rubbs
[15:32] <thread_au> the merge worked (well... attempted) which gave me more stuff to figure out that i have been working
[15:32] <thread_au> and the command line feels a lot tighter I think now I'm using it
[15:33] <rubbs> thread_au: glad you found help. sorry I couldn't help more myself.
[15:34] <thread_au> you asked the right question actually
[15:34] <thread_au> regarding trees
[15:34] <rubbs> meh, dumb luck on my part ;)
[15:34] <thread_au> so much terminology to get my head around
[15:34] <rubbs> it's hard at first, but working through it for a few weeks will really help.
[15:35] <rubbs> and once you get it, it's almost like a light turns on. it becomes much more easy after that
[15:35] <thread_au> stuff like "push vs send" and "pull vs update"
[15:35] <thread_au> (I think i have pull vs update sorted :)
[15:35] <thread_au> at the moment, trying to figure how push/submit/send/parent branches are meant to be set up/related
[15:35] <rubbs> yeah, those are hard, because the differentiation isn't within the term itself, which I think makes it the hardest.
[15:37] <thread_au> and why I couldn't merge to trunk without putting in -r0..-1
[15:37] <rubbs> push is to copy the whole history to the target location. Parent is the branch which you branched from. submit I'm not too sure to be honest, and send I believe is a way to send patch info through email.
[15:37] <thread_au> which I didn't quite understand.
[15:37] <rubbs> mmm... not sure on the merge thing.
[15:37] <thread_au> so far so good
[15:37] <thread_au> I'm used to manpages and such so I'll get there
[15:37] <thread_au> although...
[15:37] <thread_au> "man" doesn't work here on windows :-/
[15:38] <thread_au> so off to the browser it is
[15:38] <rubbs> haha. try bzr help
[15:38] <rubbs> or bzr help topics
[15:38] <thread_au> additionally...
[15:38] <rubbs> that got me through a lot
[15:38] <thread_au> are these terms bzr specific?
[15:38] <rubbs> some, but most are DVCS specific
[15:38] <thread_au> because I haven't really tried other systems and I'm not sure if that's why it's pretty uphill
[15:38] <rubbs> so many terms will work in Git and in Hg.
[15:38] <fullermd> If you had to put in -r0..-1, it's because the branches didn't share any common ancestry at all.
[15:38] <jam> guilhembi: yeah, sorry the answer wasn't better for you
[15:38] <fullermd> (and while there are many times you'd want to do that, you'd probably know it if you did)
[15:39] <thread_au> fullermd: this is what I guessed based on the error message, although 'b' was branched from 'a', and I wanted to merge back...
[15:39] <thread_au> I guess the issue was 'a' was empty when i branched off
[15:39] <thread_au> and then one empty file was added to 'a'
[15:40] <thread_au> which may have made them appear like there was no (real) ancestry.
[15:40] <fullermd> Well, it causes that appearance because that's the case   :)
[15:40] <fullermd> There's no meaning to "ancestry" aside from "what revisions are present".  Two branches sharing no revisions share no ancestry.
[15:50] <thread_au> Alright
[15:50] <thread_au> i really should go to bed, thanks to those who had helped
[15:50] <thread_au> it was a bit of a panic as It hought I mostly had grasped the concept of DCVS but then things started behaving not hwo I expected
[15:51] <thread_au> in any case, I'll likely see one or more of you again - I get the feeling learning this properly will be like getting the hang of gentoo was a while back
[15:51] <thread_au> which means the "give and learn" of IRC will be more than useful
[16:05] <guilhembi> jam: I'd like to prepare a MySQL repository converted to 2a, for sharing with my colleagues, so it's important that I don't give them something bad; I have bzr.dev of Feb 4th, is that good enough for generating the repo ?
[16:05] <guilhembi> I just would like to make sure that it does not contain an important bug...
[16:06] <guilhembi> jam: and also, after a computer poweroff/poweron, can I safely delete "obsolete_packs/*" (to not send them useless files)?
[16:07] <jam> guilhembi: after a 'sync' it is safe to delete obsolete_packs
[16:07] <jam> generally probably after a few seconds it would be safe
[16:07] <jam> the key is that *bzr* can't really know when the os finishes writing to disk
[16:07] <jam> in case there is a power outage, etc.
[16:07] <jam> guilhembi: bzr.dev from Feb4 should be fine
[16:08] <guilhembi> jam: ok, so as a clean shutdown includes a sync, I am safe with deleting...
[16:08] <jam> yeah
[16:08] <guilhembi> jam: thanks a lot.
[16:08] <jam> also, watch out for '.bzr/repository.backup' and 'backup.bzr'
[16:09]  * guilhembi checks
[16:17] <guilhembi> jam: regarding the impossible-to-fix annotate slowdown, I don't know what to do. Speed is the main reason for upgrading the 100 guys, and the speed gain is not so clear due to this annotate thing. I'm looking for something compelling to announce... is there some other command than "bzr log" which gets a speedup with 2a? some other command than "bzr annotate" which gets a slowdown?
[16:17] <jam> bzr log -v
[16:17] <jam> went from hours to minutes on bzr.dev
[16:17] <guilhembi> ok (but almost nobody uses it)
[16:17] <guilhembi> ahah
[16:17] <jam> du -ksh .bzr
[16:17] <jam> went from 600+MB to 200MB
[16:17] <guilhembi> yes, observed this
[16:17] <jam> so initial branch should be ~3x faster
[16:18] <jam> push + pull are faster similarly, though not always universally
[16:18] <guilhembi> jam: eof?
[16:20] <jam> guilhembi: you mean eol handling, or am I done talking?
[16:20] <guilhembi> jam: done talking :-)
[16:20] <jam> sorry, I've got a couple of conversations going on
[16:21] <guilhembi> jam: don't worry, this isn't urgent. I didn't mean to be pressing.
[16:22] <guilhembi> bbl
[17:25]  * bialix wonders what is the site arstechnica.com
[17:26] <rubbs> bialix: at tech news site that covers lots of topics having to do with Sci/tech.
[17:26] <rubbs> a tech*
[17:27] <bialix> thx
[17:27] <jam> rubbs, bialix: Interestingly their "About Us" link at the bottom of the page is a 404...
[17:27] <bialix> jam: yep, I saw this too, hence my question
[17:27] <poolie> hello jam, bialix
[17:27] <jam> hi poolie
[17:28] <jam> taking a light nap again :)
[17:28] <poolie> :)
[17:29] <bialix> hey poolie, your night is over?
[17:30] <poolie> unfortunately so :)
[17:30] <bialix> :-)
[17:30] <poolie> i was in london last week so i'm waking up early
[17:30] <jam> its what, 5am there?
[17:31] <bialix> 5pm
[17:31] <jam> in Sydney it is ~5am
[17:31] <poolie> 4:30
[17:31] <poolie> am
[17:31] <bialix> ah, I've talked about London
[17:31] <jam> which is why poolie is sad
[17:34] <bialix> so, 2.1?
[17:35] <bialix> is there some blockers?
[17:35] <poolie> good question
[17:35] <poolie> i don't think so
[17:35] <poolie> we should do it
[17:36] <jam> I was meaning to ask around today
[17:36] <jam> I haven't seen bzr-explorer 1.0 final
[17:36] <jam> vs beta
[17:36] <bialix> I can pack the one.
[17:36] <bialix> just today I've synch'ed translations
[17:37] <bialix> maybe we need final word from igc
[17:38] <bialix> but there is no major changes in explorer trunk since Ian called it rc1
[17:39] <bialix> jam: I would say: I can pack 1.0rc1
[17:41]  * bialix has to go
[17:49] <poolie> that sounds ok to me too
[17:50] <poolie> jam, did we ship rc1 in the last bzr rc?
[17:50] <jam> no
[17:50] <jam> I didn't do an rc3 last week because of the car stuff
[17:50] <jam> I was just going to do a final, but I can do something different if you prefer
[17:54] <poolie> well, i'm just a bit concerned that ian has put in a large change in explorer
[17:54] <poolie> but maybe we should just ship it, and if it is broken it's on his head
[18:05] <poolie> jam, thanks for all the bug triage
[18:05] <jam> I've actually found it pretty interesting
[18:05] <jam> I'm going through the "new" bugs
[18:05] <poolie> i see :)
[18:05] <poolie> i wish i'd set up a graph
[18:06] <poolie> but it's not too late
[18:06] <jam> well, if lp apis could tell you the date when something happened
[18:06] <jam> I got through what... 30 new bugs
[18:06] <jam> still have 194 to go :)
[18:12]  * jam goes and forages for food
[18:17]  * jelmer hopes Dmitrijs isn't going to invite every bug he's ever communicated with to join LinkedIn...
[18:28] <poolie> urk
[18:28] <fullermd> So informal, too.  It should be "Mr. Bug".
[18:29] <mkanat> lol
[18:33] <jam> jelmer: probably just the ones that get marked Invalid
[18:33] <jam> we should be warned :)
[18:34] <jam> speaking of which, how the heck did "Carson Coker" get his ad through to bazaar@?
[18:34] <jam> maybe an accidental "accept" ?
[18:35] <poolie> maybe
[18:43] <poolie> jam i didn't see any mail from him but maybe my spam filter caught it
[18:45] <poolie> so we have 9 bugs currently inprogress
[19:07] <bjp> how do i globally disable loggerhead as a plugin?
[19:12] <gerard_> hey
[19:15] <poolie> hi gerard_
[19:15] <poolie> bjp: just move it out of the plugins directory
[19:20] <bjp> poolie: where is the global directory?
[19:20] <jam> poolie: https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.status=In+Progress has 60
[19:20] <poolie> sorry, i meant to say 9 fixcommitted
[19:20] <poolie> which should be even closer to being ready
[19:20] <jam> which I also don't think is particularly accurate
[19:20] <poolie> bjp, how did you install it?
[19:20] <poolie> bjp, maybe i should also ask, why do you want to disable it?
[19:21] <bjp> it's giving me this error whenever i try to push/pull from the server: Unable to load plugin 'loggerhead'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages ...
[19:22] <maxb> Where is loggerhead installed? Is it systemwide or someone's home directory?
[19:23] <poolie> bjp,and you have a later bzr on the server?
[19:23] <bjp> well, i just recently installed it into /opt/loggerhead
[19:23] <bjp> yea, 2.1
[19:23] <bjp> from bzr branch
[19:24] <poolie> jam, for interest, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/520625
[19:24] <maxb> "<module 'bzrlib' from '/usr/lib/python2.6/dist-packages" does not sound like 2.1 from a bzr branch to me
[19:24] <bjp> i mean loggerhead is from bzr branch
[19:24] <poolie> max i think that's where bzr is
[19:24] <poolie> bjp you need to either upgrade or uninstall it
[19:25] <bjp> which?
[19:25] <bjp> i'm using loggerhead as a stand alone server, i don't need it as a plugin
[19:25] <maxb> Oh, is there a loggerhead 2.1 now? I assumed that was a bzr version
[19:25] <bjp> yea it was, i'm using bzr 2.1, and loggerhead's latest bzr checkout
[19:25] <bjp> sorry i didn't post the full error, i didn't want to spam
[19:26] <rubbs> bjp: could you pastebin it?
[19:26] <bjp> sure
[19:26] <rubbs> !pastebin
[19:27] <bjp> http://pastebin.com/m76ad4015
[19:27] <maxb> bjp: Also please confirm the bzr revno of loggerhead that you are using
[19:28] <bjp> 400
[19:28] <maxb> That error you paste should not be possible
[19:28] <bjp> i figured i could just remove it from the plugins dir, but i'm not sure where global plugins are
[19:29] <maxb> Is it possible you also have an older loggerhead installed?
[19:29] <bjp> not possible??
[19:29] <bjp> maybe... :)
[19:29] <maxb> Sorry, not possible with loggerhead r400
[19:29] <bjp> i installed the latest one in an isolated environment
[19:30] <maxb> I suggest 'locate loggerhead/__init__.py'
[19:30] <bjp> i ddin't even look to see if there was another one
[19:30] <bjp> oh there was one in the package manager
[19:30] <bjp> that fixed it :)
[19:33] <lifeless> jcastro: :(
[19:43] <poolie> hi lifeless
[19:46] <fullermd> poolie: Err?  bug 130783 isn't "fix released" AFAIK...   the generated files are still there.
[19:46] <poolie> the .so files?
[19:46] <fullermd> No, the .c files.
[19:49] <poolie> yes but that wasn't actually his complaint
[19:49] <fullermd> Well, it was [part of] mine, and it was my bug   :)
[19:50] <poolie> ok
[19:53] <fullermd> The .so bit was taken care of looks like a few months after the bug was filed.  I'd still like to whack the .c's though.
[19:54] <fullermd> e.g., when I upgrade pyrex or python or the like.
[20:02] <jcastro> lifeless, poolie: http://arstechnica.com/business/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
[20:03] <jcastro> if someone could answer the guy's question about netbeans bzr that would be great.
[20:06] <poolie> fullermd: i  reopened it
[20:07] <poolie> jcastro: there is no netbeans integration atm afaik
[20:08] <jcastro> poolie, ah bummer, I found some stuff on searches but it looks old and out of date.
[20:08] <jcastro> poolie, mostly I just wanted to make sure you guys were aware of the discussion, seems like the article is very popular right now
[20:09] <poolie> thanks
[20:09] <poolie> i only glanced at it but will read it now
[20:14] <fullermd> Hm.  Is anybody else actually using cython instead of pyrex?
[20:15] <fullermd> It seems to blow all sorts of bright-colored chunks for me.
[20:16] <bob2> outside of bzrland?
[20:16] <fullermd> No, with bzr.
[20:17] <mtaylor> anybody around with good grokking of the interaction between bzr-builddeb and dpkg v3.0 (quilt) from a workflow perspective?
[20:18] <lifeless> garhk
[20:26] <mtaylor> lifeless: that's how I feel!
[21:08] <poolie> jam, still around?
[21:08] <jam> poolie: yep
[21:08] <poolie> so, 2.1?
[21:10] <jam> as in, you want me to release it today?
[21:10] <poolie> well, shall we?
[21:10] <poolie> it doesn't even specifically have to be you
[21:10] <poolie> i just want to work out where we're going
[21:10] <jam> I think it is about time to do so
[21:34] <poolie> ok, so can you do it on friday, or do you want someone else to?
[21:34] <poolie> also maybe we can get a new rm
[21:34] <poolie> lifeless: i crave review of https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079
[22:04] <fullermd> jam: BTW, you can actually run bzr with cython?
[22:06] <poolie> lifeless: is there anything specific that drupal actually want help with?
[22:06] <poolie> that's a long thread
[22:06] <jam> fullermd: I don't think you can run all of bzr with cython, but you can compile the extensions with cython
[22:07] <jam> (and we do that automatically if pyrex isn't available)
[22:07] <poolie> fullermd: btw please don't say 'error' if you mean 'warning'
[22:07] <fullermd> Well, it compiled fine here, but it wouldn't run at all.
[22:07] <jam> poolie: your test won't run on Windows
[22:07] <poolie> that's why i thought there would be a bug or news entry
[22:07] <poolie> ah
[22:07] <poolie> jam, true
[22:07] <poolie> well,
[22:08] <poolie> it's meant to be a per-tree test
[22:08] <poolie> so in theory it would work on some trees
[22:08] <jam> poolie: if you like, you can skip it
[22:08] <jam> but mkdir tree; touch Tree will pretty much always fail
[22:08] <lifeless> poolie: the mails I'm forwarding are from chx; he's keen to see us provide advice on what bzr can do and how, and is drawing attention to specific points.
[22:08] <fullermd> Just wondered whether that was expected.
[22:08] <jam> poolie: I think you could use BranchBuilder instead of build_tree
[22:09] <lifeless> poolie: emmajane or davidstrauss will have opinions too :)
[22:09] <poolie> i suspect that test file is a bit inaccurate about actually testing the right class
[22:09] <jam> as that builds using a memory tree
[22:09] <poolie> jam, sometime soon i'd like to systematically rework one test file to separate all the creation
[22:09] <poolie> into a 'test factory'
[22:10] <poolie> but maybe not using that name as it's odoriferous to launchpad devs
[22:11] <jam> :)
[22:12] <poolie> winepython does actually fail on those tests
[22:12] <poolie> which is nice
[22:15] <jam> poolie: ideas for codename for 2.1.0?
[22:16] <poolie> um, i did have a good one
[22:17] <poolie> are you doing it now?
[22:18] <poolie> actually i'd just call it Strasbourg
[22:22] <jam> yeah, I'm writing up NEWS, etc
[22:23] <jam> poolie: should we try to do a summary of what 2.1 is vs 2.0?
[22:23] <poolie> yes
[22:23] <poolie> i think perhaps we should fold that all up into the summary paragraph of 2.1
[22:23] <poolie> rather than per-beta things
[22:23] <poolie> oh also
[22:23] <poolie> we shouldn't put 'not released yet' into the headings
[22:24] <poolie> because it makes the html look a bit messy
[22:24] <jam> poolie: can we put it on the release date line?
[22:24] <jam> :2.1.0: (not released yet)
[22:24] <jam> ?
[22:25] <poolie> yes i think that'd be good
[22:26] <poolie> after making a memorytree, how do i add the root so that i can start adding other stuff?
[22:30] <spiv> tree.add('') ?
[22:31] <poolie> nup
[22:31] <poolie> use treebuilder apparently
[22:31] <spiv> I think that's what BranchBuilder attempts to do, anyway.
[22:37] <poolie> i don't actually want a branch
[22:37] <poolie> it should be enough to test this on just a tree
[22:37] <poolie> but that may be easiest
[22:47] <poolie> blah
[22:47] <poolie> some of the per_tree things assume it's a real working tree on disk
[22:56] <Kilroo> Hm. If there's a ticket that would address the ability to create a branch bound to and stacked on a subversion repository, I can't seem to find it.
[22:56] <Kilroo> Probably searching for the wrong thing.
[22:59] <lifeless> Kilroo: well you want cross format stacking
[23:03] <Kilroo> that or a solution to my problem with bug 109114 that doesn't amount to "using bzr to interact with this svn repo requires a 64-bit operating system."
[23:04] <Kilroo> Well, correction. Lightweight checkouts still work.
[23:05] <Kilroo> Just slowly, and they don't gain me anything. On the repositories that don't run into that problem I can use local feature branches.
[23:11] <spiv> Kilroo: the large files are some way back in history, IIRC?
[23:11] <spiv> Kilroo: the other feature that isn't implemented yet, but might help you if it was, is "shallow branches".
[23:12] <Kilroo> The one that I'm certain is actually one specific file is probably about half a dozen to ten commits back or so.
[23:14] <Kilroo> The other branches that hit the out of memory error, the revision I can't pull is well back in the history and I am not certain if there's a large file that is the culprit or if it is just the fact that a gigantic lump of filesystem was committed all at once.
[23:15] <Kilroo> But yes, if I could have a shallow bound branch, that would work too. In fact, I was pretty much thinking of a stacked bound branch as being a surface-level shallow bound branch, in terms of functionality.
[23:16] <Kilroo> I honestly hope, though, that we will redo our repository arrangement at work in the near future, in a way that would make most of my problems disappear just by getting rid of all the crap that doesn't make sense.
[23:17] <zombor> anyone know of a plugin to push bzr into git repos?
[23:17] <bob2> the bzr git plugin?
[23:17] <spiv> Kilroo: Right, although bug 375013 probably stops stacked branches from being a solution for you atm.
[23:18] <zombor> bob2: this says push is not supported: https://launchpad.net/bzr-git
[23:18] <zombor> i want to work with github repos, but i dont want to use git
[23:18] <bob2> ok
[23:19] <Kilroo> Hm.
[23:19] <Kilroo> Yeah, looks that way.
[23:19] <zombor> ive found git -> bzr but not the other way around
[23:23] <Kilroo> From what I've read, the closest I've found to a way to use bzr to work with a git repository would be to pull stuff into bzr, work in bzr, and get everything back into git by generating patches.
[23:24] <Kilroo> Still requires working with git.
[23:24] <Kilroo> I've never tried even doing that though.
[23:26] <zombor> Kilroo: yeah, sounds icky
[23:26] <zombor> might as well work right with git ;)
[23:28] <Kilroo> spiv: Actually, I think the workflow I want to use would mean that stacked branches would work just fine, because the stacked branch would be in a treeless repository and would not receive commits directly. Without being able to test what I have in mind, I can't be sure, though.
[23:29] <spiv> Kilroo: well, that bug also stops you making commits to a stacked branch from a lightweight checkout of the stacked branch.
[23:29] <Kilroo> That was what I was about to say I wasn't sure of.
[23:30] <Kilroo> ...
[23:30] <Kilroo> What if you committed to a lightweight checkout of a branch bound to the stacked branch?
[23:30] <Kilroo> Never mind answering that, because I'm not even sure what the heck I just said.
[23:30] <fullermd> Creating that bound branch would copy over the whole history, in which case you might as well skip the stacked middleman, and you wind up back with your original problem  :p
[23:31] <spiv> fullermd: or the bound branch itself could be stacked too, which still leaves you with the original problem ;)
[23:31] <Kilroo> Oh.
[23:31] <Kilroo> Oh well.
[23:31] <spiv> Basically, if it were that easy to workaround, we'd have fixed it already :/
[23:32] <fullermd> But then you could...  you just...   well, you ca!@&$(%  Stack size exceeded (core dumped).
[23:34] <Kilroo> Yeah, sounds to me like we're more likely to fix things at work so that it's not an issue before a fix lands in bzr