[00:04] <poolie> good morning
[00:23] <pygi> poolie, hey :)
[00:24] <pygi> poolie, right, morning at 1:25AM :)
[00:24] <poolie> hello pygi
[00:24] <pygi> poolie, any idea when we'll have the next sprint? :)
[00:27] <poolie> pygi, are you keen?
[00:27] <pygi> poolie, yesh, I wanna work on this cheezburger stuff
[00:27] <poolie> we'd talked about doing something again in early 2009, roughly a year from the last one
[00:27] <pygi> a lot of people poked me about it ...
[00:28] <pygi> poolie, as long as it's not during exams/papers season, I'm good =)
[00:29] <jml> bzr just gave me a MemoryError: https://pastebin.canonical.com/9365/
[00:29] <poolie> pygi: cheezburger?
[00:29] <pygi> poolie, bzr repositories hosting thingy
[00:30] <Peng_> Oooh?
[00:30] <pygi> roughly, bzr equivalent to gitorious
[00:31] <mwhudson> jml: public channel private pastebin?
[00:32] <mwhudson> jml: but that looks like that "occasionally the sftp server sends random junk" message
[00:32] <mwhudson> bug
[00:32] <poolie> pygi, i've not heard of this before but it sounds cool
[00:32] <poolie> pygi, maybe you should come to UDS?
[00:32] <jml> mwhudson: ungh
[00:32] <pygi> poolie, I'm trying, I applied for sponsorship ...
[00:32] <pygi> poolie, you think me will get accepted?
[00:33] <lifeless> jml: unless its actually confidential, a public pastebin works better for this channel
[00:33] <pygi> (I didn't really mention cheezburger cause it's Bzr related, and not ubuntu, but I did mention I mentored for bzr two years ago)
[00:33] <lifeless> anyhow, return os.read(self.proc.stdout.fileno(), count)
[00:33] <lifeless> thats a strange line to memory error on
[00:33] <lifeless> I wonder what count is
[00:36] <lifeless> jml: is it repeatable?
[00:36]  * jml tries
[00:38] <mwhudson> jml: https://bugs.edge.launchpad.net/bzr/+bug/255292
[00:38] <mwhudson> hmm
[00:38] <jml> lifeless: yes it is. would you like to know the value of count?
[00:39]  * mwhudson things he would like to use bzrlib.graph._BreadthFirstSearcher
[00:39] <pygi> poolie, lets hope we do meet there
[00:39] <lifeless> jml: not particularly, but I should I guess
[00:39] <poolie> pygi, i hadn't decided to go but i'm thinking about it
[00:39] <poolie> lifeless and abentley will
[00:40] <poolie> be there
[00:40] <pygi> poolie, decide then :)
[00:40] <pygi> so we can talk and then later on hack!
[00:41] <jml> last two numbers are 1714499681
[00:41] <jml> 1714466917
[00:41] <jml> large numbers the twain of them.
[00:41] <pygi> poolie, I really hope I get sponsored :)
[00:42] <pygi> I did two years ago, same location, but had to decline it :-/
[00:42] <mwhudson> jml: quite close large numbers
[00:43] <mwhudson> (they only differ in three bits)
[00:45] <lifeless> jml: a 1.7GB index would be quite a sight
[00:46] <jml> lifeless: indeed.
[00:46]  * jml updates the bug report
[00:46] <lifeless> jml: do you have a 1.7GB index?
[00:47] <jml> lifeless: no.
[00:47] <jml> lifeless: unless bazaar multiplies the size when you push the branch up
[00:47] <mwhudson> lifeless: does branch.repository.get_parent_map take stacking into account?
[00:48] <jml> lifeless: locally the repo is ~600mb and the branch is ~2mb.
[00:48] <mwhudson> (as in, will it return the same thing when branch is stacked on some other branch as when branch is not stacked?)
[00:48] <lifeless> mwhudson: yes
[00:49] <mwhudson> cool
[00:49] <lifeless> mwhudson: all public apis take stacking into account, or are buggy
[00:49] <mwhudson> lifeless: good to hear :)
[00:50] <mwhudson> oh hm, i was misreading things
[00:50] <poolie> hee hee
[00:50] <mwhudson> (good)
[00:55] <lifeless> mwhudson: also any chain of public attributes/methods will be safe, except the obvious ones where you folllow a stacked relationship or some such
[00:56] <BasicOSX> I'm working on bzr repo B, a larger bzr repo (called it A) wants to absorb my bzr repo B, how do I get my files into repo A and maintain the history/changelogs?
[00:56] <mwhudson> lifeless: i think i was scared unnecessarily by the way repository.get_graph mentions "stackedparentsprovider"
[00:56] <mwhudson> (although i think stackedparentsprovider is mostly something else?)
[00:57] <lifeless> BasicOSX: bzr join
[00:57] <BasicOSX> oh, ty, let me research it
[00:58] <pygi> poolie, correction: cheezburger is roughly bzr's equivalent to gitosis, not gitorious (just noticed the "bug")
[00:58] <poolie> hm, what's the difference?
[00:59] <pygi> gitorious is with web UI and all that, something like Launchpad for git
[00:59] <pygi> gitosis is server-side stuff for creating/managing repos and access to them, and can manage things like gitweb to show repositories on web
[01:17] <abentley> mwhudson: StackedParentsProvider predates branch stacking.  Not really related.
[01:17] <mwhudson> abentley: right
[01:18] <poolie> lifeless: daniel has heaps of patches up for review for pqm
[01:18] <poolie> http://blog.daniel-watkins.co.uk/updated_state_of_pqm.html
[01:18] <poolie> can we get them unblocked somehow?
[01:18] <abentley> It's stacking on a much more temporary basis, so that you can find the LCA when neither repository has all the relevant revisions.
[01:19] <abentley> spiv: ping
[01:19] <poolie> hello abentley
[01:19] <spiv> abentley: pong
[01:19] <abentley> poolie: hi.
[01:19] <abentley> spiv: How do I use RemoteRepository.leave_lock
[01:19] <abentley> _in_place?
[01:20] <spiv> The same way as for other repos, hopefully :)
[01:20] <abentley> spiv: I am doing a branch_implementations test, and it fails with RemoteRepository only, because RemoteRepository raises NotImplemented.
[01:20] <spiv> Oh, hmm.
[01:21] <spiv> I bet it's because it's because remote pack repos don't return lock tokens.
[01:21] <abentley> spiv: The lock token is '', and this evaluates to boolean false.
[01:21] <spiv> Right.
[01:21] <spiv> The test there probably should be for "if self._lock_token is not None"
[01:22] <spiv> Hmm.
[01:22] <spiv> Or you could just notice that repo.lock_write() doesn't return a token; and thus indicates that the repo doesn't support this interface.
[01:22] <abentley> support which interface?
[01:23] <spiv> lock_write(lock_token=foo) / leave_lock_in_place / dont_leave_lock_in_place
[01:23] <abentley> Or maybe I should ask, are we saying the RemoteRepository doesn't support the interface, or that the actual repository doesn't?
[01:23] <spiv> The latter.
[01:24] <spiv> (RemoteRepository is the only repository class that varies this by instance, unsurprisingly)
[01:24] <abentley> Pack repositories don't raise NotImplementedError for this, AFAIK.
[01:26] <spiv> Yeah, there does seem to be an unfortunate behaviour difference there, but IIRC they are both providing reasonable behaviours.
[01:27] <spiv> There's a lot of per_branch/test_locking.py tests that already inspect the return value of branch.lock_write().
[01:27] <abentley> I tell a lie.  It does raise.
[01:27] <spiv> Ah, even better :)
[01:28] <nandersson> I'm about to file a job description for BzrEclipse regarding "bzr tag support". Where do you guys think would be the best place to put it? Together with "commit" or as a separate option under "project -> team -> Tag"?
[01:28] <spiv> FWIW, the docstring for leave_lock_in_place says "If lock_write doesn't return a token, then this method is not supported
[01:28] <spiv> "
[01:28] <abentley> spiv: I'm trying to fix a test that breaks a lock.
[01:28] <nandersson> Together with commit would make more sense I think
[01:28] <abentley> That test does not release the original lock.
[01:29] <abentley> I want to use leave_lock_in_place, then release the lock.
[01:29] <abentley> So should I actually be saying the test is NotApplicable for repos whose write_lock returns None?
[01:30] <spiv> Which test?
[01:31] <abentley> branch_implementations.TestBreakLock.test_unlocked_repo_locked
[01:31] <spiv> If the test needs to use leave_lock_in_place to create a lock that needs breaking, then it definitely should skip with something like NotApplicable if lock_write returns None.
[01:32] <abentley> spiv: Great, thanks.
[01:32] <spiv> (or find another way to make a broken lock)
[01:33] <abentley> spiv: But the *reason* is that the repository cannot create physical locks, right?
[01:33] <abentley> And therefore, there's nothing to leave behind or break.
[01:33] <lifeless> poolie: the next major one was merge-directives, which I reviewed but hasn't been updated AFAIK
[01:33] <spiv> abentley: I think so, yes.
[01:34] <abentley> Although, that's not entirely true for packs.  There is that names list lock.
[01:34] <spiv> abentley: the shame here is that RemoteRepository does support this interface, it's just that the pack repo behind it doesn't.
[01:35] <abentley> I see.  I just found it very confusing trying to understand why it was doing what it was doing.
[01:35] <spiv> So ideally we'd run this test against with a slightly different RemoteBranch scenario: RemoteBranch + dirstate-tags format, say.  I'm not sure it's worth the effort to arrange that.
[01:35] <abentley> spiv: I hear you.
[01:35] <lifeless> abentley: the names list lock is rather more transparently managed though, because there is atomic-insert of a bunch of data, though you probably know this :)
[01:36] <abentley> lifeless: Don't bet on it :-)
[01:36] <spiv> Also, hmm...
[01:37] <spiv> I would have expected that a RemoteBranch would still return a lock token, even if the RemoteRepo' underlying repo doesn't.
[01:38] <lifeless> spiv: the branch should yes
[01:39] <spiv> Oh, but this test is doing branch.repository.lock_write() etc, not branch.lock_write().
[01:39] <spiv> So that makes sense.
[01:57] <BasicOSX> Tried to bzr join, error about KnitPackRepository, so I  ' bzr upgrade --rich-root-pack' then tried to join, 'bzr: ERROR: Cannot join debian/.  Trees have the same root'
[02:00] <abentley> BasicOSX: There's a reason join is a hidden command.
[02:00] <BasicOSX> understood, I'll research more, sorry to bother
[02:01] <abentley> BasicOSX: Also, you should understand that --rich-root-pack is a one-way conversion.
[02:01] <abentley> For your needs, the merge-into plugin sounds more appropriate.
[02:02] <BasicOSX> researching that ... ty
[02:08] <BasicOSX> thank you abentley  that did exactly what I wanted
[02:08] <abentley> BasicOSX: great
[02:24] <poolie> abentley: hi
[02:24] <poolie> i'd like to get the lca shape merge thing unblocked
[02:25] <poolie> this seems like a case where our reviews are kind of slowing us down
[02:25] <poolie> i do really appreciate you reading it, in your own time i know
[02:27] <fullermd> Wow, PQM scares me even more now...
[02:43] <abentley> poolie: jam said he'd call me about that.
[02:46] <toytoy> hi guys, after I issued 'bzr update', I encountered this bug -> http://pastebin.ca/1207947
[02:48] <toytoy> any idea, what causes and why does that error resumes?
[02:49] <abentley> poolie: my problem with the patch is that I feel it degrades design design clarity by changing the model without changing the class to match.
[02:53] <poolie> toytoy: so it's running out of memory trying to update the dirstate
[02:53] <poolie> toytoy, i'd start by trying to upgrade to 1.6.1 or 1.7rc2
[02:54] <poolie> abentley: so i can see how it would be cleaner with those changes
[02:55] <poolie> i'm just wondering if it would be better to merge it as is first basically
[02:55] <toytoy> poolie: you mean the memory is full or sorry I am not sure why would my memory would be full
[02:55] <poolie> toytoy: is it a very large tree, or something with a large file in it?
[02:56] <lifeless> the C extensions sometimes raise MemoryError on corrupt dirstate
[02:56] <toytoy> poolie: oh i see, yeah i think so, so what is your best advise? lessen the files inside the trees?
[02:57] <poolie> toytoy: yeah it's too large?
[02:58] <AfC> toytoy: you are running a very old version of Bazaar. Really, you should upgrade to the current release and try again.
[02:58] <toytoy> poolie: btw, what do you mean by too large? i mean how many size do you expect a 'too large' to you?
[02:58] <lifeless> 500000 paths would be pushing it
[02:58] <abentley> poolie: I'm ambivalent.  On the one hand, we can always fix it later.  On the other, we could have fixed it by now.
[02:59] <poolie> abentley: i think what may be happening here is that we feel like if we don't catch things in review we won't fix them
[02:59] <poolie> however,
[03:00] <toytoy> lifeless: that's really too big, but mine is not so. let me check the trunk
[03:00] <toytoy> trunk's size
[03:00] <poolie> it's making the cycle time for reviews longer, and i think it can be discouraging for the submitter (and might be in this case)
[03:00] <toytoy> it's just 163MB so that might not too big right?
[03:01] <abentley> I think you're right about what's happening here.
[03:01] <toytoy> but yeah, my bazaar version at server is 1.3.1
[03:01] <poolie> it may also make things linger in the queue because they don't get a crisp decision
[03:02] <poolie> i think, all other things being equal, if it takes X additional work to clean it up
[03:02] <poolie> it would be preferable to land the patch and then do X,
[03:02] <abentley> The attempt to review thoroughly is part of them problem?
[03:02] <poolie> than otherwise
[03:03] <poolie> i'm assuming these are cleanups not outright bugs
[03:03] <poolie> hm
[03:03] <poolie> do you think so?
[03:03] <poolie> i wouldn't say so
[03:03] <abentley> Well, it does make the cycle time for reviews longer.  What did you mean, then?
[03:04] <poolie> ah, what i meant by "it" is asking for things to be resubmitted to be cleaner or tested in a different way
[03:05] <abentley> Ah, increasing the number of cycles, then.
[03:07] <abentley> poolie: If we change this from requiring resubmissions to asking for followup patches, should we try to ensure that the followups happen?
[03:07] <abentley> And if we did, how?
[03:15] <poolie> (back, with coffee)
[03:15] <poolie> yes, this would be trying to have more but smaller cycles
[03:16] <poolie> so one proposed idea is to get people to file bugs for the followon work
[03:16] <poolie> if people want to do it good luck to them but i don't think it's a very good general solution because
[03:17] <poolie> i think they're often too fuzzy to be good bugs - they are not falsifiable
[03:17] <poolie> and, also, just filing a bug doesn't give much assurance that it will actually get done
[03:18] <poolie> it would be weird to mark them as 'critical' and objectively they're not
[03:18] <poolie> but that seems to be the priority we're giving them by blocking out a high-priority fix until they're done
[03:20] <poolie> i think the core of it is just that people need to have time to make those cleanups
[03:20] <poolie> remembering what they have to do is not hard if they get to do them soon (within a few days)
[03:20] <poolie> and if they don't have time to do them soon, no record keeping system will help
[03:22] <abentley> Similarly, we could mark them in Bundle Buggy.
[03:23] <abentley> They would show up in peoples' 'todo' tab, even after they were merged.
[03:23] <poolie> mm
[03:23] <poolie> or we could make some more formal use of todo comments in the code
[03:24] <poolie> but - i hadn't realized it til talking to you - the record keeping is not the main issue, i think
[03:26] <abentley> Well, one issue is that in the short term, the follow-ups appear to have much lower priority than the original patch.
[03:27] <poolie> btw i can call if you'd rather talk on the phone
[03:27] <abentley> Sure, maybe that would work better.
[03:27] <poolie> skype or pots?
[03:27] <abentley> Skype's good.
[03:28] <Spaz> lol skype
[03:30] <thumper> hi people
[03:30] <thumper> if I have rev_id x in branch 1, how do I find the mainline rev_no on branch 2 where rev_id x was introduced?
[03:35] <lifeless> poolie: btw, I'm reasonably strongly negative on trading 'correct before landing' for 'please follow up' :- we already have 'please follow up' merges permitted; the process allows that and people use it
[03:35] <fullermd> thumper: The simplest way is just to branch at that rev, and see what revno you get.
[03:35] <lifeless> poolie: when reviewers ask for 'correct before landing' I believe thats because they assess that as the best route forward
[03:35] <poolie> lifeless, do you want to join us?
[03:36] <lifeless> poolie: If you are talking about the weighting different reviewers have, then sure
[03:36] <lifeless> poolie: no, I am just doing lunch, then back to getting status purged
[03:37] <lifeless> please do consider though that the current process seems to me to allow what you are talking about.
[03:37] <thumper> fullermd: that's not going to tell me the right revno
[03:37] <thumper> fullermd: and also I'm really wanting to do this through bzrlib
[03:38] <poolie> lifeless: this is a bit of a case of "what you're asking for is either wrong or is trivial"?
[03:38] <lifeless> poolie: ugh. review process is hard and complex; I'm just giving my input into your analysis. Once status is done I'd be delighted to discuss more.
[03:38] <fullermd> thumper: Sure it will.  If that revision is the head, the revno will always be the same.
[03:39] <fullermd> thumper: I dunno bzrlib near well enough to say in there.  I presume you could tell the revno-building function to pretend that rev was the head and just get the number directly.
[03:39] <mwhudson> fullermd: uh?
[03:39] <mwhudson> you have revid A
[03:39] <lifeless> fullermd: I think you misunderstood the question
[03:39] <mwhudson> in a branch, you add 17 revisions on top of A
[03:39] <thumper> fullermd: b1 was branched from b2 at revno 3, b1 has 4 commits and has revno 7 as head.  b2 has x commits one of which introduces b1
[03:40] <mwhudson> in trunk, you merge these 17 revisions and commit
[03:40] <mwhudson> you want the answer to be A + 1
[03:41] <fullermd> Oh.
[03:53] <LaserJock> I'm reading on jelmer's bzr-svn FAQ page that one can use stacked branches for large SVN repos
[03:53] <LaserJock> I'm not exactly sure what a stacked branch would do
[03:53] <LaserJock> are you "stacking" on the svn repo?
[03:58] <lifeless> poolie: what would have let me express my opinion without it being 'either wrong or trivial' ? I didn't say or suggest it was easy, and I was clear that it was my opinion
[04:01] <mwhudson> LaserJock: yes
[04:05] <lifeless> mwhudson: there is a method on branch I think
[04:05] <lifeless> thumper: ^
[04:11] <LaserJock> hmm, this is still gonna take forever, KDE's svn is *huge*
[04:12] <beuno> lifeless, would that be _gen_revno_map ?
[04:12] <beuno> I mean, get_revision_id_to_revno_map
[05:46] <lifeless> ok, full test running and then submit time
[06:04] <poolie> lifeless: so, basically i'm suggesting that we should look harder at cases where patches are being asked to resubmit when they are not actually wrong
[06:56] <vila> hi aal
[06:56] <vila> :-/ all
[06:57] <beuno> hi vila
[07:03] <poolie> hello vila
[07:31] <jonnydee> Does anyone know if there is a similar functionality like the q*-commands of mercurial? (They allow to manage and version-control patches on a patch-stack)
[07:31] <poolie> jonnydee: yes, see bzr-loom
[07:32] <jonnydee> oh, that was a pretty fast answer :) thanks for your help :)
[07:32] <poolie> let us know how you go
[07:32] <jonnydee> ok, I'll let you know
[08:06] <a_c_m> hey all :)
[08:16] <ngnp> How do I move my .bzr dir out of my project. "bzr init project" create project/.bzr and I don't want it there but in ~/backup/bazaars/ for backup reasons
[08:18] <Peng_> ngnp: Err.. I don't you can. You could try to move it and symlink it, but bzr would probably freak out.
[08:18] <Peng_> ngnp: You could move it to ~/backups/bazaar and then make "project" a lightweight checkout of that.
[08:18] <bob2> a simpler solution is to make project/ a lightweight checkout of a branch in ~/backup/bazaars
[08:18] <ngnp> At Froscon some guy claimed i could be done
[08:19] <Peng_> ngnp: Then ask him. :P
[08:19] <spiv> Depending on how your backup system works, maybe you could just put a symlink to the .bzr dir in ~/backup/foo ?
[08:19] <ngnp> Peng_: bob2: can i do a lightweight checkout with the file:// protocol?
[08:19] <bob2> ngnp: yup
[08:19] <spiv> But my guess is the Froscon guy was thinking of lightweight checkouts.
[08:20] <Peng_> Or he was weird. :D
[08:20] <ngnp> thanks guy ... i'll check it out ... dunno how to do a lightway one
[08:20] <spiv> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-checkouts
[08:20] <ngnp> no he was not weird .... worked for sun afaik ... they are not weird guys
[08:20] <ngnp> spiv: :-)
[08:22] <spiv> ngnp: if you get stuck, feel free to ask for help in here.
[08:22] <ngnp> thanks
[08:24] <spiv> lifeless: The last two bzr.dev commits announced on bazaar-commits@ don't seem to be published yet.  Can you check if there's something awry at PQM's end?
[08:27] <a_c_m> i'm not sure on the terminology, but here is the situation. I have a few generic programs (web sites) which i want to then take copies of to make clients sites, but i want an easy way, for me to say fix a bug or add some new function to the generic version, and then be able to pull that change down into the specialized ones. What is the correct terminology for this (is it upsteam?) and can anyone point me at some workflows / descriptions on 
[08:28] <spiv> a_c_m: your text got cut off at "workflows / descriptions on".
[08:29] <a_c_m> ﻿ / descriptions on how to do this?
[08:29] <a_c_m> :)
[08:30] <spiv> a_c_m: But it sounds like you could make the "generic" version a branch called "trunk", and have the specialised versions be branches off the trunk.  You'd then merge the trunk into the branches when appropriate.
[08:30] <spiv> (You don't have to call it "trunk", but it's a convention that seems to fit your situation ok)
[08:31] <a_c_m> spiv: right, except ideally the projects would be self contained, with only some dev's having commit access to some projects etc... is this still possible with branches ?
[08:32] <fullermd> Well, it's not possible any other way but with branches   ;)
[08:32] <spiv> a_c_m: in bzr, you can't version anything without using branches :)
[08:33] <spiv> So your question is effectively "is this still possible with bzr?" :)
[08:33] <ngnp> spiv: I still don't get it ... I'm new to bzr, lost a day work by 'eclipse/cvs replace with head' ... I understand the 'normal' commands but setting things up is brand new :-( ... haven't created a branch yet.
[08:33] <a_c_m> spiv: humm ok, but in that case, can branches have different read-write rights?
[08:34] <spiv> Commit access is generally managed with regular filesystem permissions.
[08:34] <a_c_m> spiv: ahh ok, that might work
[08:36]  * a_c_m is also going to be trying to play with commit hooks ! 
[08:36] <spiv> ngnp: so, the key thing with lightweight checkouts is that you can make a "branch" in one location, and make a "checkout" of that branch somewhere else.
[08:37] <ngnp> spiv: I misread some part of the url ... i now have a working checkout ... let me test some more
[08:37] <ngnp> thanks btw
[08:37] <spiv> ngnp: a branch in bzr is the thing that tracks the history; i.e. "the current version is revision ABC".
[08:39] <spiv> ngnp: so for instance if you are starting a new project, you could do "bzr init mybranch; bzr checkout --lightweight mybranch mycheckout".  Then all the commits etc you do in "mycheckout" will be recorded in the branch at mybranch.
[08:39] <spiv> ngnp: ah cool.
[08:40] <ngnp> I still have to get used with this D in drcs :p
[08:50] <ngnp> spiv: thanks ...  I think I get to an understanding with bzr ... he now listens somewhat to my commands :p
[08:52]  * ngnp missed some documentation about a workflow that is working in conjunction with another vcs like cvs or subversion. That is making sure the .bzr is not committed into cvs/subversion and not overwritten by a 'cvs replace from head'
[08:56] <spiv> ngnp: Off the top of my head, it'd probably be enough to make bzr ignore 'CVS', and make cvs ignore '.bzr'?
[08:57] <ngnp> a_c_m: can we upgrade these pages http://drupal.org/node/45368 together?
[08:57] <a_c_m> hey ngnp
[08:57] <a_c_m> i will help where i can for sure
[08:57] <ngnp> spiv: me stupid ... you are so right :-)
[08:58] <ngnp> .cvsignore
[08:59] <ngnp> hmm ... but that does not prevent a 'replace from head' if i'm not in control of the cvs ... which is the case ... I do some patches for drupal as an anonymous cvs user ...
[09:00] <a_c_m> i'm trying to build an "uber" system, PQM to check against coding standards (and perhaps even coder) before commiting
[09:00] <ngnp> a_c_m: after I have this cvs/bzr workflow a little in place i'll update those pages
[09:00] <ngnp> a_c_m: auto coder ... is that possible? (sorry for the drupal talk)
[09:01] <a_c_m> ngnp: http://www.trellon.com/blog/daily-quality-control-checks-coder
[09:02] <ngnp> a_c_m: thanks ... have you tried drush_mm too?
[09:04] <a_c_m> not yet
[10:18] <stewart> lifeless: ping, aronud again? came back at about 4:50am (in europe atm), and went to bed instead of responding :)
[10:53] <LeoNerd> Hrm...
[10:53] <LeoNerd> bzr baz-import => This command is disabled.  Please install PyBaz.
[10:53] <LeoNerd> apt-get install pybaz => E: Package pybaz has no installation candidate
[11:06] <Stavros> hello
[11:06] <Stavros> is there in bzr something equivalent to git rebase?
[11:08] <james_w> Stavros: there's a bzr-rebase plugin
[11:09] <Stavros> james_w: ah, thanks
[11:10] <Stavros> actually i want to branch some official code and make some changes to it, keeping up with the official version. what's the best way to do that?
[11:11] <james_w> get a branch of the code and work on it, and occaisionally "bzr merge" the official version
[11:11] <Stavros> ah, i don't need rebase then?
[11:11] <james_w> you could use rebase, but they will both do what you want
[11:12] <Stavros> great, thanks
[11:12] <james_w> they will just do it in slightly different ways
[11:12] <Stavros> hmm yes
[11:13] <Stavros> i'm looking to keep my drupal installation up to date, so i figured i can pull from their repo, but i have some local changes
[12:02] <james_w> siretart: hi, would you be available for sponsoring an upload today?
[12:04] <siretart> james_w: sure
[12:04] <james_w> siretart: great, thanks. Do you have time now, or would you prefer to wait until after work?
[12:05] <siretart> james_w: perhaps you can sign and upload to alioth, and I'll rebuild and upload it to debian?
[12:05] <james_w> siretart: that works for me.
[12:13] <james_w> siretart: they're in /srv/alioth.debian.org/chroot/home/groups/pkg-bazaar/htdocs/2.0.1
[12:14] <james_w> siretart: targeted at experimental
[12:14] <james_w> siretart: I would like this version in Intrepid, is a sync request going to be processed in a timely manner do you think? Or should a fakesync be done?
[12:16] <siretart> it depends on how hard you hit the archive admins ;)
[12:18] <LeoNerd> Does bzr have the equivalent of tla/baz's "sync-tree".. Ie. pretend I have a commit when really I don't...?
[12:19] <LeoNerd> I have two longlived branches that I crossmerge a lot; it would be nice to be able to ignore all the merges in one side on the other
[12:20] <LeoNerd> .oO( Mm.. I suppose merge + revert might do it... )
[12:28] <siretart> james_w: is the Vcs-Bzr location in debian/control up to date? it seems the last commit there was in march
[12:28] <james_w> siretart: no, you are correct
[12:30] <Kinnison> LeoNerd: I tend to pull when I can, so if I know I've merged on my laptop, and haven't committed recently on the desktop, I pull from the laptop.
[12:30] <Kinnison> LeoNerd: that kind of thing
[12:30] <LeoNerd> Kinnison: Ya.. this is for two branches of some code that's quite diverged between them, for the last.. er.. 4 years
[12:31] <james_w> siretart: fixed packages uploaded
[12:32] <Kinnison> LeoNerd: aah, :)
[13:29] <james_w> siretart: thanks a lot.
[13:29] <siretart> you're welcome!
[13:31] <Stavros> hello
[13:31] <Stavros> will bzrtools ever be included in the repo so there aren't broken dependencies?
[13:48] <jelmer> james_w:ping
[13:48] <james_w> hey jelmer
[13:49] <jelmer> james_w, hi!
[13:49] <jelmer> james_w, I noticed the function that exports tarballs is a bit simpler now in bzr
[13:49] <jelmer> james_w, I was wondering whether bzr-builddeb could perhaps just call that directly and override the last modification time?
[13:50] <james_w> jelmer: perhaps, I haven't looked at the changes
[13:52] <jelmer> james_w, you have no objections to calling the tarball creating function directly and bypassing the export infrastructure though?
[13:53] <james_w> jelmer: ah, I think I get it now. I'd have to see the patch really, but I have no objection on principle.
[13:53] <james_w> jelmer: the only think would be that it ignores .bzr* as the export code does
[13:56] <jelmer> james_w, It's still exercising that code
[13:56] <jelmer> http://samba.org/~jelmer/bzr-builddeb-tar-exporter.diff
[13:58] <james_w> jelmer: I see "def tar_exporter(tree, dest, root, subdir, compression=None):"
[13:58] <jelmer> I've got a patch for bzr.dev as well that allows overriding "now"
[13:59] <james_w> ah
[13:59] <james_w> once that patch is in bzr.dev I don't really care how the builddeb bit is done, so your patch would be fine
[13:59] <jelmer> cool, thanks
[14:00] <james_w> jelmer: does the bzr.dev patch also use the time from the tree if it is not overridden?
[14:00] <jelmer> it uses the time.time() as was done previously
[14:01] <james_w> ok
[14:01] <james_w> it could use tree.get_file_mtime() instead
[14:02] <jelmer> Hmm, I wasn't aware of that function
[14:03] <jelmer> When using that, bzr-builddeb wouldn't need patching anyway
[14:03] <james_w> for revision trees I think it just backs on to the timestamp of the revision
[14:07] <jelmer> ah, but that is too slow for real use..
[14:07] <jelmer> hmm
[14:07]  * jelmer gives up
[14:19] <Leonidas> what do I need to do to move the TREE_ROOT?
[14:20] <Leonidas> I tried setting set_root_id and deleting the former root folder, but that throws exceptions.
[14:37] <pysquared> Hi all, I have been evaluating Bazaar, and want to get away from CVS.
[14:37] <pysquared> One nice thing about CVS was that I understood how it represented files and revisions and subdirectories etc. and therefore what it might be able to do for me.
[14:37] <pysquared> Does anyone know where I could find similar info about Bazaar without attempting to grok the source?
[14:44] <jelmer> pysquared, you may want to look in doc/developer/
[14:44] <jelmer> *-format.txt in particular
[14:46] <pysquared> jelmer, thanks, will do
[15:04] <Leonidas> abentley: In the commit that I saw, there was a new file called '' with the fileid TREE_ROOT created and the old '', with tree_root-* deleted. But when I try changing the root_id and deleting '', it throws an exception
[15:23] <strk> guys, I manually installed bzr latest (1.6) on a Debian stable.
[15:23] <strk> then I 'bzr branch sftp://strk@......'
[15:23] <strk> modified, commit
[15:23] <strk> and (wow: commit was incredibly fast)
[15:23] <strk> well, now I pull from other machines and my changes are not there
[15:23] <strk> no wonder commit was fast :)
[15:23] <strk> so, hints on how to find out what happened ? bzr status shows no changes.
[15:25] <strk> on push: bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
[15:25] <strk> so, does it mean my commits were "offline" ?
[15:31] <Leonidas> strk: your commits are always offline, that's the nature of DVCS
[15:32] <Leonidas> strk: I'd try a pull (to get the newest changes), merge and then a push.
[15:33] <james_w> strk: if you "bzr branch" instead of "bzr commit" then all commits are offline, "bzr bind" will bind your branch to the master branch so that they are no longer offline by default
[15:34] <strk> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
[15:35] <james_w> strk: that was for the bind?
[15:35] <ngnp> This Quick Start Card is not a quick start http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.svg as I do not understand ie bzr branch mp myproject ... how to make this better? File a bug?
[15:36] <Leonidas> ngnp: file a patch would be more effective :)
[15:36] <ngnp> how? I'm a newbie to bzr
[15:37] <Leonidas> ngnp: bzr branch np mayproject branches the repo in the mp directory to the myproject directory.
[15:37] <strk> james_w: nope, that was for push. Trying bind now.
[15:37] <Leonidas> ngnp: basically, this is a quick reference, not a quick start tutorial. It's just useful then you know how things work, but forgot the commands.
[15:38] <ngnp> Leonidas: I know after testing ... but it should be more like "bzr branck myproject newproject"
[15:38] <strk> still, the bind gave me no automatic commit of the pending changes
[15:38] <Leonidas> ngnp: download the file, edit it, run diff and create a bug with a patch added to it.
[15:38] <strk> and push still gives me "Operation denied"
[15:39] <ngnp> Leonidas: that's part of that patch :-) ... how to patch is now the question ;-(
[15:39] <strk> now how do I get out of this ?
[15:39] <ngnp> Leonidas: ok
[15:39] <Leonidas> strk: if you want to have SVN-like workflow one normally uses bzr checkout.
[15:39] <james_w> strk: does "bzr update" bring in the remote changes now?
[15:39] <james_w> strk: it will leave pending merges of the things you committed "offline"
[15:40] <strk> Your local commits will now show as pending merges with 'bzr status', and can be committed with 'bzr commit'.
[15:40] <strk> ah, great :)
[15:40] <strk> update seemed to help
[15:40] <strk> now I commit ? (I'm bound now)
[15:41] <james_w> strk: yeah, if you commit now then it will happen "online", and so the master branch will receive your offline commits
[15:41] <strk> and they'll look like a merge
[15:41] <james_w> strk: exactly
[15:41] <strk> now, how do I go to make each of my offline commits appear as online ones ? is that possible at all ?
[15:42] <strk> the use for it would be for gnulog to produce nicer ChangeLog entries basically
[15:42] <james_w> ngnp: a bug explaining clearly the problem and how you think it could be improved would be ok
[15:42] <james_w> strk: ok, that's possible, it will take me a minute to find the best way to do it.
[15:43] <ngnp> james_w: I'm inkscaping atm :-)
[15:43] <james_w> strk: you will need to do a rebase if you want this, do you have bzr-rebase installed?
[15:45] <james_w> strk: ok I believe "bzr rebase --pending-merges" will do what you want
[15:47] <Leonidas> how can I change the directory that is used as root directory?
[15:48] <ngnp> james_w: what project the bug is for?
[15:48] <james_w> ngnp: bzr please
[15:48] <plexq> how can I diff two branches?
[15:49] <james_w> plexq: there are a couple of ways
[15:49] <james_w> plexq: "bzr diff --old ../other-branch" from one of them is one way
[15:50] <james_w> "bzr diff -rbranch:../other-branch " would be a second
[15:54] <Leonidas> what do I need to change the root directory in a repository?
[15:57] <ngnp> james_w: see https://bugs.launchpad.net/bzr/+bug/273160
[15:57] <james_w> thanks ngnp
[15:58] <ngnp> james_w: thank you!
[16:05] <ngnp> hmmm ... that patch is not in order .... bzr branch myproject newproject .... as ... bzr branch --help ... suggests FROM_TARGET TO_TARGET ... any suggestion with this?
[16:22] <rkerr> problem...
[16:22] <rkerr> "If you're sure that it's not being modified, use bzr break-lock lp-140342092://..."
[16:23] <rkerr> bzr: ERROR: Unsupported protocol for url "lp-140342092://..."
[16:25] <ngnp> so I had to type  bzr branch ./myproject ./newproject :-( including the path
[16:27] <nandersson> Verterok, Hi, I'm about to file a bug in bzr-eclipse regarding "bzr tag" support, but I'm not sure how it would best be implemented
[16:27] <nandersson> To me it makes sense to place it together with "commit"
[16:27] <Verterok> nandersson: hi!
[16:27] <nandersson> In order not to clog down the right click menu
[16:28] <nandersson> Because I think that "bzr tag" is a thing you don't do that often - not as often as a commit
[16:29] <nandersson> and my guess is that you first commit, then tag, when you're "tagging" a source tree
[16:29] <Verterok> nandersson: so, adding a "commit & tag" feature in the commit dialog? (like the optional fixes or adding untracked in commit)
[16:29] <nandersson> i.e you don't want to tag a tree that isn't first commited
[16:29] <nandersson> Verterok, yes, thats how I see it - I don't know if others agree
[16:29] <james_w> ngnp: that should be no different to "bzr branch myproject newproject"
[16:29] <nandersson> But to me it makes sense
[16:30] <nandersson> I can't see where you would like to tag a branch that isn't commited.
[16:31] <Verterok> nandersson: I think both approaches could coexist, i.e: having a tag dialog, and the optional "tag after commit" in the commit dialog
[16:31] <nandersson> In that case - it makes sense to put it in the "commit" dialog
[16:32] <nandersson> Verterok, yes, of course - and if you tag a tree that is modified I think you should raise a warning
[16:32] <Verterok> nandersson: ok, file the bug with your requirement, and this comment about raising a warning (I like it :))
[16:33] <nandersson> Verterok, I'll do that. I think that's how it should be implemented
[16:33] <nandersson> Verterok, BzrEclipse works as a charm - very nice job indeed
[16:34] <Verterok> nandersson: if someone want to have it outside the commit dialog, I can easily add a standalone tag dialog (once it's implemented for the commit) ;)
[16:34] <Verterok> nandersson: thanks, I really appreciate this kind of feedback :-D
[16:35] <nandersson> Verterok, yes, I guess there could be scenarios when you realize that the existing tree should be "tagged" Good to have it as an option
[16:35] <nandersson> Verterok, I'm glad I can help out :)
[16:36] <Verterok> nandersson: by the way, I'll be rolling out a new build at the end of the day, (minor bug fix, related to xmlrpc service, and possibly a new option to limit the log fetching)
[16:36] <nandersson> Verterok, cool :) I update then
[16:42] <Verterok> nandersson: if you are interested in peeking what I've playing with, I have a screensshot (it's just a prototype) of future launchpad integration (via launchpadlib) :) http://verterok.com.ar/images/BranchList_prototype.png
[16:45] <Verterok> nandersson: my idea is to allow branching directly from that list, I'm sure there are other possible use cases
[16:46] <Verterok> nandersson: but it's just a prototype, it need a lot more work to make it "usable"
[16:50] <nandersson> Verterok, That looks cool. Perhaps something that could be used together with the "New -> Other -> Bazaar"-Wizard?
[16:50] <nandersson> Verterok, i.e to have the possibility there to browse your launchpad code repository?
[16:51] <Verterok> nandersson: ideed, and with all dialogs that asks for a branch location :)
[16:51] <nandersson> Verterok, or projects that have your name on it - if that is possible
[16:51] <Verterok> nandersson: launchadlib, it's still in early stages, so I depend on what features it provides. ATM, it only allows to get the branches of a project
[16:52] <Verterok> nandersson: but I'm sure that's going to change soon :)
[16:53] <nandersson> Verterok, cool, I think that would be an effort then that depends on what Launchpad provides. a "Navigate Launchpad"-feature would be cool.
[16:53] <nandersson> Verterok, but I guess it is also dependent on the amount of data that flows between LP and Eclipse
[16:55] <nandersson> Verterok, what you said about Mylyn seems interesting - and to connect Eclipse with the bugtracker and TODO-lists
[16:55] <Verterok> nandersson: sure, quering LP is in the roadmap of launchpadlib, so it 'll land sooner than later. that 'ld allow me to add the "Navigate" option
[16:55] <nandersson> Verterok, I filed the bug by the way with some useful links
[16:56] <Verterok> nandersson: Mylyn integration is also on it way ;)
[16:56] <Verterok> nandersson: great!, thanks.
[16:57] <Verterok> nandersson: I just need a bit more of time to put on this, too many things to do :p
[16:57] <nandersson> Verterok, hehe, I can imagine :-)
[16:58] <nandersson> Verterok, Now I'm very pleased with the workflow. The rest is pure features
[17:03] <Verterok> nandersson: great to know.
[17:35] <pagenoare> Hello
[17:50] <Verterok> pagenoare: Hi
[19:02] <frikazoyd> So when using bzr, is there a way to release locks automatically once you push?
[19:03] <frikazoyd> Or an option for push that releases locks?  I didn't see one immediately
[19:07]  * LarstiQ blinks
[19:07] <LarstiQ> frikazoyd: I'm not sure what you mean?
[19:07] <frikazoyd> Okay
[19:07] <frikazoyd> So we just started using bzr for a project
[19:07] <frikazoyd> Now I committed some files, and that went fine.  Everything seems to work so far.
[19:08] <frikazoyd> But then someone else wanted to edit that file, and couldn't commit his changes.  Said I had a lock on it
[19:08] <frikazoyd> but I was done with it.  And I didn't request a lock on it in the first place.
[19:08] <frikazoyd> so he broke my lock
[19:08] <frikazoyd> now, I couldn't pull after that.  Had to do a merge, and now I can't commit without breaking his locks and further causing problems down this vein
[19:08] <LarstiQ> that's rather weird
[19:09] <LarstiQ> frikazoyd: in normal operation, locks don't get left around
[19:09] <frikazoyd> Hm
[19:09] <frikazoyd> so something may be borked
[19:09] <LarstiQ> frikazoyd: a lock either means: someone is actively doing something with it, or, a client got interrupted (^C) and didn't get the chance to clean up
[19:10] <frikazoyd> Hm
[19:10] <LarstiQ> frikazoyd: if you're getting locks strewn all over in regular operation, something is wrong.
[19:10] <frikazoyd> I know neither is the case at the moment
[19:44] <ngnp> james_w: i do not copy :p ... is bzr branch myproject newproject should work?
[19:46] <ngnp> ok ... i tested it without ./ and it worked ... aargh
[19:46]  * ngnp go to sleep
[21:15] <aa_> hi, anyone got any experience (nice way) to do a bzr mirror of an hg repo?
[21:30] <mwhudson> aa_: there's bzr-hg, don't know how well that works currently
[21:31] <aa_> mwhudson: just trying it, it kind of hates me :)
[21:31] <mwhudson> aa_: and a fast-import based stuffs
[21:34] <aa_> hmm, is there a way I can get an actual traceback with the "send this traceback to bug tracker"
[21:34] <aa_> I just get some output about version and thing, but no traceback
[22:05] <rsc-> hey guys.
[22:05] <rsc-> so lets say I made a local branch out of a remote branch (bzr branch lp:xxxxx). if I made 10 new revisions on my local branch, how can I update the remote branch with just one consolidated revision?
[22:06] <beuno> rsc-, branch the remote branch again
[22:06] <romaia> Hello there. Does someone have a quick reference for a server-side post push hook that updates the tree after the push?
[22:06] <beuno> rsc-, and, locally, go to that branch, bzr merge ../otherbranch
[22:06] <rsc-> okay
[22:06] <beuno> commit n' push
[22:06] <beuno> you can also just do a checkout
[22:06] <beuno> and just commit
[22:07] <rsc-> what do you mean?
[22:07] <beuno> isntead of a branch again, do: bzr co lp:xxx
[22:08] <beuno> so, when you commit, it will send the changes
[22:08] <beuno> so you don't need to push
[22:08] <rsc-> oh, right
[22:08] <beuno> checkouts are bound to it's parents
[22:08] <rsc-> it sort of automatically pushes it
[22:08] <rsc-> because it's the "same" branch, just stored in 2 different locations, right?
[22:09] <beuno> yeap
[22:18] <rsc-> are there locks?
[22:18] <rsc-> like in svn?
[22:19] <beuno> yes, it takes out some write locks in certain cases
[22:19] <rsc-> okay
[22:19] <rsc-> when i do a "bzr merge", can I use meld?
[22:19] <rsc-> to preview the changes to be done?
[22:20] <rsc-> and perhaps to decide on how to merge certain conflicting files
[22:21] <beuno> yeap, you can
[22:21] <rsc-> how do i do that?
[22:21] <beuno> with bzr-extmerge plugin
[22:21] <rsc-> sounds good.
[22:21] <rsc-> not sure if its in the ubuntu repositories though
[22:22] <beuno> it isn't
[22:22] <beuno> mkdir ~/.bazaar/plugins
[22:22] <rsc-> but im sure it's easy to install. ill check it out :)
[22:22] <beuno> bzr co lp:bzr-extmerge ~/.bazaar/plugins/extmerge
[22:22] <beuno> and you're set
[22:22] <rsc-> so do i just do "bzr extmerge" in place of "bzr merge" ?
[22:22] <beuno> well, you can do bzr help after you install the plugin  :)
[22:22] <beuno> I don't really remember
[22:23] <Verterok> rsc-: you should do something like: bzr extmerge <file_with_conflicts>
[22:23] <Verterok> hey beuno
[22:23] <rsc-> okay
[22:24] <beuno> hey Verterok
[22:24] <Verterok> rsc-: after you executed a 'bzr merge'
[22:24]  * Verterok brb
[22:25] <rsc-> oh there we go
[22:29] <rsc-> hmm, extmerge does a 3 way diff. shouldn't it be 2 way? (my changes vs. remote changes)
[22:32] <mwhudson> i usually just run 'meld .' after a merge
[22:32] <mwhudson> oh, he left
[23:14] <poolie> good morning
[23:16] <Verterok> hi poolie
[23:39] <lifeless> abentley: your preview intertree diff seems to include lots of stuff in NEWS that isn't part of your branch; I haven't read further yet because I presume you had an our of date bzr.dev mirror or some such
[23:39] <abentley> lifeless: Yes, that's why I sent in a corrected one.
[23:40] <lifeless> abentley: cool, I haven't seen that yet
[23:40] <abentley> lifeless: Subject was [MERGE] Intertree testing for PreviewTree
[23:40] <lifeless> great, thanks
[23:42] <lifeless> jam: when do you finish?