[02:49] If I move (w/ filesystem tools, not w/ bzr) paths around, how do I tell bzr about the new arrangement of folders and files? [02:49] I had to migrate some code to a new server, which has a different directory structure... "/www/htdocs/" has become "/www/a.com/pages/" and "/www/htdocs/common/" has become "/www/c.com/pages" [02:50] kumi: bzr mv --after [02:50] Verterok: thanks :D [02:50] np :) [03:29] * Verterok heading to bed === kostja|zzz is now known as kostja [09:43] Hey all.. is there any way to prevent bzr logfiles from littering my directories after each checkin? [10:02] moin [10:05] hi jelmer [10:05] awmcclain: to which logfiles do you refer? [10:06] bzr_log.OxncjQ~ bzr_log.RNweuu~ [10:06] Commit logs [10:06] I think those are only left when bzr aborts a commit [10:08] awmcclain: if that is not the case then I think a bug report is appropriate [10:08] Hrm [10:08] Bug report! [10:08] awmcclain: what's your OS? [10:09] I think this is Windows-related [10:09] 10.5, running bzr 1.2.0, using vim to edit commits. [10:09] (commit mesages) [10:09] they are not editor backup files are they? [10:09] since it's by default impossible to delete a file unless nobody has it open [10:09] actually, I think they are [10:09] So. Silly [10:09] that's not what vim's look like on linux, but I don't know Mac. [10:10] Yeah, you'd think the ~ would have tipped me off. [10:10] Hrm [10:10] weird though [10:10] james_w: if you 'set backup' in vim, it'll write ~ files [10:10] Is there a setting to have the commit files written to /tmp? [10:10] ah, backup as opposed to .swp, I see. [10:11] perhaps we should be using $TMPDIR anyway. [10:15] james_w: The current setup has the nice side-effect that if bzr crashes during commit, the log file is still there [10:30] moin === weigon__ is now known as weigon [11:15] New bug: #197597 in bzr "branches command slow" [High,Confirmed] https://launchpad.net/bugs/197597 [12:46] New bug: #197618 in bzr "Document BZR_REMOTE_PATH in man page" [Undecided,New] https://launchpad.net/bugs/197618 [14:30] Hi all. I'm at the hotel. [14:39] hi [14:40] I'm at the office [14:42] abentley: which hotel are you in? [14:52] abentley: hi [14:53] Hey there. How's things? [14:53] good [14:53] at the office at the moment [14:53] have you eaten lunch? [14:53] No. [14:53] Henrik Nordstrom and I are considering food [14:53] which hotel are you in? [14:53] I'm in favour of food. [14:53] I'm at the Rochester. [14:54] cool [14:54] I think all the Canonical people are at the Rochester. [14:54] many are, but not al I believe [14:55] I'd happily swap to the plaza - they serve prridge for breakfast :> [14:55] abentley: we'll come to the hotel [14:55] abentley: be about 15 minutes [14:56] Cool. I'll be in the lobby. [15:22] hi [15:22] i am importing from hg to bzr using fastimport [15:23] i used to have a crash till last rls [15:23] and now i have some warning msg like that instead: [15:23] WARNING: ignoring delete of content/xul/document/public/nsIXULContentSink.h as not in inventory (:65) [15:23] what does it mean exactly ? [15:24] seba__: I'm guessing that fastimport is being told to delete that file, but it doesn't think that it exists to delete it. [15:24] that's rather strange [15:25] seba__: indeed. [15:25] i guess a delete from hg was actually made on an existing file [15:27] it might have been done in a different order and hg-fast-export might not handle it correctly [15:34] bah it failed again now later... [15:34] I wonder if those fastimport plugin are tested on projects bigger than 5 commits and 1 branch... [15:38] seba__: I believe it is being developed as the developer is working on importing OO.org [15:42] oo chose bzr ? [16:19] hey [16:19] any sprint people awake? [16:28] jelmer: i am, but I'm not there. Are you after someone there, or just someone who is going? === asak_ is now known as asak [16:29] james_w, jelmer: hi [16:30] hi thumper [16:30] anyone staying in the rochester? [16:30] I am, but I don't arrive until Wednesday. [16:31] I think lifeless and abentley are. They were here a little earlier. [16:31] james_w: Just wondering who is here [16:32] james_w: I just met up with the two eclipsebzr guys [16:32] we're going to get some food in a few minutes [16:32] thumper: All the canonical folks are in the rochester [16:32] All the non-canonical folks are in the park plaza [16:34] jelmer: ah, is that the way it is [16:44] hmm, LarstiQ either forgot to turn his phone on or is still on the plane.. [16:44] hi -- can anyone tell me what's the advantage of 'bzr ignore foo-pattern' over 'echo foo-pattern >> .bzrignore'? [16:52] jelmer: Where did you meet the EclipseBzr guys? [16:58] nexus10: the former's more intuitive to find for the newcomer and the latter makes Git users happy? :D [16:58] nexus10: (ignore me, I'm in a grumpy flame-git mood today) [16:58] jdong :-D [16:58] jdong: that's what [16:59] jdong: ... I was hoping you'd say -- cos I have some probs with bzr ignore [17:00] nexus10: Yeah, from a user interface perspective, the first place I'd look for my VCS's "ignore" function would be in the commands list [17:00] jdong (and anyone else): is there a "why bzr kicks git's posterior' doc you can suggest? [17:00] nexus10: indeed there is one on the wiki [17:01] http://bazaar-vcs.org/BzrVsGit [17:01] jdong: ta, I'll go hunt -- dunno how git has got such buzz in the Rails world, but I need some ammo against all that buzz [17:01] jdong: fantastic, ta [17:02] nexus10: I think the reasons are quite compelling, and although that article prefaces itself to be bzr-biased, for the most part I think it's a quite unbiased view of reality [17:02] nexus10: the one thing I do give Git massive credit for is performance. Git's still noticeably faster than bzr on some tasks (bzr log on 5000 revisions), etc [17:02] jdong: I don't need persuading -- but I have a git diehard to win over [17:03] nexus10: though frankly for the average size project I don't care if I wait another 1 second for log to show [17:03] the time it took me to figure out how to tell git to stop committing things without my permission, bzr could'll logged itslef a billion times [17:03] lol [17:04] nexus10: if this Diehard Git user is a part of a bigger project, cross-platformness will instantly knock him down a few pegs. Force him to live the life of a Windows user for a day, and I bet he'll reconsider his choice :) [17:04] jdong: Rails projects are usually small - 2000 files or so [17:05] nexus10: yep, as I've noticed. I worked on a rails project last summer that was entirely versioned via bzr and all went great [17:05] jdong: bzr log doesn't seem that slow on 3184 revisions here, time bzr log > /dev/null == real 0m4.640s (hot cache though) [17:06] jdong: this user was on Windows -- now on gentoo and much happier [17:06] TFKyle: time git log > /dev/null on the entire mirror of Subversion's repository took less than a second [17:06] TFKyle: git log is unbelievably fast, but faster than most people would need it to be [17:06] speed is addictive [17:06] nexus10: yes, but in reality most projects would have to address Windows contributors, and Git's frankly unusable under Windows [17:07] nexus10: its speed and functionality are closely knit with the POSIX model of doing things [17:07] jdong: hmm, indeed [17:07] nexus10: and something else that might be a concern.... Git has little support for "dumb protocols" [17:07] jdong: don't understand why the git buzz is so incessant for Rails [17:08] nexus10: in particular, to push a git repo somewhere, you almost HAVE to have a git server on the remote end. Which isn't something one can always negotiate [17:08] can git even do symlinks properly? [17:08] nexus10: not sure. I'm not sure if we do that correctly too. At least we can *version empty directories* [17:08] (which might be something useful in dir-structure-sensitive things like Rails) [17:09] indeed [17:09] eg -- a Rails plugin has foo.rb and foo/* [17:09] rename it and you need to rename both [17:09] jdong: having a bit of a hard time measuring git log's performance btw as it seems to run PAGER. there a quick way to disable that? [17:10] TFKyle: AFAIK if it's redirected somewhere it would not use a pager [17:10] doesn't here (git 1.5.4.3) [17:10] -p|--paginate [17:10] Pipe all output into less (or if set, $PAGER). [17:10] I guess you can set PAGER to (1) nothing (2) cat [17:11] still, I assume setting it to cat hurts it a bit, but meh [17:12] lol if setting a pager to cat hurts performance, change operating systems :) [17:12] * jdong looks on his HDD for any git repos he has lying around [17:13] (doing that on the wine source tree from maybe a month ago takes ~1.5secs btw [17:13] how many revisions are in the wine tree? [17:13] ok I've got a git mirror of Rockbox and a bzr-svn mirror of it [17:14] the git mirror is 1k revs behind, lemme bring that up and we can compare [17:14] (though, gitk and qgit4 do seem quite slow compared to bzr visualize, dunno why) [17:14] I wish gitk was a gtk based frontend [17:14] there's apparently something called gitview somewhere out there [17:15] jdong: gitview is based on bzr viz :) [17:15] hi, i have a beginner question here. how do i actually start a project using a centralized style - the user guide seems to cover only the developer's site, but are there tutorials on how to setup the server? [17:16] * TFKyle wishes hg view was gtk-based as well [17:16] git log > /dev/null 0.60s user 0.00s system 98% cpu 0.615 total [17:16] * jdong waits for bzr [17:16] bzr log > /dev/null 10.86s user 0.33s system 98% cpu 11.305 total [17:16] order of magnitude [17:17] of course, logging 16378 revs is not exactly a "real world usecase" [17:17] * TFKyle still isn't sure how to tell the amount of revs in a git tree, hardly ever uses it :) [17:18] git rev-list --all | wc -l [17:18] lol that might be a hack [17:18] but everything in git seems that way. [17:18] and that's why I love bzr :) [17:18] and it's ALSO kinda annoying that git's on-disk size explodes when you commit to it [17:19] kinda forcing you to pack at least once every busy coding day if you don't want the thing taking up 5x the space it should. [17:19] 43449 [17:19] jdong, TFKyle: thanks, this was v useful [17:19] nexus10: oh, sorry - didn't mean to go off topic [17:19] TFKyle: yeah, git's fast at operations like this :) [17:19] but the UI is so.... urg.... [17:19] TFKyle: no worries, not OT for me [17:20] I tried to explain Git to someone who uses svn the other day, and he thought I was mocking him [17:20] jdong: so the consensus is -- git wins on speed, bzr on evetrything else? [17:20] i.e. I invented a parody of svn that was hard to use [17:20] nexus10: roughly put, yeah [17:21] nexus10: rather, git has a lot of gotchas that should make one think twice before adopting it across some project where not everyone is familiar with the tool [17:22] nexus10: on my coding project last summer, one guy had no experience with version control, and in an afternoon he was comfortable branching, pushing, pulling, merging..... bzr's that intuitive. [17:22] I can't say the same about git [17:24] There was a bunch of patches to the git list the other day to make it halfway windows compatible. [17:24] so, the git on windows effort seems to be progressing ok. === bigdo1 is now known as bigdog === andrea-bs is now known as andrea-b1 === andrea-b1 is now known as andrea-bs [18:06] * jdong bzr branches his todo list ponders the real-life meaning of what he just did. [19:01] jelmer: no [19:01] :-) === lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org//SprintLondonMarch08 [19:29] lifeless: the link needs a /Sprint .. instead of //Sprint === lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08 === cprov is now known as cprov-afk [19:50] Hi [19:50] hope I can ask a question related to launchpad and bzr here? [19:50] I have locked my own branch :-(. How can I unlock it [19:52] bzr lazy imports are self-created and not a standard python thing, right? [19:52] h4writer_: bzr break-lock, I think? [19:52] elmo: impoty bzrlib.lazy_import [19:52] doesn't do the job, but I had this before and had to use sft [19:52] *sftp [19:53] h4writer_: bzr break-lock URL [19:53] lifeless: ok - not sure I wanna make dak depend on bzrlib :) thanks [19:53] Still having the issue [19:53] :-( [19:54] bzr break-lock bzr+ssh://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons [19:54] doesn't do anything [19:55] elmo: go on [19:59] Is there a way to set a configuration value across all users and branches? [20:00] h4writer_: Total shot in the dark, but have you tried bzr break-lock sftp://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons ? [20:01] awmcclain, Indeed I thought it was that, but it isn't helping either :-( [20:01] :( [20:01] awmcclain, still locked, already for 30 min. :-( [20:02] ...or is the only way to specify a branch.conf in each one of my branches? [20:02] h4writer_: you tried both 'sftp://' and 'bzr+ssh://' ? [20:03] poolfool, indeed [20:03] but I see there are some processes busy with bzr if I do "ps -ax | grep bzr" [20:04] h4writer_: What is with the '+' plus sign in your path? ... what exactly is displayed on your screen about the lock OR when you try and break the lock? [20:04] poolfool, when I try to break it, nothing happens (so I get nothing returned) [20:04] h4writer_: Wait ... 'ps -ef' on your local machine or on the lauchpad server? [20:05] poolfool, local [20:06] poolfool, can't kill those :-S, how come that [20:07] h4writer_: do you own the process ? '#ps -ef |grep bzr' and check the User ID (uid). [20:08] poolfool, don't know, but I now killed them with system monitor :-D [20:08] poolfool, still locked :-( [20:09] poolfool, ? [20:09] poolfool, I did the committing with sftp [20:09] poolfool, and now it works [20:10] h4writer_: Yea ... kind of new to bazaar my self. but you did fix the 'lock' problem? But you can commit with sftp? [20:11] poolfool, I didn't fix the lock problem. I still have it when I try with bzr bzr+ssh:// LOL [20:11] If I want to track /etc with bzr, what is the proper way to ignore all the rcX.d directories? rc.d/rc*.d/ in .bzrignore doesn't seem to work [20:11] poolfool, only a workaround :-( [20:11] poolfool, lifeless, awmcclain and elmo thank you for helping. I can do again further :-D [20:16] Polarity: I saw something on the channel the other day, someone is doing the same thing but with Ubunto(sp) ... maybe a google search might help. [20:16] Polarity: But sounds like something I have wanted to try for a while. Good luck. [20:30] lifeless: playing around with loom a bit, this has probably been suggested before or is total crack but would something like a goto-thread command to go to a specific thread instead of manually up/downing multiple times be a good idea? [20:31] TFKyle: 'bzr switch threadname' [20:31] New bug: #197748 in bzr "getattr on WorkingTree should not raise ObjectNotLocked" [Undecided,New] https://launchpad.net/bugs/197748 [20:31] going out to dinner now, back tomorrow UK morning time [20:32] ah, cool [20:34] I was tole to: bzr co http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk [20:34] but that errors. [20:35] while I wait, is there any poking around that might help? [20:36] CarlFK: "co" with "http" doesn't make much sense. but what error do you get? [20:36] http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk/ is permanently redirected to https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/ [20:36] bzr: ERROR: Not a branch: "https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/". [20:38] CarlFK: they gave you a wrong URL [20:39] yep [20:40] "Never mind, I've attached the full checkout tarball." [20:41] a colleague of mine requested similar functionality to "hg cleanup" -- which removes all unknown files in the current working tree. i wrote a small script to do just that... would it be of any interest? how hard would it be to convert it to a plugin, or to add it as a command? [20:41] stefanv: hm. "clean-tree" from the bzrtools package can do that [20:41] great, thanks for the pointer [20:43] I often just use rm `bzr unknowns`. (adding -r when necessary) [20:43] that's probably fine for posix [20:43] i'm not sure what he is running [20:44] unknowns must be fairly recent [20:46] Anyone know... can I use pyqt4 with qbzr? [20:50] Soo. [20:50] Remind me not to get swapped to death (presumably by svn-import) in the future. === luks_ is now known as luks [21:19] Ug. What a nightmare it is to compile PyQt on a mac. === hsuh` is now known as hsuh [21:36] awmcclain: don't tell me that ... I am still looking for something nice to run on Mac OS X (leopard) with an OK gui. [21:36] awmcclain: Do you have a good link for a Mac OS X tool chain? Have you tried fink? [21:37] poolfool: Ug. I'm not a huge fan of fink. Plus i think they only have pyqt3, not pyqt4. One of htese weekends when things die down I'm going to start a cocoa app for bzr. [21:38] poolfool: Wildcat works pretty well, except for the fact that it doesn't work. ;) [21:38] ... and qbzr is no an 'app' :) [21:38] *not [21:39] luks: Well, an "app" that has extensive, non-trivial dependencies. :) [21:40] no, I mean it's more like tortoise* except that instead of using a graphical shell you use the command line [21:40] there is no actual application that would run on it's own [21:41] I'm confused... did you mean bzr or qbzr is not an 'app'? [21:41] qbzr [21:42] * awmcclain scratches his head. [21:44] the dev version has a partially-working standalone application, but I guess I'll never finish that [21:44] luks: did you write qbzr ? [21:44] mostly because I know that I won't use it, so I'm not very motivated :) [21:44] yes [21:45] :) [21:46] Oh, I see.. you mean you have to invoke qbzr from the command line [21:46] more that you invoke qdiff, qci, etc. from the command line [21:48] ahhh... [21:48] luks: Can qbzr give me a graphical display of bzr status? [21:48] yes and no :) [21:48] meaning it shows me the console output in a window? [21:48] qcommit shows you the equivalent of bzr status [21:49] but there is no standalone command for that [21:49] No, that's fine [21:49] Can you step through each file and get a graphical diff? [21:49] sure [21:49] And finally....can you resolve conflicts through it? [21:49] and add files, revers, etc. [21:49] *revert [21:50] no [21:50] ok. [21:50] but this one is on my todo list pretty high [21:50] mmm [21:50] any sense of timeline? [21:51] depends on when will I have to deal with first conflicting merge :) [21:51] Bascially I'm just looking for a way to 1. see the specific changes going out and 2. be able to resolve conflicts using a side-by-side diff. [21:52] I definitelly don't plan writing a merge tool [21:52] so resolving conflicts would involve just involving an existing tool [21:54] Ah yes, sorry, I wasn't more clear... can you pipe those diffs to diffmerge or something? I'm just looking for the workflow, really. [21:54] at the moment, no [21:54] ah. [21:54] it just uses internal side-by-side diff viewer [21:55] Basically I'm just looking for the eclipse-style team synchronization view. (But we've abandoned eclipse, thankfully) [21:56] hm, I've never used eclipse with a VCS [21:57] http://publib.boulder.ibm.com/infocenter/wsphelp/topic/org.eclipse.platform.doc.user/images/Image245_sync_view.jpg ? [21:59] Pretty much, yeah. You see files incoming, files outgoing, ignored and conflicts. [21:59] I suppose I could just run extmerge with a file merger for file conflicts. [22:02] I'm afraid qbzr isn't going to help you much in it's current state [22:02] S'ok. :) [22:02] I seem to need a GUI for quite different actions [22:02] branching and such? [22:03] no, mostly history browsing [22:03] ahhh [22:03] we have bzr-trac for that. :) [22:03] (which also doesn't really work. ;) ) [22:03] :) [22:06] Is there any way to see, when you update, what the exact merges will be? [22:07] something a bit more detailed than bzr missing? [22:09] now that I know about bzr missing, i think, no. :) [22:10] ditch the checkout, use a real branch, merge --preview? :) [23:02] I've accidentically remove am file with rm. Can I restore it with bzr? (It was version controlled of course) [23:03] mc__: bzr revert file # should do it. [23:03] thanks [23:04] any security issues w/ bzr server for ro access? [23:05] New bug: #183565 in trac-bzr "KeyError: 'root_directory'" [Low,Incomplete] https://launchpad.net/bugs/183565 [23:07] ferringb: none known, but I don't think it's been audited [23:07] mmm [23:10] New bug: #57447 in trac-bzr "Viewing changeset diffs is slow" [Low,Triaged] https://launchpad.net/bugs/57447 [23:10] New bug: #126835 in trac-bzr "COPYING file not being included in tarball" [Low,Fix committed] https://launchpad.net/bugs/126835 [23:11] james_w: do you know what sort of perms it requires? specifically, I'm thinking about locking on the repo [23:11] I'd rather run the server as a user that has no write access on disk personally [23:12] ferringb: that should help. [23:12] ferringb: there are read and write locks taken out by bazaar, and working tree, branch and repo locks. [23:12] yeah, that's specifically what I was concerned about [23:13] some of the read locks are just nops, but I can't remember if all are. [23:13] mmm [23:13] well, I'll experiment [23:13] server is fast enough I'm going to bring it up- 3.2k revs, http pull has been pretty painful for our users [23:13] read only on everything except .bzr/whatever/lock/ should be ok I guess. [23:13] Obviously not ideal, but better than nothing. [23:13] * ferringb nods [23:14] ferringb: does bzr+http:// not suit you? [23:14] james_w: wasn't even aware of it- specifics? [23:15] ferringb: well you can serve over http:// [23:15] however for better performance you can use the "smart server", which requires bzr to be installed on the server. [23:16] yeah, bzr server; thought that was 'bzr branch bzr://...' ? [23:16] That means you can use bzr+ssh:// for people you trust and need to grant write acess to. [23:16] ah, right [23:16] And you also get bzr+http:// which is fast readonly (though I've never used it, so don't believe everything I say) [23:16] mmm [23:17] how do you setup bzr+http:// ? only familiar with bzr+ssh [23:17] and bzr:// which is a native tcp protocol, which by default is read only, but you can grant write access with. [23:17] and allows read access to every file beneath the directory you serve. [23:19] ferringb: http_smart_server in the docs. Do you have the source of bzr? Otherwise what OS are you on? [23:19] linux, likely have docs, but didn't see it in the --help [23:19] It's not a help topic, but a doc [23:20] this up on the site at all? I went looking for perf. stats on bzr --server (and a quick intro to it), but didn't find anything [23:20] /usr/share/doc/bzr/txt/en/user-guide/http_smart_server.txt.gz [23:20] for me on Debian/Ubuntu [23:22] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi [23:23] it's got a big fat warning on that section, so maybe it is not trustworthy. [23:23] Serving over plain http should be pretty secure for read only access. [23:23] It is slower though, so if you have a large project it would be far from ideal. [23:24] well hell [23:25] been forcing people to use http://; speed up is a speed up, even if I just use bzr+http:// ;) [23:30] james_w: does bzr+http play nice with shared repositories? [23:30] it's giving me a 404 error indicating it doesn't ;) [23:31] ferringb: you trying to branch a shared repository, or a branch in a shared repo? [23:31] branch a shared repo [23:32] bzr.pkgcore.org/ferringb/pkgcore-dev; trying to pull that down, /bzr/ferringb/pkgcore-dev, shared repository at /bzr/ [23:34] mmm. screw it, bzr:// it is (it's fast enough I'll shove through the permissions issues) [23:34] james_w: thanks for the info [23:35] ferringb: no problem. Feel free to ask again if you need any more info. [23:35] bzr, bzr+ssh, and bzr+http use mostly the same code, so they should be equally speedy and secure (or slow and insecure) [23:35] heh [23:36] hell, I'm just happy to see smart server is around- been waiting for it a while, *very* happy to see a 71s checkout for users rather then the usual ~15m affair [23:59] jelmer: friendly ping on getting newer bzr-svn in PPA for gutsy :-)