[00:12] <jelmer> Peng_: ping
[00:46] <bendj> If I "bzr init-repo A; bzr branch (url) A/test1; mkdir -p A/B; bzr branch A/test1 A/B/test2"
[00:46] <bendj> then, "cd A; bzr multi-pull", will multi-pull "know" to always pull in the correct dependency order?
[00:47] <fullermd> Yes, but no.
[00:47] <bendj> Ok, thanks!  Bye!
[00:47] <bendj> Just kidding ... pls 'splain
[00:48] <fullermd> Yes, it will pull in "correct" order there, but not because of any sort of dependancies.
[00:48] <bendj> fullermd: Hrm.  How's that?  Order of creation?
[00:48] <fullermd> multi-pull doesn't do anything more than "for i in `bzr branches`; do (cd ${i} && bzr pull); done"
[00:49] <bendj> alphanum order, then?
[00:49] <fullermd> Lexical ordering of the paths.  At least, I'm pretty sure it orders 'em.
[00:51] <bendj> fullermd: hrm.  doable, then -- but a bit fragile. other than multi-pull, *IS* there a 'better way', then, to build a hierarchy of dependent branches, and, auto-update the whole shebang -- in correct dependency order?
[00:51] <fullermd> Not pre-built.  You could probably bang up something to pre- or otf- build a graph and walk it.
[00:52] <fullermd> Though I wonder why you'd just have a long chain of copies of the same branch.
[00:52] <fullermd> Presumably you'd actually have changes around, and be merge'ing rather than pull'ing, which generally means interaction anyway.
[00:53] <bendj> fullermd <klingon pain stick> versioning modules, core hacks, and site code for multiple drupal sites can be such a joy </klingon pain stick>
[00:53] <fullermd> If it's a single series, loom could do some level of automation, but that doesn't help you once the branch graph branches.
[00:53] <bendj> loom? looking ...
[00:54] <bendj> as in http://www.isi.edu/isd/LOOM/  ?
[00:54] <fullermd> It's a tool for automating having branch A, with branch B based off that, with branch C based off that, with branch D based on that, with...
[00:54] <fullermd> But it doesn't help when you have branch A, with branch B based on that, with branch C also based on A, with branch D based on B, with branch E based on D and C, with...
[00:54] <bendj> ah, heh -> https://launchpad.net/bzr-loom
[01:02] <bendj> fullermd: Comparing levels of pain/confusion, your point's looking better by the moment" "... generally means interaction anyway ..."
[01:03] <bendj> 5 minutes of manual interaction versus the possibility to fubar the whole mess -- under script control.
[01:03] <bendj> methinks "Door #1" is the saner option ...
[01:04] <fullermd> Scripts are inanimate objects.  Inaminate objects are volitional entities hell bent on imposing any perversity imaginable on anybody in range.  Basic precept.
[01:05] <bendj> Well, some of the emplyees around her are inanimate objects as well ... more similar to voles than volitional entities.  But point taken.
[01:05] <bendj> {employees, here}
[01:06] <fullermd> Exactly.  People are safer.  It's like the difference between genius and stupidity; genius has its limits.
[01:08] <bendj> fullermd: Heh.  I could extend that argument to DVCS vs sneaker-net-n-punchcards, but been there, done that already ;-)
[01:10] <Kilroo> I need to write down the sequence of steps that I use that sometimes results in bzr concluding that the directory foo has been renamed to foo
[01:10] <Kilroo> and try to figure out why it happens.
[01:10] <Kilroo> I keep being in too much of a hurry when it does.
[01:36] <poolie> Kilroo: 'foo has been rename to foo'?
[01:40] <poolie> *renamed
[01:42] <Kilroo> Yes.
[01:42] <Kilroo> I get a rename conflict on a directory with the same name. Haven't stopped to figure out why yet.
[01:43] <Kilroo> I am having trouble recalling what I'm usually doing when it happens.
[01:43] <poolie> this can happen when two people add the same directory independently
[01:44] <poolie> which is a known bug
[01:44] <poolie> spiv, did you see https://answers.launchpad.net/loggerhead/+question/108796 ?
[01:48] <Kilroo> Ah.
[01:48] <Kilroo> Well, that would explain it, even though I added them both.
[01:48] <spiv> poolie: hmm, no, I hadn't.
[01:52] <poolie> you should subscribe to answers if you're not already
[01:53] <Kilroo> I'm still debating what I want to do about the fiasco of "version control" we have at work...
[01:54] <spiv> I am, but apparently not for loggerhead.
[01:55] <Kilroo> I think, if either I can't get them to change how we're doing it at all OR I can convince them to move source code out of subversion completely, I'm going to end up pushing hg; if I can convince them to restructure the repositories sanely but they insist on sticking with subversion, I might stick with bzr.
[01:56] <Kilroo> Personally I like 'em both, but for purposes of adoption by the rest of the team I think HgEclipse might make the difference between getting brushed off and being given serious consideration.
[01:56] <Kilroo> Still experimenting though.
[02:38] <poolie> jam, still here?
[02:54] <Kilroo> I wonder if I'm going to end up fouling myself up by having a lightweight checkout for switching among the branches of a shared no-trees repository in .bzr/r.
[03:03] <Peng_> jelmer: pong
[03:11] <Peng_> poolie: No. jam /quit.
[03:19] <poolie> Kilroo: no that's pretyt standard
[03:20] <Kilroo> Ok. I didn't think it was too likely to foul up anything, but I also wasn't sure how common it was to put things under .bzr that bzr didn't put there for you.
[03:24] <poolie> oh i thought that was a typo
[03:24] <poolie> you should look at bzr-colo
[03:24] <poolie> it may confuse upgrade and things like that
[03:25] <masmullin> hello.  does anyone know if there is a timelapse view for bzr similar to this one (http://code.google.com/p/svn-time-lapse-view/) ?
[03:26] <poolie> check out bzr gannotate
[03:26] <poolie> but not directly with a slider afaik
[03:26] <masmullin> thank you
[07:18] <GungaDin> Is there a way to make bzr ask for a username when executing bzr commit (with a remote url)?
[07:19] <spiv> I think some transports like HTTP can do that.
[07:28] <vila> hi all
[07:30] <vila> GungaDin: Like spiv said, http suports that, but most of the time you want to always use the same user to you specify it in the url (user@host)
[07:30] <vila> and all protocols supports that
[07:39] <vila> poolie: I can't find the tag for 2.2b1 in lp:bzr/2.2, it's associated with mbp@sourcefrog.net-20100401011841-9x637emlcah1a0qv9
[07:40] <vila> poolie: err, I can find the tag, but not the associated revision
[07:40]  * vila gets more coffee
[07:44] <poolie> hi there vila
[07:45] <poolie> i didn't end up merging that branch because i tried a last-minute merge of some fixes from gary
[07:45] <poolie> that ended up being rejected by pqm
[07:47] <vila> poolie: no worries, just thought I mentioned it
[08:01] <bialix> hi all
[08:07] <poolie> hi there bialix
[08:07] <bialix> jelmer: if I want to check whether some directory has svn checkout inside, what method of bzr should I use?
[08:07] <bialix> hello poolie
[08:08] <bialix> there is open_tree_or_branch method
[08:08] <bialix> I need the way to ensure bzr clean-tree won't delete nested branches/trees/repos
[08:08] <bialix> any suggestions?
[08:13] <bialix> hmm, `bzr ignore foo` does not check for duplicates. I don't think it's good
[08:21] <poolie> that would be nice
[08:21] <poolie> obviously you can have globs that may overlap with each other
[08:21] <poolie> by precise dupes seem pointless
[08:26] <bialix> poolie: how you call in english any bzr object (branch/tree/checkout/repo)?
[08:27] <bialix> as cummulative name>
[08:27] <bialix> as cummulative name?
[08:27] <poolie> control component
[08:27] <poolie> mm,
[08:27] <bialix> so when I don't care what the bzr kind there but want to say "something which is bzr handle"
[08:28] <bialix> either branch or tree or ...
[08:28] <bialix> bzr control component?
[08:29] <bialix> guidance needed on https://bugs.launchpad.net/bzr/+bug/572098
[08:38] <poolie> hm
[08:38] <poolie> bialix, i think if you do BzrDir.open it should tell you whether there is any control directory there
[08:39] <poolie> not specifically .bzr but also including .svn
[08:39] <bialix> thanks, that's what I need
[08:41] <jszakmeister> Hello all!
[08:42] <jszakmeister> So I was examining some history on bzr trunk recently, and saw something interesting...
[08:42] <jszakmeister> the tag for bzr-2.1.0rc1 is at 4981.1.6, but the bzr-2.1.1 tag is at 4797.41.1
[08:42] <jszakmeister> ...which seems a bit odd. :-0
[08:43] <jszakmeister> That was meant to be :-)
[08:52] <jszakmeister> Looking at it with qlog, it seems to make sense now.
[08:53] <bialix> qlog ftw!
[08:53] <jszakmeister> trunk was merged into the branch for rc1, picking up some more fixes.
[08:53] <jszakmeister> Definitely!
[08:53] <jszakmeister> qlog is the best bzr tool there is!  I use it *all the time*.
[08:54] <jszakmeister> But it does make me think dotted revision numbers are less useful than I previously thought.
[08:55] <bialix> jszakmeister: and also slow
[08:55] <bialix> jszakmeister: they're human-readable
[08:55] <bialix> that's main idea
[08:55] <bialix> did you read recent thread from jam about history-db and dotted revnos?
[08:55] <jszakmeister> Yeah, and they're easier to remember... but I wanted to assign some meaning to it, and you really can't.
[08:55] <jszakmeister> Yes, I did.  Good stuff!
[08:56] <jszakmeister> It seems like a lot of trouble to go through to keep them useful though.
[08:56] <bialix> yep
[08:56] <bialix> but I was surprized that topo_sort is the main bottleneck though
[08:57] <jszakmeister> Yeah, it was all very intriguing.
[08:58] <jszakmeister> I would have thought something so visible to the user would have a simpler calculation... I was surprised by some of the answers in that thread.
[09:00]  * bialix nods
[09:03] <bialix> vila: ping
[09:04] <vila> bialix: pong
[09:04] <bialix> vila: I have problems with selftest -s
[09:04] <bialix> wait a sec I do paste
[09:05] <bialix> vila: http://pastebin.com/UR68Awqc
[09:05] <bialix> I've added new test to bb.test_clean_tree
[09:05] <bialix> but selftest don't see it?
[09:05] <bialix> what I'm doing wrong?
[09:05] <bialix> gremlins?
[09:06] <Peng_> bialix: "C:\Program Files\Bazaar\lib\library.zip\bzrlib" -- it's using the system-wide bzrlib.
[09:06] <bialix> rats
[09:06] <Peng_> bialix: Run "./bzr selftest ..." or whatever the Windows equivalent is.
[09:06] <bialix> `python bzr`
[09:07] <vila> Peng: wow ! Good catch :)
[09:07] <jszakmeister> So another weird tag issue: bzr tags on bzr.dev shows:
[09:07] <bialix> Peng_: many thanks
[09:07] <jszakmeister> bzr-2.2b1            ?
[09:07] <Peng_> :)
[09:07] <bialix> now I can't run test at all :-(
[09:07] <vila> jszakmeister: Yeah, I mentioned that poolie earlier, related to a pqm failure
[09:07] <bialix> bzr: ERROR: No module named testtools
[09:07] <bialix> it's not my day
[09:08] <Peng_> Ow.
[09:08] <vila> bialix: gee, that was changed sometime ago, you should run tests more often :-O
[09:08] <bialix> vila: I do run tests everytime. for qbzr and scmproj!
[09:08] <vila> bialix: easy_install ftw
[09:08] <vila> bialix: but not from bzr.dev it apperas
[09:08]  * bialix hates easy_install but it does not matter
[09:08] <vila> appears
[09:09] <jszakmeister> vila: I thought that's what you were asking.  But how did the tag show up?
[09:09] <vila> jszakmeister: bug most probably
[09:10] <Peng_> Wait, now the bug is PQM is propagating tag too much? That's new. :D
[09:10] <jszakmeister> I wouldn't think the tag would carry over without the corresponding revision...
[09:10] <jszakmeister> :-)
[09:10] <vila> jszakmeister: yeah, me neither :-/
[09:11] <jszakmeister> Would it be a PQM problem or bzrlib?
[09:12] <jszakmeister> I'm curious if you can trigger this via the command line itself (I'm not sure how PQM does it's thing)
[09:12] <vila> jszakmeister: I'm not sure, I guess pqm could be involved
[09:13] <jszakmeister> Hmm... maybe I'll play around a bit and see if I can trigger the issue.
[09:13] <bialix> vila: bzr get lp:testtools; cd testtools; python setup.py bdist_wininst -d.; run testtools-0.9.2.win32.exe <-- and no easy_install! :-P
[09:14] <vila> jszakmeister: if you find interesting bits, please file a bug
[09:14] <jszakmeister> vila: will do
[09:14] <vila> bialix: wow
[09:15] <vila> bialix: worth giving feedback to the testtools project I think
[09:15] <jszakmeister> Heh.  I can reproduce it.
[09:15] <vila> bialix: if only to tell them this alternative setup works out of the box
[09:15] <bialix> vila: testtools does not use setuptools and this is fine
[09:16] <bialix> vila: what kind of feedback needed?
[09:16] <bialix> everything is fine
[09:16] <vila> bialix: yeah, that's good feedback :)
[09:17] <jszakmeister> Looks like it's a known bug: https://bugs.launchpad.net/bzr/+bug/99137
[09:19] <vila> jszakmeister: cool, thanks for checking !
[09:20] <jszakmeister> No problem!
[09:20] <jszakmeister> I'm going to add a note to the ticket saying that we were both a bit surprised by the behavior, if you don't mind.
[09:23] <vila> jszakmeister: sure, don't forget to click the metoo button
[09:24] <vila> jszakmeister: that should enough to nudge poolie to provide an updated tad :-D
[09:25] <poolie> mm?
[09:26] <vila> poolie: bzr tags -> bzr-2.2b1            ?
[09:27] <vila> grrr bzr erro 'check your limbo', yeah, it's *empty* just get rid of it !!
[09:27] <poolie> ah, they propagate even if the merge is rejected
[09:27] <poolie> sorry
[09:28] <vila> poolie: no worries, just a papercut :)
[09:39] <bialix> vila: yeah
[10:01] <jszakmeister> Is there a way to get a list of the mainline revision ids between two revids, without the merged revisions (just the mainline)?
[10:02] <poolie> in code?
[10:02] <jszakmeister> Or do I just need to use iter_merge_sorted_revisions and filter them myself?
[10:02] <jszakmeister> poolie: yes
[10:02] <poolie> i thought you'd be able to get them directly
[10:02] <poolie> i don't recall the precise function tohugh sorry
[10:03] <jszakmeister> No worries
[10:03] <vila> jszakmeister: bzrlib.log._get_mainline_revs() , but note that it's private
[10:04] <vila> jszakmeister: at least you can use it as an example
[10:04] <jszakmeister> vila: Thanks!
[10:19] <poolie> ok good night all
[10:53] <ElMonkey> any pointers as to how to split off a sub-project from a repo without the sub-project retaining all unrelated history?
[10:54] <ElMonkey> i'm in the situation that i'd like to release a part of a private project as open source, with the history, but of course wouldnt want the other parts of the project visible in the repo
[10:56] <spiv> ElMonkey: probably the easiest way is to use the bzr-fastimport plugin to export and filter a dump of the history, and import the filtered history.
[10:57] <spiv> ElMonkey: note that the history that will synthesise will have new revision-ids, so won't be easy to merge with the existing history
[10:57] <ElMonkey> that wouldn't be a problem
[10:59] <ElMonkey> know of any article that describes the process?
[11:01] <jszakmeiste> Does anyone know if you can limit the access to just the smart server over http?  Or do I have to allow both smart and plain access to http?
[11:12] <bialix> ElMonkey: see the help for fastimport plugin and for fast-import-filter command. it's pretty straightforward
[11:12] <Peng_> jszakmeiste: Sure, if your web server is smart enough (no pun intended). Smart requests are .bzr/smart. Dumb requests are everything else under .bzr.
[11:12] <Peng_> jszakmeiste: Just curious, why?
[11:12] <ElMonkey> bialix, looking at it
[11:13] <ElMonkey> though i'm currently confused what they mean by front-end
[11:13] <ElMonkey> as in "front-end | bzr fast-import-filter..."
[11:13] <Peng_> ElMonkey: Whatever fast-outputs.
[11:13] <bialix> ElMonkey: for you frontend will be `bzr fast-export` command
[11:13] <Peng_> Um. I hope.
[11:13] <ElMonkey> ah, ok
[11:13] <Peng_> OK then. :D
[11:14] <Peng_> Oh, right, "export" is the word.
[11:14] <jszakmeiste> Peng_: I've got my server handling the smart requests, and I like that because I can easily put fine-grained access controls in front of it (check the authenticated user, and allow no access, read access or write access)
[11:14] <bialix> ElMonkey: it supposed to support conversion from other (d)VCS
[11:14] <Peng_> jszakmeiste: Why can't you do that with dumb requests?
[11:14] <jszakmeiste> Because being authenticated doesn't mean that you should be allowed to view the branch
[11:15] <ElMonkey> hmm, i can't fast-export a subdir, can i?
[11:15] <bialix> you can't
[11:15] <jszakmeiste> And it would dramatically increase the maintenance required as compared to our svn setup
[11:15] <bialix> my favorite topic detected: ACLs!
[11:16] <Peng_> I thought building on Windows was your favorite topic. :D
[11:17] <bialix> phew! buildout kills windows builds for me
[11:18] <bialix> it seems my head is not robust enough to break the wall
[11:27] <ElMonkey> spiv, bialix, thanks for the pointers, i think i'm on my way. just need things to re-appear at the right spot when importing
[11:29] <ElMonkey> there's no way to make it keep stuff in a directory?
[11:29] <ElMonkey> eg, i have source/foo.c etc i want to include
[11:30] <ElMonkey> but they all end up in / in the new repo
[11:30] <ElMonkey> i know i can solve this when importing
[11:30] <ElMonkey> but what to do when i want foo/abc.h and bar/abc.h both?
[11:33] <ElMonkey> or nevermind, i can apparently *not* make things reappear where they want even in the simple case...
[11:45] <ElMonkey> the fastimport files are ok to be edited by a text editor, right?
[11:45] <ElMonkey> i need to redact parts of some commit messages
[11:57] <a212901390231901> hm, I need to go out in a couple of minutes so I better save this for later, but the new fix for bug 491763 has the same problem as the old one,
[11:58] <a212901390231901> "%s %s %s" % (unicode, unicode, bytestring) is not safe.
[11:59] <a212901390231901> and if someone who set up for building windows installers could test lp:~gz/bzr/support_OO_flag_installer that'd be great
[12:02] <Peng_> ElMonkey: Yeah, go ahead.
[12:02] <lifeless> a212901390231901: your nick is uhm, undescriptive ;)
[12:02] <Peng_> ElMonkey: Obviously it'll change revision IDs and such if you import them into the same VCS as you exported them from, but if that's okay with you...
[12:02] <Peng_> lifeless: It's Martin[gz]. All of his other nicks were taken. We have too many Martins, eh?
[12:03] <Peng_> Thank goodness for {auto,tab}-complete.
[12:03] <lifeless> a212901390231901: have you registered martin[gz] ?
[12:03] <ElMonkey> Peng, thanks
[12:04] <a212901390231901> in the UDS launchpad group you sent a link to? yes.
[12:04] <lifeless> a212901390231901: on freenode
[12:04] <a212901390231901> no, I'll pick something more sane next time I ping out.
[12:05] <lifeless> if you register with nickserv
[12:05] <lifeless> you can then kick off anyone grabbing your nick
[12:06] <a212901390231901> I tried a bunch of different options I use on other networks and they were all taken, then I got annoyed ;)
[12:07] <lifeless> :(
[12:09] <a212901390231901> it's something of a miracle I've stayed on this long without being taken down by a brown out or my flakey hardware
[12:16] <Peng_> You say "miracle" like it's a good thing. ;-)
[14:52] <rbriggsatuiowa> how do I specify a default format?
[14:52] <rbriggsatuiowa> I get warnings about "Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 with rich root (needs bzr 1.0)\n') to RepositoryFormat2a()."
[14:52] <jelmer> rbriggsatuiowa: the default format is part of bazaar itself
[14:52] <jelmer> rbriggsatuiowa: in that particular case the remote branch is in an older format and your local branch is in a newer format
[14:52] <rbriggsatuiowa> so do I have to downgrade?
[14:53] <jelmer> rbriggsatuiowa: fetching between two different formats is significantly slower than fetching between two branches with the same format
[14:54]  * rbriggsatuiowa goes off to refresh his apt skills so he can install 2.0.3
[14:55] <jelmer> rbriggsatuiowa: you can either downgrade your local branch ('bzr upgrade --rich-root-pack'), upgrade the remote branch ('bzr upgrade <url>') or live with the slowneess
[14:57] <Peng_> Can suppress_warnings suppress that warning?
[14:59] <jelmer> I'm not sure
[15:17] <sproaty> uhm did bzr just autopush? http://paste.pocoo.org/show/208074/
[15:19] <sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/changes  hmm aparently so
[15:21] <vila> speakman: more likely you're using a checkout or a bound branch, what does 'bzr info
[15:22] <vila> ' says ?
[15:22]  * vila curses return key
[15:22] <sproaty> me?
[15:23] <sproaty> I think I did bzr bind yesterday while trying to solve pushing trying to push to http://
[15:23] <vila> rhaaa, /me curses xchat too
[15:23] <vila> sproaty: yes you :) 'bzr info' ?
[15:24] <sproaty> http://paste.pocoo.org/show/208077/
[15:25] <vila> sproaty: right, so you've using a bound branch,, the commit happens on the remote branch first and then locally
[15:26] <vila> sproaty: there is nothing left to push in this case :)
[15:26] <sproaty> was wondering why there was a pause after committing
[15:27] <vila> sproaty: you can 'bzr unbind' and then 'bzr push' when you feel the need to publish your changes
[15:28] <sproaty> alrighty then
[15:28] <sproaty> thank you very much, vila
[15:28] <vila> sproaty: you're welcome
[15:28] <sproaty> bzr rocks, wish we were using it in work
[15:28] <sproaty> no more damn .svn folders
[15:30] <rbriggsatuiowa> jelmer: thanks for your help - I installed from source and things are going smoothly
[15:30] <rbriggsatuiowa> also - just wanted to mention how awesome the bzr plugin architecture is
[15:30] <jelmer> rbriggsatuiowa: np, great to hear :-)
[15:39] <lelit> hi, I noticed that while the home page mentions 2.1.1 as the latest, the SourceDownloads page carries only 2.1.0...
[15:40] <bialix> lelit: it's a wiki, feel free to update it
[15:40] <lelit> right
[16:17] <bialix> anybody seen this before? https://bugs.launchpad.net/bzr/+bug/572405
[16:18] <bialix> I'm tempted to mark this bug as Critical
[16:21] <bialix> light checkout problem again
[18:41] <ShermanBoyd> Hello, I'm pretty new to version control in general, and after a ton of research I've decided I'd like to use Bazaar.  I've got a Windows 2003 production server and a 2003 Dev server and a couple of developers running Windows 7.  I want the developers to make changes on the dev box for testing and then periodically push those changes to production.
[18:44] <ShermanBoyd> How do I approach this?
[18:44] <ShermanBoyd> Two branches?
[18:48] <ElMonkey> so you want dev->testsrv->production ?
[18:48] <ShermanBoyd> Yeah
[18:48] <ElMonkey> well, should be simple
[18:49] <ElMonkey> all repos are "branches", if you will
[18:49] <ElMonkey> so you just create a repo on each machine, and the push/pull appropriately
[18:50] <ShermanBoyd> ElMonkey: so I need to set up an sftp server on each one?
[18:51] <ElMonkey> ssh should do
[18:52] <ElMonkey> dunno how bzr behaves with network shares, though, that might be simpler
[18:52] <ShermanBoyd> ElMonkey: then the devs push to the dev server and I pull the final tested changes by running bzr on the prod server
[18:52] <ShermanBoyd> they are in different physical locations
[18:53] <ElMonkey> different networks, too?
[18:53] <ShermanBoyd> yeah
[18:54] <ElMonkey> for a long time i used a common repo on a usb flashdrive on one project, due to the computers not being networked
[18:54] <ElMonkey> but anyway, ssh/sftp or samba shares should work
[18:55] <ElMonkey> pulling from a network share should certainly work
[18:56] <ShermanBoyd> Hmm, I think I'm still wrapping my head around decentralized ...
[19:23] <ShermanBoyd> anyone here interested in helping me set up bzr on some windows servers for $25/hr ?
[19:42] <sproaty> can someone explain about merging/branches? I've kind of done merging with svn at work, but not branches
[19:44] <sproaty> like if I was to branch off to develop a new feature, that I see as being code-heavy, and then I find/fix bugs in the main code base that was branched from -- how do you like get the changes over into the other branch?
[19:44] <sproaty> or is it a case of branching from trunk, working on that then merging that back into trunk
[19:49] <fullermd> Generally, you just fix those bugs in the main branch.
[19:54] <sproaty> then merge the 'new feature' branch back into trunk?
[19:58] <fullermd> Well, not before the feature is ready to land   :)
[20:00] <sproaty> cool
[20:09] <cody-somerville> how do I push a pending merge on top of a branch instead of merging all the revisions into one
[20:09] <cody-somerville> ?
[20:09]  * cody-somerville forget he made a bunch of --local commits on a binded branch and ran bzr update.
[20:13] <cody-somerville> ugh
[20:13] <cody-somerville> bzr: ERROR: Selected-file commit of merges is not supported yet
[20:14] <cody-somerville> I have changes in my working tree I don't want to commit :(
[20:15] <IslandUsurper> cody-somerville, you could `bzr revert --forget-merges`, and then commit your changes file-by-file. if they're more intertwined than that, I wouldn't worry about it too much
[20:15] <fullermd> That's almost certainly a bad idea.
[20:16] <fullermd> That's just going to lose those commits and get you a bunch of illogical and entangled new ones.
[20:16] <fullermd> The first thing to do is get a handle on your previous head state.  Update should have printed that out.
[20:17] <fullermd> Assuming upstream hadn't moved, you can use diff to recover your uncommitted changes relative to that, and stash that somewhere.
[20:18] <fullermd> Using another branch (or unbinind that one), you can use pull to jack back to that last commit.  Re-apply the changes, commit them,  Push over the upstream.
[20:18] <cody-somerville> why wouldn't bzr revert --forget-merges not work? the commits were local and the master branch hasn't changed
[20:18] <fullermd> Then stab --local in the eye with a #2 pencil.
[20:18] <cody-somerville> err, sorry for double negation
[20:18] <fullermd> Oh, it'll _work_.  But I doubt it'll leave you where you want to be.
[20:18] <IslandUsurper> because it does indeed erase the commits you've already done. but it leaves the changes in the working tree
[20:18] <cody-somerville> aye
[20:18] <cody-somerville> so I can just commit now directly onto master
[20:18] <fullermd> It'll leave you with all your local commits thrown away, and the sub of their changes (and whatever uncommitted stuff you had) sitting waiting to be committed.  That doesn't sound healthy.
[20:19] <fullermd> (s/sub/sum/)
[20:19] <cody-somerville> fullermd, all the changes from my local commits were still sitting in the tree since it was a merge.
[20:20] <cody-somerville> doing a merge is like uncommiting everything and then recommitting it as a single revision but keeping the history
[20:21] <fullermd> It...  umm...  not with any meaning of those words I can dredge up...
[20:22] <fullermd> Talking about "your changes" is ambiguous.
[20:22] <IslandUsurper> fullermd, sorry I mentioned --forget-merges. I should have just said "commit it anyway. it won't hurt."
[20:23] <fullermd> You can take it to refer to the set of files as they now exist, or to the revisions you created.  revert --forget-merges leaves the former intact, but tosses the latter.
[20:24] <cody-somerville> IslandUsurper, on the contrary, I'm all good now thanks to --forget-merges
[21:06] <cody-somerville> how do I see the full log entries for pending merge revisions?
[21:07] <IslandUsurper> bzr log -n 0
[21:08] <fullermd> That won't tell you anything about pending merges.
[21:08] <IslandUsurper> d'oh!
[21:08] <fullermd> There's no direct way through the UI.  You'd have to get your hands on the revid's and go from there.
[21:08] <IslandUsurper> qlog does it
[21:08] <fullermd> Oh, really?  That's nifty.
[21:08] <IslandUsurper> I use it so much, I didn't think that regular log wouldn't
[21:09] <IslandUsurper> though status -v will show you the commit messages of pending merge parents
[21:09] <fullermd> Well, it shows you something like log --line.  But that just shows you the first handful of words.
[21:11]  * fullermd adds an entry to his "cool stuff about qlog" mental list.
[22:16] <micahg> what's the proper way to import files from a branch so one can merge between the two without the history?
[22:25] <ubuntujenkins> Is there a command that i would use to view all the changes made in previous revisions to a particular file showing the lines changed in the file?
[22:27] <micahg> ubuntujenkins: bzr log -p /path/to/file
[22:28] <ubuntujenkins> thanks micahg
[22:33] <Kilroo> So guess what I learned today that I didn't know before
[22:33] <Kilroo> I learned that switch first looks relative to where the branch you already have checked out lives
[22:33] <micahg> what's the proper way to import files from a branch so one can merge between the two without the history?
[22:36] <Kilroo> ...cp?
[22:48] <micahg> Kilroo: that's what I was thinking, but I was worried about th efile Ids
[22:48] <micahg> *file
[22:53] <Kilroo> micahg: I don't know of any meaningful way to merge without involving the history...if you don't want the history I'd think you'd just write/overwrite the files and commit.
[23:00] <ikanobori> Hey people, I was wondering if `bzr up` supports some kind of switch to make it pull unauthenticated. It seems it will always try bzr+ssh if I have a `bzr whoami`.
[23:01] <ikanobori> On a lp-branch that is.
[23:50] <spiv> ikanobori: lp: URLs are always resolved to bzr+ssh if you have done bzr launchpad-login
[23:51] <spiv> 'bzr whoami' isn't involved at all.
[23:53] <ikanobori> spiv: Thanks for the clarification.