[00:14] <poolie> hi all
[00:23] <jbowtie> Hey, is there any reason the Sphinx template doesn't look like the wiki? Should I update it?
[00:23] <poolie> hi jbowtie, the one for docs?
[00:24] <poolie> no good reason; we'd like to make the themes for the main site, the wiki and the docs more consistent
[00:24] <jbowtie> poolie: Yes; I was just thinking it would be nice to make things consistent.
[00:24] <poolie> the www site is the most recent and arguably the best
[00:24] <poolie> though improvement there is still possible
[00:25] <jbowtie> poolie: OK, I'll have a look at rolling a Sphinx template this week along with fixing as many doc bugs as possible.
[00:25] <poolie> that would be brilliant
[00:25] <poolie> it doesn't need to slavishly follow the main site
[00:25] <poolie> for example i think the left-side table of contents is useful and should stay
[00:26] <poolie> but if we could at least get consistent tabs across the top that would be good
[00:26] <poolie> it may help if you post screenshots as you go
[00:26] <jbowtie> poolie: I'm looking at the tabs across the top and the footer at the bottom.
[00:26] <jbowtie> poolie: As well as coordinating fonts and colors.
[00:27] <jbowtie> poolie: Good point, I'll attach some screenshots to the bug when I make my merge proposal.
[00:30] <jbowtie> Looking at #405452 - what's a "ghost" revision?
[00:32] <jelmer> jbowtie: it's a revision that Bazaar knows about but that is not present in the repository
[00:33] <jelmer> jbowtie: so for example a parent revision of some revision that is present in the repository could be missing
[00:33] <jelmer> jbowtie: ghosts are usually created when importing revisions from baz or subversion
[00:33] <jelmer> jbowtie: but they could also be created using a (hypothetical) command in bzr
[00:33] <mwhudson> jelmer: since we rolled out the bzr-git update, it seems a few imports now fail with:
[00:33] <mwhudson> bzrlib.plugins.git.errors.NoSuchRef: The ref master was not found.
[00:33] <mwhudson> jelmer: any instant ideas?
[00:34] <jelmer> mwhudson: my guess would be that these repositories do not have a master branch :-)
[00:34] <mwhudson> jelmer: the imports worked before the rollout though
[00:34] <mwhudson> jelmer: see https://code.edge.launchpad.net/~cjwatson/packages-arch-specific/trunk
[00:35] <mwhudson> has bzr-git become more careful about this?
[00:35] <jelmer> mwhudson: yeah, we've become a bit stricter
[00:35] <mwhudson> jelmer: ok
[00:42] <jeremy_c> If I create a project on launchpad.net, can I remove it later or is it like SF.net, once it exists, it lives forever?
[00:44] <mwhudson> jeremy_c: you have to ask an admin to have it removed, but it's not a big deal
[00:45] <jeremy_c> I wanted to give it a try for a while but be able to backout if it doesn't seem like it's working out after a few weeks.
[00:45] <parkesy> Hi I've got some problems with my bzr branch,  I get  "bzr Error: Revision {...} not present in CHKInventoryRepository(...) is there a way to repair this
[00:45] <jelmer> parkesy: when do you get these errors exactly?
[00:45] <parkesy> jelmer: when i do bzr log
[00:46] <jelmer> parkesy: immediately or after a few revisions?
[00:46] <parkesy> jelmer: the first time it was a few seconds after now it is immediately
[00:47] <parkesy> jelmer: it also happens with bzr version-info
[00:47] <jelmer> parkesy: but after a few revisions?
[00:48] <parkesy> jelmer: sorry, it just started happening over night, it was fine on friday, then when i came into work today its failing.
[00:49] <parkesy> jelmer: I tried to fix it myself and had to get the Sysadmins to restore my working branch from a backup taken over the weekend.
[00:51] <mkanat> igc or mwhudson: Are you guys going to merge https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/23977 ?
[00:52] <mwhudson> mkanat: i guess i will unless Peng_ beats me to it
[00:52] <mkanat> mwhudson: Okay.
[00:59] <Peng_> Go ahead. I'm busy watching TV. :P
[00:59] <Peng_> mwhudson: ^
[00:59] <Peng_> Is mkanat a member of loggerhead-team?
[00:59] <mwhudson> done
[00:59] <mkanat> Peng: I'm not.
[01:00] <mwhudson> mkanat: want to be?
[01:00] <mkanat> mwhudson: Oh, um, sure. :-) You'll have to educate me on checkin procedures and so on.
[01:01] <Peng_> Nah, there's not much to educate on.
[01:02] <mwhudson> well, merge into trunk, then push
[01:02] <mwhudson> rather than merging trunk into your branch then pushing that to trunk
[01:02] <spiv> Good morning.
[01:02] <Peng_> You should also commit!
[01:02] <mwhudson> but i'm sure you wouldn't be that tasteless anyway
[01:06] <mkanat> Peng_: Okay. :-)
[01:06] <mkanat> I mean, mwhudson.
[01:06] <mkanat> Peng: Hahah, yes, committing would help.
[01:06] <mkanat> spm: You might want to update to trunk loggerhead again to get that fix we just pushed. It's one of the crashers.
[01:07] <spm> mkanat: okis, ta
[01:17] <mkanat> spm: BTW, has loggerhead stayed up since the pygments fix?
[01:17] <spm> hrm. not sure. looking...
[01:18] <mkanat> spm: I think I'm more or less going to become the contact for loggerhead stability, so any time there's crashes or hangs, I'd love to know.
[01:19] <spm> mkanat: nod; I'll pass that on.
[01:19] <spm> it's been up for about 9 hours atm :-)
[01:19] <spm> not sure what the cause was there
[01:19] <mkanat> spm: Heh. Okay.
[01:19] <spm> unresponsive restart; two of 'em.
[01:19] <mkanat> spm: Would you send me the log from before the restart?
[01:20] <spm> 2010-04-26 15:30 & 2010-04-26 08:28 <== bot hUTC
[01:20] <spm> sure
[01:54] <spm> mkanat: sorry. not forgotten, just had to progress a high priority task. just fetching logs now.
[01:54] <mkanat> spm: Okay, no problem. :-)
[01:54] <santagada> hi I think I found a bug on bzr, it is actually and old hack for osx that I think it is not necessary anymore
[01:54] <santagada> and it makes bzr break on top of pypy
[01:55] <spiv> santagada: oh good.  :)  Please file it at https://bugs.launchpad.net/bzr
[01:56] <spiv> santagada: how close is bzr to running on pypy?
[01:57] <santagada> spiv: run it is running, now I would love to run a test suite to see if there isn't any bugs in it
[01:58] <santagada> spiv: how do I run bzr unittests?
[02:00] <spiv> santagada: bzr selftest
[02:00] <poolie> hi spiv
[02:01] <santagada> i need testtools... just a sec I will first finish filling the bug report
[02:01] <spiv> santagada: to be pedantic, that runs the full automated test suite.  Many of those can be accurately called unit tests, but many are integration tests.
[02:01] <spiv> Morning poolie.
[02:01] <santagada> spiv: so I will be happier if it works
[02:04] <spm> mkanat: mwhudson: ew! this looks .. bad: ERR [20100423-23:59:43.593] [1101093200] root: RuntimeError: maximum recursion depth exceeded
[02:04] <mwhudson> spm: i _think_ Peng_ fixed that
[02:05] <spm> urg even. there's a few in teh debug log
[02:05] <santagada> bzr has a mbp and hg team has one mpm, I wonder how many times people confused the two nicks/people
[02:07] <spm> santagada: probably about as often as spm and spiv :-)
[02:07] <mkanat> spm: I think that's a python bug?
[02:07] <mkanat> spm: Does it say it's being ignored?
[02:10] <spm> mkanat: not that I can see; but it is in the older log = the access and debug aren't rotating at the same time. only just noticed that was from Fri; not today.
[02:10] <mkanat> spm: Okay.
[02:11] <santagada> spiv: https://bugs.launchpad.net/bzr/+bug/570495 if there is any more needed info just ask :)
[02:16] <santagada> spiv: bzr: ERROR: No module named paramiko can't I just skip those testes?
[02:17] <a212901390231901> fixed in r5165 so pull bzr.dev
[02:17] <spiv> santagada: hmm, they should be automatically skipped if the module isn't found.  I think you might be encountering a recently fixed bug.
[02:17] <santagada> spiv: I'm using a tarball for 2.1.0
[02:17] <santagada> the bzr repo is huge
[02:20] <spm> mwhudson: ew. ERR [20100426-09:20:07.255] [1120741712] root: ConnectionError: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known') <== that so can't be good.
[02:22] <mwhudson> spm: i'd agree with that
[02:22] <mwhudson> spm: i'd also apply the SEP field from my POV
[02:22] <mwhudson> if DNS isn't working in the data centre....
[02:22] <spm> there's a heap of them in the debug log
[02:23] <spm> ha
[02:23] <spm> mwhudson: what's a strong I can search for "Oh Hai. loggerhead is now starting up"??
[02:23] <spm> err string, strong string even
[02:23] <spiv> santagada: hmm, that fix hasn't been backported to the 2.1 branch, it's just on trunk
[02:23] <mwhudson> spm: "Starting up..." i think
[02:24] <spm> too bloody obvious. can't possibly be that.
[02:24] <santagada> spiv: also not on 2.2b1 :( cloning the whole repo now
[02:24] <spm> mwhudson: 'loggerhead: Starting up...' haha
[02:24] <a212901390231901> don't think I daggied it either as the previous attempt blew up the push
[02:25] <a212901390231901> trivial diff to cherrypick though
[02:25] <spiv> santagada: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5165
[02:26] <spiv> santagada: you can view/download just that diff from there if you like... but probably having a copy of trunk will turn out to be worth it if you find more issues to fix
[02:26] <santagada> yep... how big is it? it is more than 50mb
[02:27] <a212901390231901> was going to suggest a lightweigth checkout, but my test run is... still running
[02:27] <a212901390231901> B:\TEMP>bzr co --lightweight lp:bzr bzr.dev
[02:27] <a212901390231901> [########\           ]  21179KB   107KB/s | Build phase:Adding file contents 1163/1296
[02:27] <a212901390231901> so, not much of a transfer saving.
[02:28] <santagada> a212901390231901: thanks for the help but now I will just let it finish
[02:28] <spiv> santagada: shouldn't be much more than 50
[02:28] <spiv> a212901390231901: yeah, we haven't really spent much time optimising creating lightweight checkouts via the smart protocol yet
[02:29] <a212901390231901> seems the tree is really that big, too.
[02:29] <spiv> (or updating them, for that matter)
[02:31] <spiv> Yeah, "bzr export bzr-trunk.tar" gives me a 21M tarball.  It compresses down to 6.4M with gzip though.
[02:32] <spm> mkanat: ow. http://paste.ubuntu.com/423106/
[02:33] <mkanat> spm: Lame.
[02:33] <spm> heh, does explain why I was having trouble find the '2nd' start. was 2 mins later.
[02:37] <santagada> the full repo is 60mb or a little more
[02:38] <santagada> I didn't see the ending
[02:40] <santagada> the tests are running
[02:41] <santagada> lots of failures
[02:43] <a212901390231901> it had big problems with unicode filesystem access when I looked at it, but that might be less of an issue on nix
[02:43] <santagada> uhm... it completely froze [1017/23179 in 40s, 1766 failed] blackbox.test_serve.TestCmdServeChrooting.test
[02:43] <santagada> a212901390231901: yep, most of the errors are unicode related
[02:44] <a212901390231901> ...that one's probably not its fault, all the server tests are flakey
[02:44] <a212901390231901> rely on refcounting and spit to hold them together
[02:44] <santagada> I will report some to pypy and someday maybe there can be a buildbot running bzr tests
[02:45] <santagada> a212901390231901: ok, so it will probably not happen
[02:45] <spiv> santagada: we're aware that our server tests have some flakiness, we'd like to fix that.
[02:46] <santagada> I'm getting a ton of NotBranchError: Not a branch: "/private/tmp/testbzr-fP73Gq.tmp/"
[02:47] <spiv> It's biting us in regular use too, we often seem to be leaking threads from tests that spawn servers, and that can lead to spurious failures due running out of fds and similar.
[02:47] <spiv> (And probably makes 'bzr selftest' consume more memory than necessary, etc)
[02:48] <santagada> no I think the real failure is this:
[02:48] <santagada> File "/Users/santagada/projects/bzr/bzrlib/config.py", line 940, in _auto_user_id
[02:48] <santagada>     gecos = w.pw_gecos.decode('utf-8')
[02:48] <santagada> AttributeError: 'NoneType' object has no attribute 'decode'
[02:49] <a212901390231901> that's fixable.
[02:50] <spiv> Interesting that we haven't encountered that one before, but yes should be easy to fix.
[02:50] <poolie> there's another bug asking to just remove auto_user_id
[02:50] <poolie> that would be better imo
[02:51] <spiv> Yeah.
[02:51] <spiv> Certainly there's no need for the test suite to be triggering it for every test as I suspect it does.
[02:51] <poolie> erk
[02:52] <a212901390231901> I was going to file a bug complaining about it, and parse_username, which combine to do some very silly things
[02:52] <santagada> heres the full traceback if someone whants to have a go at it http://paste.pocoo.org/show/206563/
[02:52] <spiv> After all it resets $BZR_EMAIL etc :)
[03:01] <santagada> it appears to be run on all tests, and when it fails I get that notbrancherror probably in another thread if I understood correctly
[03:06] <spiv> santagada: what about this patch: http://bzr.pastebin.com/3EtrtFUu ?
[03:08] <santagada> invalid syntax for some reason
[03:08] <spiv> Oh, missing trailing comma
[03:09] <spiv> My bad for not testing.
[03:09] <santagada> yep, let me fix that
[03:10] <santagada> a TON less failures
[03:10] <santagada> 2 failed thus far
[03:10] <spiv> Hmm, a quick run of the test suite finds a little bit of collateral damage (e.g. blackbox.test_annotate.TestSimpleAnnotate.test_annotate_edited_fileedited_file)
[03:11] <spiv> But that's a good sign.  It's probably a touch faster, too ;)
[03:13] <santagada> unsuported locale setting... uhm maybe pypy _locale is not working as expected
[03:14] <santagada> spiv: is those tests results being saved anywhere?
[03:17] <spiv> santagada: my test results?  No, but I can if you like.  I only ran the blackbox tests, as they seemed most likely to fail, and in the end got 3 failures.
[03:18] <santagada> nope the ones I'm running
[03:18] <spiv> Oh right.  Not by default.
[03:18] <santagada> as there is this status line I don't know what whill happen if I redirect stderr to a file... but I should be doing that..
[03:19] <spiv> If you use --subunit you'll get the test run emitted in a machine-readable format.
[03:19] <spiv> (You can use the subunit2pyunit filter in the subunit package to see the output in a familiar format)
[03:21] <spiv> It'll be a pretty large file (it includes details of the passing tests, too), but it should gzip pretty well.
[03:21] <santagada> well 22 failures out of 1545 tests run, not too bad
[03:22] <poolie> spiv, do you think user_url and control_url etc are reasonable names?
[03:22] <spiv> Yes.
[03:23] <spiv> Especially user_url!
[03:23] <poolie> mm, a big clue that if you're showing it to the user you should use that one :)
[03:27] <Peng_> Ack! I just remembered that I meant to reply to an email like a month ago.
[03:28] <Peng_> It said "let me know this week". :(
[03:28] <Peng_> (My answer was no anyway, so it doesn't matter, but sorry for forgetting to decline the Brussels sprint, poolie.)
[03:41] <santagada> had to kill the selftest process it stopped responding completely
[03:42] <santagada> in test "per_bzrdir.test_bzrdir.TestBzrDir.test_sprout_bzrdir_tree_branch_reference(RemoteBzrDirFor"...
[03:53] <poolie> Peng, ok, thanks anyhow, maybe next time
[05:38] <poolie> spiv, could i get a quick eyeball over https://code.edge.launchpad.net/~mbp/bzr/testsubjects/+merge/24188
[05:48] <spiv> Sure.
[06:13] <lifeless> poolie: I'd like to do a pre-imp call with you on test subjects :- I'd like to clarify what you want to achieve and see if I can help you with that.
[06:14] <lifeless> poolie: if that wouldn't help you, say no thanks :)
[06:15] <poolie> uh, ok
[06:15] <poolie> call me?
[06:16] <lifeless> I'll just see if I've got skype on this machine yet
[06:16] <lifeless> one minute
[06:16] <poolie> do you have a pots line?
[07:32] <vila> hi all
[07:40] <GaryvdM> Morning
[07:41] <poolie> hi vila, gary
[07:42] <vila> hey GaryvdM
[07:42] <vila> hi poolie
[07:53] <vila> Did anybody (else than me) testing bzr on lucid have a failure for bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh ?
[08:05] <poolie> oh lifeless, where did we eventually get to with pqm?
[08:05] <poolie> vila, not me, yet
[08:06] <vila> poolie: hmm, too bad, you were my best hope :)
[08:06] <poolie> i'll try it
[08:07] <vila> poolie: running just this test alone is enough here, I'm wondering if my setup is somehow screwed or if it's something deeper
[08:13] <poolie> no actually i do get that too
[08:13] <poolie> i suspect either a change in ufw
[08:13] <poolie> which i think i'm running here
[08:13] <poolie> or an icky order dependency
[08:13] <lifeless> poolie: spm says no exceptions in pqm since the 24th
[08:21] <Peng_> vila: FWIW, PyCrypto doesn't like fork()ing the random number generator because both processes will wind up with the same state, which is not very random. IIRC it also has thread-safety issues.
[08:23] <vila> Peng: yup, but nothing we care about for tests, thanks for the info though
[08:23] <bialix> hi all
[08:23] <vila> lifeless: no execptions doesn't mean no pending bugs, there are still no feedback on failures
[08:24] <vila> (among other things)
[08:26] <GaryvdM> Hi bialix
[08:26] <vila> bialix: _o/
[08:26] <bialix> Heya GaryvdM !!!
[08:26] <bialix> bonjour vila!
[08:27] <bialix> GaryvdM: I have strnge problem with qpush
[08:27] <poolie> lifeless: ok, but what's the state now? still running with lp integration, or pulled down?
[08:27] <bialix> GaryvdM: push to lp (when no ssh key is loaded to pageant) blows with traceback
[08:28] <GaryvdM> Traceback
[08:28] <bialix> GaryvdM: http://pastebin.com/EDdekYpm
[08:28]  * GaryvdM looks
[08:28] <bialix> the most strange thing is when I set BZR_PDB=1 then qpush simply hangs
[08:29] <bialix> it's in qpush
[08:29] <bialix> my problem is BZR_PDB related
[08:29] <lifeless> poolie: running with integration
[08:29] <lifeless> vila: I will look at that tomorrow
[08:29] <vila> lifeless: be blessed :D
[08:29] <poolie> you didn't pull it out on thursday?
[08:30] <lifeless> it was behaving much better
[08:30] <poolie> k
[08:30] <lifeless> emailed submissions get mailed failures I think now
[08:30] <bialix> GaryvdM: do you (we) change something in qbzr that broke BZR_PDB you made long ago?
[08:30] <GaryvdM> bialix: hmm - you need BZR_PDB on for the qbzr process, but not for the subprocess
[08:30] <bialix> or maybe it's a newer bzr issue
[08:30] <GaryvdM> not sure how to do that.
[08:31] <bialix> GaryvdM: so you think it's a subprocess starting pdb session?
[08:31] <bialix> hmmmmmmmmmmmmmmmm
[08:31] <GaryvdM> yes - before the main process errors
[08:32] <bialix> I don't understand what's going on
[08:32] <bialix> the plain push never raise error?
[08:32] <bialix> or there is some hidden bug in our subprocessUI class?
[08:32] <GaryvdM> bialix: what about running bzr qsubprocess push
[08:33] <bialix> oh, I think I understand
[08:33] <bialix> \n issue
[08:33] <GaryvdM> I do that often to debug qsubprocess
[08:33] <bialix> again :-(
[08:33] <bialix> bzr produce multiline error message
[08:33] <bialix> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
[08:33] <bialix>   bialix@bazaar.launchpad.net
[08:33] <bialix> supported auth types: ['publickey']
[08:34] <GaryvdM> Oh - my new error passing code :-(
[08:34] <bialix> but we're trying to send it as one string
[08:34] <bialix> ok, I understand the problem now
[08:34] <bialix> our bencode stream is very fragile re \n
[08:35] <bialix> we have to encode them somehow, or manually split the string into multiple strings
[08:35]  * bialix filing a bug
[08:36] <bialix> GaryvdM: any ideas re BZR_PDB in subprocess? maybe we should manually delete this variable from subprocess environment?
[08:36] <GaryvdM> That would be a good idea.
[08:37] <GaryvdM> And if one needs to debug the subprocess, then one can just run the subprocess.
[08:39] <poolie> spiv, still here?
[08:39] <bialix> GaryvdM: agree
[08:41] <spiv> poolie: yeah
[08:42] <vila> lifeless: I don't think I got test failures even for my mail submissions (at least I can't find the relevant mail for https://code.edge.launchpad.net/~parthm/bzr/no-chown-if-bzrlog-exists/+merge/22197 and I'm pretty sure I submitted by mail)
[08:42] <poolie> spiv i split out the cleanup change into https://code.edge.launchpad.net/~mbp/bzr/cleanup/+merge/24200
[08:42] <vila> lifeless: I only got failure mails for the NEWS conflicts and the 'nothing to merge' cases
[08:42] <poolie> i have mixed feelings about whether this patch is worthwhile
[08:44] <bialix> poolie: hi :-)
[08:45] <poolie> spiv: istm that some other objects, like a test case, can make use of the concept of having a list of cleanups
[08:45] <poolie> and that it's not part of their public interface to expose a single run()
[08:45] <poolie> but perhaps the answer is that they should just us an OperationWithCleanups internally
[08:50] <spiv> poolie: Command as well as TestCase
[08:50] <spiv> poolie: although I think we now delegate the cleanup management in TestCase to testtools?
[08:50] <poolie> probably
[08:50] <poolie> though there, ideally, if not practicalyl, this same class would be used by all of them
[08:51] <spiv> Oh, and commit.Commit, slightly weirdly perhaps, psuedo-does.
[08:53] <spiv> (it doesn't have an add_cleanup method, instead it passes the operation var around, but in general seems a bit confused about if it's an object with state or a bunch of related functions with intimate knowledge of each other's workings)
[08:53] <WimYedema> Hi all
[08:53] <WimYedema> Can anyone tell me how to change the default editor for editing project files?
[08:53] <WimYedema> Setting the editor in prefs seems to work only for config files
[08:53] <WimYedema> sorry
[08:54] <WimYedema> in bazaar explorer
[08:54] <poolie> WimYedema: is this in explorer?
[08:54] <WimYedema> :/
[08:57] <spiv> poolie: Btw, you may like https://code.edge.launchpad.net/~spiv/bzr/hpss-compat-528041/+merge/24202 — it removes the raise AssertionError in _remember_remote_is_before
[08:57] <lifeless> vila: I will experiment in detail tomorrow when spm is around
[08:57] <spm> lifeless: pls being ware we have zomg priorities atm....
[08:58] <lifeless> spm: and at a time of your choosing
[08:58] <poolie> WimYedema: I don't know off hand
[08:58] <spiv> spm: the LTS can wait, surely? :P
[08:58] <lifeless> spm: primarily though I'll be throwing known bad stuff at it and just asking for backtraces to be pastebinned
[08:58] <WimYedema> I think I can edit editors.conf but it seems I need to add an extension there, and I don't much feel like adding all the possible extensions (never mind things without extension)
[08:58] <spm> spiv: ....
[08:58] <spm> lifeless: we should so get you access to the logs...
[08:59] <vila> spm: +1e6
[08:59] <lifeless> spm: that would be nice; I mean I used to be able to log in to diagnose directly ;)
[08:59] <poolie> WimYedema: I _think_ it's configured at the os level
[08:59] <poolie> and explorer has no opinion
[09:01] <WimYedema> poolie: Hmm... okay, unfortunately Gnome doesn't seem to have a prefered text editor application. I'll try setting EDITOR then...
[09:01] <bialix> WimYedema: please, file a bug
[09:02] <WimYedema> bialix: okay
[09:02] <poolie> yeah it's definitely by extension
[09:02] <poolie> which was a bit strange
[09:03] <bialix> GaryvdM: btw, I have working code for commit-history, now I need to figure out how to fill the combobox with pending merges messages. Any hints?
[09:03] <GaryvdM> bialix: The autocomplete combobox?
[09:03] <poolie> $EDITOR should control it
[09:04] <bialix> GaryvdM: I feel simple combobox will be much easier and faster to use than qdiff + message. Just because I don't need to launch qdiff window, select, copy, close window and paste
[09:04] <bialix> GaryvdM: but your qdiff+message is very good, I think we can do it every time for qdiff -cN
[09:05] <bialix> GaryvdM: it's not autocomplete
[09:05] <bialix> user select message in combobox and it appended to the comment
[09:06] <poolie> WimYedema: setting editor= in your bazaar.conf should do it
[09:06] <WimYedema> setting either EDITOR or BZR_EDITOR does not seem to have any effect
[09:06] <GaryvdM> bialix: I'm not to sure about adding extra widgets to qcommit....
[09:06] <WimYedema> poolie: nope, that's what the preferences menu sets, but it doesn't help
[09:07] <poolie> what does happen then?
[09:07] <WimYedema> it starts gedit
[09:07] <bialix> GaryvdM: it's only one-line combobox
[09:07] <bialix> GaryvdM: what's problem?
[09:07] <WimYedema> could it be Mime configuration or something?
[09:08] <GaryvdM> bialix: qcommit is allready busy.
[09:08] <bialix> GaryvdM: I know. but what is alternative here?
[09:09] <GaryvdM> bialix: we could put it in the autocomplete list.
[09:09] <bialix> GaryvdM: no
[09:09] <bialix> GaryvdM: this is wrong
[09:09] <bialix> the idea is you can put there some past entire commit message
[09:09] <bialix> it could be very long
[09:11] <poolie> WimYedema: it might be mime or it might be /etc/alternatives, controlled by update-alternatives
[09:11] <GaryvdM> bialix: Maybe a button that pops up list or menu, but does not a extra text box like a combo box.
[09:12] <bialix> GaryvdM: and where to put such button?
[09:12] <bialix> can you run my branch to see it in action?
[09:13] <GaryvdM> bialix: ok
[09:13] <GaryvdM> bialix: sorry - what is the url agian?
[09:13] <bialix> you need to make some commits to seed the history, plain bzr ci catched too ;-)
[09:14] <bialix> GaryvdM: lp:~bialix/qbzr/post-commit
[09:14]  * GaryvdM branches...
[09:15] <bialix> the hooks are cool things! I will add similar hooks for post_push/post_pull to store push/pull history in similar manner to commit-history
[09:15] <bialix> MRU
[09:15] <WimYedema> bialix: https://bugs.launchpad.net/bzr/+bug/570573
[09:16] <bialix> WimYedema: thanks!
[09:18] <spiv> WimYedema: GNOME might be using mailcap to figure out how to open the files
[09:18] <poolie> in which case probably /etc/mimetab
[09:18] <poolie> mimecap?
[09:18] <poolie> spiv, so what do you think overall about cleanups?
[09:18] <spiv> poolie: that name would make sense, but no!
[09:18] <poolie> should i withdraw that patch?
[09:19] <spiv> /etc/mailcap, see 'man mailcap' and 'man run-mailcap'
[09:19] <GaryvdM> bialix: I'm going to experiment with putting the messages in the autocomplete list.
[09:19] <spiv> poolie: I just sent a review, did you see it?
[09:19] <bialix> GaryvdM: I'm still think it's a wrong idea
[09:20] <bialix> combobox shows the commit messages in descending order
[09:20] <bialix> auto-complete will lose this ability
[09:20] <spiv> Ooh, and actual PQM failure in a merge proposal.
[09:20] <spiv> s/and/an/
[09:20] <spiv> repr(lines) isn't my preferred format for reading failure output, but it's a lot better than nothing :)
[09:21] <bialix> GaryvdM: does auto-complete handle multiple words?
[09:22] <GaryvdM> bialix: I think so. I want to check.
[09:22] <lifeless> spiv: url ?
[09:22] <bialix> ok, I will test your auto-complete then
[09:22] <spiv> lifeless: https://code.edge.launchpad.net/~mbp/bzr/components/+merge/23827
[09:22] <poolie> oh thanks for the review
[09:23] <SuperMMX> s
[09:23] <SuperMMX> s
[09:23] <lifeless> spiv: that seems to be working okish
[09:23] <poolie> it does feel a bit half done to me
[09:24] <lifeless> spiv: but actually I think its a bug, will leave this open and look tomorrow
[09:24] <poolie> lifeless: which one?
[09:26] <lifeless> [] around the lines in the merge review feedback
[09:26] <spiv> poolie: yeah.  I'm not necessarily against landing half-done things, as I hope I made clear.  Just that it seems something to be aware of.
[09:27] <spiv> poolie: (especially not against it when the next step isn't immediately crystal clear, and the half-done point isn't likely to paint us into a corner.)
[09:28] <spiv> Also, rather than risk mixing metaphors any further I might go have dinner :)
[09:29] <poolie> agree :)
[09:29] <poolie> also about dinner :)
[09:29] <spiv> "No metaphors were harmed in the making of this patch."
[09:30] <bialix> GaryvdM: I'm thinking about adding main menu to qci and qdi to allow user hide the elements he is not interested to see
[09:31] <GaryvdM> bialix: I had such plans for qdiff.
[09:31] <GaryvdM> *have
[09:31] <bialix> but you feel qci is also busy, so we need to allow customization here as well
[09:32] <GaryvdM> bialix: Similar to lp:~garyvdm/qbzr/annotate_find
[09:32] <bialix> also I want to work on redesign of bugs/author area, as Craig suggested in ML
[09:32]  * bialix looks
[09:32] <bialix> poolie: is it possible to work on tags v2 on the sprint?
[09:33] <bialix> poolie: maybe it's better if I send the mail with some my thoughts how I think we could improve current tags
[09:33] <bialix> and operations on tags
[09:34] <bialix> amanica said me he's willing to work on nested trees. I have many feedback on this topic based on scmproj workflow. And I have many questions on the intended nested trees behavior
[09:47] <bialix> GaryvdM: annotate_find: cool! why you don't merge it?
[09:48] <WimYedema> Ugh! you've got to be kidding! I did some googling, and the solution is: Change the Applications>Text Editor entry to the editor you want to use.
[09:51] <GaryvdM> GaryvdM: I want to do similar ui changes to diff, cat, log and browse, an I want to do it at the same time, so that qbzr dialog have consistent feel.  (maybe I'm being silly...)
[09:51] <WimYedema> Anyway, thanks for the support guys.
[09:51] <WimYedema> See you later
[09:51] <GaryvdM> Lol - I'm talking to myself...
[09:51] <GaryvdM> bialix ^
[09:52] <bialix> GaryvdM: noble goal, ok
[09:53] <bialix> GaryvdM: "View options seems misleading. Maybe just "Options"?
[09:54] <GaryvdM> bialix: sure
[09:54] <bialix> nice work, really. although it's not windows style to have such toolbars.
[09:55] <GaryvdM> bialix: Neither gnome, neither mac....
[09:55] <bialix> maybe I'm just nitpicking
[09:55] <bialix> ignore me
[09:56] <GaryvdM> bialix: No - you are correct. This is another reason why I have not merged it.
[09:56] <bialix> GaryvdM: ok, I will ponder about it in the background of my mind
[09:57] <GaryvdM> bialix: It's sort of the route the chrome has taken, an firefox is going to take.
[09:57] <bialix> do you think it's worth to announce our unfinished stuff so people can test/dogfood it?
[09:58] <bialix> my commit-history was easier to implement than I've thought
[09:59] <GaryvdM> bialix: I did link it to the bug. And also discussed here (but as a side topic): http://groups.google.com/group/qbzr/browse_thread/thread/14cae28792ed3ebb
[10:00] <bialix> GaryvdM: It seems I've lost the track of qbzr things after last 2 months :-( I will re-read ML
[10:01] <GaryvdM> bialix: Me too! I did not know about http://wiki.bazaar.canonical.com/QBzr/Roadmap
[10:01] <GaryvdM> bialix: I've done the last item on http://wiki.bazaar.canonical.com/QBzr/Roadmap - see https://code.edge.launchpad.net/~garyvdm/bzr/diff_using_gui/+merge/24076
[10:02] <bialix> GaryvdM: Roadmap was assembled from similar ML discussion
[10:02] <bialix> our users did this actually :-)
[10:03] <bialix> GaryvdM: cool, we will have a chance to discuss roadmap soon. I hope
[10:03] <GaryvdM> bialix: Yhea. I'm looking foward to meeting you! :-)
[10:03] <bialix> :-)
[10:04] <bialix> and volcano calmed down
[10:06] <bialix> GaryvdM: when the football started?
[10:06] <GaryvdM> 48 days I think..
[10:07] <bialix> it will be winter in your land?
[10:07] <GaryvdM> I'm not really interested in soccer, but it's good for SA
[10:07] <GaryvdM> bialix: yes
[10:08] <bialix> snow? ;-)
[10:08] <lifeless> meep, I'm beat -> crashing
[10:09] <GaryvdM> bialix: No. The last time it snowed in Johannesburg was in 1981
[10:10] <bialix> GaryvdM: ok, I see
[10:15] <GaryvdM> bialix:  lp:~garyvdm/qbzr/message_history_auto_complete
[10:15] <GaryvdM> bialix: It could be better.
[10:15] <bialix> GaryvdM: thanks! I'll test
[10:16] <GaryvdM> bugs: Does not handle new line correctly.
[10:16] <GaryvdM> Should find/select if you type in a word in the middle
[10:18] <GaryvdM> QCompleter hits some limitations. :-(
[10:19]  * GaryvdM goes to find food..
[10:19] <bialix> I will test your branch some time. But for me using combolist means nice real summary list where I can look to refresh my memory
[10:20] <bialix> auto-completer lose this ability
[10:20] <bialix> I'm still not sure...
[10:20] <bialix> maybe special button as you said
[10:20] <bialix> :-/
[12:30] <cbz> how do i merge *tO* the subversion trunk?
[12:34] <GaryvdM> cbz: do you have a checkout, or a straight branch?
[12:34] <GaryvdM> If checkout: update, commit, push
[12:35] <GaryvdM> if straight branch: create new branch, merge in that branch, commit, push
[12:35] <GaryvdM> cbz^
[12:53] <cbz> straight branch
[12:54] <cbz> so i pushed to the branch i made - now how do i merge back to subversion? In the normal case where the trunk is on top of everything i guess i can do a push - but if things have progressed since, don't i actually want to do a merge back to subversion?
[12:57] <xnox> how do i reconfigure a branch to use a different higher level bzr shared repo? I've ended up with ~/src/.bzr and ~/src/stable/.bzr   Branches under ~/src/stable/ should use the ~/src/.bzr shared repo
[12:58] <awilkins> cbz, switch your bzr checkout to the trunk and merge your branch to it using bzr, then push it
[12:59] <awilkins> xnox, It automatically uses the first one it finds via directory climbing
[12:59] <cbz> okay
[12:59] <awilkins> xnox, You sound like you might want to try some lightweight checkouts
[12:59] <cbz> i just assumed from http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
[13:00] <cbz> that i should be using a merge *to* the subversion branch
[13:00] <cbz> rather than a push
[13:00] <awilkins> cbz, I think you have to make sure your branch is up to date with trunk
[13:01] <xnox> awilkins, yeap I know that. But if i delete the current sub-share-repo my branches will become broken and i will need to refetch packs over the intranetz to get the packs into higher level shared-repo
[13:02] <awilkins> xnox, You could move the shared repo out with it's branches and push them into the higher level shared repo
[13:03] <awilkins> cbz, Yes, that's why we are switching the checkout to trunk, so we can merge to it and preserve all the bzr metadata
[13:03] <awilkins> cbz, Are you using heavyweight branches / checkouts or lighweights?
[13:03] <cbz> heavyweight branches
[13:04] <cbz> so i have branch trunk with a parent of by svn repository and another branch whose parent is trunk
[13:04] <cbz> I've delivered into trunk - however there is newer stuff in svn
[13:04] <awilkins> cbz, I find using lightweight checkouts of branches in a no-trees repository to be easier with SVN
[13:05] <cbz> I can hack normally get things into the svn repository, this paragraph has me wondering whether i'm missing something though:
[13:05] <cbz> "This is where the potential problem comes into play. You could push myhacks directly into trunk, after all, it’s up-to-date with the changes. But look at the commit ordering. Right now, F is the last commit on trunk. If you push myhacks into trunk, it needs to re-order the commits to make them look like what is present in myhacks. From a Subversion user standpoint, that’s confusing to see, although correct from a commit graph perspective. For this reas
[13:05] <cbz> "A better answer is to merge your feature branch back to trunk, just as you would have done with Subversion or a short term branch. The resultant commit graph is now: "
[13:06] <awilkins> Right, so no pushing branches straight to trunk
[13:06] <cbz> I could always fix it using rebase - but it implies i could merge *to* the svn repository
[13:06] <awilkins> Instead, keep a local "trunk" mirror that you never work on
[13:06] <awilkins> Pull that, merge to it, push back
[13:07] <cbz> And if someone has put something into it between my pull and my merge?
[13:07] <cbz> (it in this case being the svn repository)
[13:07] <awilkins> cbz  then you'll have to do it again
[13:08] <awilkins> cbz, It's annoying.
[13:08] <awilkins> cbz, It shouldn't be too bad unless your commit rate is mad
[13:52] <swathanthran> would bzr send take much data transfer?(and is it much problematic that my copy may be a bit behind the original) (its 2.3mb and going and i have a costly bandwidth:))
[13:54] <swathanthran> oh btw would  bzr send -o my-patch.txt  try to mail the patch too?(not just produce my-patch.txt?)
[13:55] <maxb> No
[13:55] <maxb> If bzr send is doing network access, it would be to access the submit branch
[13:56] <swathanthran> yeah my copy is not upto-date
[13:56] <swathanthran> its >3mb and i guess i would have to try it later on free net time.
[14:00] <swathanthran> in general the download was slow compared to usual file download rates .. would that be with the server? i am working with emacs so its connecting bzr.savannah.gnu.org
[14:06] <vila> swathanthran: yeah, AFAIK, savannah haven't deployed the bzr smart server which should greatly improve (i.e. reduce) bandwidth use
[14:06] <swathanthran> oh ic
[14:08] <xnox> I'm trying to experiment with join --reference using 2a format. Does that work? join succeeded and added just the directory but now I have all files under the JoinedBranch/ being status unknown when I'm in the containing tree
[14:09] <swathanthran> see ya later:)
[14:12] <xnox> Oh I get errors of not being supported to generate inventory =) oh well i'll try again later ;-)
[14:13] <maxb> Although bzr's network usage can be a bit silly even with the smart server :-/
[14:21]  * jelmer wonders if he should respond to the huge bzr thread on the mercurial mailing list
[14:23] <bialix> GaryvdM: I think I don't like auto-completion idea in general. My use case for commit-history: select some past commit message and insert it into text area, then edit/change if necessary
[14:24] <bialix> jelmer: is it worth it?
[14:24] <jelmer> bialix: the thread, or replying?
[14:25] <GaryvdM> bialix: ack
[14:25] <bialix> jelmer: replying
[14:25] <GaryvdM> jelmer: What is the subject, so I can google it?
[14:25] <bialix> I don't read that thread though
[14:25] <bialix> GaryvdM: what it means (ack)?
[14:26] <GaryvdM> bialix: (Ack)nowledge receiving message.
[14:27] <bialix> GaryvdM: ack
[14:33] <xnox> bialix, I can't find it either =(
[14:33] <xnox> jelmer, please tell us which thread it is =)
[14:33] <bialix> xnox: what?
[14:34] <xnox> Sorry got the nicks mixed up
[14:34] <bialix> jelmer: do you mean this thread: Not a holy war - just some salient facts
[14:34] <bialix> ?
[14:34]  * xnox was talking about that =)
[14:35] <jelmer> bialix: yeah
[14:35] <bialix> jelmer: I don't read it
[14:35] <bialix> saw it
[14:36] <bialix> but don;t read
[14:37] <bialix> folks, beginning of the thread is here http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/1927
[14:38] <bialix> sorry, beginning of the thread is here http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/19277
[14:38] <bialix> copy-paste error
[14:41] <bialix> vila: ping
[14:42] <GaryvdM> Pretty civilized, as for as dvcs discussions go... :-P
[14:42] <vila> bialix: pong
[14:47] <bialix> vila: I'm a bit confused re hooks
[14:48] <bialix> what is the best idea to avoid duplicating of hooks?
[14:49] <bialix> maybe I need to check (how&) that some hook is already installed before I'm starting to install it again?
[15:00] <xnox> is there a way to pass hooks together with a branch to someone else? e.g. developer hooks for developers to run on the branch? or shall i just create my custom souce hooks plugin and ask my devs to install it?
[15:01] <vila> bialix: I don't understand, why would you install the same hook twice ?
[15:01] <bialix> xnox: you have to create plugin
[15:01] <xnox> bialix, ok thanks ;-)
[15:01] <bialix> vila: read my recent mail in bzr ML
[15:02] <bialix> vila: in short: I want to share some functionality between plugins
[15:05] <vila> bialix: hooks can have names, that should allow checking their presence
[15:05] <bialix> vila: it seems I've lost in hooks.py
[15:06] <vila> bialix: when you can't understand the code anymore, write a test :-D
[15:06] <bialix> vila: Hooks class have _callable_names private
[15:07] <bialix> vila: there is no public method to check either my name is already registered
[15:07] <bialix> so I don't understand the purpose of this names?
[15:08] <vila> Hooks is a dict
[15:08] <vila> meh, wrong class
[15:09] <bialix> Hooks have install_named_hook method which I'm talking about
[15:09] <bialix> s/have/has/
[15:14] <xnox> jelmer, that thread as far as I see died off by itself. It does hurt to read some comments about bzr while some of them are true they are not quite precise. Hg is nice it's a bit gitified for my opinion though. And getting your revision number renumbered just because you pulled some branches in a different order is just plain silly imho
[15:16] <xnox> they try to make it obvious that: "hg has rev numbers just because we use python and can do easy index lookups using those supplied by the user"
[15:17] <xnox> and then you have ML threads on python: "doh how do we identify builds of the mainline"
[15:17] <vila> bialix: what's wrong with get_hook_name ?
[15:18] <bialix> vila: it requires callable argument?
[15:19] <bialix> so I have to iterate over all callables and check if some of them have interesting name?
[15:19] <vila> bialix: I still don't understand what you want, a callable is fine to use to check for uniqness no ?
[15:19] <vila> bialix: meh, you know the hook you want to install right ?
[15:20] <bialix> 2 plugins will have 2 copies of the same callable. so these 2 callables will be different
[15:20] <bialix> I don't want to fire the 2 copies of one callable
[15:21] <vila> If there are 2 different callables neither one will be called twice....
[15:21] <vila> If you want to have a unique callable... define a single callable
[15:21] <vila> if two plugins are involved, how do you guarantee that the code is the same ?
[15:22] <bialix> I can't guarantee of course
[15:22] <bialix> but I can assume this
[15:23] <bialix> in my particular case hook store some data in file, and I don't want to store the data twice
[15:24] <vila> check the data then ?
[15:24] <vila> IME, hooks shouldn't depend on other hooks (not bzr-specific)
[15:25] <bialix> I'm agree with you
[15:26] <bialix> but what about plugin depending on other plugin? ;-)
[15:26] <vila> yeah, depends is not the correct word, sorry,
[15:26] <bialix> or maybe just depends on qbzr always
[15:27] <bialix> I think I'm wrong somewhere
[15:27] <vila> it's more that hooks shouldn't step on each other toe
[15:27] <bialix> I'm just trying to get your feedback
[15:28] <bialix> maybe I need to read book on developing hooks
[15:28] <bialix> unfortunately I don't have such book
[15:28] <vila> At first glance I'd go with a dedicated plugin
[15:28] <vila> Most of my experience with hooks is from emacs (and gtk a bit)
[15:30] <vila> there you can check for the presence of a given hook (a given callable) and insert your own hook in front of the list of at the end
[15:31] <vila> but ISTM you want to *ensure* a hook is present or insert it otherwise, I don't think you want to play tricks with different versions of the same hook managing the exact same data
[15:32] <bialix> vila: correct
 nested trees
