[00:04] <Riddell> pathogenic: Bazaar rocks of course
[00:04] <pathogenic> is it distributed?
[00:04] <Riddell> Bazaar users are better looking and more attractive to the opposite sex than git or Mercurial users
[00:04] <Riddell> yes it's distributed, but you can also do a checkout similar to subversion so you have a choice of workflows
[00:07] <pathogenic> do they drive Ferraris too?
[00:08] <fullermd> I hope not.  It's hard to toss a couch in the back of a Ferrari...
[00:08] <Riddell> no, we're environmentally friendly and cycle
[00:11] <pathogenic> so what can i do in bzr that i can't in hg?
[00:11] <pathogenic> what are bzr braches like?
[00:13] <pathogenic> branches
[00:19] <pathogenic> ?
[00:21] <pathogenic> can you use git-diff format in bzr?
[00:30] <pathogenic> hello?
[00:33] <pathogenic> are you folks scared to answer?
[00:41] <fullermd> I don't know of any concise answer to that sort of question, and work doesn't really leave me time for open-ended discussions...
[00:43] <pathogenic> translation:  i'm afraid to answer, because any answer involves either lying or pointing out how hg is actually better
[00:43] <fullermd> Oh darn, you broke the code.
[00:43] <jimis> pathogenic: google is your friend
[00:44] <jimis> pathogenic: but since you won't, here is the result: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
[00:44] <pathogenic> i already read that, jimism
[00:44] <jimis> pathogenic: do your homework, try various things, and come ask us specific technical questions
[00:45] <jimis> pathogenic: do you really expect us to write an essay and list all reasons we prefer bazaar?
[00:46] <pathogenic> i asked some questions
[00:46] <pathogenic> it's a chat room
[00:46] <pathogenic> jimis:  if someone came into #mercurial, i could tell them all about it
[00:46] <pathogenic> i wouldn't be some stuck-up twat
[00:47] <bignose> pathogenic: you started out hostile, please don't demand answers to loaded questions.
[00:48] <pathogenic> i guess you folks are clueless
[00:48] <bignose> yep, that must be it. you'd better find some people more suited to your needs.
[00:48] <pathogenic> you've probably never even tried hg
[00:49] <bignose> pathogenic: see? you don't need us, you already know everything you need to know.
[00:49] <jimis> I agree
[00:49] <jimis> I think hg is better suited to your needs, pathogenic
[00:49] <jimis> now go
[00:49] <jimis> :-)
[00:49] <pathogenic> make me
[00:49] <bignose> ah, so you're not here for information, buit to squat
[00:50] <pathogenic> you go
[00:50] <pathogenic> bignose:  leave
[00:50] <jimis> Cool, I needed a break from work
[00:50] <pathogenic> hg has far more users anyway
[00:50] <pathogenic> bzr has little support on various sites
[06:06] <aminpy> http://dpaste.com/593859/plain/ <- how can I fix this?
[06:56] <bignose> aminpy: the informative part is “[Errno 111] Connection refusedxmlrpc.launchpad.net:443”
[06:56] <bignose> aminpy: the informative part is “[Errno 111] Connection refused” while it tried to connect to ‘xmlrpc.launchpad.net:443’
[06:56] <bignose> aminpy: so you'd best see why that connection is refused. either that host, or something between you and the host, is refusing that connection.
[06:57] <bignose> I have no trouble establishing that connection directly (using ‘telnet xmlrpc.launchpad.net 443’)
[10:29] <cheater_> hey guys
[10:29] <cheater_> if i have an up to date checkout of a bzr repo, and no one's working in branches or anything like that, then i can use that checkout to re-create the repo, right?
[10:30] <bignose> cheater_: you don't have a checkout of a repo
[10:30] <bignose> cheater_: you have a branch
[10:30] <cheater_> ok
[10:30] <bignose> cheater_: the concepts ‘repository’, ‘branch’, ‘tree’ are all distinct in Bazaar
[10:30] <bignose> cheater_: am I telling you something new to you?
[10:30] <cheater_> yes
[10:31] <bignose> okay. a repository stores revision data
[10:32] <bignose> a branch is a record of the distinct line of development; it refers to revisions, so is specific to a repository
[10:32] <bignose> a tree is the state of files that result from applying all the revisions of a branch
[10:32] <cheater_> gotcha
[10:32] <bignose> cheater_: so does that help you to re-phrase your question?
[10:33] <cheater_> not necessarily. i have a bzr repo on a server, and i did bzr co on my local computer. i'm wondering if i can just get rid of the server it's on, or if i need to back up the repository.
[10:34] <bignose> cheater_: if you actually have the repository locally, you have all the data you need
[10:34] <cheater_> i don't know. do i have the repository locally?
[10:35] <cheater_> how can i check?
[10:35] <bignose> cheater_: one way to tell is to branch from there to somewhere else (make sure it's in a separate location so you're not accidentally using the same repository)
[10:35] <cheater_> how would i do that?
[10:35] <bignose> cheater_: another way is to use ‘bzr info’ on the branch
[10:35] <bignose> cheater_: which will tell you what kind of branch it is, and where its repository lies
[10:35] <AuroraBorealis> if you only have one branch then doing a bzr branch on that will mirror it. but if you have more you would have ot branch all of them
[10:36] <cheater_> no i just have the, uh, "default" branch or something like that.
[10:36] <cheater_> sorry, i'm not too versed in the bzr data structure.
[10:37] <bignose> cheater_: it's okay, you don't need to know much of the structure
[10:37] <bignose> (one of the key advantages of Bazaar in my opinion)
[10:37] <AuroraBorealis> if you just have one branch then doing a bzr branch will mirror it.
[10:37] <cheater_> bzr info on my local computer says:  checkout of branch: bzr+ssh://login@server.com/srv/bzr/project/
[10:37] <bignose> but the flexibility of Bazaar does unfortunately require knowing that those separate concepts are indeed distinct
[10:37] <bignose> cheater_: that means the repository to which you commit is at that location
[10:37] <AuroraBorealis> you need to branch it, not do a checkout
[10:38] <bignose> cheater_: the purpose of a checkout is to emulate the centralised workflow
[10:38] <cheater_> ok.
[10:38] <cheater_> perfect, let me do a branch.
[10:38] <bignose> cheater_: if you want to be actually distributed-only, don't use checkout
[10:39] <cheater_> well.. in fact it's only just me using this.
[10:39] <cheater_> i'm a one-man act :)
[10:39] <bignose> cheater_: that's fine, I use both distributed and centralised on branches which are just me
[10:39] <bignose> cheater_: it's great to have the opiton of both, and even both at the same time
[10:40] <cheater_> yeah
[10:40] <cheater_> i've never *really* used bzr in distributed mode..
[10:40] <bignose> you don't need multi-person to get great benefit from distributed VCS
[10:40] <bignose> nor centralised, I guess
[10:40] <cheater_> i've used hg once branching out something and then using bitbucket's pull request feature
[10:40] <cheater_> but they handle all of that through a web gui
[10:41] <cheater_> so now i gotta learn how to do it per hand in bzr :)
[10:41] <cheater_> per/by
[10:41] <bignose> cheater_: you just ‘bzr branch’ without making it a checkout, without making it bound, without making it lightweight... basically just the default :-)
[10:41] <cheater_> yeah, doing that
[10:42] <cheater_> but let's say i did some work on the branch, how do i merge it back into the main repo?
[10:42] <cheater_> something like bzr push, right?
[10:42] <cheater_> just guessing here
[10:42] <bignose> Bazaar defaults to plain old distributed. but doesn't prevent other workflows at any future time.
[10:42] <AuroraBorealis> so if you just do a branch
[10:42] <bignose> cheater_: well which is it, you want to remove the other repository or not?
[10:42] <AuroraBorealis> then its not 'bound' to anything. it will just commit to your local copy
[10:42] <AuroraBorealis> but you can 'bind' it so that when you commit it will commit to both your local copy and your copy on the server or something
[10:43] <bignose> cheater_: use ‘push’ and/or ‘pull’ to maintain a mirror.
[10:43] <AuroraBorealis> or if you don't want to do that, you can either do push (which will make the repo a mirror) or a merge which will merge the repo's branch with yours
[10:43] <bignose> cheater_: once branches diverge, they're no longer mirrors; that's when you use ‘merge’ to reconcile them.
[10:43] <cheater_> AuroraBorealis, what about committing locally, but then at some point specifically saying "ok, take all the changes i've doneo ver the last few commits since branching, and put them in where i branched out from"
[10:44] <AuroraBorealis> haha
[10:44] <bignose> cheater_: first, please confirm whether or not you want the remote repository deleted, like you originally said
[10:44] <AuroraBorealis> well, you can either bind the branch, and do 'local commits'
[10:44] <AuroraBorealis> or you can leave it unbound and then commit locally then push or merge the branch'
[10:45] <cheater_> bignose, actually i do, but right now i'm playing with the (unrelated) idea of distributed work with bzr, since you guys sell it so well.
[10:45] <cheater_> just getting some info, that's all.
[10:45] <bignose> cheater_: okay. you have a checkout from a remote location
[10:45] <cheater_> :)
[10:45] <bignose> cheater_: so, when you commit, the revision data goes first to the remote branch and then to the local one, automatically.
[10:46] <bignose> cheater_: that's how Bazaar emulates a centralised workflow
[10:46] <bignose> cheater_: if you want temporary disconnected operation on the local branch, do one of two things:
[10:46] <bignose> cheater_: ‘bzr commit --local’ to do it just for the one commit
[10:47] <bignose> cheater_: or turn the binding off with ‘bzr unbind’, do your disconnected commits for a while, then turn back on the binding with ‘bzr bind REMOTE_URL’
[10:48] <bignose> cheater_: <URL:http://doc.bazaar.canonical.com/explorer/en/guide/core_concepts.html> is essential reading for you now you're askign these questions
[10:49] <cheater_> cool!
[10:49] <bignose> cheater_: and <URL:http://doc.bazaar.canonical.com/latest/en/user-guide/using_checkouts.html> for switching between distributed and centralised
[10:50] <bignose> cheater_: after reading those, explore the rest of the Bazaar documentation as your interest takes you. it's pretty good.
[10:51] <cheater_> :)
[10:51] <cheater_> i've noticed the bzr community is fairly supportive, i like that
[10:52] <bignose> like with PYthon, it helps that the system is *very* well designed and hence easy to teach
[10:53] <cheater_> yeah, in fact i'm sort of trying to push that sort of thing in the haskell community, i think it's lacking in that regard
[10:53] <cheater_> ok so.. how can i merge the parent branch with the one i'm in, so that the merged result is in the parent branch?
[10:53] <bignose> cheater_: I gave up very quickly on Haskell when I found that camelCaseNames are endemic through the library and community :-(
[10:54] <cheater_> it could've been worse, at least no braces
[10:54] <bignose> heh
[10:54] <cheater_> haha
[10:54] <bignose> cheater_: so first of all the terminology is wrong there
[10:55] <cheater_> ok so i've done a local branch, did a checkout of that, and added a file which i then committed to my local branch.
[10:55] <bignose> cheater_: you “merge branch BAR into FOO”, in order to get all the revisions from BAR to appear in FOO. FOO remains unaffected.
[10:55] <AuroraBorealis> camel case isn't that bad o.o
[10:55] <cheater_> now i want that file to show up in the parent that i branched out of.
[10:56] <cheater_> AuroraBorealis, your nick tells us you're a proponent..
[10:56] <cheater_> i'd say you're not objective on that matter ;-)
[10:56] <bignose> cheater_: no AuroraBorealis has a TitleCaseName, which is fine by me
[10:56] <bignose> cheater_: it's camelCaseNames that are inconsistent and ugly and stupid
[10:56] <cheater_> i know, j/k
[10:56] <AuroraBorealis> eh, its up to someone's opinion =)
[10:56] <AuroraBorealis> i guess i'm used to it because of java.
[10:57] <bignose> AuroraBorealis: that may be a reason why I'm emotionally against it :-)
[10:57] <AuroraBorealis> =P
[10:57] <bignose> cheater_: so, if you could name these branches, that would help us talking about them.
[10:57] <cheater_> ok let's call the server branch "server" and the local branch "local"
[10:57] <cheater_> :p
[10:57] <AuroraBorealis> what, you don't like classes like these? http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html
[10:58] <bignose> cheater_: better to name them for the purposes.
[10:58] <cheater_> that is their purpose. i've only done this to test how branches work.
[10:58] <bignose> cheater_: perhaps one is “trunk” and you branched for the purpose of a “feature-foo”?
[10:58] <bignose> cheater_: any objection to that for the sake of discussion?
[10:58] <cheater_> nah that's fine too
[10:58] <cheater_> :)
[10:59] <bignose> okay. so the implications of those names is that “trunk” will eventually get all the revisions that we want to keep, and “feature-foo” is limited in span and focussed on one area of work
[10:59] <cheater_> yes
[11:00] <bignose> so you might merge from “trunk” into “feature-foo” if “trunk” has gained a bunch of changes that you want to get up to date with on your ongoing work on feature Foo
[11:00] <bignose> alternatively, you might merge from “feature-foo” into “trunk” if your work on feature Foo has reached a point that it's worth making part of the main line of development
[11:01] <bignose> cheater_: so what's the case in this instance?
[11:01] <cheater_>  yes, i want to merge from "feature-foo" to "trunk"
[11:01] <bignose> cheater_: okay. a merge is always done into the current branch.
[11:01] <cheater_> i know how to merge from "trunk" to "feature-foo", i just go to the feature-foo directory and do bzr merge
[11:01] <cheater_> ok
[11:01] <cheater_> however, my feature-foo is located behind a firewall
[11:02] <cheater_> so i'd somehow need to initiate the connection from here
[11:02] <bignose> cheater_: if the branch doesn't have a remembered location to merge from (it's “parent”, I think; that might have changed recently)
[11:02] <cheater_> yes, it's "parent"
[11:02] <bignose> cheater_: then you specify the branch to merge from on the ‘bzr merge’ command line.
[11:02] <cheater_> ok
[11:03] <cheater_> how do i go about fixing my firewall problem?
[11:03] <bignose> cheater_: the concept there is that “feature-foo” should ideally keep getting changes from upstream, i.e. changes perhaps made on other branches that themselves got merged into trunk earlier
[11:03] <cheater_> yeah
[11:03] <bignose> cheater_: and you choose when that happens by merging explicitly, but the default place to merge from is its parent.
[11:04] <bignose> cheater_: whereas “trunk” shouldn't necessarily have any parent; there is no good default palce to merge from, so you specify each time you merge into trunk.
[11:04] <bignose> cheater_: what firewall problem?
[11:04] <bignose> need to be AFK for dinner now. I leave you in the tender care of the other channel denizens.
[11:05] <cheater_> :)
[11:05] <cheater_> thanks a lot for the help
[11:05] <cheater_> enjoy your dinner..
[20:39] <lifeless> jelmer: is https://bugs.launchpad.net/launchpad/+bug/826082 got any chance of being a regression from your refactoring ?
[20:44] <jelmer> lifeless, looking
[20:49] <lifeless> jelmer: thanks!
[21:13] <jelmer> lifeless: hmm, it indeed seems like it would be related. The problem isn't obvious to me though, and unreproducible (at the moment).
[21:21] <lifeless> so far only one occurence
[21:21] <lifeless> but its a little concerning ;)
[21:22] <jelmer> lifeless: yeah
[21:41] <thomi> Hi, is there a safe way to delete a branch from disk on a bzr repo server? I mean, what if someone's half way through read/writing it?
[21:44] <lifeless> so for a read, they will get an error
[21:44] <lifeless> for a write, their repository transaction will complete ok but then the change to the branch pointer will error
[21:45] <lifeless> neither case should lead to repository corruption