[10:24] <sobersabre> hi.
[10:25] <sobersabre> I am trying to resolve conflict
[10:25] <sobersabre> (I mean in bzr)
[10:26] <sobersabre> and I think if I need to "take this", I should run:
[10:26] <sobersabre> bzr resolve --take-this filename.txt
[10:26] <sobersabre> but this DOESNOT resolve.
[10:26] <sobersabre> what is the syntax for actions ?
[10:43] <sobersabre> anyone alive ?
[12:54] <LeoNerd> Hrmm... Any bzr command in one workdir here is just giving me:  bzr: ERROR: pack-names is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[12:57] <LeoNerd> For reference, my .bzr/repository/pack-names file - http://paste.leonerd.org.uk/?show=1232
[13:22] <maxb> LeoNerd: interesting... I've only seen pack-names that are "B+Tree Graph Index 2" format
[13:23] <LeoNerd> I had some other workdirs that looked very similar, those worked
[13:23] <LeoNerd> I've managed to work by just checking out again, seems happy
[13:27] <AfC> sobersabre: just do
[13:27] <AfC> $ mv file.txt.THIS file.txt
[13:27] <AfC> $ bzr resolve file.txt
[14:35] <sobersabre> hi.
[14:35] <sobersabre> I have a bzr branch, and I want to push changes to it (remotely).
[14:35] <sobersabre> I want to override any file that is not like the pushed ones.
[14:36] <sobersabre> I currently run a merge. I think this is not correctly the thing I want.
[14:36] <sobersabre> I want to simply put the changes and commit'em.
[14:36] <sobersabre> And if athe target branch has uncommitted changes, I want to quit the operation.
[14:36] <sobersabre> which bzr command best fits my description ?
[14:38] <sobersabre> I am now reading the fine manual of push: bzr --strict --overwrite push /branch/name I think is what I want.
[15:33] <pluma> I'm used to creating a bare git repository on my virtual linux testing server, cloning it on my windows desktop via SSH and pushing back from the shell. How can I recreate this workflow with bazaar?
[15:34] <pluma> Note: my virtual linux server may or may not be online, so it is important that the push is triggered manually.
[15:42] <maxb> pluma: 'bzr init-repo --no-trees path/to/repo' on the server
[15:43] <pluma> maxb: Can I make bzr use defaults so I don't have to type out the full repository path everytime I type "bzr push", too?
[15:43] <maxb> bzr will remember the first-used push and pull locations automatically, and use them if no location is specified
[15:44] <pluma> Ah, good.
[15:44] <maxb> afterwards, you can use push/pull --remember to reset the remembered location
[15:44] <pluma> Ah.
[15:45] <pluma> Should I have one repository shared among all projects or one repository per project? The docs confused me a bit about that.
[15:46] <maxb> For most purposes it does not really matter. In Bazaar, a repository is just a disk-space and time optimization
[15:47] <maxb> So, it's important that branches of a project reside in one repository, to get those advantages of not needing to store revisions twice
[15:47] <maxb> Personally I prefer to go one repository per project, but there's no harm to multiple projects residing in a single repository
[15:48] <maxb> Except that if you ever did need to separate them, you'd have to branch each branch into a new shared repository of smaller scope, rather than just being able to move directories around on disk
[15:57] <pluma> maxb: Okay, I did init-repos and init on the server, checked out locally, shut down the server and committed. The commit failed because the server can't be reached. Is there a way to make it _not_ auto-push?
[15:58] <maxb> Ah, it's only trying to do that because you used 'bzr checkout' rather than 'bzr branch'. To change the behaviour of an existing checkout, use 'bzr unbind'
[16:01] <pluma> Okay. I unbinded, committed successfully, restarted the server, pushed successfully and am a happy bunny. You're saying I won't need to specify the target when pushing again?
[16:03] <pluma> maxb: Thanks for the help so far. I'm a bit surprised that I found the initial hurdles of bzr bigger than those of git (probably because of the shared repos), but I'm excited to see how this will turn out in the long run.
[16:18] <pluma> Any thoughts on fossil?
[17:02] <jam> lifeless: https://code.launchpad.net/~jameinel/lp-production-configs/lp_service_qa_staging/+merge/43921
[18:51] <knighthawk> I've set up a central repo. But when members of my team check out they are getting different revisions. Like the latest is rev 11 one team member is able to get that one but another is only able to get up to 9 and another can only get rev 7
[18:52] <knighthawk> I haven't had them ask for rev 11 yet. Wondering what I did wrong in setting up the central repos that they are seeing this.
[18:53] <jelmer> knighthawk: how are they creating their clone and how are they pullin gin new revisions?
[18:55] <knighthawk> bzr checkout to get their branch (though the eclipse plugin) and I think they are using bzr up to get new revisions.
[18:56] <maxb> Have you checked the exact URLs various people are using, by making them show you their 'bzr info' output?
[18:57] <jelmer> knighthawk: does the eclipde plugin use checkout, not "bzr branch"?
[18:59] <knighthawk> checking
[21:00] <knighthawk> okay no it *does* do a branch. Any reason that wouldn't allow them to access the Head?
[21:01] <knighthawk> rev 11 should be head at this point.
[21:01] <knighthawk> but when they branch they get rev 7
[21:01] <jelmer> knighthawk: if the branch is not bound they should use "bzr pull" rather than "bzr up"
[21:03] <knighthawk> okay I don't know too much about bounding except I did have to do that for myself. is it likely that they can set up bounding from a gui?
[21:06] <knighthawk> its still says "Tree is up to date at rev 7"
[21:07] <knighthawk> tried bzr bind
[21:14] <knighthawk> just forced a checkout.
[21:15] <knighthawk> I'm noticing that when I run bzr info I'm getting submit branch and when they do they do not.
[21:35] <jam> spiv: https://code.launchpad.net/~jameinel/bzr/2.3-update-from-readonly-701212/+merge/45760
[21:38] <poolie> looks good to me
[22:02] <lifeless> jam: btw - https://lp-oops.canonical.com/oops.py/?oopsid=1834CBB6546
[22:02] <lifeless> jam: we're not showing codebrowse oops properly
[22:03] <lifeless> jam: if poolie is there, can you poke him onto irc
[22:03] <jam> lifeless: he is here, I'll poke him, but when I go to that page, I get nothing
[22:03] <jam> just a search box
[22:03] <lifeless> jam: thats the openid login brokeness - see the url you ended up on :P
[22:03] <jam> lifeless: hmm,, re opening that page, I get something
[22:06] <lifeless> hi poolie
[22:06] <poolie> hi
[22:06] <lifeless> poolie: I've filed a couple of shallow loggerhead bugs that we're capturing now we get loggerhead bugs
[22:06] <poolie> ?
[22:06] <lifeless> s/bugs/oopses/
[22:06] <poolie> ok
[22:07] <lifeless> we're getting 16000 oopses a day
[22:07] <poolie> hooray
[22:07] <lifeless> https://bugs.launchpad.net/loggerhead/+bugs?field.tag=oops
[22:07] <lifeless> in launchpad we treat oops as higher-than-high bugs today
[22:07] <lifeless> in the new triage process we'll treat them as critical
[22:07] <poolie> bug 700,000 hey?
[22:08] <lifeless> I'm wondering if you can ok mkanat to look at these?
[22:08] <poolie> if he has time i'm very happy for him to
[22:08] <lifeless> he said to talk to you :)
[22:08] <poolie> ok, loop closed then
[22:09] <mkanat> poolie: You mean if I have time after the things we've already discussed?
[22:09] <lifeless> later today I should get the first frequency analysis of these oopses
[22:09] <poolie> what's in your queue now?
[22:09] <poolie> mkanat, ^
[22:10] <mkanat> poolie: Etags and then performance of single requests.
[22:11] <poolie> i think it's fair to treat these ahead of them
[22:11] <poolie> because they're actually failures
[22:11] <mkanat> poolie: Okay. Even if it means not getting to those?
[22:11] <poolie> yes
[22:11] <mkanat> poolie: Okay.
[22:11] <poolie> https://bugs.launchpad.net/loggerhead/+bug/701256 is kind of interesting
[22:12] <poolie> in a way, it is valid for it to be a bug
[22:12] <poolie> i mean an oops
[22:12] <poolie> it's an error meaning we can't show the branch to the user
[22:12] <mkanat> Yeah, I mean, I'm not sure that I want to mask every single possible bzr error from the user.
[22:12] <catphish> what network protocols does bzr support for cloning / publishing?
[22:13] <poolie> ftp, sftp, ssh, http
[22:13] <poolie> you can add others
[22:13] <catphish> great :)
[22:14] <poolie> mkanat, so i'd probably do the other two first
[22:30] <mkanat> lifeless: Are the ones you're reporting ones that you know to be frequent, or do you not have any frequency analysis at all yet?
 later today I should get the first frequency analysis of these oopses
