[00:02] <maxb> The ideal thing to do here would be for Brian Aker to uncommit the last two merges, and redo them not merging the backout
[00:03] <SpamapS> hm
[00:13] <SpamapS> maxb: your solution may have, if nothing else, produced the correct diff. ;)
[00:30] <maxb> Actually the other option which might have been quite neat is:
[00:30] <maxb> Branch the tokyo branch just before the merge + backout
[00:31] <maxb> Merge time-order into that
[00:31] <maxb> Merge the result into trunk
[00:34] <SpamapS> maxb: wouldn't that still result in those changes not going into trunk?
[00:35] <maxb> I think the key thing is that you would have recommited the delta in the new merge revision, which wouldn't be in the current trunk
[00:39] <maxb> hmm
[00:39] <maxb> It doesn't do what I thought it would
[00:40] <SpamapS> Flat out.. the message here is.. do not commit from a revert w/o --forget-merges ... :-P
[00:41] <Kilroo> So incidentally
[00:41] <SpamapS> http://doc.bazaar.canonical.com/latest/en/user-guide/undoing_mistakes.html#reverting-to-the-state-of-an-earlier-version
[00:41] <SpamapS> Did it based on this ...
[00:41] <maxb> --forget-merges would not have helped you
[00:41] <SpamapS> no? so the moral of the story is, use uncommit
[00:43] <maxb> uncommit would have been more appropriate in this use case, yes
[00:43] <SpamapS> i think in reading it..
[00:43] <SpamapS> I didn't want to believe that it would be that easy. ;)
[00:43] <SpamapS> so used to perforce.. :-P
[00:43] <Kilroo> if I do something like 'branch --bind http://subversion/repository svnbranch' in a --no-trees shared repository, and then 'checkout --lightweight svnbranch lwco', what should happen to the subversion repository when I commit in lwco?
[00:44] <Kilroo> I think I generalized my paths a little more than I meant to, but...eh. Does the question even make sense?
[00:45] <maxb> I would suggest that committing to a bound branch ought to commit the changes to the upstream svn repo
[00:46] <Kilroo> I hope you're right.
[00:47] <Kilroo> Of course, unfortunately, the repos for which it would be the most helpful if that works the way I want it to, it doesn't matter because there's a revision bzr can't look at without running out of memory.
[01:00] <NfNitLoop> actually I think I saw someone in here say that that will give you an error.
[01:00] <NfNitLoop> you can't commit to a branch that's bound to a bound branch.
[01:00] <NfNitLoop> IIRC.
[01:00] <Kilroo> But it's a lightweight checkout.
[01:01] <NfNitLoop> and?  It's still a checkout (bound branch)
[01:01] <NfNitLoop> oh.
[01:01] <NfNitLoop> Hrmm.  Yeah, I think it still applies.
[01:01] <NfNitLoop> I dunno, I'm only guessing.
[01:01] <NfNitLoop> try it! :p
[01:02] <Kilroo> Yeah, that's pretty much what I'm gonna have to do
[01:02] <Kilroo> possibly tomorrow
[01:03] <Kilroo> ...assuming that I actually have commit access to any of the subversion repos that don't have revisions that choke bzr
[01:06] <NfNitLoop> SpamapS: Uncommit would have worked if you only had local history.
[01:06] <NfNitLoop> but once it's out in the wild, you can't uncommit it from other people's repositories.
[01:06] <NfNitLoop> so you just have to create a new revision with the same content.
[01:06] <SpamapS> Yeah we were working pretty fast.. ;)
[01:13] <NfNitLoop> SpamapS: so did you get it resolved?
[01:15] <mtaylor> GAAAAAAAAAHHHHHHHHHHHHHHHHHHHH
[01:16] <mtaylor> $ bzr branch bzr+ssh://bazaar.launchpad.net/~drizzle-developers/pkg-drizzle/trunk /home/hudson/hudson/workspace/drizzle-build-debian-packaging
[01:16] <mtaylor> Branched 29 revision(s).
[01:16] <mtaylor> except:
[01:16] <mtaylor> on a different machine:
[01:16] <mtaylor> $ bzr pull bzr+ssh://bazaar.launchpad.net/~drizzle-developers/pkg-drizzle/trunk
[01:16] <mtaylor> Now on revision 37.
[01:16] <mtaylor> why the crap am I seeing different versions of the branch over ssh ?
[01:17] <NfNitLoop> does that machine have 8 local revisions?
[01:17] <mtaylor> NfNitLoop: the top one is doing a clean branch ... and is also getting an older version of the branch
[01:18] <NfNitLoop> oh.  Yeah, that's not good.
[01:19] <mtaylor> wow. if I do it on the top machine _from a different account_ I get the right number of revs
[01:19] <NfNitLoop> sounds like there's some load-balancing going on and maybe one of them got a stale version of the branch.
[01:20] <mtaylor> it would be so great if there were a location I could pull from on my build servers after I've pushed to launchpad that would get the version I just pushed...
[01:22] <NfNitLoop> host your own? :p
[01:22] <mtaylor> yeah...
[01:31] <maxb> mtaylor: https://code.launchpad.net/~drizzle-developers/pkg-drizzle/trunk <-- there's an error there
[01:31] <Peng> mtaylor: Is one of your LP accounts in ~drizzle-developers?
[01:32] <Peng> mtaylor: Oh, the stacked-on branch is owned by you?
[01:32] <Peng> mtaylor: Launchpad keeps two copies of branches, one for people who can write to it, and one for people who can't. Maybe only one of them is busted.
[01:33] <Peng> Or...maybe it's something completely different! :D
[01:33] <mtaylor> maxb, Peng: yeah  ... also, thumper is looking in #launchpad
[01:33] <Peng> Ah. :D
[03:03] <igc> hi all
[05:18]  * igc dentist - bbl
[05:35] <lifeless> moinish
[07:34] <GaryvdM> Hi igc.
[07:35] <igc> hi Garyvdm
[07:36] <GaryvdM> Do you want to review changes for be, or should I just push?
[07:37] <GaryvdM> igc: ^ fix for bug 513138
[07:37] <igc> garyvdm: just push is fine
[07:38] <igc> you know the qbrowse widget better than I :-)
[07:38] <GaryvdM> Ok - cool.
[07:40] <GaryvdM> igc: done. I think you are going to have a smack your forehead moment when you see the fix :-)
[07:43] <igc> thanks garyvdm: consider forehead suitably smacked :-)
[07:43] <igc> on the first bit at least ...
[07:43] <igc> on the second bit, what's the reason for it?
[07:43] <igc> garyvdm: ^
[07:44] <igc> switching pages perhaps?
[07:45] <GaryvdM> igc: The default in qbrowse is to show versioned and non versioned, but not ignored.
[07:46] <GaryvdM> igc: So in be, we need to set it to whatever the combo defaults to
[07:46] <GaryvdM> because it is different to the qbrowse default.
[07:47] <igc> ah - ok
[07:47] <GaryvdM> ok - bye
[08:23]  * igc dinner
[08:24] <jam1> morning igc
[08:26] <igc> hi jam
[08:28] <igc>   File "./check-hottest.py", line 143, in main
[08:28] <igc>     output_stream = ui.ui_factory.make_output_stream(encoding_type='exact')
[08:28] <igc> AttributeError: 'TextUIFactory' object has no attribute 'make_output_stream'
[08:29] <igc> jam: ^^^
[08:29] <igc> any ideas?
[08:31] <Peng> I think that's been fixed.
[08:32] <Peng> bzrlib.ui.text.TextUIFactory.make_output_stream certainly exists for me.
[08:33]  * Peng shrugs
[08:34] <Peng> Looks like a new feature, lp:bzr r4880 (2009-12-09)/.
[08:46] <lifeless> igc: run with 2.1
[08:57] <jam> igc: right, make_output_stream is a 2.1-ism, probably your system bzrlib is 2.0
[09:18] <igc> jam: it is. I have 2.2 on my path but that doesn't seem enough ...
[09:19] <jam> igc: in PYTHONPATH ?
[09:19] <igc> no, just PATH
[09:20] <jam> igc: right, it has to be in PYTHONPATH or we won't use that bzrlib
[09:20] <lifeless> igc: PATH doesn't a ffect loading of python modul,es
[09:20] <jam> export PYTHONPATH=/home/igc/dev/bzr/bzr.dev
[09:22] <igc> jam, lifeless: better now thanks
[09:56] <napster> t
[09:57] <napster> Hello everyone. I'm new to bazaar. Can anyone help me to learn the basics of bzr...
[10:18]  * jam looks around to see who the current LOSA is
[10:18] <mthaddon> o/
[10:28] <jam> hey mthaddon, I had to bump a tag, and need to get that value propagated through pqm
[10:28] <jam> it requires running some "bzr pull --overwrite" on a couple of branches
[10:32] <jam> on the pqm machine, going to the 2.1 branch and running: bzr pull --overwrite http://bazaar.launchpad.net/~jameinel/bzr/2.1.0rc1-dev
[10:33] <jam> and then pulling that into the branch on launchpad itself
[10:33] <jam> which may just be "bzr push --overwrite lp:bzr" from that same directory
[10:50] <lifeless> igc: yo?
[10:50] <igc> lifeless: hi
[10:50] <lifeless> want to skype up?
[10:51] <lifeless> or happy as you are ? :)
[10:51] <igc> lifeless: absolutely
[10:51] <lifeless> igc: vila will be a few minutes
[10:51] <igc> lifeless: ready on my end
[11:36] <lifeless> vila: my flighttomorrow is at  07:40 CET
[11:36] <lifeless> vila: how long will a cab to the airport take ?
[11:44] <igc> lifeless: bug #513225
[13:30] <napster> I've created a project in launchpad and have bzr installed on my system. The project folder with source code is in my /home/Public folder. What is the next step to initiate the trunk?
[13:36] <maxb> napster: The quick answer?  bzr init; bzr add; bzr commit -m "Initial revision."   At some point you should plan on reading the docs to learn how a shared repository can make branching easier
[13:36] <maxb> s/easier/faster/
[13:37] <napster> maxb, I don't get :(  I'm really new to bazaar. Can you explain a bit?
[13:38] <maxb> What in particular would you like more detail on?
[13:38] <napster> maxb, I've just created a project in launchpad. I think there should be some url in the init commands, Am I right?
[13:39] <Peng> napster: You need to create your branch locally. Then you can push it to Launchpad, bzr lp-login (if necessary) and "bzr push lp:~whatever"
[13:40] <napster> ok, now it seems ok...
[13:40] <rubbs> napster: when you created a project on LP you made a place for your local repo to go, you need to create your project localy first and then do a bzr push lp:~directory/to/project
[13:41] <rubbs> this will "push" your repo up do LP, that will start the repo right on LP
[13:41] <napster> rubbs, Then I'll get a remote repo right?
[13:42] <rubbs> no, DCVS's have remote and local repos, you do all your work on your local repo, and when you "push" you more or less overwrite the remote repo (although that's not a good word, maybe update is better)
[13:42] <rubbs> the idea is to never be directly connected to a remote repo unless you are updating.
[13:43] <rubbs> that way you can do work away from a network and at the same time as someone else.
[13:43] <rubbs> napster: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
[13:43] <rubbs> it talks about mercurial, but the concepts are very similar to bzr
[13:44] <rubbs> that's the article that helped me understand how bzr, git, and mercurial works.
[13:44] <napster> rubbs, tnx mate :)
[13:44] <rubbs> np
[14:18] <napster> Path(s) are not versioned: I see this error when I've added some files and dir to my already inited,added project directory
[14:18] <napster> How to fix this?
[14:19] <rubbs> do you just want everything in your repo to be added?
[14:20] <rubbs> if so you can just run bzr add in the root of your repo, it will add everything in for you
[14:21] <rubbs> napster: this is another decent tutorial to help more specifically with bzr: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/tutorial.html
[14:21] <rubbs> http://doc.bazaar.canonical.com/en/ <- this can usually help you out too.
[14:21] <rubbs> and as always, if you have questions, we are more than willing to help here too :D
[14:23] <napster> rubbs, Actually how to add a directory to my project dir?
[14:25] <rubbs> so you have a directory already there and you want it tracked? or you want to add a directory that isn't there yet?
[14:26] <napster> rubbs, second one...
[14:27] <rubbs> ah, that's a little easier. while you are in the project dir, do this "bzr mkdir ./dirname"
[14:28] <napster> rubbs, But i've created one using "mkdir /nc/img" and then moved some files to it...!
[14:29] <Peng> I love 2a over nosmart+http. Of course you need to make a dozen 64k requests to figure out you have nothing to pull!

