[00:20] <jml> I get this error when I branch bzr: bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "thanks.txt-20050309044946-58141ea3091846d8".
[00:20] <jml> It happens whether I use bzr.dev or bzr 1.3
[00:26] <bob2> into a rich-root{,-pack} repository?
[00:27] <jelmer> grrr, I just hit the rich root bug again as well :-(
[00:37] <jml> bob2: into a standalone branch
[00:38] <Talden> My Scenario:
[00:38] <Talden> Reviewers have full checkouts of mainline to merge dev branchs into (update -> merge from dev1 -> review and commit).
[00:38] <Talden> QA has a lightweight checkout (update -> test and tag)
[00:39] <Talden> My Question: How do tags propagate in checkouts?
[00:39] <Talden> The QA tags show up for any new checkouts or brances made from mainline but they don't show up in reviewer checkouts that already have the tagged revision.
[00:39] <Talden> If a reviewer uses pull (which requires a path strangely) they do get the tags.  Shouldn't update transfer tags like pull and shouldn't pull default, in a checkout, to the checked out location?
[00:59] <spiv> Good morning.
[00:59] <spiv> igc: good morning!  I'm jealous :)
[01:00] <igc> hi spiv
[01:00] <igc> spiv: if it makes you feel better, it rained a lot :-)
[01:05] <poolie> dhello
[01:09] <spiv> poolie: good morning
[01:10] <poolie> hello spiv
[01:11] <lifeless> back
[01:16] <igc> hi lifeless
[01:20] <lifeless> hi igc, welcome back
[01:20] <igc> thanks
[01:30] <igc> jamesh: thanks for working on the set_revision_info hook stuff
[01:31] <jamesh> igc: no problem.  The API from your branch was better than mine anyway :)
[01:32] <jamesh> igc: was there a particular thing you wanted the hook for?
[01:32] <jamesh> (I wanted it for bzr-dbus)
[01:33] <igc> jamesh: it was part of the work spiv and I started in the Chicago sprint to get good server-side hooks
[01:36] <Stavros> hello
[01:37] <Stavros> what is the proper procedure after merging branches that have diverged?
[01:37] <poolie> Stavros: fix any problems, test or read the diff, then commit
[01:37] <Stavros> and everything will go in its proper place?
[01:37] <Stavros> in the graph, i mean?
[01:38] <poolie> can you explain your question more?
[01:38] <Stavros> well, i have two branches that have diverged and i merge on mine
[01:38] <Stavros> and "bzr status" gives me some weird stuff, pending merges and the like
[01:38] <poolie> right :)
[01:38] <Stavros> and i am just wondering if that is proper behaviour
[01:39] <poolie> that's correct
[01:39] <Stavros> ah, good
[01:39] <poolie> now commit on your branch
[01:39] <Stavros> so if i commit everything will work fine?
[01:39] <Stavros> good
[01:39] <spiv> jamesh: in combination with the code I recently landed to add a Branch.set_last_revision_info smart verb, it starts making some server-side hooks possible
[01:39] <Stavros> okay great, thanks!
[01:39] <poolie> now, depending on the purpose of the two branches you may want to take one further step
[01:39] <poolie> if they are both _meant_ to be the same,
[01:39] <Stavros> what's that?
[01:39] <jamesh> spiv: I suppose you don't see the pre/post_commit hooks on the server side?
[01:40] <poolie> for example if you are working on the same bug on your laptop and desktop
[01:40] <jamesh> since it is just pushing a locally committed revision
[01:40] <poolie> you may want to push your merge from the branch where you committed it into the other
[01:40] <Stavros> ah
[01:40] <ubotu> New bug: #217031 in bzr ""bzr launchpad-login -v MYNAME" gives no feedback" [Undecided,New] https://launchpad.net/bugs/217031
[01:40] <poolie> that will switch the other branch to be in the same revision- you can then push and pull between them without needing to merge
[01:40] <poolie> however
[01:40] <poolie> if the branches have different purposes
[01:40] <Stavros> well i have a different workflow with a master server, but i see what you mean
[01:40] <spiv> jamesh: right
[01:40] <poolie> for example if one is the trunk and one is your feature branche
[01:40] <Stavros> yes
[01:40] <Stavros> that's it
[01:41] <poolie> then you shouldn't do this
[01:41] <poolie> cool
[01:41] <Stavros> yes
[01:41] <poolie> glad i could help
[01:41] <Stavros> so i just wait until i finish the feature then
[01:41] <Stavros> thanks a lot!
[01:41] <spiv> jamesh: and for some cases at least, you might not care if it was a new commit vs. a push vs. uncommit or whatever, you might want to always run a hook if the branch's tip changed.
[02:07] <lifeless> abentley: ping; you've been talking with alexander about line ending stuff; is he doing roughly what we planned in London, or something different?
[02:07] <abentley> I don't have a clear idea what he's doing.
[02:07] <abentley> Sorry, gotta go.
[02:07] <lifeless> bye
[02:08] <lifeless> I'll read the thread in detail then
[02:23] <lifeless> poolie: 1.4 made
[02:32] <Stavros> i am tagging revisions with already existing tags, but pushing with --overwrite so the tags will get accepted is a bit dangerous, isn't it?
[02:44] <hersonls> martin pool, you be here?
[02:44] <spiv> hersonls: he's poolie
[02:44] <hersonls> poolie, hey guy
[02:44] <hersonls> poolie, you be here?
[02:53] <lifeless> hersonls: I suggest you ask the question/start the discussion you want to have; 'presence' on IRC is a fairly weak concept.
[02:55] <hersonls> lifeless, tanks
[02:59] <wildfire> bzr internal error: http://pastebin.com/m373ccb16
[03:00] <wildfire> and is there no way to specify a path delimiter with bzr? e.g. git add -- foo/; git commit -- foo/ seems to have no analogue in bzr
[03:00] <bob2> as in make it non-recursive?
[03:01] <wildfire> no, as in not have to specify each of the files in the foo directory to bzr commit individually
[03:01] <poolie> wildfire: bzr commit foo should do that
[03:01] <bob2> bzr commit -m 'blah foo/ will commit all changes to foo and below
[03:02] <wildfire> hmm, apparently I've managed to break the repository and I get the internal error now; so I can't check that that works
[03:02] <wildfire> even on 'bzr status'
[03:03] <poolie> hersonls: go ahead
[03:03] <hersonls> poolie, hey, you remeber me?
[03:04] <poolie> yes
[03:04] <hersonls> poolie, tanks for help
[03:05] <wildfire> bob2, poolie: oh, it appears me doing that command 'bzr commit blosxom' is what caused the internal error
[03:14] <lifeless> wildfire: is bloxsom versioned?
[03:14] <lifeless> wildfire: does 'bzr st' work?
[03:14] <lifeless> wildfire: and do you have nested trees?
[03:16] <hersonls> poolie, how i crate new team in lauchpad?
[03:17] <wildfire> lifeless, it was versions, bzr st fails with an internal exception (assuming it is the same, and assuming 'st' is 'status'), not a nested tree, no
[03:17] <wildfire> s/it was versions/it was versioned/
[03:18] <wildfire> lifeless, 'bzr st' output http://pastebin.com/m532dfc0e
[03:24] <poolie> wildfire: i'm looking into that assertion
[03:29] <wildfire> poolie, okay, I'll probably only be up for another 30 mins or so
[03:49] <poolie> wildfire:  i think you are hitting bug 150438
[03:49] <ubotu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [Medium,Incomplete] https://launchpad.net/bugs/150438
[03:50] <poolie> can you provide any moer information beyond the traceback about what caused it?
[03:50] <wildfire> poolie, progsoc is using bzr to manage /etc on a few machines; I did a 'dpkg -P blosxom' which also removed the /etc/blosxom directory
[03:51] <wildfire> poolie, I then wanted to commit that directory removal, so I did "bzr commit blosxom" and from this point onwards bzr is failing with an internal error on a number of commands
[03:55] <lifeless> thumper: I would breakpoint in the failing tests setup(); and check that the queue setup's setUp() really is working correctly
[03:55] <thumper> lifeless: ok
[03:55] <thumper> lifeless: I'm just off to collect kids from school et al, and will get back to you
[03:55] <lifeless> k
[03:55] <poolie> wildfire: thanks
[03:56] <poolie> to recover that directory i suggest you
[03:56] <poolie> bzr branch /etc /tmp/new-etc
[03:56] <poolie> mv /etc/.bzr /etc/.bzr.broken
[03:56] <poolie> mv /tmp/new-etc /etc/.bzr
[03:56] <poolie> (maybe make a backup of all of etc ot a tarball first)
[03:57] <wildfire> poolie, actually I don't want to recover the directory. I want to record the removal of it ...
[03:58] <poolie> i meant, to get bzr back in a working state
[03:58] <wildfire> ah, okay
[03:58] <poolie> to commit the removal of it and avoid this bug
[03:58] <poolie> i suggest you just remove it, and then commit the whole thing (with no other changes made)
[03:58] <spiv> I think the last line should be "mv /tmp/new-etc/.bzr /etc/.bzr"
[03:58] <poolie> thankyou for reporting it
[03:58] <poolie> !
[03:58] <poolie> you're right, sorry
[04:02] <wildfire> poolie, hmm, the first command 'bzr branch /etc /tmp/new-etc' is also failing with the internal errors
[04:02] <wildfire> poolie, also, just in case this was related to the interative plugin I checked with that removed and it also fails
[04:02] <poolie> could you paste it?
[04:02] <wildfire> sure, one sec.
[04:02] <lifeless> spiv: ivar - thats ":ivar THING: details" right ?
[04:03] <spiv> lifeless: yeah, I think so.
[04:03] <spiv> just like param, except s/param/ivar/ :)
[04:03] <wildfire> poolie, http://pastebin.com/m5ffc2800
[04:04] <poolie> what does 'bzr log -r -1 /etc' show you?
[04:05] <wildfire> wildfire@muspell:/etc$ sudo bzr log -r -1 /etc
[04:05] <wildfire> ------------------------------------------------------------
[04:05] <wildfire> revno: 51
[04:05] <wildfire> committer: Anand Kumria <wildfire-bzr@progsoc.uts.edu.au>
[04:05] <wildfire> branch nick: Muspell /etc
[04:05] <wildfire> timestamp: Mon 2008-04-14 11:56:12 +1000
[04:05] <wildfire> message:
[04:05] <wildfire>    Ignore generated berkeley db files
[04:06] <poolie> is that the revision you were trying to commit when it failed/
[04:07] <poolie> does bzr branch -r -2 work?
[04:09] <wildfire> bzr log -r -2 works
[04:09] <wildfire> the revision I am trying to commit is the removal of the /etc/blosxom directory
[04:11] <poolie> ok
[04:11] <poolie> can i suggest you start from the branch of revision -2, put it back in place as above, and then try the commit from the top of your tree
[04:12] <wildfire> poolie, you mean 'bzr branch -r -2 /etc /tmp/new-etc' and then go from there?
[04:12] <poolie> yes
[04:15] <wildfire> poolie, done and now 'bzr status' tells me that the blosxom directory has been removed
[04:15] <poolie> ok
[04:16] <wildfire> how should I now go ahead and commit that ('bzr commit blosxom' is what caused the breakage before)
[04:16] <poolie> i think you should just commit with no arguments from the root of /etc
[04:16] <lifeless> poolie: I'm smelling an update_by_delta bug
[04:16] <poolie> unless you want to see if that reproduces it
[04:16] <wildfire> ahh, I have other unrelated changes that I'd like to commit in a separate changeset
[04:17] <lifeless> wildfire: bzr shelve++
[04:18] <poolie> ah
[04:18] <poolie> it's possible those changes are causing this
[04:18] <poolie> could you paste bzr st?
[04:18] <wildfire> one second
[04:19] <poolie> actually it would be easier if you just put it in bug 150438
[04:19] <ubotu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] https://launchpad.net/bugs/150438
[04:19] <poolie> since that's just what i was going to do :)
[04:19] <wildfire> http://pastebin.com/d1e7a407
[04:20] <wildfire> poolie, I'll try but it appears progsoc's email is b0rked, which is why I'm trying to look at the configuration (and remove unnecessary stuff)
[04:24] <poolie> ok, thanks for that
[04:24] <poolie> lifeless: ^^
[04:24] <poolie> it doesn't *look* strange
[04:25] <poolie> wildfire: if you want them in separate commits i suggest selectively committing everything but the blosxom deletion
[04:27] <wildfire> poolie, just tried (bzr add .bzrignore; bzr commit .bzrignore; bzr status) which returns me to the broken state again
[04:28] <lifeless> .bzr << bloxsom << dovecot
[04:28] <hersonls> i need help commit with bzr
[04:28] <hersonls> someone help me
[04:29] <wildfire> lifeless, -EPARSE ?
[04:29] <lifeless> wildfire: I'm speculating about the nature of the bug
[04:29] <poolie> hersonls: just ask your question please
[04:29] <hersonls> poolie, how i send the commit to launchpad?
[04:29] <poolie> lifeless: you suspect another ordering problem in the dirstate?
[04:30] <wildfire> oh, okay, well I can redo the tmp/new-etc thing and try the dovecot one first then
[04:30] <wildfire> one sec
[04:30] <poolie> hersonls: have you created a Launchpad account?
[04:30] <hersonls> yeah
[04:30] <hersonls> poolie, i try bzr push and return locked 30 minutes, 24 seconds ago
[04:30] <poolie> hersonls: what url are you trying to push to?
[04:30] <lifeless> poolie: in the update via delta code of commit; yes
[04:30] <hersonls> poolie, bzr+ssh://hersonls@bazaar.launchpad.net/~hersonls/bzr/slackbuild
[04:31] <poolie> hersonls: did you maybe previously try to push to it and interrupt the process?
[04:31] <poolie> hersonls: if so ,try 'bzr break-lock URL'
[04:32] <wildfire> lifeless, poolie: okay, redone. (bzr add dovecot/dovecot.conf; bzr commit dovecot/dovecot.conf; bzr status) works
[04:35] <lifeless> wildfire: I speculate that add .bzrignore; commit; status will still break
[04:36] <wildfire> lifeless, if you had bet, you would be
[04:36] <wildfire> ...
[04:36] <wildfire> wrong
[04:37] <poolie> :)
[04:37] <poolie> biab
[04:38] <lifeless> fwiw you could have done 'bzr commit dovecot' - dovecot/dovecot.conf was already added according to your status
[04:41] <hersonls> poolie, i push to the branch bzr+ssh://hersonls@bazaar.launchpad.net/~hersonls/bzr/slackbuild and in https://code.launchpad.net/~hersonls/ say be empty
[04:43] <spiv> hersonls: it doesn't look empty to me
[04:43] <poolie> lifeless: oh could you please fix 1.4 pqm this afternoon, if you did'nt already?
[04:43] <poolie> hersonls: there is a slight lag before the web ui updates, you might have hit that
[04:44] <hersonls> poolie, i can lock this branch for push by another users?
[04:45] <poolie> hersonls: oh is this the data to build bzr in slackware? great!
[04:45] <hersonls> poolie, yeah
[04:45] <poolie> hersonls: you want to let them write, or not let them write?
[04:46] <poolie> man, team creation is just impossible to find in lp...
[04:46] <hersonls> not write
[04:46] <poolie> ok
[04:46] <hersonls> i can do that?
[04:46] <poolie> because that branch is owned by you, only you can write
[04:46] <hersonls> ohhh
[04:46] <hersonls> yeah
[04:47] <hersonls> i can build team for this branch?
[04:47] <poolie> on that page it says (to me) "Upload URL:   You cannot upload to this branch. Only hersonls  can upload to this branch. "
[04:47] <hersonls> oh, tanks...
[04:47] <hersonls> i brazilian, and my english is bad
[04:47] <hersonls> sorry
[04:47] <poolie> if you want it to be writeable by a team create one at https://launchpad.net/people/+newteam
[04:47] <poolie> it's ok
[04:48] <poolie> de nada :)
[04:48] <hersonls> ohh
[04:48] <hersonls> você fala portugues?
[04:48] <poolie> un poco
[04:48] <poolie> uh that's about the limit :)
[04:48] <hersonls> bomm
[04:49] <poolie> but there are several brazilian people in #launchpad
[04:49] <poolie> or indeed sometimes here
[04:49] <poolie> like kiko
[04:49] <poolie> biab
[04:51] <hersonls> poolie, my team can write in branch?
[04:53] <poolie> you'd need to also change the branch to be owned by that team
[04:55] <hersonls> ok
[04:56] <hersonls> poolie, the list of all files of the branch, can see where?
[04:56] <hersonls> in http://bazaar.launchpad.net/~hersonls/bzr/slackbuild
[04:56] <hersonls> ?
[04:57] <poolie> hersonls: click the directory name
[04:57] <poolie> (really gone now
[04:58] <hersonls> i can use that links to wikipage of the bazaar for download?
[05:00] <hersonls> poolie, ?
[05:29] <lifeless> bbiab
[05:42] <thumper> lifeless: found the problem
[05:43] <thumper> lifeless: ping me when you have some time to talk about it
[06:31] <lifeless> thumper: so
[06:32] <thumper> lifeless: bug 217112
[06:32] <ubotu> Launchpad bug 217112 in pqm "Test failures on a clean checkout" [Undecided,New] https://launchpad.net/bugs/217112
[06:33] <thumper> lifeless: I was also bitten by 210165
[06:33] <thumper> bug 210165
[06:33] <ubotu> Launchpad bug 210165 in launchpad-bazaar "BugBranch links created after pushing a copy of a branch with "bugs" revision properties" [High,Fix committed] https://launchpad.net/bugs/210165
[06:33] <thumper> lifeless: so I'm cleaning the branch on LP right now
[06:35] <lifeless> thumper: so, linking the branch is good
[06:36] <lifeless> what would be better is linking the branch *and* providing a link which will show me the merge preview of the branch.
[06:36] <lifeless> (presumably via loggerhead)
[06:36] <thumper> lifeless: the merge preview stuff is coming (RSN)
[06:36] <thumper> unfortunately I have to head out for an hour and a bit
[06:36] <thumper> so we could talk about this tomorrow morning if you like
[06:37] <lifeless> cool; but it should be there *before* the merge is requested, if you see what I mean
[06:37] <lifeless> thumper: +1 on the fix; but the comment isn't needed there
[06:37] <lifeless> it is clear that it is the right thing to do
[06:38] <thumper> ok
[06:38]  * thumper away
[06:38] <lifeless> drop the comment and update the branch, I'll merge it to mainline tomorrow
[08:32] <ubotu> New bug: #217134 in bzr "Break-lock: Bzr doesn't accept my keystrokes to allow it to continue" [Undecided,New] https://launchpad.net/bugs/217134
[08:49] <igc> night all
[08:54] <lifeless> thumper: well, a) lp should notify the bug subscribers
[08:55] <lifeless> thumper: and b) a bug comment would be fine
[08:55] <poolie> night ian
[08:55] <thumper> yeah, I guess
[10:34] <jelmer> Ran 783 tests in 29550.804s
[10:56] <ubotu> New bug: #217180 in bzr-svn "Bzr update crashes" [Undecided,New] https://launchpad.net/bugs/217180
[11:47] <ubotu> New bug: #217188 in bzr "bzr update crashes with KnitCorrupt error" [Undecided,New] https://launchpad.net/bugs/217188
[12:58] <poolie>  /win 12
[13:24] <guilhemb> Hello! a question: I used bzr on a Windows machine, to modify a file originally created under Unix (lines terminated with LF), and after that the file had all its LF changed with CR-LF, and "bzr gcommit" showed all lines changed because of that.
[13:24] <guilhemb> I remember some other revision tool which handles that fine (it must discard CR-LF along the way);
[13:24] <bob2> ideally your editor should not screw them up
[13:24] <guilhemb> is there a switch in bzr to have that too?
[13:25] <bob2> but there is development in bzr to add that feature
[13:25] <guilhemb> bob2: I agree; but I'm not driving Visual Studio's roadmap :))
[13:25] <bob2> but it does not afaik exist yet
[13:25] <guilhemb> bob2: this is good news! do you know a place where the planned development is tracked (a bug report, anything?)
[13:26] <bob2> http://bazaar-vcs.org/LineEndings seems still current tho old
[13:28] <bob2> "Status of this work: I have working implementation and will send merge request soon.", yay
[13:30] <guilhemb> bob2: and that comment is 2 days old!!
[13:30] <guilhemb> bob2: thank you for the link!
[13:30] <bob2> no worries
[14:32] <nevans> jelmer: is the 0.4 bzr-svn branch "safe" to use with bzr 1.4rc1 at the moment?  or should I stick with bzr 1.3 for a while longer?
[14:40] <awilkins> Anyone know the status on custom merge support? The particular case I'm interested in is "per filetype merge support" ; I want to be able to unpack an XML file into a more merge-friendly line format, then pack it back up again after the merge has finished.
[14:50]  * awilkins reads the code and concludes that he could make a plugin that implemented a merger that inherited from Merge3Merger or Diff3Merger that did the required stuff.
[14:50] <awilkins> Would that be accurate?
[14:53] <asabil> awilkins: there is a plugin that implements diff for ms word files iirc
[14:54] <awilkins> Aha, yes, I'll take a look at the source for that
[14:54] <asabil> http://gigo-ice.org/scm/bazaar/plugins/docdiff.html
[14:55]  * awilkins is quick on the draw and is aleady pulling the branch :-)
[14:55] <asabil> :)
[14:57] <awilkins> Not quite what I wanted though ; I want something that meshes seamlessly with "bzr merge" for my special case.
[14:58] <awilkins> I think I see the way though - if I inherit from one of the existing mergers I should be able to register a new one.
[15:13] <abentley> awilkins: That's correct.  Odd_Bloke was working on support for custom merges at the sprint, but I haven't heard since.
[15:14] <awilkins> abentley: From what I've read so far, the merge classes could be refactored out a little ot make custom merging a bit easier to implement
[15:14] <abentley> awilkins: I'm sure that's true.
[15:15] <awilkins> abentley: e.g. ; all I require is a pre-process step and a post-process step, but I'm probably going to have to (at a minimum) cut/paste the whole text_merge routine from Merge3Merger
[15:16] <awilkins> Odd_Bloke: awake?
[15:32] <intellectronica> howdy
[15:33] <intellectronica> i am having problems pushing a local branch using bzr 1.4rc1 to a server running 1.3.1 (i suspect this is since the upgrade, but am not certain). is that a known problem?
[15:46] <abentley> intellectronica: no
[15:46] <intellectronica> abentley: cheers. i'm now discussing this with jam on bzrlp, b.t.w
[16:01] <ubotu> New bug: #217290 in bzr "Error during "bzr commit" ERROR: exceptions.MemoryError" [Undecided,New] https://launchpad.net/bugs/217290
[16:44] <Odd_Bloke> abentley, awilkins: Just going to bed, in fact.  To answer several questions at once, I'm not at uni ATM so am catching up with family and friends who I don't see that often.  I head back on Wednesday and so should get back into the swing of things shortly. :)
[16:44]  * Odd_Bloke --> sleep the sleep of the dead
[17:00] <ubotu> New bug: #217313 in bzr ""bzr push" fails with error "unable to rename ..."" [Undecided,New] https://launchpad.net/bugs/217313
[17:49] <LeoNerd> I wonder what the reaction would be to a bzr plugin with an amusing name. I'm thinking of a combined push/pull, which syncs in either direction provided one side is just older than the other... "bzr sync" sounds too generic. What about "bzr llama", as a joke on the Push-me-Pull-you from Dr Doolittle
[18:07] <sm> good morning.. what's the correct lp: equivalent for bzr branch http://bazaar.launchpad.net/~zope2book/zope2book/zope2book ?
[18:09] <sm> I thought bzr help urlspec would tell me
[18:09]  * sm has 1.3
[18:15] <sm> why do I get bzr push lp:~zope2book/zope2book/zope2book
[18:15] <sm> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ezope2book/zope2book/zope2book/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[18:15] <sm> ?
[18:15] <radix> sm: you can't push to launchpad over HTTP
[18:15] <radix> sm: use bzr+ssh instead
[18:15] <sm> ah, thanks
[18:16] <radix> sm: oh, I see your command. I think you can use 'bzr lp-login' and a sufficiently recent version of bzr to have that automatically happen for 'lp:' urls
[18:16] <radix> or maybe I'm making all of that up
[18:20] <sm> trying bzr lp-login username then push lp: .. it's sitting there for quite a while
[18:20]  * sm has made one small patch
[18:20] <sm> worked! thanks
[18:20] <radix> sm: cool!
[18:20] <radix> I'm not a liar! yay
[18:24] <fullermd> Hm.  bzr viz misnumbering revisions...
[19:30] <ubotu> New bug: #217377 in bzr "merge in shared repository failed assertion" [Undecided,New] https://launchpad.net/bugs/217377
[20:25] <dwt> Hey guys, I'm still new to bzr - is there a way to cherrypick individual hunks out of a file for a commit?
[20:25] <dwt> I couldn't find anything on the wiki
[20:26] <dwt> so I figured I'l ask you guys.
[20:26] <dwt> oh, and I'm on 1.2.0
[20:31] <awilkins> dwt - bztools shelve plugin
[20:40] <dwt> thanks
[20:47] <asabil> dwt: and the interactive plugin provides the opposite
[20:47] <dwt> awilkins: Thats indeed very cool. I do prefere to puth stuff to the side
[20:47] <dwt> so I can test in the tree
[20:47] <dwt>  before comitting
[20:48] <dwt> However I don't quite get how to tease apart individual hunks.
[20:48] <dwt> Is that possible with shelve?
[20:48] <dato> it is
[20:48] <dato> it will show you each hunk
[20:49] <dato> and ask what to do with it
[20:49] <fullermd> No, you can't work at a sub-hunk granularity with it...
[20:49] <dwt> Is there a way to separate a hunk manually?
[20:50] <dwt> I mean, so bzr sees it as two hunks?
[20:50] <dato> ah, I misunderstood the question
[20:53] <awmcclain> Hi all. Just wanted to say how much we love bzr. We just re-rooted our entire branch effortlessly and bzr handled all the merges like a dream.
[20:56] <dwt> dato: Thanks anyway!
[21:18] <abentley> dwt: At sub-hunk granularity, you're better off using your editor's diff mode.
[21:18] <abentley> e.g. bzr diff --using gvimdiff
[21:19] <dwt> abentley: Well, my diff tools all dont let me choose what parts of a hunk I want it to see as a new hunk. :-(
[21:20] <dwt> But maybe I'm missing something
[21:21] <abentley> dwt: For shelf to work at sub-hunk granularity, it would have to become a crappy editor.
[21:21] <rockstar_> Can I use bzr-svn on an svn repo over https?
[21:21] <abentley> So use an editor instead.
[21:22] <dwt> abentley: yeah, I could try to insert something that was in the old revision in between those so I can shelve the other stuff and then return to the previous state
[21:22] <abentley> dwt: What is your editor?
[21:23] <dwt> I use Xcode mostly
[21:23] <dwt> Or Textmate
[21:23] <dwt> On OS X
[21:23] <abentley> Does Textmate have a diff mode?
[21:23] <dwt> not really - it can view diffs
[21:23] <dwt> in very nice ways
[21:24] <dwt> though no commands to bzr from there
[21:24] <abentley> Ah.  Vim and Emacs both provide ways to edit a file while showing a comparison to a previous version.
[21:25] <dwt> How does that allow me to split a hunk
[21:25] <dwt> ?
[21:25] <abentley> Which makes it easy to restore old lines.
[21:25] <dwt> ok, true
[21:25] <abentley> There is no hunk-splitting support in bzr because if you need to split hunks, you really need to use an editor anyhow.
[21:26] <abentley> This does not mean that the editor does hunk splitting.
[21:27] <abentley> It means that the editor is a better alternative than hunk splitting.
[21:30] <Pilky> anybody any idea how long it usually takes for the OS X installer packages to be updated?
[21:35] <dwt> abentley: Well, thanks for the help
[21:36] <dwt> I will see how that works.
[21:56] <statik> dwt: there is a textmate plugin here, but I have not tried it myself: http://bazaar-vcs.org/TextMateBundle
[21:56] <dwt> statik: thanks for the link!
[22:30] <ubotu> New bug: #217454 in bzr-svn "Trying to branch a subversion branch into a shared repo gives AssertionError" [Undecided,New] https://launchpad.net/bugs/217454
[23:16] <mxpxpod> jelmer: does bzr-svn 0.4.9 work with 1.4rc1?
[23:16] <jelmer> mxpxpod: Nope, there's nothing compatible with 1.4rc1 out yet
[23:16] <jelmer> mxpxpod: I hope to release something before friday (when 1.4 is released)
[23:16] <mxpxpod> jelmer: gotcha
[23:32] <lifeless> jam: I am fixing the regression
[23:32] <jam> lifeless: thanks
[23:37] <lifeless> jam: did you file a bug?
[23:38] <jam> lifeless: no, I didn't. Do you want an official bug?
[23:38] <lifeless> no
[23:38] <lifeless> just would have recorded if there was one
[23:38] <jam> sure, how did you chose to fix it, btw
[23:38] <lifeless> patience kemosabe :)
[23:39] <lifeless>     * Severe performance degradation in fetching from knit repositories to
[23:39] <lifeless>       packs due to parsing the entire revisions.kndx on every graph walk
[23:39] <lifeless>       iteration fixed by using the Repository.get_graph API. (Robert Collins)
[23:42] <jam> lifeless: I had thought about that at one point, but it didn't make it into the email, and I also wasn't sure if Graph.get_parent_map() would also be cached.
[23:42] <jam> But I guess KnitRepo.get_graph() returns a wrapper around the KnitVF itseldf
[23:42] <lifeless> KnitRepository._make_parents_provider returns a closure with the revision versioned file
[23:43] <lifeless> actually with my changes it can return the revision vf directly
[23:43] <jam> lifeless: Implementing get_parent_map directly on KVF?
[23:44] <jam> lifeless: have you been telling people about your fix on #bzrrlp?
[23:44] <lifeless> already done
[23:45] <lifeless> no, should I?
[23:46] <lifeless> poolie: ping; I think versioned properties are likely a bad idea and not a dependency for the eol stuff bialix has done
[23:46] <lifeless> poolie: but I don't want to discourage him
[23:46] <jam> lifeless: I'm happy to tell them
[23:46] <jam> they were just reverting from 1.4rc1 back to 1.3.1
[23:46] <jam> and it would be good to have them test it after your patch
[23:46] <lifeless> oh sure
[23:56] <igc> morning
[23:57] <jam> bug #208418
[23:57] <ubotu> Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Fix released] https://launchpad.net/bugs/208418