[22:32] <mkanat> lifeless: Okay. Once you have that, let me know and I will fix the most frequent ones first.
[22:50] <lifeless> james_w: ping
[22:50] <james_w> hi lifeless
[22:50] <lifeless> mkanat: I would start with any
[22:51] <mkanat> lifeless: I only have a limited amount of time available.
[22:51] <lifeless> james_w: could you spare a few minutes to look at a bzr-builddeb pristine-tar-using-failure with me and ncommander in presidente on 3?
[22:51] <mkanat> lifeless: It's not a scheduling matter; it's a contract thing.
[22:51] <james_w> lifeless, sure, 2 minutes and I'll be there
[22:52] <lifeless> mkanat: sure, uhm the KeyError one worries me most in terms of correctness
[22:52] <lifeless> mkanat: the other two worry me in potential volume
[22:53] <mkanat> lifeless: Okay. Well, you'll have the analysis later today, right?
[22:53] <mkanat> lifeless: So then we won't have to worry too much about potential volume, we can just know for sure what's got the highest volume.
[23:05] <jam> vila
[23:05] <jam> vila
[23:05] <jam> vila
[23:06] <james_w> lifeless, http://paste.ubuntu.com/552623/
[23:06] <jam> I was trying to figure out what timer was going off
[23:06] <james_w> lifeless, something to do with export + .bzrignore?
[23:07] <mkanat> lifeless: The KeyError one does sound like something that shouldn't ever be happening, though.
[23:07] <mkanat> And that I did fix.
[23:11] <lifeless> james_w: is bzr-builder integrated with pristine-tar yet ?
[23:11] <james_w> lifeless, no
[23:14] <james_w> lifeless, so, pristine-tar gets unhappy if you don't give it all the files, and we provide those files by exporting the tree, so .bzr* will be missing. My hunch is that we can get away with providing /more/ files that pristine-tar needs, so we could use sprout rather than export, or add a hack and manually export any .bzr* files in the tree
[23:15] <lifeless> argh!
[23:17] <jam> vila
[23:28] <mkanat> lifeless: Oh, somehow sourcedeps never got updated to pull in the loggerhead that had the fix for that KeyError.
[23:33] <mwhudson> mkanat: ! :(
[23:33] <mkanat> mwhudson: I know.
[23:33] <mkanat> mwhudson: I'm proposing a merge for that now.
[23:34] <mkanat> https://code.launchpad.net/~mkanat/launchpad/lp-loggerhead-update/+merge/45787
[23:38] <lifeless> james_w: what does builder do for v3?
[23:38] <james_w> lifeless, falls over
[23:39] <lifeless> ok