[00:24] <thumper> lifeless: do you have some time to talk?
[00:25] <lifeless> sure
[00:26] <lifeless> how would you like to talk?
[00:27] <lifeless> thumper: ^
[00:27] <thumper> lifeless: voice probably
[00:27] <lifeless> ok
[00:27] <lifeless> skype me baby
[00:27] <thumper> ok, just getting a game down for maia
[00:29] <bob2> jelmer: yeah, replied
[00:29] <thumper> lifeless: trying to skype, no answer
[00:29] <lifeless> thumper: sorry missed it
[01:19] <mwhudson> jelmer: you around by any chance at all?
[01:19] <jelmer> mwhudson: somewhat :-)
[01:19] <mwhudson> jelmer: awake enough to talk about bzr-hg and incremental imports at all?
[01:20] <mwhudson> or just a basic grounding in mercurial concepts i guess
[01:21] <jelmer> mwhudson: Yeah, though planning to get some sleep soonish
[01:21] <jelmer> mwhudson: anything in particular you'd like to know?
[01:22] <mwhudson> jelmer: hm, i guess i'd like to know what remote.branches(unknowns) returns
[01:22] <mwhudson> this seems to be a use of the word 'branch' i don't usually use
[01:22] <mwhudson> is a branch a run of commits with a single parent?
[01:24] <jelmer> mwhudson: IIRC yes
[01:25] <jelmer> mwhudson: so that allows you to mainly worry about merge commits and not waste any roundtrips on simple ones
[01:25] <mwhudson> jelmer: ok, that makes some kind of sense
[01:26] <mwhudson> jelmer: i like the ample docstrings and meaningful variable names in the mercurial source btw

