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