[15:33] <vila> bialix: another alternative you didn't mention is adding support in core...
[15:33] <vila> worth discussing in Brussels at least
[15:34] <bialix> adding to core what? my mru-beast?
[15:34] <bialix> yes, someone asking for this in the past
[15:35] <vila> xxx around saving commit messages when uncomitting
[15:35] <bialix> vila: yep
[15:35] <bialix> vila: why <shudder> nested trees?
[15:36] <vila> there are various needs in this area that are addressed (or not) differently by various plugins for various needs
[15:36] <bialix> this area?
[15:36] <bialix> we need to resync
[15:36] <vila> your mru-history plugin could be a nested tree in qbzr while being a plugin on its own
[15:36] <vila> or something
[15:37] <bialix> vila: hmm
[15:37] <bialix> but bzr can't load nested plugins
[15:37] <jelmer> bialix: lazily importing it?
[15:39] <vila> bialix: no, but you could register your hook is the plugin wasn't installed, still the same code
[15:40] <bialix> jelmer: import the plugin?
[15:42] <bialix> maybe try-except ImportError
[15:43] <bialix> maybe jelmer right: try to import mru plugin, if it is not installed then register hook from the nested copy
[15:43] <bialix> that's idea
[15:44] <jelmer> bialix: lazily import from the plugin
[15:44] <jelmer> bialix: when you use it, rather than when your plugin is imported
[15:45] <bialix> jelmer: mmm... I need to eliminate duplicating of hooks, I feel I can't do this with lazy import
[15:47] <xnox> jelmer, some of my problems with svn-keywords was that upstream committed expanded keyword as a commit and bzr-svn would shrink it again. Do we need to handle cases like that?
[15:47] <xnox> jelmer, also bzr-svn does it cache "discovering revisions / tags"
[15:47] <xnox> i'm pulling gcc branches it takes for ever to discover tags over 150k of svn commits
[16:16] <cody-somerville> jelmer, Can you look at why https://code.edge.launchpad.net/~vcs-imports/live-helper/trunk is failing?
[16:17] <jelmer> xnox: I'm not sure I understand the problem
[16:17] <jelmer> xnox: the keywords aren't stored expanded in the repository
[16:17] <jelmer> xnox: it should cache the tagging information; if it doesn't, please file a bug
[16:17] <jelmer> cody-somerville: one sec
[16:19]  * GaryvdM is adding --preview-using and --preview-format to merge
[16:20] <GaryvdM> Is there a way to control the order that options show in help?
[16:48] <bialix> GaryvdM: no, AFAIK
[16:49] <GaryvdM> bialix: ok. Not to important
[16:50] <GaryvdM> bialix: now working on bzr merge --preview-format qdiff :-)
[16:50] <bialix> wow!
[16:51]  * bialix dogfooding commit-history. feels happy
[16:51] <GaryvdM> Jelmer made some changes which makes it eaiser :-)
[16:51] <bialix> !!!
[16:52] <bialix> GaryvdM: I'm using colo all the time
[16:52] <bialix> maybe we should provides some colo-specific branch manager in qbzr?
[16:52] <bialix> there is some q-commands in colo itself
[16:53] <jelmer> cody-somerville: hmm
[16:53] <bialix> will be nice to have more richier
[16:53] <jelmer> cody-somerville: the issue is in what we use as the default branch
[16:53] <jelmer> cody-somerville: we used to just use HEAD, but that didn't work for all branches so we switched to refs/heads/master. Arguments can be made for both.
[17:01] <jelmer> cody-somerville: the proper fix here is to use the colocated branch support but that hasn't landed yet.
[17:57] <blueyed> How can I rewind to a previous revision, before e.g. some merge? "revert -r" helps, but when reverting local changes via "revert", I'm back at the tip of the branch..
[18:01] <xnox> blueyed, if you want to throw away those commits you can do $ bzr uncommit
[18:01] <xnox> if you need to do something useful with the past commit do
[18:02] <xnox> $ bzr branch -r$rev_spec_before_merge branch_current/  snapshot_old/
[18:02] <blueyed> xnox: thanks. I'm not sure.. I got them via "pull" - or rather "rebase", which fell back to pull.
[18:02] <blueyed> Can I uncommit, but then pull/merge again?
[18:03] <xnox> blueyed, why do you want to go back?
[18:03] <blueyed> I want to merge another branch, but rebase the commits in the same step
[18:03] <xnox> branch off the commit you want as I showed above. Redo merge and use that branch for rebasing
[18:04] <xnox> "redo merge" means "do any merge you want" and then rebase that new branch as you want
[18:04] <blueyed> shouldn't uncommit -r $BEFORE and then retrying from there work the same way? and more easily?
[18:07] <blueyed> How do I merge a forked off branch, but rebasing on the go? (doing "bzr rebase $derived" will use pull instead)
[18:07] <blueyed> via --force or something like that?
[18:08] <blueyed> or "merge && rebase --pending-merges"?
[18:09] <blueyed> well, "bzr rebase --pending-merges" says "No revisions to rebase."
[18:11] <blueyed> xnox: I
[18:11] <blueyed> 'm lost.. any further hints.
[18:11] <xnox> blueyed, ok
[18:11] <xnox> what's the branch name which has this merge pulled in?
[18:11] <blueyed> given I've uncommitted, what to do to merge a branch, but rebase it.
[18:11] <blueyed> I've uncommitted. back to the start.
[18:11] <blueyed> the remote branch is via sftp
[18:12] <xnox> so you can regrab what you have just uncommitted? (checking to make sure we didn't mess up)
[18:12] <blueyed> yes
[18:12] <xnox> ok
[18:12] <xnox> what do you want to rebase onto what?
[18:13] <xnox> do you want your branch to be on top of the sftp one or the other way around?
[18:13] <blueyed> I have my "master", and have branched from there into "sftp".. Now I want to get "sftp" into master, but rebased.
[18:13] <xnox> right do this
[18:14] <xnox> $ bzr branch sftp branch-sftp
[18:14] <xnox> so you have a local branch which is what you have on sftp
[18:14] <xnox> cd branch-sftp
[18:14] <xnox> bzr rebase master
[18:15] <xnox> this way all changes in sftp will appear as if you made them after getting everything from master (your history will be linear)
[18:15] <xnox> does this get you what you want?
[18:16] <blueyed> xnox: well.. I prolly misunderstood rebasing then (in this case): they are already linear (I've not changed master after branching sftp from it). I just want to redo the commits.
[18:16] <blueyed> it's different from git rebase then apparently
[18:16] <blueyed> current procedure says "No revisions to rebase."
[18:17] <xnox> ok if you want to redo commits. do get back to the start of the commits you want to change.
[18:17] <xnox> for example $ bzr branch master -r-20
[18:17] <xnox> $ bzr branch master -r-20 rework
[18:18] <xnox> this will put you back 20 revision for example
[18:18] <xnox> then in rework you can either commit new stuff or pull new stuff
[18:18] <xnox> for example
[18:18] <xnox> $ bzr merge master -r-20..-19
[18:19] <xnox> $ bzr merge master -r-20..-19 --force
[18:19] <blueyed> well.. I'd rather like to pull the sftp branch, then rebase anything since -r-20, the commit and push. is this possible?
[18:19] <xnox> yes
[18:19] <blueyed> also, "bzr branch master -r-20 rework" is the same as "uncommit -r-20" prolly, isn't it?
[18:20] <xnox> yes it is
[18:20] <xnox> once you are at that old point
[18:20] <blueyed> I am - via uncommit.
[18:20] <jam>  /who xnox
[18:21] <jam> btw, hi :)
[18:21] <xnox> so merge only those revisions you want
[18:21] <xnox> e.g. $ bzr merge sftp -r-20..-10
[18:21] <xnox> or something like that
[18:21] <blueyed> ok. I see. I uncommit, then merge each revision by hand, and commit..
[18:21] <xnox> blueyed, yeap then you will have different history from master
[18:22] <blueyed> seems like git rebase is far more advanced and not the same as bzr rebase.
[18:22] <blueyed> xnox: no. I uncommit and recommit in master.
[18:22] <blueyed> master has not been pushed yet, so no problem.
[18:22] <xnox> blueyed, you can do everything in bzr rebase what you can do in git rebase
[18:22] <blueyed> just not very convenient for ~20 revisions
[18:22] <xnox> blueyed, $ bzr merge -r-20..-1
[18:23] <xnox> will merge all 20 revisions
[18:23] <blueyed> sure.. but with the same time and same commit message.
[18:23] <xnox> blueyed so what do you want to change
[18:23] <xnox> sorry I'm confused
[18:23] <xnox> for example master is
[18:23] <blueyed> mostly timestamps
[18:23] <blueyed> (and group some commits)
[18:24] <blueyed> IIRC "git rebase -i" allows you to squish/squash single commits.
[18:24] <xnox> well for that you will need to do $ bzr merge -r-20-19      <- to change timestamp of one revision
[18:25] <xnox> and to squish you would do $ bzr merge -r-19..-15
[18:25] <blueyed> not only merge, but also commit. two commands per revision.
[18:25] <xnox> I was about to write that --interactive is the only killer bit in git rebase ;-)
[18:25] <xnox> blueyed, that's by design ;-)
[18:25] <blueyed> so :) - not the same :D
[18:25] <xnox> generally bzr strongly discourages rewrites of the history
[18:26] <blueyed> I see :P
[18:26] <xnox> blueyed, you can get away from rewriting in your case actually
[18:26] <xnox> eg. $ bzr merge . -r-1..-20
[18:26] <xnox> this will create a merge which undoes previous 20 commits while keeping history linear
[18:27] <xnox> but this will look a bit messy in the $ bzr log =) if you are perfectionist
[18:27] <xnox> jam, hi wassup?
[18:27] <blueyed> you mean "merge ." after "pull"?
[18:27] <jam> nothing, just seeing who was talking
[18:27] <jam> I didn't recognize your nick
[18:29] <xnox> blueyed, yeap "merge . -r-1..-20" will merge commits from the current branch in reverse order meaning undoing them
[18:29] <xnox> so if you really don't like commit 7
[18:29] <xnox> you can do $ bzr merge . -r7..6
[18:29] <blueyed> I see. sure. but I like 99% of those 20 commits.
[18:30] <xnox> so undo just one of them
[18:30] <xnox> the once you don't like
[18:30] <xnox> so take your sftp branch and reverse-merge those you don't like ;-)
[18:30] <blueyed> I start from uncommit anyway. they are quite separate already. I do not squash them into less than 15 commits on master.
[18:31] <blueyed> Yes, I've understood that I have to merge by hand.. ^^
[18:31] <blueyed> really messy though.
[18:31] <xnox> blueyed, good =) hope this helped a little bit
[18:31] <xnox> blueyed, how did you get to this state?
[18:31] <blueyed> sure. thanks for your help, xnox
[18:31] <blueyed> branched off and developed. should be quite common ^^
[18:32] <xnox> cause sometimes I do a trick of developing on one branch and then going to a fresh master and instead of merging I just bluntly copy the whole dir from the states I like and commit that
[18:32] <blueyed> It's just that I want to rewrite history and bzr makes this far too difficult.
[18:32] <xnox> quicker then bothering with rewrite
[18:32] <blueyed> sure. but then you have it all in one commit.
[18:32] <blueyed> it's about ~15
[18:33] <xnox> blueyed, also look into bzr-pipeline plugin which helps with refactoring work into commits
[18:33] <dash> some people use bzr because they feel that rewriting history is morally suspect ;-)
[18:33] <xnox> blueyed,  I think you will have easier time with bzr-pipeline plugin
[18:33] <blueyed> i've looked at pipeline already, also loom (the same?). too difficult.
[18:34] <blueyed> ok, thanks, will look at it again
[18:34] <xnox> blueyed, pipeline is simple imho
[18:35] <xnox> create pipes as in master -> what-you-want-in-commit-1 -> what-you-want-in-commit-2 etc
[18:35] <xnox> and each of those is a separate branch refactor them as you like
[18:35] <xnox> and then just do $ bzr pipe-patches which will give you patch series that you can cleanly apply onto master
[18:36]  * blueyed already has a bash script to merge commits with markers in the log message to some CVS repo (real trunk) and feels to need this kind of manual merging for bzr, too.. :/
[18:36] <blueyed> xnox: sounds like pipeline does not rewrite history, too?!
[18:37] <xnox> blueyed, it uses merges. But if you export it as patches & commit them as if you are commiting a real patch you are rewriting history
[18:37] <xnox> commit patches to the star-point you rewrote history
[18:38] <xnox> blueyed, http://how-bazaar.blogspot.com/2009/07/breaking-up-work-for-reivew.html
[18:39] <xnox> here is the link on how-to rewrite history with pipelines
[18:39] <xnox> it uses shelve, uncommit, merge to create refactored history such that it is easy to review changes
[19:10] <blueyed> can we have "bzr subject -r $foo"? :)
[19:10] <blueyed> how do I get only the commit message of a commit?
[19:11] <blueyed> starting point "log --short"
[19:38] <icebrain> hi! I couldn't find out how to get all the revisions that changed the line L in file F, can you help me?
[19:39] <icebrain> I've googled for it, but I've only found out how to do it in code
[19:39] <beuno> icebrain, I don't think you can do that from the client
[19:39] <icebrain> beuno: really? oh... ok. thanks anyway
[21:17] <cr3> I tried to bzr tag --delete a bunch of tags and then push my changes, but they still seem to appear when I pull from the same branch
[21:18] <IslandUsurper> using bzr-git, can I merge in changes from a specific branch, or do I have to import them all first, and merge in the particular directory?
[21:19] <NfNitLoop> cr3: I think tags are always copied, never removed, when  you push/pull branches.
[21:19] <NfNitLoop> cr3: so you may need to remove them from both branches.
[21:22] <cr3> NfNitLoop: so maybe I need to delete the branch on the server and push again without the tags :(
[21:24] <maxb> cr3: I believe a push --overwrite might work. But be really sure you don't accidentally overwrite non-tag stuff you wanted to keeP!
[21:24] <lifeless> morning
[21:25] <cr3> maxb: I'm not sure what non-tag stuff there might be though, got any examples?
[21:25] <cr3> lifeless: top of the morning
[21:26] <maxb> Just revisions, I *think*, but I didn't want to be guilty of suggesting push --overwrite without a strong caution
[21:31] <NfNitLoop> maxb: if he's just going to delete it anyway... what could push --overwrite overwrite that he wan't going to delete?
[21:31] <NfNitLoop> unless push --overwrite is short for rm -rf /
[21:31] <NfNitLoop> ;)
[21:51] <tetsuo--> how can i revert my working tree?
[21:51] <tetsuo--> all the commands seem to be failing
[21:54] <rubbs> tetsuo--: have you tried bzr revert?
[21:54] <tetsuo--> yeah it fails miserably
[21:54] <rubbs> how does it fail?
[21:55] <tetsuo--> but i think i know why, the parent is my svn repository
[21:55] <tetsuo--> so i'm making a new one with the bzr repository as a parent
[21:55] <rubbs> that is recommended ;)
[21:55] <tetsuo--> yeah it makes sense
[21:55] <tetsuo--> i can still import revisions from svn
[21:55] <rubbs> the repo that has the svn parent should always be a mirror of the svn. then you branch from that.
[21:55] <rubbs> exactly
[21:56] <rubbs> well, I'm off work and heading home. if you have more questions, there are plenty of awesome people here to help, just keep asking away.
[21:56] <tetsuo--> thanks
[21:56] <rubbs> np. hope that solves your problem.
[23:01] <dutchie> is there a way to do something similar to git add -p, where you can commit some of the changes in the working directory in bzr?
[23:02] <LeoNerd> bzr ci names of files
[23:02] <LeoNerd> Will commit all the changes in just those files
[23:02] <dutchie> what about only some of the changes in those files?
[23:02] <LeoNerd> For more fine-grained control, what I do is use bzr shelve to take out the changes I don't want to commit, commit the rest, then unshelve it back in
[23:03] <dutchie> ah, ok
[23:03] <LeoNerd> I believe there may be a selective commit plugin but I don't happen to know its name
[23:03] <dutchie> thanks
[23:06] <dutchie> hmm, bzr shelve doesn't seem to want to let me split diffs
[23:07] <jelmer> dutchie: no, I don't think it supports splitting hunks
[23:07] <dutchie> is there anything that does?
[23:09] <Kilroo> merge -i does, doesn't it?
[23:09] <Kilroo> ...I mention it because it's the only thing I can think of, more than because I think it might be useful...
[23:14] <xnox> LeoNerd, i believe it is interractive plugin which enables interactivy for a few commands
[23:16] <fullermd> At one point there was a 'record' plugin I think, after darcs.