[00:03] jelmer: interestingly, the crash did not happen with svn 1.4.6 and the patch. [00:03] jelmer: it seems 1.5.x specific for some reason. [00:04] anyway, I'm too tired to investigate more carefully, I'll just leave it at its pseudo working state :D [00:37] jam: thanks for looking in to the cherrypick issue. [02:05] silly question, but will bzr reconcile ever be faster? [02:32] jelmer: is there a straightforward way for determining what bzr rev matches a svn rev? [02:32] other than grepping both logs [03:16] jdong: There is a svn: revision specifier [03:16] that allows you to get from svn to bzr revision [03:16] that will only work against a native svn branch though [03:16] as there is no one-to-one mapping in other cases [03:21] jelmer: ok, cool I'll take a look at that [03:50] hi all. i asked this in #ubuntu-doc, but i was pointed here. https://wiki.ubuntu.com/DocumentationTeam/Repository#head-7349bc14cd12ae1087537a239427a70a4d73295d talks about setting up a shared repository for checkout histories. i'm wondering if theres a way i can check my 3 docs checkouts (edu/kubuntu/ubuntu) are shared or not [03:50] kgoetz: cd into your branch, type "bzr info" [03:50] shared repository: /home/jdong/src/rockbox [03:50] ^^ you'll see a line like that if it's shared [03:52] kgoetz: and you should probably omit the --format argument too; the new default pack format is more efficient and faster over network [03:52] jdong: thanks a lot! "Shared repository with trees (format: dirstate-with-subtree)" [03:52] cool [03:52] jdong: i setup the repo months ago, but i've only just come back to it. [03:52] ah [03:52] consider upgrading to the packs format for space savings [03:53] and consider telling the same to doc team :) [03:53] ok :) [03:53] I'm quite sure you remember how painful it was to branch the first time :) [03:53] i'll check on bzr's site to see if i can find instructions [03:54] yes i do *g* [03:56] kgoetz: if you don't have a "shared repository:" then I think they may not be shared. [03:56] Although it would be odd to say "Shared repository" if it didn't mean shared. [03:57] Ah, the code is sensible after all :( [03:58] I was wrong, you get "Unshared repository" if not, so it should be fine. [03:59] ah, the forward thinking of bzr is just simply astonishing at times [04:01] yeah, and yet again it makes me look like a fool. [04:21] I need a pointer to any docs that will show a noob how to setup and use PQM. [04:44] james_w: The "info" code was a rat's nest. I've cleaned it up somewhat, but there's still plenty left to do, especially in the test cases. [04:46] kgoetz, http://beuno.com.ar/archives/48 (instructions to upgrade your branches) [04:46] beuno: thanks. [04:46] I'm off to bed now, it's too close to 6am [04:47] later mate [04:47] kgoetz, np. Upgrade them in Launchpad too if you host them there (upgrade them with sftp) [05:08] kgoetz: remember that packs are only compatible with bzr 0.92 or above (though they're a very very good reason why everyone should upgrade to said versions) [05:49] jdong: ok. theres always a catch :| [05:50] kgoetz: well... it's not much of a catch. IMO anyone using an earlier version of bzr is seriously missing out [05:50] kgoetz: I mean, in many of my branches you're talking about a 10x to 20x increase in branching speed by switching to packs [05:50] to ask someone to upgrade to a newer bzr is not at all unreasonable [05:51] sounds like installing 1.1 was a good call *heh* [05:51] not to mention the bzr team provides great methods for doing so on nearly all platforms [05:52] mmm. === doko_ is now known as doko [10:21] beuno: pong [13:39] lifeless, was in doubt on how to implement a change you requested, but I figured it out eventually. Sent the patch to the list :D [14:48] hello guys [14:49] is it possible to use bazaar with eclipse [14:50] I haven't tried this yet, but here's info about the eclipse plugin. [14:50] http://bazaar-vcs.org/BzrEclipse?highlight=%28eclipse%29 [14:58] 404: http://doc.bazaar-vcs.org/bzr.1.2/en/release-notes/NEWS.html [14:58] (That's the top link from http://bazaar-vcs.org/news#1.0released) [15:05] elijah: yes, there is a symlink missing on the server. Thanks for telling us about it though. Hopefully someone with access will fix it soon. === weigon__ is now known as weigon [16:37] Hello, how do I go back to the version x of my code. Lets suppose I commited 7 times. But then I regret and I say: I want to go back to commit #4. How do I do that? [16:38] Bloguero__Connor, bzr revert -r 4 [16:38] gracias! [16:38] Bloguero__Connor, ;) [16:39] later [16:42] lifeless: why doesn't bzr pack remove all obsolete_packs at the end of its run? [16:42] it seems like a logical time to do it [16:43] [jdong@jdong:src/rockbox]$ du -sh .bzr/repository/*packs [16:43] 130M .bzr/repository/obsolete_packs [16:43] 112M .bzr/repository/packs [16:43] kinda silly after a pack the repository size doubles [16:50] jdong, fun discussion about it in: https://lists.ubuntu.com/archives/bazaar/2008q1/036719.html [16:53] beuno: interesting.... thanks for the info, though reading it didn't give me a satisfied happy ending [16:54] jdong, me neither :p [16:54] beuno: all I see is "bzr help pack" tells me it recompresses packs to save me disk space, and du -sh tells me my repository size *doubled* after running it [16:55] we could change it to say "reorganizes packs to save disk space 5 commits later" but that sounds silly :) [16:55] log(n) commits later? [16:55] jdong, yeap yeap, I upgraded ~200 repos and maxed out my servers harddrive [16:55] was fun [16:55] than had to script something that would check the repo and delete them [16:56] LarstiQ, hey :D [16:56] there should be a [16:56] an option to remove them automagically [17:55] New bug: #197356 in bzr-svn "Branches created in svn don't seem related in bzr" [Undecided,New] https://launchpad.net/bugs/197356 [17:56] Hey, this one is mine! === mw|out is now known as mw === mw is now known as mw|out [18:58] Hi guys! Anybody here are using any bazaar plugin for Eclipse ide? [19:01] Lo-lan-do: yeah, sorry it took so long to forward it. [19:01] gnumarcelo: I think there are a couple of people [19:01] gnumarcelo: Verterok is the developer. [19:06] I'm planning use Bzr in my new project but i saw that plugin for eclipde is alpha version...I d'like to know if it is usable now [19:06] im sorry, im not speak english [19:45] what's the easy command to revert to a previous revision in the current branch? [19:46] bzr revert [19:48] example? [19:48] bzr revert -r6 [19:48] oh, that easy [19:48] Keybuk, "bzr revert" will revert to the last revision, or you can do "bzr revert -r revno" [19:48] it reverts the branch to the revision 6 [19:49] oh, easy then [19:49] yeap. or bzr uncommit if you want to remove all metadata for that commit [19:53] hey guys, if i have a a couple of standalone branches, would an init-repo after they are created have any effect on their storage optimization? Or does it only work before branch creation? [19:54] scorpioxy, I would say itwon't affect them at all [19:54] I'm not sure if you can re-convert them to be shared without re-branching [19:54] scorpioxy: you can make them use the storage by branching them to a temp dir in the shared repo, and then renaming. [19:55] scorpioxy: or directly in to the shared repo if you don't create it in the directory that contains the branches. [19:57] james_w: aha, so creating a shared-repo and then branching from into it....and so, is are we still limited by one level of ancestry for branches and shared repos? I remember that there was a discussion about that some time ago. [19:58] scorpioxy: what do you mean by one level of ancestory? [20:00] james_w: i mean any branches that want to use the shared-repo have to be first level children...as in just one ".."(single directory up) [20:01] scorpioxy: no, they will search down directories and stop at the first .bzr (pretty much). [20:02] and second silly question of the day [20:02] james_w: you mean search up, don't you? shared-repo would be be parent [20:02] how do I push new tags to another branch? :) [20:04] scorpioxy: up/down, it depends whether you are standing on your head :-) [20:04] Keybuk: I think you just do it with a push [20:04] james_w: that says "No new revisions to push." [20:05] Keybuk: however I think there is a bug report about not pushing tags if there are no new revisions, just new tags. [20:05] Keybuk: ah, yeah, that sounds like the bug. [20:05] yes, there is a bug report about that [20:06] james_w: :) i remember earlier that the shared-repo was only supposed to be one directory up from any branches in this repo...i guess that was changed.. [20:07] james_w: well, i'll give it a try, thanks for the help [20:07] beuno: thanks for the help too [20:07] scorpioxy: no problem. [20:08] scorpioxy, :D [20:17] jelmer: what do you think about ancestry between bzr-svn and launchpad vcs-imports? [20:18] it'd be nice if they recognized each other [20:18] jdong: There has been talk about that a year or so ago [20:57] jdong: We may end up discussing it again this sprint [20:57] jdong: but it's really all up to the launchpad folks to decide they want to use the same mappings and revision ids as bzr-svn [20:57] it would also involve trashing all existing imports... [20:58] hi [21:03] hello kosipov [21:12] beuno: is there a gui tool you would recommend for browsing change history with bazaar? [21:13] kosipov, have you tried bzr-gtk? [21:15] beuno: yes, and qt. I am having a very long history here, > 3000 revisions, and both are quire slow [21:15] quite [21:15] kosipov: Even newer versions of bzr-gtk? [21:15] kosipov: It loads up a 26k revision tree in a couple of seconds here [21:16] jelmer: hm.. maybe a bug in the way we imported our revision history here [21:16] takes about 2 to 5 minutes [21:17] the way you imported your history shouldn't matter [21:17] jelmer: I believe I have the latest version here [21:17] And you're just running "bzr viz" ? [21:17] kosipov: the one from bzr-gtk trunk? [21:17] is there a way to find out the total number of revisions? [21:18] jelmer: yes, I just bzr branched it [21:18] "bzr revno" should print it [21:18] (the number of revisions on mainline) [21:18] this is very strange then [21:18] kostja@dipika:~/mysql-5.1-runtime$ bzr revno [21:18] 2624 [21:18] * kosipov . o O (why does it take so much time?) [21:19] jelmer: hm... mainline we actually have very heavy branching [21:19] kosipov: bzr info should be able to print the total number of revisions [21:20] kosipov, there is also a very-alpha WX-based tool: https://code.launchpad.net/wildcat-bzr [21:20] what OS are you on? [21:21] ubunty gutsy [21:21] ubuntu [21:21] hm... [21:21] interesting... [21:21] I started bzr info --verboze and it took 20 secs for it to finish [21:21] kosipov, I'm on gutsy too and I can navegate _much_ bigger projects very quickly [21:21] Branch history: [21:21] 2624 revisions [21:21] 871 committers [21:21] 2770 days old [21:21] first revision: Mon 2000-07-31 21:10:05 +0200 [21:22] latest revision: Wed 2008-01-16 01:17:05 +0300 [21:22] what version of bzr are you using? [21:22] Repository: [21:22] 51009 revisions [21:22] 596938 KiB [21:22] 1.2 [21:22] so is above big enough? [21:22] jelmer, looks pretty big to me :p [21:23] ok, then this is expected I think [21:23] I was just wondering [21:23] kosipov, not sure if it's expected, would be nice if we could look into it a bit [21:23] good thing is that when it finally started it works with ok performance [21:24] kosipov, can you run bzr info again [21:24] and paste out what repository format you have? [21:24] it's the latest [21:24] second [21:24] you might be using an old version instead of the new one optimized for speed (packs-0.92) [21:25] or is it not: [21:25] Format: [21:25] control: Meta directory format 1 [21:25] branch: Branch format 6 [21:25] repository: Packs containing knits without subtree support [21:25] okay, then the question is how do I change the format? [21:25] and also, if I create a branch, does it preserve the old format? [21:25] it seems it's not [21:26] kosipov, your repo seems fine [21:26] but working with the branch wasn't too fast either. [21:26] kosipov, yes, it does [21:27] kosipov, can you file a bug with this information, noting it's too slow? [21:27] hi all. i'm having a problem where when i've changed my local branch of a repo, and someone else has committed changes on the server. how can i commit both sets of changes without any conflicts? [21:27] or without the commited change showing as reverted, and then re-committed. [21:28] j1mc, you want both changes merged? or discard one of them? [21:28] beuno: I believe I will be able to give you all the data [21:28] hi beuno ... i would like both changes merged. [21:28] just writing a report here for our group [21:29] my problem is that the committed change shows as reverted, and then recommited at the end. [21:29] we're trying to migrate, but first need to check that we can actually work ok [21:29] kosipov, even more interesting if you can file a bug so we can follow up and help you get the performance you need [21:30] j1mc, the work flow would be "bzr merge", resolve conflicts, than "bzr commit" [21:30] and, finally push if you want the final version on main [21:30] beuno: I will sure file a bug but when I have a tarball with the source tree with which you can play to attach to it. [21:30] New bug: #197426 in bzr "bzr diff message when some files are not versioned is unhelpful" [Undecided,New] https://launchpad.net/bugs/197426 [21:31] beuno: I need to double check that if I attach this tarball my company is not sued... [21:31] kosipov, maybe just file it with the "bzr info -v" data to get it rolling, and attach it later on [21:31] might not need the tarball at all [21:32] j1mc, you also might not get any conflicts, but you have to commit anyway [21:33] beuno: ... ok. i'm just looking up info on resolving conflicts. any tips? [21:34] j1mc, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts [21:35] beuno, you are the reason irc is awesome. :) [21:35] thanks for your help [21:35] j1mc, muehehe, no problem [21:44] https://bugs.launchpad.net/bzr/+bug/197429 [21:44] Launchpad bug 197429 in bzr "bzr gui tools are too slow with old/large repositories " [Undecided,New] [21:48] beuno: btw, what airport are you guys flying into tomorrow? [21:48] jelmer, gatwick I belive. You? [21:49] beuno: looks like Heathrow [21:50] * beuno double checks [21:50] I'm arriving an hour or a half before you guys but I guess waiting doesn't make sense if it's a different airport ;-) [21:51] jelmer, confirmed, Gatwick [21:51] it would be a bit odd to wait for us if we're in different airports :p [21:52] I was told to stay away from heathrow for some reason [21:56] New bug: #197429 in mysql "bzr gui tools are too slow with old/large repositories " [Undecided,New] https://launchpad.net/bugs/197429 [22:07] in mysql? [22:08] james_w, he seems to work for mysql [22:08] and is trying to use bzr with mysql devel [22:08] ah, ok [22:08] but, of course, it shouldn't be assigned to mysql [22:09] kosipov: mind if I drop the mysql part of that bug, it doesn't really reflect where the problem is? [22:10] jelmer, do you think it should be asigned to bzr-gtk too? It does seem a bzr problem but... [22:10] beuno: If it's consistent across all tools I think it's a bzr problem [22:10] perhaps it can be reassigned if it turns out there is a specific issue in bzr-gtk [22:11] jelmer, 50k revisions doesn't look like a bzr-gtk probem, no. Just wondering if it would be useful for other people reporting the same problem (it does affect bzr-gtk indirectly anyway) [22:18] beuno: well, we can always mark it as a duplicate if people report the same bug although marking it as occurring in bzr-gtk is also fine with me [22:22] jelmer, nah, it's fine, just a though [22:23] *thought [22:23] james_w: sure [22:27] kosipov: thanks. [22:28] james_w: should I attach the total size of the directory, number of files, lines? [22:28] would that help? [22:29] kosipov: I don't think the exact numbers are necessary. [22:29] ;-] === kosipov is now known as kostja|zzz