[00:50] <stewart> hi! i have a "bzr pull --overwrite" (as part of jenkins build) that didn't, in fact, overwrite the tree.
[00:50] <stewart> instead the checkout failed :(
[00:50] <stewart> with can't delete and conflicts.
[00:51] <stewart> which then said "now on revision X"... but files appear to be missing
[00:57] <spiv> stewart: what does 'bzr status' report?  Does 'bzr revert' and or 'bzr clean-tree' help?
[00:58] <spiv> Also, I'm guessing the build products are in the same tree as the source?
[01:01] <stewart> spiv, yes, build products are there.
[01:01] <stewart> spiv, I get about every file under "removed"
[01:01] <stewart> spiv, and a bunch of renamed from foo to foo.OTHER
[01:01] <stewart> spiv, a usual set of "ignored" and a whole bunch of conflicts
[01:02] <stewart> spiv, befor etrying revert/clean-tree, any debugging info i can gather?
[01:02] <stewart> spiv, I've actually modified the jenkins bzr plugin so that on failure to check out it wipes the tree clean and tries again (solves the problem of bzr getting into unrecoverable state on killing it during checkout/pull)
[01:02] <stewart> spiv, and what's interesting here is that the bzr process completed "successfully"
[01:10] <spiv> stewart: it sounds like the usual "bzr produces a ton of conflicts when a tree update operation wants to delete a directory with unversioned files" bug
[01:13] <spiv> stewart: The config option mentioned in http://doc.bazaar.canonical.com/beta/en/user-reference/conflict-types-help.html#deleting-parent will probably help
[01:18] <stewart> spiv, other thought... would "bzr branch --stacked" work for checking out for jenkins builds? our problem for lightweight checkouts was the huge network IO of pulling everything down for each build, would we get any less with --stacked ? and should/does this work with "bzr pull --overwrite" ?
[01:18] <spiv> It will probably help, and it should work fine.
[01:19] <spiv> (It will definitely help a fair bit if jelmer got around to finishing my patch to it…)
[01:20] <stewart> spiv, we run a variety of bzr versions around as we have everything from lucid to centos5
[01:20] <stewart> spiv, so it's a bit of an adventure :)
[01:20] <spiv> Ah, heh.
[01:20] <spiv> Well, maybe it won't work out, but give it a shot :)
[01:20] <stewart> spiv, we've had fairly bad experiences with shared repositories on jenkins hosts whenever more than 1 process tries to do something with them at any one time.
[01:20] <spiv> Yes, Twisted has had the same problem.
[01:21] <spiv> There is (was?) a bug with concurrently inserting the exact same pack into a repo
[01:22] <spiv> Which is exactly what tends to happen when you want N builders to fetch and test the latest revision.
[01:22] <stewart> spiv, yep :)
[01:23] <stewart> spiv, so... jenkins does "bzr revision-info -d /path/to" and " bzr log -v -r revid:foo" ... should that fit with stacked on ?
[01:24] <stewart> spiv, because if so... we could just stack on the launchpad branches and be done with it...
[01:24] <spiv> Sure, stacking is transparent (aside from the cost of hitting the stacked-on repo over the network if you need to access data from older revisions)
[01:24] <stewart> spiv, (and i'd likely go and push this into the jenkins bzr plugin)
[01:25] <stewart> spiv, it never does that. it's only ever current revision or pulling a tree with --overwrite.
[01:25] <spiv> The downside stacking used to have is that you couldn't commit to a stacked branch, but that's fixed for 2a
[01:25] <spiv> (And has been for a year or so)
[01:25] <stewart> spiv, and a jenkins checkout should probably never be committed to anyway (the bzr jenkins plugin doesn't)
[01:25] <spiv> Right
[01:25] <stewart> spiv, as it's really just using bzr as a transport to get the latest tree.
[01:26] <spiv> Right.
[01:26] <spiv> Which is something that bzr really ought to support as a cheap operation!
[01:26] <spiv> And either creating a stacked branch or lightweight checkout are the obvious ways the UI provides that *should* do it.
[01:26] <stewart> spiv, when was stacked introduced?
[01:27] <stewart> spiv, yeah, the lightweight checkout isn't really lightweight :)
[01:27] <spiv> But I haven't kept up with bug fixes/new features, so I don't know if they have been fixed to meet that goal yet.
[01:27] <stewart> spiv, so, bzr revert seemed to fix things up.... I'm kinda tempted to add that to the standard bzr jenkins plugin checkout procedure.
[01:27] <stewart> spiv, it may have been fixed, but only in more recent versions... which is fun when you have ancient systems like CentOS 5
[01:28] <stewart> heck... until earlier this year we had debian 5
[01:28] <stewart> and centos5 will exist approximately forever.
[01:28] <spiv> (If not, I can point you to an old branch of mine on lp that is a working proof-of-concept for making stacking work reasonably fast for this case)
[01:29] <spiv> Well, so long as you can install bzr plugins, there's hope…
[01:29] <spiv> But first it requires that the bzr on the server (in this case Launchpad?) has the necessary features :)
[01:30] <stewart> spiv, yeah, we always point at launchpad trees, so it's a non issue for us :)
[01:31] <stewart> spiv, i gather things would explode if somebody put a sftp:// branch or something with --stacked ?
[01:37] <spiv> stewart: it won't be hugely efficient, but it shouldn't be utterly horrible either.
[01:39] <stewart> spiv, awesome. Basically it was a "should I make a configuration variable for this" :)
[01:39] <stewart> spiv, I'm kind of tempted to remove the functionality for checkouts and just replace it with stacked branches. I'm struggling to see the benefit of checkout over stacked branch.
[01:42] <spiv> stewart: probably they tickle different performance bugs depending on the bzr versions involved :/
[01:43] <spiv> (And really they ought to be about as efficient as each other for this use case)
[01:48] <stewart> spiv, yeah, ought to be but aren't :)
[01:59] <mwhudson> stewart: bzr super-revert is rm -rf *; bzr revert :)
[02:00] <mwhudson> (maybe bzr remove-tree --force; bzr checkout)
[02:03] <spiv> mwhudson: or 'bzr clean-tree --ignored --unknown --detritus; bzr revert' I think :)
[02:04] <mwhudson> spiv: yeah something like that
[02:04] <mwhudson> bzr ls -R0 | xargs -0 rm ?
[02:09] <spiv> mwhudson: then do alias hulk_SMASH='…'
[02:09] <mwhudson> :)
[06:27] <hacosta> i ran bzr mv on a directory, but then i regreted that, so i mv'ed them back
[06:27] <hacosta> and now when i run bzr status i get a bunch of renames that show the same path
[06:27] <hacosta> e.g
[06:28] <hacosta> a/b/foo.c => a/b/foo.c
[06:28] <hacosta> will that appear how do i remove that
[06:28] <hacosta> i haven't commited anything at this point
[06:30] <fullermd> That probably means something in the dir tree wasn't mv'd back, but took on a new identity.
[06:31] <fullermd> You can use revert to throw things back (trickier if you have content or nearby changes to preserve)
[06:31] <hacosta> i had a couple of modifications on some files :S
[06:40] <fullermd> Well, you could stash a diff and reapply it by hand.  Or try shelving.
[06:43] <bob2> bzr mv --help
[06:43] <bob2> tl;dr after or whatever it is
[12:10] <Oli> How do I drop all the changes in a working branch (so that it drops back to the state it was at the last commit)?
[12:10] <jelmer> Oli: 'bzr revert'
[12:11] <Oli> Duuh. Thanks jelmer!
[15:13] <jelmer> vila: https://code.launchpad.net/~jelmer/bzr/rm-get-ancestry/+merge/112090
[15:14] <jelmer> vila: https://code.launchpad.net/~jelmer/bzr-upload/install-lazy-named-hook/+merge/97942
[15:25] <jelmer> vila: bug 863261
[15:25] <jelmer> vila: triiiiing
[15:26] <jelmer> vila: and bug 544776
[15:44] <jelmer> vila: if you feel like doing more bzr reviews, I have some more.. :-)
[15:46] <vila> jelmer: trying to *commit* in all my pies currently ;)
[15:59] <jelmer> hehe, okay
[17:12] <dobey> hey all
[17:13] <dobey> so bzr 2.6 removes Hooks.create_hook() which was deprecated in 2.4, but switching code to use that breaks compat with bzr 2.1 and 2.3 which are shipped in lucid and natty
[17:14] <dobey> anyone have a suggestion how to deal with this in a reasonable way?
[17:14] <dobey> or does one just have to duplicate the calls by doing try/except?
[17:27] <dobey> i guess try/except with a bit of magic is the way to goo. nevermind me