[00:22] Hrmm. I'm trying to use 'bzr launchpad-login' and I get a crash within urllib2_wrappers.py. Anyone not going wrong? Am I running an inappropriate version of Python for use with bzr? (2.5.2?) [00:25] KhaZ: bzr version, and pastebin the traceback [00:28] I'm running 1.12 dev. Let me get on that pasetbin. [00:28] *pastebin [00:29] http://pastebin.com/m38be0452 [00:30] KhaZ: That's a known bug. It's been discussed on the mailing list a bit. [00:30] Ah. Is there a workaround? [00:31] KhaZ: Well, you could revert to an older revision, or apply the patch on the list. [00:31] KhaZ: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/52120 [00:32] AH, thanks for the thread. I'll dig around a bit. I wonder why the patch isn't in dev? [00:33] KhaZ: Cuz it only came up today. [00:33] Outrageous. Turn around time in bzr isn't instantaneous? I'm apalled. [00:34] ;) Anyhow, thanks Peng_. [01:07] hello good evening [01:09] I have put some file on the shelve : bzr shelve file1 file2 file3 [01:10] in order to do an automic commit [01:11] now I would like to bring them back into my working tree [01:13] I found that bzr unshelve do what I want but I can have several shelve I would like to know if it is possible to : list them, name each shelf wit a meaning full name, explore their content ? === abadger19991 is now known as abadger1999 [01:51] yml: bzr help shelve/bzr help unshelve [02:40] bob2 I read them both but I haven't find answer to my questions [06:32] jelmer: Is bzr-svn's "discovering revisions" progress bar supposed to say the progress is a negative number? [08:38] Oooh, network <3 [08:39] ? [08:39] FOSDEM wireless. [08:40] Ah. [08:40] Let us say it hasn't proved very reliable yesterday. [09:02] LarstiQ: I pushed the current (almost empty) results of what we did yesterday at http://bzr.debian.org/bzr/users/lolando/misc/bzr-gc [11:50] Peng_, Nope, that's a bug. [12:02] Uh [12:02] $ bzr info [12:02] Repository branch (format: 1.12-preview or 1.9) [12:02] ... [12:02] what the hell? [12:05] AfC, Hi! [12:05] AfC, ? [12:06] AfC: What is the problem there? The fact that it mentions two formats? [12:06] AfC, this is because those formats are the same except for the working tree format [12:06] I'm asking what's with the "or" in the statement given by `info` about the format in place in the branch. Given that it was created with --format="1.9" I have no idea what that statement means,. [12:06] But worse is that it sounds like Bazaar doesn't know. [12:07] the problem is that if there is no working tree, there is no way to distinguish between the two formats [12:07] I cannot believe the core developer of a tool that purports to be a clean user experience exposed that kind of uncertainty in the UI. [12:08] jelmer: perhaps I could suggest that if there is no Working Tree present to not report about such things then. If it doesn't know, it doesn't know. [12:09] AfC: In that case, it couldn't print a format at all if you are in a shared repository [12:09] AfC, there is technically no difference between the two formats if you don't have a working tree, so I don't think there is any uncertainty here [12:10] AfC, I can agree it's a bit strange, but I don't see a good way to fix this.. [12:10] AfC, what would you rather see? [12:10] bzr could just show you one format I guess, that would be technically less accurate but less confiusing too [12:11] I just don't want Bazaar embarrassing itself in front of users. We made so much of the premise that bzr was a better user experience than other tools, but this is precisely the sort of thing that causes us to squander such branch equity. [12:12] ... such brand* equity. [12:12] :) [12:28] Can we file that under "yes, we know bzr has too many formats" and ignore it? :D [12:32] Jc2k: you around somewhere? [12:34] Peng_: what? again? [12:35] bialix: It was about "bzr info" showing stuff like "Repository branch (format: 1.12-preview or 1.9)" :) [12:35] oh [12:35] wait [12:35] how about this: [12:35] Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack) [12:36] IMO there is stil the room for dozen formats [12:36] Hahaha. That's excellent. :) [12:36] Too bad the subtree formats are hidden. [12:36] yeah [12:38] I think we scared AfC away. [12:38] :-D [12:38] lol [12:38] poor guy :) [12:40] Wait a minute, why is the lightweight checkout list in that order? In order of age, that's like 5, 5, 6, 6, 1, 2, 3, 4, 3. [12:40] Err, that should be 5, 5, 6, 6, 1, 2, 4, 3, 4. [12:40] ...Oh, alphabetical. [12:40] * Peng_ bonks himself on teh head [12:42] we need add randomizer I guess [12:43] so there will be everytime something new [12:43] That's a horrible, evil, excellent idea. [12:43] ...It'd make blackbox tests a bit tricky though. [12:44] put them in a set? [12:44] and check the set [12:45] * bialix don't think there is blackbox for light checkout info [12:45] Good point. It would still be slightly more complicated though. [13:32] LarstiQ: im at the front of the cross desktop room [15:52] This sounds stupid, but I cant find how to refetch a folder I deleted by mistake from the remote working branch [15:53] er, make that, refetch the folder from the remote working branch, which I deleted locally [16:06] right, bzr revert * === ja1 is now known as jam [17:23] what is the equivalent to os.path.join in bzrlib? osutils.join? [17:24] * bialix found osutils messy [17:25] bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.osutils.html [17:25] I think it is joinpath [17:25] Hi. Can I ask you? I am new to Bazaar and I really, really can't understand one thing (yes, I have read the user guide and the user reference manual first). It is shared repository. In the texts mentioned above is written that shared repository is created after "init-repo" command. New branches could be created by "init" command executed from the shared repo. Can you tell me what the branches share and if they depend on other branches in the shared repo? [17:26] share history [17:27] bialix: History? Do you mean the commits? [17:27] yep. all of the commits are stored in the shared repo. so if two branches have the same commits, then they won't be duplicated [17:28] it becomes a little bit more obvious if you sneak a peek into the .bzr directories. [17:28] yep [17:29] normally, a branch's .bzr dir will contain a branch, checkout, and repository subdirs [17:29] for a standalone branch, that is. [17:29] in the end the result is the same as the common working of svn I think [17:29] is you copy files around it will not copy history [17:29] copy/branch [17:30] nevans: So it is good to have a shared repo if you have some branches that have some common code (uh)? [17:30] pi_m: only if they share the same commits [17:30] pi_m: common history. I use shared repos whenever I expect to work on many branches of the same project. [17:31] pi_m: which is the usual thing when you work on branches [17:31] santagada: joinpath -> Undocumented :-P [17:31] I guess pathjoin actually is right [17:31] actually, I've got a single shared repo for all of my work projects... even though some of them don't share commits. it's just simpler than having a shared repo per project. [17:31] santagada: Yes. So placing the different project's branches to shared repo has no sense, I think... [17:31] bialix: at least you know the name :D [17:32] problem is: there are 2 functions: joinpath and pathjoin [17:32] pi_m: it doesn't help... but it is not a performance problem either (i'm guessing here) [17:32] pi_m: if you look into a branch's .bzr (under a shared repo), you'll only see branch and checkout dirs. and the shared repo's .bzr will contain the repository. [17:33] and if you run du on any .bzr dir, you'll see that the repo dir is always the largest. [17:34] santagada: pathjoin = os.path.join [17:34] :-P [17:34] * bialix anyway thinks osutils.py is messy [17:34] bialix: thanks... i'm also trying to learn the bzr api [17:35] pi_m: so if you have 5 branches that are fairly similar (and most branches within a project are), and their working trees take ~20MB, and their repos each take ~100MB, then it would take ~600MB to store them without a shared-repo, and ~200MB with a shared repo [17:35] * bialix using this api for several years and anyway it's messy [17:36] and since there's less disk usage, certain operations will also run more quickly with a shared repo (e.g. bzr branch) [17:37] Thank you, your advices were very useful! [17:40] Can I ask why there is an osutils versus using the os.path stuff? === asac__ is now known as asac [17:45] KhaZ: cross-platform support [17:46] let's just be franc that os.path.join is cross platform [17:46] what is diffente on osutils? stat? [17:48] Aye, I thought os.path.join *is* cross platform. Although I do realize that a lot of stuff in Python wraps it nicely but doesn't necessarily yield the same results.. [17:49] the difference is: osutils try to canonicalize the path after transformation to one standard [17:50] always / as path separator, even on windows [17:50] fix drive letter for windows and some other small details [17:50] Ah, gotcha. Hrmm. I'm sure the patch I submitted'll be rejected based on that alone. ;) [17:50] what? [17:51] Heh, just that I ended up using os.path and stuff directly in the patch I submitted w/RFC. [17:52] don't worry, you'll get detailed review and precise hints what to use instead [17:52] * bialix son't remember all gory details [17:53] s/son't/don't/ [17:55] Just be gentle. ;) [17:59] sorry [18:33] Hey guys, I'm confused on how to use bzr, what should I be doing... (bzr add, commit, and then push?) or should I have done merge? It's a two person project, and now we seemingly messed it up with conflicts in some auto-gen files. I'm thoroughly confused. [18:38] if the files auto-generated you'd probably better re-generate them? [18:38] I can't seem to do that? [18:38] I don't understand [18:39] Well, I don't know why, but it seems bzr thinks there was a conflict and put it's TREE, MERGE etc things into the file. [18:39] The file was created once... I don't think it should've ever changed, so I don't know why Bzr says it changed, here, one second, let me look at it's diff. [18:39] do you know how to solve 3-way merge conflicts? [18:39] Nope! [18:40] I don't know how to solve 2-way merge conflicts :) [18:40] Ignorance ain't bliss. [18:40] read `bzr help conflicts` first, please [18:40] Aight. [18:41] you're interested in text conflicts section [18:42] Yeah, reading that now. [18:42] I think, I can actually auto-gen this file, but not the others, let's give the auto-gen a shot. [18:43] yep [18:49] Ok, so, it just to make sure I have this clear, it sticks two files into each other if it doesn't know what to do? [18:49] Like, the earlier revision, and then the later one? [18:50] no [18:50] it tries to be intelligent and combine common parts together [18:50] Then why does it look like the same xml document twice over? [18:50] if you have 2 files entirely in conflict there is different line-endings perhaps [18:51] Mmm. [18:51] check .THIS and .OTHER in binary mode [18:51] I just deleted the second one and hope it works ;-) (That's bad practice!) [18:51] you can repeat merge ;-) [18:51] `bzr resolve` will delete this junk automatically [18:52] Ok, so I'm taking it my usual, "Bzr add, commit, pull" isn't the way to do stuff? [18:52] Not pull, push I mean. [18:52] bzr add, commit, push [18:53] I always thought push and merge were the same thing... [18:56] bialix: Or let me rephrase, I Thought pushing merged as well - automatically, take it as a no? [18:56] no [18:57] you should get 'branches are diverged' error -- then you need to merge locally and then push again [18:57] They weren't diverged (I assume, I never got that error), it was 20-21 21-22, etc. Basically, I worked on it, then my friend did, we just kept our code base in sync... [18:58] He worked at home, I worked at school, so - that's why we never merged. [18:59] you're pull when you need get his changes [18:59] Yep, that's what I did. [18:59] and push when you need to publish your changes [18:59] and then I pushed when I had changes. [18:59] so? [18:59] Why the conflicts? [19:00] you did pull? [19:00] Yep. [19:00] you had uncommitted changes in your branch [19:00] Yeah, About to say that. [19:00] And then I pulled. [19:00] = Errors. [19:00] Right? [19:01] Should I always commit before pulling then? [19:01] bzr did merge for you because you had uncommitted changes [19:01] Then merge before pushing? [19:01] Ahh, that's nice of it. [19:01] you'd better have 2 branches [19:01] 1 branch is exact mirror of remote [19:01] 2nd branch for your own work [19:02] you did pull only in 1st branch [19:02] I didn't even know I had two branches. [19:02] no [19:02] sorry [19:02] may be my English is not ideal [19:02] Nah; not your fault, I don't know what I'm doing. (That's my fault) :) [19:02] will be better if you create 2 branches to work on [19:02] Yeah. [19:03] and then merge them, right? [19:03] if they are diverged -- yes merge [19:03] Yeah. [19:03] if not diverged -- just pull from 1 to 2 [19:03] Yeah. [19:03] Diverged means, mismatched revision numbers - right? [19:03] you can do `bzr merge --pull` and bzr selects appropriate action to you [19:04] not exactly numbers [19:04] say you have revision 20, and your friend too [19:04] your branches are full mirror of each other [19:05] then you change say file foo.txt and commit [19:05] but in the same time your friend change file bar.txt and also commit [19:05] you both will have revision 21, but they are different [19:05] so, I should do bzr merge -pull from now on? So it just does whatevers right for us? [19:06] ok? [19:06] bzr merge --pull [19:06] Yeah, that's cool. [19:06] I get it now :) [19:06] yes, it's safe choice [19:06] you can create alias [19:06] Boy do I need that one then ;-) [19:07] * bialix is not boy [19:07] Er, figure of speech. [19:07] creating alias will save you typing this everytime [19:07] check `bzr alias -h` for details [19:08] I don't have alias? [19:09] bzr alias -h bzr: ERROR: unknown command "alias" [19:09] bzr version [19:10] what is your bzr version? [19:10] Bazaar (bzr) 1.3.1 [19:10] I take it, that that is old. [19:10] very old [19:10] :) [19:10] I probably got it from the repo long ago. [19:10] you'd better upgrade [19:10] Yep, yep. [19:10] Haha. [19:10] I bet you're on Ubuntu [19:10] Haha. [19:11] no? [19:11] Wow, Ubuntu is going to be what Windows was to the world. "Oh, you're on "UBUNTU". [19:11] Yeah I am. [19:11] I'm on Windows [19:11] hehe [19:11] I never upgraded the newest version of Ubuntu, I don't really care for it - waiting for 9.10 (I think) in April. [19:12] read instructions on how to update bzr at bazaar-vcs.org [19:12] And I think I installed this through a .deb package so it doesn't auto-update. =/ [19:12] I can't uninstall/reinstall newest? [19:12] go to Download page, look for Ubuntu and read instructions [19:12] kk [19:13] you should be able to aapt-get [19:13] Oh cool, it has it's own apt server. [19:14] Didn't know this. [19:18] many people don't know [19:19] I don't get it... bzr is worked on by conical - why don't they just put it in the main repo branch? [19:19] Bazaar (bzr) 1.11 [19:19] Now what? [19:20] where? [19:20] Huh? That's what my up-to-date bzr is. [19:20] 1.11, rather than whatever it use to be. [19:20] now `bzr alias` will work :-) [19:21] Cool. [19:21] :-D [19:22] Ok, so if I do bzr resolve, it delete the >>TREE stuff, right? [19:23] yep [19:23] np [19:23] no [19:23] sorry [19:24] Confused, what? [19:24] you need to resolve conflict (with meld e.g.) and then run `bzr resolve` [19:24] meld? [19:25] if the file has no '<<<< >>>>' markers then .THIS .BASE .OTHER files will be deleted [19:25] Yeah, it's just a properties file that I don't care about, so I removed the <<<< markers and called it a day. ;-) [19:25] Probably not a good thing, but whatever. [19:26] Ok, here's a good one. [19:26] Text conflict in pangea/nbproject/genfiles.properties [19:26] That file doesn't exist? [19:27] Found out why, I deleted it, my bad. Nevermind. [19:30] Ok, so all my conflicts are gone, thanks to ya' :) Though, here's what I need help with, sorta? It'll take a second to type it down - ready? [19:31] I've branched from revision 20 (the last one that worked) and pulled to 21, and then fixed the conflicts. The latest revision however is 23. [19:32] How can I merge with 22-23? [19:37] brrr [19:37] again [19:37] bzr commit your current state [19:38] Did so [19:38] then bzr merge [19:38] I did... [19:38] bzr merge --pull [19:38] so? [19:38] bzr st [19:38] actually, I did bzr merge --pull -r 22 [19:38] I don't want rev 23 atm. [19:38] Two conflits. [19:38] Conflicts* [19:38] resolve them [19:39] then commit [19:39] Ok, this is a different conflict though. [19:39] Conflict adding file pangea/build/classes/pangea/resources/New Folder. [19:42] The other thing is I have "PangeaVIew.class" to PangeaView$39.class, (Using Netbeans) but I think these files were from bzr. Do I need them? [19:42] Nevermind, I answered my own question, Yes I do need them. [19:56] bialix: Ok, so - here's one more thing I want to know how to do, remove stuff from bzr version control. [19:56] I have a lot of junk classes and old images I no longer want bzr to keep track of, in fact, I wanted them deleted. [19:56] What do I do? [19:59] either just delete them [19:59] or use bzr remove [20:00] with bzr remove you have fine grained control, read `bzr remove -h` [20:00] I used bzr remove. [20:01] Deleting them made bzr just throw them back up when I pull again. [20:01] delete + commit [20:01] but `bzr remove` is better way [20:01] Mmk. [20:01] "explicit" [20:01] Off hand, what's the better thing about it? [20:02] explicit is better than implicit [20:02] just don't forget commit [20:03] Phill: try this `python -c "import this"` :-D [20:04] I've learned not to use commands that I don't know, but hey, you can try rm -r / [20:04] * bialix on Windows [20:04] Oh right. [20:04] Darn. [20:04] :-P [20:04] Open up fdisk and figure out how to nuke your cdrive, I'm to lazy. ;-P [20:05] format c: [20:05] it's easy [20:05] Yeah, I've since forgotten 90% of the commands that aren't related to the Cisco IOS. [20:05] It's a bummer. [20:05] ok [20:07] Ok, now this is the last thing, bzr alias? [20:08] morning [20:08] just remembered: if you like the risk in life, try to run format c: drive [20:08] Thumper? [20:08] Phill: I may have missed some context, but aliases aren't exactly new [20:08] Oh no, I think I recognized you from another form. [20:08] forum* [20:08] Phill: last thing for what? [20:08] thumper: hi [20:09] Thumper: Ever been on the Firefox support forums? [20:09] Phill: no [20:09] Thumper: Wrong thumper then. [20:09] no, he's right thumer [20:10] Phill: just different :) [20:10] Ahh. [20:11] What's a good alias for bzr merge --pull ... [20:11] maybe: get-the-new-stuff [20:11] ;-) [20:12] Mmm. [20:12] get-new [20:12] OR, sync. [20:12] not bad [20:12] get-sync [20:12] actually I think "sync" is good [20:13] yep [20:13] and the command was "merge --pull" right? [20:13] right [20:13] Neeto. [20:13] That's not a word. [20:14] не то? [20:14] or не это? [20:14] I don't know? [20:15] Ok, so, when I push back up, I can just run bzr push right? [20:15] never mind [20:15] Or should I do "bzr merge --push" ? [20:15] yes [20:15] no [20:15] ok [20:15] merge is when you get the new stuff [20:16] you can't do merge for remote server [20:16] just push [20:17] Oh ok. [20:17] Well thanks. [20:17] Any other cool things you could teach me about launchpad and bzr? lol [20:18] tomorrow [20:19] haha [20:19] sure ;-) [20:25] Adys: just revert foldername [20:25] Adys: or if you want to revert everything, just 'revert' [20:53] did anyone end up volunteering for that editor thing kfogel proposed on the ml? [20:57] hello [20:57] i tried to do bzr shelve and bzr is crapping out now [20:57] i have 1.11 [21:03] Stavros: crapping out -> how? Can you pastebin a traceback? [21:03] it's not crashing, but bzr shelve tells me that it can't acquire a lock and then does strange stuff like telling me to break a lock before telling me again it can't acquire another [21:04] bzr: ERROR: Could not acquire lock "repo/.bzr/checkout/dirstate" [21:04] It should tell you who created the lock that is blocking you. [21:04] i'm the only user [21:04] Stavros: are you using windows? [21:04] yes [21:05] i think you may be using the new shelf (shelf2) which doesn't work with windows yet [21:05] oh [21:05] hmm [21:05] shouldn't it print something, then? :/ [21:05] there's probably a way to use shelf1. maybe someone else knows? [21:05] it's okay, i just wanted to shelve one file, so i committed it, but the errors were odd [21:06] i'm still using an older version of bzr, so i don't know what the solution is, sorry :/ [21:06] ah, thanks anyway [21:15] you could alias shelve to shelf1 (if that is the command) [21:16] * thumper wonders why the new shelve doesn't work with windows [21:16] * thumper looks at abentley [21:16] abentley: should the new shelve have problems with windows? [21:17] 1.12 should work fine [21:17] jam fixed it [21:49] Hi bialix [21:50] Hi Gary [21:50] I've edited NEWS [21:50] you'd better look at it with fresh eye [21:50] Ok - will do [21:50] because difftools is not mandatory thing [21:51] as you said [21:51] Do you have specific question to me? [21:51] I've been trying to build a deb - but I got frustrated - move on to more intresting things. [21:51] I'm looking at how I can use igc's revno-cache plugin to improve qlog's startup performance [21:51] ouch [21:52]