[14:30] <rubbs> napster: oh. so you have the new dir img and you want bzr to add it to the project
[14:31] <napster> rubbs, yes
[14:31] <rubbs> is there any files/directories in your project you *don't* want added?
[14:31] <napster> rubbs, the file inside /img too
[14:31] <napster> rubbs, Nothin "not to be added"
[14:32] <rubbs> ok, easiest is to just be in your project and do "bzr add" that will automatically recurse and add every file that isn't already added.
[14:32] <rubbs> also, you can say "bzr help add" to see what kinds of things add can do
[14:33] <napster> rubbs, done, but error exists...
[14:34] <rubbs> hmm. that's strange. you get the "Path(s) not versioned?" what version of bzr are you running (first line of output from "bzr version")
[14:35] <napster> rubbs, Bazaar (bzr) 2.0.2
[14:37] <rubbs> napster. have you commited since you ran bzr init?
[14:38] <napster> rubbs, that means run bzr commint?
[14:38] <napster> rubbs, that means run bzr commit?
[14:38] <rubbs> yes
[14:39] <napster> the error shown up when i try to commit
[14:39] <napster> bzr commit "Added some icons"
[14:39] <napster> Committing to: /home/napster/Public/netchat/
[14:39] <napster> aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: "Added some icons")
[14:39] <napster> bzr: ERROR: Path(s) are not versioned: "Added some icons"
[14:39] <napster> ^^ pls take a look
[14:40] <rubbs> oh... bzr needs the -m flag when commiting. Try this "bzr commit -m 'Added some icons'"
[14:40] <napster> rubbs, ohhh... I'm really sorry...
[14:40] <rubbs> no problem. it's all about learning
[14:41] <napster> rubbs, :)
[14:41] <rubbs> best way to learn is to make mistakes
[14:41] <rubbs> ;)
[14:41] <Peng> Unless your mistake is so bad that you die. Then other people learn, but it's not so good for you.
[14:42] <napster> rubbs, ;)
[14:42] <rubbs> Peng: ha... I suppose, I'll add that caveat next time I say that.
[14:50] <rubbs> napster: did that help?
[15:19] <jml> hey sprinters
[15:19] <jml> any of you know where bzr-builder gets the sourcepackage name from?
[15:20] <napster> rubbs, Absolutly
[15:21] <rubbs> napster: great!
[15:21] <napster> rubbs, I didn't say thanks because I need your help again.... :)
[15:21] <rubbs> haha, no problem, what's up?
[15:26] <lifeless> jml: the changelog
[15:26] <jml> lifeless, thanks.
[15:27] <lifeless> de nada
[15:32] <napster> rubbs, I'm really new to all such things. I need a software which should be maintained as a opensource project.
[15:32] <napster> rubbs, :)
[15:35] <rubbs> are you atempting to make your own from scratch, or are you trying to contribute to an open source project that has already been started?
[15:47] <napster> rubbs, Pls add my nick when you talk :) ... I'm trying to create on from scratch. I searched in launchpad, but can see similar projects in java
[15:53] <rubbs> napster: sorry forgot to add your name earlier. Have you read the launchpad help docs? They are pretty helpful on how to launch and maintain a project.
[15:54] <napster> rubbs, I'm on the help/tutorial pages for a while :)...
[15:55] <napster> rubbs, Is it harder to post a project on lp, if I've already a bzr branch on my local system?
[15:56] <Peng> No?
[15:56] <Peng> Wait, what are we talking about?
[15:57] <napster> Peng, About hosting a new project
[15:58] <rubbs> napster: the way to post your project is to set up the project and then do "bzr push lp:~/username/projectname/branchname"
[15:58] <lifeless> ~username
[15:58] <rubbs> er... should be ~username not ~/username
[15:58] <rubbs> thanks lifeless
[15:59] <napster> rubbs, and the branchname?
[15:59] <napster> rubbs, may be main?
[16:00] <Peng> Well, you could name it lp:~username/projectname/rubbs_is_awesome if you wanted to, but something like "main" or "trunk" is common.
[16:00] <napster> Peng, Thats nice :)
[16:02] <rubbs> Peng napster naming something rubbs_is_awesome is most definately not recommended ;), mostly because it wouldn't be true.
[16:02] <napster> rubbs, lol
[16:02] <Peng> Since when have software products had accurate names? :D
[16:04] <rubbs> Peng: good point
[16:42] <napster> I've tried to push my local branch to lp, but seems happened nothing...! What to do??
[16:43] <Peng> napster: What makes you think nothing happened?
[16:43] <Peng> napster: Pastebin the command you ran and its output.
[16:45] <napster> Peng, http://pastebin.com/m76cdcacd
[16:45] <napster> Peng, I can't see a branch named main in the launchpad site :(
[16:46] <Peng> napster: It exists: https://code.launchpad.net/~subinsebastien-gmail/netchat/main
[16:47] <napster> Peng, Why its not trunk?
[16:47] <Peng> napster: What do you mean?
[16:47] <napster> Its not the trunk branch right?
[16:47] <Peng> napster: If you want it to be set as the development focus branch or something, that's a separate step on LP's website.
[16:48] <napster> Peng, yes, how?
[16:48] <Peng> No idea! Should be pretty obvious.
[16:49] <chrisboom> ok. using windows bazaar
[16:49] <chrisboom> im a idiot, btw
[16:49] <chrisboom> im getting this message you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again
[16:49] <chrisboom> what do i do?
[16:51] <napster> Peng, I've set it. If we have only one branch, a search would return it and suggest to set as development focus branch
[16:53] <lifeless> mtaylor: pandora .98 in testing
[16:54] <napster> Why there should be a number of branches? What is the purposes?
[17:11] <MattCampbell> What's the status of nested tree support in bzr?  I mean something similar to svn's externals.
[17:13] <MattCampbell> I'd even be happy with something analogous to the Chromium project's depot tools (which support svn and git).
[17:21] <napster> rubbs, Peng lifeless Thanks a lot for you help. I think I'm covering the first learning curve and will continue... tnx once agin... :) see you later....
[17:22] <rubbs> napster: goog luck. glad to have helped
[17:22] <napster> rubbs, see you..
[17:23] <rubbs> chrisboom: are you using bzr via the windows commandline?
[17:23] <VSpike> Hi.  I have project tree, and I want to split a chunk of it out into a new, related project ...
[17:23] <chrisboom> nope
[17:23] <chrisboom> im using bazaar explorer
[17:24] <chrisboom> think we need a good tutorial out there for using explorer to simply log in to a launchpad id, set up ssh and start going
[17:24] <VSpike> Logically it's a sub-tree, in that the first project will depend it, but it can't reside in a directory below the first project because of restrictions of the dev env.
[17:25] <VSpike> My questions are, what is the status of Nested Trees, and is there a way to move the files into a new project but keep their history from the first project?
[17:25] <rubbs> chrisboom: did you do anything to the .bzr folder or name anything .bzr?
[17:26] <chrisboom> how do i set up ssh on windows?
[17:27] <rubbs> VSpike: I'm not entirely sure of the status of Nested trees, but you could look here: http://wiki.bazaar.canonical.com/NestedTreesDesign that might help
[17:27] <rubbs> chrisboom: do you have putty installed?
[17:27] <chrisboom> nope
[17:27] <VSpike> I already have main/lib and main/web, for example.. with main/lib being a component sub-project of main/web .. but I just handle the relationship manually
[17:27] <rubbs> chrisboom: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html click on the installer
[17:27] <chrisboom> ok, downloading that
[17:28] <chrisboom> now what?
[17:28] <rubbs> chrisboom: it should install putty, and pagent.
[17:28] <rubbs> chrisboom: you need to run puttygen
[17:28] <chrisboom> cool
[17:28] <rubbs> puttygen will create an ssh key for you
[17:29] <chrisboom> which i enter into launchpad?
[17:29] <rubbs> chrisboom: yes
[17:29] <rubbs> chrisboom: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[17:30] <chrisboom> ok, added the public key
[17:30] <rubbs> chrisboom: ok, then open your key with pagent
[17:30] <rubbs> pagent will have a small icon in the systray
[17:30] <MattCampbell> I'm just starting to use bzr (and version control in general) for a project which has many dependencies on open-source packages, some of which I've modified for this project and many of which I haven't.  It seems that importing the source trees for these packages into the project's main repository is a suboptimal solution, even though some other projects (e.g. Mozilla) do that.
[17:30] <MattCampbell> If I were using svn, I'd use externals, at least for the third-party packages that have svn repositories.
[17:30] <rubbs> chrisboom: when pagent has the ssh key loaded, you can use bzr with ssh.
[17:31] <chrisboom> kl
[17:32] <chrisboom> it worked!
[17:32] <rubbs> MattCampbell: there are lots of requests for externals, but IIRC there is no support for externals in bzr.
[17:32] <rubbs> chrisboom: awesome
[17:32] <rubbs> MattCampbell: I could be wrong.
[17:33] <MattCampbell> Any suggestions in the meantime?
[17:35] <VSpike> MattCampbell: see the NestedTrees link above - it's supposed to be bzr's answer to externals, I believe
[17:35] <rubbs> MattCampbell: I'm not sure, but i think that the nested trees is supposed to help (I know they are getting closer to full support).
[17:35] <VSpike> Just trying to ascertain the status, because AFAICT that is a design document, and doesn't explain status
[17:36] <rubbs> MattCampbell: VSpike  IIRC bzr explorer (the beta version) has some rudimentary way of doing it.
[17:36] <rubbs> I'm not sure though
[17:36] <MattCampbell> So that's only in the GUI tool right now?
[17:37] <rubbs> I've gtg to lunch, but keep asking questions, someone here is bound to help you ;)
[17:37] <rubbs> MattCampbell: I think so, but I'm unsure. This is really not my area of expertise
[17:47] <MattCampbell> OK, I see two tools that implement something like nested trees, config-manager and bzr-scmproj.  It seems that bzr-scmproj is more actively developed.  So does anyone here know of any advantages of config-manager?
[17:54] <pynonoir> Hi. I'm still trying to convert my svn repository to bzr branches. However the svn repository layout is not a classical one and I think it can't be done with either svn2bzr.py or fast-export-from-svn
[17:55] <mzz> pynonoir: I'd expect bzr-svn (the foreign branch support) to be your best choice at this time
[17:55] <pynonoir> So first I would like to be sure that it can't be done
[17:56] <mzz> pynonoir: but I haven't looked into this recently, so an even better choice may be available
[17:56] <mzz> oh wait, *not* a classical one
[17:56]  * mzz cannot read
[17:56] <pynonoir> no pb
[17:56] <mzz> hmm, at some point the repository layout was pluggable
[17:56] <mzz> I don't know if that went anywhere though.
[17:56] <mzz> I'd stick around in here and wait for someone to show up who knows about that
[17:57] <pynonoir> The last time I tried bzr-svn was not able to import the repo
[17:58] <pynonoir> Then I had other ideas. One of them would be to use mercurial as an intermediate
[17:59] <pynonoir> But I'm not sure it would work better, at least the hg-->bzr part
[18:01] <pynonoir> I'm also looking for some informations about bzr internals, at least to know if there is in theroy a working solution for me
[18:02] <pynonoir> for example, how does bzr knows that two bzr branches share a common history before doing a merge
[18:03] <mzz> bzr revisions all have an internal (globally unique) id. They also know the id (or ids) of their parent.
[18:04] <mzz> bzr-svn works by constructing fixed bzr revision ids for a given svn repository url and revision number, basically.
[18:04] <mzz> so if you convert the same svn repo more than once using bzr-svn you get the same revision ids, so bzr knows they're actually the same branch
[18:04] <mzz> when I looked into bzr-svn in the past you could modify the repository layout it assumed, but I don't know if it still supports that
[18:05] <pynonoir> then would it be possible to convert each branch of a svn repo, one after another ?
[18:05] <mzz> (doing that would affect the revision ids it generates)
[18:05] <mzz> you don't normally want that, because you'd lose the relation between the revisions (those parent ids I mentioned)
[18:05] <mzz> err, relation between the *branches*
[18:05] <pynonoir> that's what I was afraid of
[18:06] <mzz> I suspect bzr-svn can be hacked up to do this, but I don't know how hard that would be, or if there is an easier solution.
[18:07] <pynonoir> ok, I note bzr-svn in my todo list :)
[18:09] <pynonoir> mzz: so you think that the relations between branches must be analyzed at once, while creating a new bzr shared repository for all imported branches ?
[18:10] <mzz> pynonoir: bzr-svn can handle this (for multiple repository layouts, last time I checked, although possibly not for yours)
[18:10] <pynonoir> Ok, I'm going to check right now. Thanks :)
[18:11] <mzz> it can do branches separately, but if the layout assumptions it makes change you want the generated ids to change too, or you get insane conflicting branches
[18:20] <gerard_> hey
[18:25] <rubbs> hey
[18:28] <Peng> hey
[18:28] <Peng_> hey
[18:29] <gerard_> anything new for bug #113809?
[18:29] <gerard_> I'm beginning to think the whole update command is in need of a redesign/rewrite
[18:30] <gerard_> it sometimes changes the repo I'm updating from
[18:30] <gerard_> also, the fact that "bzr update; bzr revert" loses all local changes is REALLY counterintuitive
[18:30] <gerard_> it should go back to the situation before the update in my opinion
[18:31] <gerard_> also, "bzr pull" on a bound branch should not pull from the saved location but from the location of the bound branch
[18:48] <NfNitLoop> gerard_: yikes!  How would it change the repo you're updating from?
[18:49] <NfNitLoop> gerard_: "bzr revert" is defined as reverting your working tree... I don't find it very counterintuitive.  It's the same as in SVN and other SCMs.
[18:50] <gerard_> so what command should I use if I mess up fixing a conflict after update?
[18:50] <gerard_> it's really scary to have no backup
[18:50] <NfNitLoop> *nod*   That's one of the weak points of that workflow.
[18:51] <NfNitLoop> If you do development in a standalone branch, you can commit first.  Then merge.
[18:51] <NfNitLoop> and if your merge goes poorly, you can revert to your last commit.
[18:51] <NfNitLoop> The latter workflow is how distributed development goes.  The prior is just allowing the same workflow that people are used to in SVN.
[18:52] <NfNitLoop> (You have the same problem in SVN.)
[18:52] <gerard_> you say I can "revert to your last commit"
[18:52] <gerard_> don't think so
[18:52] <gerard_> the revert will make my branch a copy of the one I updated from
[18:53] <gerard_> I'm using the centralized with local commits
[18:53] <gerard_> workflow
[18:53] <gerard_> though I'm beginning to wonder if anyone else does
[18:53] <NfNitLoop> I do.
[18:53] <gerard_> because some things are buggy as hell
[18:53] <gerard_> if you have some local commits and local changes update will mess up severely
[18:54] <NfNitLoop> Oh, hrmm.
[18:54] <NfNitLoop> Yeah, I try to avoid that case.   What does it do?
[18:54] <NfNitLoop> I would assume it tells you that you've diverged from the parent branch?
[18:55] <gerard_> no, you get conflicts with your own work
[18:55] <gerard_> it's really confusing
[18:55] <gerard_> that's the bug #113809 I mentioned
[18:55] <gerard_> it will do two merges, and if the first one is a conflict it will then finds conflicts in the conflicts
[18:56] <gerard_> you end up with files like file.moved.moved
[18:56] <gerard_> trying to fix that case now
[18:56] <gerard_> it's going ok but one of the testcases doesn't want to cooperate
[18:56] <gerard_> the first merge it is supposed to do doesnt work in that case or something
[18:56] <gerard_> I'm beginning to expect a bug in the merge code
[19:01] <NfNitLoop> by "it will do two merges" do you mean "it will do a merge for each locally-committed revision"?
[19:01] <NfNitLoop> Because that's what I would expect.
[19:01] <gerard_> NfNitLoop: it will merge your local changes into the master and merge that into your local commits
[19:02] <gerard_> if your local changes conflict with the master, the conflicts will conflict with your local commits
[19:02] <gerard_> I'm trying to swap the order of merges around
[19:03] <gerard_> so it should first merge your local changes with your local commits (the simplest merge possible) and then merge that into the master
[19:03] <gerard_> the reason for the first merge is that instead of "local commits" you should be able to read "the commits on the branch this lightweight is bound to"
[19:05] <hersonls> Hi, i need export a revision with python lib bzrlib
[19:05] <hersonls> but i need have a repo Tree
[19:06] <hersonls> i import from bzrlib import tree
[19:06] <hersonls> but i dont know how create a Tree object
[19:07] <gerard_> hersonls: is that the ultimate problem you want to solve?
[19:07] <hersonls> someone know?
[19:07] <gerard_> maybe you can tell us what you want to achieve in the end?
[19:07] <hersonls> ok
[19:08] <hersonls> i want export a revision like "bzr export . /tmp/project" with python
[19:09] <gerard_> ah
[19:13] <hersonls> tanks, i found!
[19:13] <hersonls> from bzrlib.workingtree import WorkingTree; w = WorkingTree.open('.');
[19:14] <hersonls> :)
[19:14] <gerard_> ah, good job :)
[19:15] <gerard_> you could try looking in the tests/blackbox dir of bzr
[19:15] <gerard_> for lots of small tests/examples
[19:21] <hersonls> its work! :)
[19:21] <hersonls> from bzrlib.export import export; export(w, '/tmp/test');
[19:21] <hersonls> great!
[19:21] <gerard_> hehe
[19:22] <gerard_> yeah, I like bzrlib, really easy to use
[19:29] <MattCampbell> I've read about vendor branches in cvs and svn, a way to version-control an upstream package that has no public version control, and more importantly, one's modifications to that package.  Is there a similar best practice for bzr?
[19:30] <MattCampbell> There are even scripts to help maintain such branches for other VCSes, e.g. John Goerzen's vcs-load-dirs scripts, which support hg and git but not bzr.
[19:31] <gerard_> MattCampbell: have a "clean" branch with the upstream code and a private one?
[19:31] <gerard_> and them merge from the clean one into the private?
[19:32] <MattCampbell> Right.  Now when a new upstream version comes out, how do I update the clean branch from the upstream archive?
[19:33] <gerard_> just untar the new version over the old one and then commit
[19:43] <gerard_> sometimes merge.merge_inner doesn't merge anything?
[20:06] <gerard_> graph.is_ancestor doesn't work?
[20:32] <pynonoir> Hi again. I'm playing with bzr svn-import (from bzr-svn, right ?). I still have some problems importing the svn repository with my not-so-standard layout
[20:34] <pynonoir> I've edited ~/.bazaar/subversion.conf, and added a layout for the repository
[20:36] <mzz> oh hey, I thought that'd be harder than editing a config file
[20:36] <mzz> shows how out of date I am
[20:36] <pynonoir> :)
[20:37] <pynonoir> mzz, it seems so be harder, because I get nothing interesting with that
[20:37] <mzz> strange.
[20:38] <pynonoir> so either my config file is wrong, or it works but I don't get what I expect
[20:40] <pynonoir> I have set-up a small svn repository with the same layout
[20:41] <pynonoir> to do some tests on 9 revisions only
[20:42] <pynonoir> I can provide the url if someone has the courage to try...
[20:44] <pynonoir> the repo should be located here:    svn://ion.wizzi.net/sandbox
[20:54] <pynonoir> maybe I need to send my question to bzr-svn guys...
[20:54] <hersonls> someone know how i can get the revision number of working tree with bzrlib?
[20:56] <gerard_> hersonls: maybe self.get_parent_ids()[0] ?
[20:56] <gerard_> ahh, I think I fixed the update performs two merges bug
[20:57] <gerard_> it now performs the merges in a logical order, and also stops if the first merge has a conflict
[20:57] <gerard_> running all selftests now
[20:58] <hersonls> gerard_, return the 20100114122424-xzieq8r43ttzo8lg
[20:58] <hersonls> gerard_, i want some like  "revno: 4"
[20:59] <gerard_> hersonls: Branch.get_revision_id_to_revno_map ?
[21:01] <hersonls> gerard_, but, i have the WorkingTree object, not a Branch
[21:01] <gerard_> workingtree.branch ?
[21:01] <hersonls> gerard_, tanks man
[21:02] <hersonls> gerard_, but return a dicionary, what the way to get only current revn?
[21:03] <gerard_> there may be a shorter way, but you could try workingtree.branch.get_revision_id_to_revno_map[workingtree.get_parent_ids()[0]]
[21:03] <gerard_> it really looks like there should be a better way
[21:03] <gerard_> I'll check the source again
[21:04] <hersonls> i think in this
[21:04] <hersonls> and think if have another way, but tanks
[21:04] <gerard_> workingtree.get_root_id ?
[21:04] <gerard_> gmm
[21:05] <gerard_> workingtree.branch.revision_id_to_revno
[21:05] <gerard_> :p
[21:17] <gerard_> what's "bzr update -r" supposed to do?
[21:31] <IslandUsurper> is that a new option for update?
[21:32] <IslandUsurper> it's not in 2.0.2
[21:33] <rubbs> I don't see any help on the command with an -r option
[21:33] <gerard_> someone added it, and I'm rewriting the update command
[21:33] <gerard_> I think it still works, at least the tests do
[21:34] <gerard_> I'll just hope the tests are good enough then
[22:04] <gerard_> what would update -r do with local changes?
[22:08] <IslandUsurper> I would expect it to try to merge, like regular update. Which version you're updating to shouldn't matter
[22:09] <IslandUsurper> that's assuming, of course, that update -r tells it to get changes up to the specified revision
[22:09] <gerard_> regular update is a monster
[22:09] <gerard_> it's not just an inverted merge
[22:10] <IslandUsurper> hmm, are these local changes committed or not?
[22:11] <gerard_> not committed
[22:11] <IslandUsurper> never mind, they shouldn't be
[22:13] <IslandUsurper> from a user's perspective, I would still expect update to deal with local changes the same way, with or without -r set
[22:13] <gerard_> true
[22:13] <gerard_> it is a little weird though
[22:14] <gerard_> imagine a master with an additional commit, a bound branch with an additional local commit, and a lightweight checkout of that branch
[22:14] <gerard_> what would update -r2 do?
[22:14] <gerard_> (from the lightweight)
[22:15] <IslandUsurper> (Disclaimer: I've not looked very hard into bzr's code.)
[22:15] <gerard_> (Disclaimer: Me neither)
[22:15] <IslandUsurper> fair enough
[22:15] <gerard_> what is most important is what you would expect
[22:16] <IslandUsurper> update still looks like a pull or a merge to me
[22:16] <gerard_> the description of update is "prepares your working tree for a commit to the master"
[22:16] <gerard_> or something very close
[22:17] <gerard_> so the final goal is to have something that has both your latest changes and those from master
[22:17] <IslandUsurper> for local commits, though, they are temporarily uncommitted until you're back in sync with the master
[22:17] <gerard_> are they?
[22:17] <IslandUsurper> conceptually
[22:17] <IslandUsurper> remember, I haven't really looked at the code
[22:18] <IslandUsurper> but the end result is that your local commits end up in a pending merge into the latest changes from master
[22:18] <gerard_> I'd expect any uncommitted changes to turn into some invisible local commit, and then a merge would happen between that commit and the master
[22:18] <gerard_> IslandUsurper: right
[22:18] <IslandUsurper> and no matter how messy the merge gets, the working tree is passed to the lightweight checkout
[22:20] <gerard_> yeah
[22:20] <gerard_> and what happens to any "new" commits on the bound branch?
[22:21] <IslandUsurper> they look like a pending merge too, with the uncommitted changes being the tip of that merge
[22:21] <gerard_> like I have it working now is that first the new changes from the branch are merged with your local changes (stop here if there are any conflicts) and then the changes from master are merged into that
[22:22] <pynonoir> mzz, the import from the svn repo seems to work now !
[22:22] <mzz> pynonoir: ah, good. What fixed it?
[22:22] <pynonoir> mzz: with bzr-svn. You (almost) saved my life
[22:22] <IslandUsurper> gerard_, there ought not be any conflict between local commits and the changed working tree
[22:23] <gerard_> IslandUsurper: that's right
[22:23] <pynonoir> mzz: not sure what fixed it. I think I may have typed too many white spaces in the subversion.conf layout
[22:23] <gerard_> anyway, it seems we conceptually agree what bzr update should do
[22:24] <gerard_> I'll have something to eat, and clean up my patch that should prevent uncommitted local changes from conflicting with your local commits
[22:24] <IslandUsurper> yeah. ok
[22:25] <pynonoir> mzz: I still need to check some thinks on the real svn repo, but looks good.   svn merge are not taken into account, but I can live with that
[22:35] <pynonoir> mzz: one last question. svn2bzr allowed to define a mapping between svn commiter logins and a bzr-style author names with e-mails. I can't find this option with svn-import
[22:36] <mzz> pynonoir: sorry, I'd have to dig through the documentation, and I'm already doing something else
[22:36] <pynonoir> mzz: ok, I'll try harder to find it :)
[22:36] <pynonoir> mzz: thanks again
[22:37] <mzz> np
[23:18] <magcius> I accidentally tried to do "bzr up" to pull
[23:19] <magcius> And I got a confusing message.
[23:19] <mzz> I'd expect "Working tree is up to date", but I might be confused.
[23:19] <magcius> "Tree is up to date at revision 11848."
[23:19] <mzz> or yes, that.
[23:19] <mzz> apparently I've been brainwashed enough that I don't find it confusing.
[23:20] <magcius> Could you make it say, if nothing changed, "If you meant to pull new revisions, do bzr pull"
[23:20] <magcius> Because I thought it meant there was no new revisions./
[23:21] <mzz> and/or mention what branch it's up to date relative to?
[23:22] <magcius> Huh?
[23:22] <magcius> Sorry, I don't use bazaar, I just deal with it.
[23:24] <mzz> if it had mentioned what branch it was checking you would've noticed that wasn't the branch you meant to pull from
[23:24] <magcius> Oh. Does "branch" mean the same thing as "repository"?
[23:24] <mzz> no
[23:24] <magcius> I'm very confused by what "branch" means in bzr.
[23:24] <mzz> "repositories" aren't interesting in bzr land other than as an (important!) optimization.
[23:25] <magcius> So a "branch" in bzr is a "repository" in git?
[23:25] <mzz> well, I'm very confused by what pretty much anything means in git :)
[23:25] <mzz> but that wouldn't surprise me.
[23:25] <magcius> repository is a holder for objects.
[23:25] <mzz> you can stick (even unrelated) branches in a repository and they'll share storage
[23:25] <magcius> Then what are 'stacked branches'?
[23:25] <magcius> What do you call those as shorthand?
[23:26] <mzz> if you don't use a shared repository operations like "bzr branch path/to/some/local/branch" have to copy all history
[23:26] <magcius> bzr's overloading of the word "branch" confuses me.
[23:26] <mzz> I haven't actually used stacked branches other than very indirectly through launchpad
[23:26] <mzz> so I don't call them anything, sorry.
[23:27] <magcius> Alright.
[23:28] <mzz> there's documentation on what's what, but if you're like me you might find it useful to look at "bzr info" for some things and peek in the .bzr directory.
[23:29] <mzz> a branch really isn't much, just a revision id (identifying the head revision), tags, and a few settings
[23:29] <magcius> And the branch I would be up'ing from would be . and the thing I'm trying to pull from is the remote?
[23:29] <mzz> I'm assuming you got the branch you're working on through "bzr branch http://blah", and you didn't explicitly set up a repository?
[23:31] <mzz> (I can't answer your question until you either answer mine or run "bzr info" for me :)
[23:32] <mzz> "bzr up" updates the working tree from its branch, but if you got the branch from "bzr branch" the working tree and branch are both sitting right in ".", and you have to do something weird to get the branch ahead of the working tree.
[23:32] <mzz> so yeah, "bzr up" doesn't do anything interesting, and your suggestion to make that message better sounds good to me.
[23:32] <magcius> mzz, alright
[23:33] <mtaylor> bzr up is only really useful if you're doing lightweight checkouts
[23:33] <mzz> there are some weird situations where it's useful, like if you managed to push to this branch through a protocol that didn't update the working tree.
[23:33] <mzz> but that's not all that common.
[23:37] <NfNitLoop> isn't it?  push over ssh or sftp doesn't update the WC.
[23:37] <NfNitLoop> and that's how I always push.
[23:38] <maxb> Usually in such circumstances, you push to a branch without a WT at all
[23:39] <NfNitLoop> touche.
[23:44] <mzz> exactly.
[23:44] <mzz> I forgot if it even lets you push if there is a wt, but I'm pretty sure it warns about leaving the wt stale if it does
[23:46] <NfNitLoop> that may be new.
[23:46] <NfNitLoop> I don't think it used to.