[01:26] <jelmer> :-)
[01:28] <mwhudson> jelmer: so unknowns takes a set of revision ids and returns ... what?  the branches that contain the unknown revisions ?
[01:28] <mwhudson> er
[01:28] <mwhudson> remote.branches
[01:29] <jelmer> my memory is failing
[01:29]  * jelmer grabs the mercurial source
[01:31] <james_w> jelmer: dude!
[01:31] <james_w> yet more great patches!
[01:31] <jelmer> james_w: hey!
[01:34] <jelmer> mwhudson: unknowns the variable contains a set of revisions we have yet to fetch the branches for
[01:35] <mwhudson> it seems branches for each revision walks back until it reaches a rev with 2 or 0 parents
[01:35] <mwhudson> each *passed* revision
[01:35] <jelmer> mwhudson: when we fetch a branch we check if we know the base of that branch - if we do we know we don't have to check that branches' parents - the revisions we have to fetch are in between the base and the head of that branch
[01:36] <jelmer> mwhudson: which revisions we need from that branch we figure out later using a binary search
[01:36] <mwhudson> ok, this is starting to make sense
[01:38] <blunted> anyone familiar with the bazaar api?
[01:38] <jelmer> blunted: somewhat
[01:39] <blunted> i cant figure out how to get the url of a branch from its object
[01:39] <lifeless> branch.base
[01:40] <mwhudson> jelmer: i still don't get where we can decide to limit the revisions we fetch
[01:40] <mwhudson> i guess it's going to make the function quite a bit more complicated
[01:41] <blunted> thanks much, the documentation i've found doesn't seem to include attributes... maybe i'm missing something
[01:41] <jelmer> mwhudson: I'm sorry, I might've been more optimistic about that when my brain had lost the impression of what this function is doing :_)
[01:41] <mwhudson> jelmer: heh heh
[01:42] <jelmer> mwhudson: we definitely can't do much before the binary search
[01:51] <jelmer> mwhudson: yeah, I think it'd indeed be too hard
[01:52] <jelmer> mwhudson: it's a pity though, because you'll still have to process a lot of data you're going to discard later
[01:52] <mwhudson> jelmer: i don't really understand how all the revisions from a completely unseen branch end up in the returned set :/
[01:52] <jelmer> mwhudson: branches that aren't seen at all are already present locally
[01:53] <mwhudson> jelmer: i mean a branch where neither head nor root are present locally
[01:53] <mwhudson> it seems to me at some point you need to add all the revs from between(head, root) to the returned set
[01:54] <jelmer> mwhudson: the returned set isn't a set of revisions to fetch, it's the set of tips that's missing
[01:55] <jelmer> hmm
[01:55] <jelmer> I should get some sleep before I talk more nonsense
[01:55] <mwhudson> jelmer: oh
[01:55] <mwhudson> jelmer: yes, probably sleep is good :-)
[01:56] <jelmer> that last sentence (<jelmer> mwhudson: the returned set isn't a set of revisions to fetch, it's the set of tips that's missing) is gibberish
[01:56] <mwhudson> jelmer: noted
[01:57] <jelmer> g'night!
[01:58] <mwhudson> jelmer: talk you you on your monday i guess
[01:58] <jelmer> mwhudson: yeah, happy to continue discussing this then - I guess it's not really urgent until the majority of the imports are fixed anyway?
[01:59] <mwhudson> jelmer: no not really
[01:59] <mwhudson> jelmer: it would be nice to make the code that passes limit= in the puller uniform across branch types
[01:59] <mwhudson> but that's no big deal
[03:00] <Emzzzz> http://imggmi.info/DSC-1268362455.jpg/ do my tits look big?
[03:04]  * igc lunch
[05:10] <spiv> I started a bit early today, so I'm off.  Happy weekend everyone!
[07:30] <vila> hi all !
[08:46]  * igc dinner
[09:18] <sjamaan> Hi
[09:18] <sjamaan> I get this error message in my apache log:  No handlers could be found for logger "bzr"
[09:18] <sjamaan> What's causing this?
[09:42] <evanton> how do I purge a file completely from a bzr repository? I believe that doing bzr remove will leave traces of the file in older revision (please correct me if I'm wrong), so this doesn't suffice
[09:44] <bob2> yes, with difficulty
[09:46] <evanton> I believe it at least makes sense to expect for such a feature from bzr, because it's file-based
[09:46] <bob2> hm, it's not very file based
[09:47] <evanton> it would be harder for git, because excluding a file would change the sha checksum for that revision snapshot totally
[09:47] <bob2> that's not to do with file-ness, that's to do with identifying revisions based on content hashes
[09:47] <bob2> you can use fast-export/import for this, I think
[09:48] <bob2> or rebase
[09:49] <sjamaan> evanton: It has more to do with the fact that people already have the full history in their own branches
[09:49] <sjamaan> If you kill a revision afterwards, their branch will be inconsistent with the master branch
[09:49] <evanton> sjamaan: not a problem in my case, since the branch is unique, but I see your point
[09:50] <evanton> I was thinking about building a branch mirror revision by revision, from the moment when the file I want to purge was included
[09:50] <evanton> and just recommiting each revision without including that file
[09:51] <evanton> does this make sense?
[10:08] <sjamaan> I get this error message in my apache log:  No handlers could be found for logger "bzr". What's causing this?
[10:08] <gour> i'd like to use bzr with LP, but still keep using darcs for local development. now i'm curious if it is possible to configure bzr-explorer to use bzr-fast-import on certain repo and then push branch to LP. similar when pulling from LP (using fast-export) ?
[10:21] <gour> i'm not sure whether hats in explorer are working here
[10:29] <gour> I read http://bazaarvcs.wordpress.com/2010/03/01/bazaar-explorers-killer-feature article but do not see docs about adding one's own hats
[11:03] <sjamaan> After installing the bzr desktop bundle on OS X, I don't see any new apps under Applications, and "bzr explorer" says "unknown command".  How do I open the explorer on OS X?
[11:03] <gour> sjamaan: what bzr plugins says?
[11:04] <sjamaan> gour: Just a sec
[11:07] <sjamaan> gour: It lists qbzr, but not explorer
[11:07] <gour> sjamaan: then it's not installed (properly)
[11:08] <sjamaan> gour: Then what can I have done wrong?  I simply downloaded the desktop bundle and clicked through its installer
[11:08] <sjamaan> I retried using custom installation, but that doesn't make a difference
[11:08] <gour> sjamaan: i do not know mac, but maybe it's not part of bundle?
[11:09] <sjamaan> gour: I don't know mac either (helping out a colleague), but the docs all point to the bzr download page, and say you should download the desktop bundle as it contains explorer
[11:10] <sjamaan> "The latest Bazaar 2.x application bundles for OS X include Explorer. In some cases, you still need to install Qt binaries separately. See http://wiki.bazaar.canonical.com/MacOSXDownloads for details."
[11:10] <sjamaan> [http://doc.bazaar.canonical.com/explorer/en/install-osx.html]
[11:10] <gour> hmm
[11:10] <sjamaan> There's only one desktop bundle too, only for the previous release
[11:11] <sjamaan> Luckily the OS X version matches my colleague's OS X version
[11:11] <gour> :-)
[11:34] <sjamaan> jeez, if I understand correctly the bundle is broken in some way and you need to go download a new version of the Qt SDK from the Trolltech site
[11:34] <sjamaan> WTF
[11:35] <sjamaan> [ http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac ]
[11:36] <gour> :-/
[11:37] <sjamaan> Or pay up and upgrade to 10.6, coz that works
[11:37] <sjamaan> :)
[11:37] <sjamaan> That SDK is 550 Mb
[11:38]  * sjamaan wonders how others were able to get bzr working on their macs
[11:38] <sjamaan> It's not exactly obvious
[11:54] <huntz0r> Was wondering if someone could give me a real quick answer (not been able to find this out on the docs).  How can I "unstage" files or rather reset the current working tree? (I think that's the terminology)
[11:57] <hmeland_> huntz0r: I think you're looking for "bzr revert".
[11:58] <huntz0r> Thats the one!!  Cheers hmeland_!
[12:39] <BjornW> I'm looking for a howto for using bzr and I find the documentation not in depth enough. Is there another source available with more info?
[12:41]  * SamB_XP hands BjornW a pair of 3D glasses
[12:41] <gour> BjornW: what did you try?
[12:42] <BjornW> I'm trying to setup a workflow for 2 people where one is on Windows and I'm on Ubuntu.
[12:44] <SamB_XP> BjornW: and ?
[12:44] <gour> BjornW: you can use it as both are on the same machine
[12:45] <BjornW> What I would like to achieve is have 1 master branch and merge from our local branches
[12:45] <SamB_XP> does the 'dozer have an SSH account on your machine ?
[12:45] <BjornW> SamB_XP: nope
[12:45] <SamB_XP> or on some machine you both have accounts on?
[12:46] <BjornW> SamB_XP: I think we can setup a server
[12:50] <SamB_XP> it's really quite simple to use bzr over ssh ... did you look at the wiki ?
[12:51] <SamB_XP> oh, and if by some chance the project you are (going to be) working on happens to be open source, you could just use launchpad instead of setting up your own server
[12:53] <BjornW> SamB_XP: would love to use LP, but this is not my project and the other person does not want to make this floss :(
[12:53] <SamB_XP> fear not -- that would only simplify it a teensy bit
[12:56] <SamB_XP> well, I mean, once you get the permissions set up on the server so that you can both push to whatever branches you keep there
[12:57] <SamB_XP> the issues involved are really no different from those you see with darcs or git, except that bzr works a lot better on Windows than I remember darcs working there :-)
[13:15] <SamB_XP> BjornW_: getting anywhere ?
[13:15] <BjornW_> SamB_XP: I'm now setting up my server. Just created a bzr repo
[13:17] <BjornW_> Trying to fix this issue for future collaboration as well :)
[13:17]  * gour is quite satisfied with darcs, but will use bzr for publishing branches on LP
[13:19] <SamB_XP> BjornW_: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial says that setting the permissions on a directory to "02770" should keep everything bzr puts under the directory group-writable
[13:20] <SamB_XP> at least, if you use bzr+ssh:// and not sftp://
[13:20] <sjamaan> :(
[13:21] <SamB_XP> sjamaan: ?
[13:21] <sjamaan> It looks like my attempt to switch our company over to bzr has failed
[13:21] <SamB_XP> oh
[13:21] <SamB_XP> what are you using now ?
[13:21] <sjamaan> svn
[13:21] <SamB_XP> could be worse!
[13:21] <sjamaan> True :)
[13:21] <sjamaan> The GUI situation for OS X is horrible
[13:22] <SamB_XP> I heard about a professor who was making everyone in his class use CVS, and called the use of the CLI "unprofessional"!
[13:22] <sjamaan> heh
[13:22] <idnar> wait, what CVS GUI were they using then?
[13:22] <sjamaan> tortoise?
[13:22] <sjamaan> It's pretty good
[13:23] <SamB_XP> I think he was suggesting they use, say, Emacs' integration
[13:23] <sjamaan> haha
[13:23] <idnar> Tortoise is Windows only, isn't it?
[13:23] <BjornW_> SamB_XP: thanks!
[13:23] <SamB_XP> idnar: er ... maybe ?
[13:24] <sjamaan> idnar: yeah
[13:24] <sjamaan> Most schools are still 100% windows
[13:58] <BjornW_> SamB_XP: how can I use a different user with bzr+ssh? Something like bzr+ssg://anotheruser@myserver.com/repos/trunk?
[13:58] <BjornW> bzr+ssh
[15:01] <BjornW_> how can I branch from a branch only a specific directory? Is this even possible?
[15:03] <jelmer> BjornT: no, this (partial checkouts) is not supported (yet)
[16:20] <NfNitLoop> What do people in here generally use to handle 3-way merging when you encounter conflicts?
[16:21] <NfNitLoop> and how do you integrate w/ kde?  I remember last time I did this trying to call kdiff...
[16:22] <NfNitLoop> and it would open the .THIS, .OTHER, and .BASE files...
[16:22] <NfNitLoop> Hrmm.  I guess I'm just a n00b at 3-way merging in general.
[16:22]  * NfNitLoop does some more googling.
[16:24] <jelmer> NfNitLoop: I'm pretty sure there is some integration for things like kdiff in qbzr
[16:24] <jelmer> but I have no experience with them
[16:31] <NfNitLoop> jelmer: so it does.  Thanks.
[16:31] <NfNitLoop> Apparently I was just missing the point where 3way merge tools don't bother copying the modified .THIS over the versioned file for you.  I assumed I was doing something wrong. :p
[16:36] <NfNitLoop> Oh well, it ended up being trivial anyway.  (My changes win!)  :p
[20:24] <aspidites> i can't seem to find a way to check out an earlier revision
[20:25] <jelmer> aspidites: bzr branch -r<revnum>
[20:25] <Peng> "bzr branch -r 123" "bzr revert -r 123" "bzr update -r 123"
[20:25] <Peng> Depending on what you want.
[20:25] <aspidites> jelmer: wow. that easy? how did i not see that. Thanks!
[20:25] <Peng> "bzr checkout -r 123" too! :D
[20:30] <aspidites> btw, is there a preferred method of resolving conflicts? doing "bzr merge" "bzr resolve filename" is what got me in this situation in the first place
[20:30] <aspidites> adding a bunch of <<<<'s and >>>'s to the file in question.
[20:35] <NfNitLoop> aspidites: the preferred method is to actually resolve your conflicts before running 'bzr resolve filename'.
[20:35] <NfNitLoop> resolve just *marks* the file as resolved, a human (i.e.: you) still has to make sense of the differnces and choose how to integrate them.
[20:36] <NfNitLoop> This is not unique to bzr, by the way.  SVN and CVS have this same behavior.
[20:37] <NfNitLoop> There are a couple ways to actually do the resolving, though.
[20:37] <NfNitLoop> 1)  Read the file and remove the >>>> <<<< bits, making sure what code you leave in is how you want the merge to go.
[20:38] <NfNitLoop> 1b) then run bzr resolve.   do that on all files.  Then do 'bzr commit' to finish your merge.
[20:38] <NfNitLoop> Or 2)  Use a GUI 3-way merge tool for more complicated merges.   as jelmer recommended to me earlier, qbzr has some integration for that.
[20:39] <NfNitLoop> so I did:  bzr qconflicts.   Double-clicked on each of my conflicts, merged changes in my GUI diff viewer.  Copied the .THIS file over the versioned file, then ran 'bzr resolve'.
[20:44] <aspidites> NfNitLoop: thanks, i will try that
[21:00] <aspidites> so if i understand correctly, the >>>'s etc are added during a merge to note conflicts. i then decide after sifting through the files which changes i want to commit, then do resolve on each of those files?
[21:01] <Peng> aspidites: You edit the file somehow to what you want, and then you use "bzr resolve" to tell bzr that you've resolved the conclits.
[21:01] <Peng> Err.
[21:01] <Peng> conflicts*
[22:01] <Milo-> hey, I made a commit, and then pulled and had some conflicts which I couldn't handle at that time of day, so I did 'bzr revert', which for some reason removed my commit and all the changed made with it
[22:01] <Milo-> how do I undo revert?
[22:02] <Milo-> I know the files are reachable, since I had commited
[22:02] <Milo-> just like bzr uncommit lets you undo, so can bzr revert be undone?
[22:03] <NfNitLoop> Milo-: Did you do a 'bzr pull --overwrite'?
[22:03] <NfNitLoop> or a 'bzr merge'?
[22:03] <Milo-> actually, bzr update, checked my logs..
[22:04] <NfNitLoop> ah, this is a bound branch?
[22:04] <Milo-> yes
[22:04] <Milo-> wasn't bound when I committed.
[22:04] <NfNitLoop> right, so you had local commits, then did an update, got conflicts, then reverted...
[22:04] <NfNitLoop> Hrmm.
[22:04] <Milo-> yup
[22:04] <NfNitLoop> did you do any commits after that?
[22:04] <Milo-> no
[22:04] <NfNitLoop> that's good. :p
[22:04] <NfNitLoop> what does 'bzr status' say?
[22:05] <Milo-> says clean
[22:05] <NfNitLoop> Hrmm.  Sounds like revert is acting differently on bound branches?   *reads*
[22:05] <Milo-> well, clean as in I have a lot of uncommitted changes, mainly binaries and such
[22:05] <Milo-> ahhh meh
[22:05] <Milo-> there is "dir.moved"
[22:06] <Milo-> I failed to see that .moved earlier:)
[22:07] <NfNitLoop> likely what you'll have to do is find the old commit in your log, resurrect it as a new branch, and merge those changes back in.
[22:07] <Milo-> Don't know how to get that commit from the log, since it is not visible
[22:07] <NfNitLoop> it's not in ~/bzr.log?
[22:08] <Milo-> oh, didn't know about such log :
[22:09] <NfNitLoop> yeah, so when you update a bound branch, it tries to merge your stuff with upstream.  When you reverted...
[22:09] <NfNitLoop> well, usually revert only reverts files, did you do revert --forget-merges too?
[22:10] <Milo-> just 'bzr revert'
[22:10] <NfNitLoop> or do you have pending merges in your 'bzr status'?
[22:10] <Milo-> not according to bzr status
[22:10] <lifeless> NfNitLoop: 'bzr revert' will discard pending merges. 'bzr revert .' won't.
[22:11] <lifeless> just FYI
[22:11] <Milo-> ah
[22:11] <NfNitLoop> oh?  Is that new?
[22:11] <Milo-> that explains it
[22:11] <lifeless> NfNitLoop: no
[22:11] <NfNitLoop> Huh.  I guess maybe I added the '.' when I ran it before without realizing.
[22:11] <lifeless> NfNitLoop: revert with no args reverts everything; revert of any path only reverts that path
[22:12] <Milo-> there were no harm done when it nuked some of my source code
[22:12] <NfNitLoop> Milo-: so when you ran revert, it reverted to upstream's branch.
[22:12] <Milo-> yeah seems so
[22:12] <NfNitLoop> and you no longer have a reference to your commit in your history.
[22:12] <NfNitLoop> so you have to go pluck it out of your log.
[22:12] <Milo-> no need
[22:12] <Milo-> I Only had spent 40 minutes on that feature anyways
[22:12] <Milo-> re-made the whole feature with better quality in less than 10 minutes :P
[22:13] <NfNitLoop> hehe.
[22:13] <NfNitLoop> that's how you'd get around that, though.
[22:13] <Milo-> came here to ask how it is done, in case I actually need something like that in the future
[22:13] <NfNitLoop> without the log... I'm not sure what you would do.
[22:13] <NfNitLoop> anyone else have a suggestion?
[22:20] <fullermd> heads
[22:28] <NfNitLoop> fullermd: ah, handy.
[22:28] <NfNitLoop> I figured there was a tool like that, but hadn't poked around bzrtools enough to find it.
[23:30] <Kamping_Kaiser> wow... i'm impressed with bzr-svn, merged in new changes without me doing anything.
[23:30] <Kamping_Kaiser> jelmer: thanks :)
[23:30] <NfNitLoop> Kamping_Kaiser: isn't it awesome?
[23:30] <Kamping_Kaiser> NfNitLoop: it just is.
[23:31] <NfNitLoop> We use SVN at work and I use bzr for all my local branches for just that reason.
[23:31] <NfNitLoop> Well, plus I don't have to pollute the central repo w/ all my branches.
[23:31] <NfNitLoop> And when our SVN server goes down I can keep on working. :p
[23:31] <Kamping_Kaiser> :)
[23:32] <Kamping_Kaiser> interesting. patches are replayed on top. wondered where the -rewrite dependency came from
[23:33] <NfNitLoop> Kamping_Kaiser: it depends on how you do your development.
[23:33] <NfNitLoop> but bzr-svn will warn you if they're not going to be linear when you try to push back to svn.
[23:34] <Kamping_Kaiser> NfNitLoop: I only deal with r/o svn repos, so i haven't had a chance to encounter that yet
[23:35] <NfNitLoop> Oh.  Then I'm not sure what you meant by "patches are replayed on top".
[23:35] <NfNitLoop> (or, for that matter, "the -rewrite dependency.")
[23:36] <Kamping_Kaiser> NfNitLoop: bzr-svn in debian recommends bzr-rebase (which iirc is now bzr-rewrite)
[23:38] <Kamping_Kaiser> NfNitLoop: and i was mistake about the replay, the changes were merged, but they don't have a commit associated with them
[23:45] <wgrant> Kamping_Kaiser: If the branch you merge from doesn't exist on the svn server, then its revisions can't be recovered when you check out trunk again.
[23:45] <wgrant> It results in a so-called 'ghost' revision.
[23:46] <Kamping_Kaiser> wgrant: itdoes exist - i pulled it with svn into its own branch, and with bzr into a branch i modify