[00:00] Strange [00:00] that's the latest revision I pushed [00:01] If I try to pull the trunk branch, I get a KeyError on another revision from today. [00:01] I can pull lp:bzr-svn. [00:01] branching here locally works fine [00:02] "bzr log -r -1 http://people.samba.org/bzr/jelmer/bzr-svn/0.4/" works fine. [00:04] I get the same KeyError on a copy of the branch on another computer. [00:05] FWIW, my branches are in pack-0.92-subtree, not rich-root-pack. [00:05] Peng_, please file a bug against bzr [00:05] no idea what's causing this [00:06] * jelmer runs bzr check in his 0.4 directory [00:09] jelmer: OK, I'll do that [00:12] Check passes on my repo, aside from 22 inconsistent parents. [00:13] works fine here, no inconsistent parents either [00:17] I just reconciled. No more inconsistent parents, but it didn't help the KeyError. [00:24] jelmer: Did you run check on http://people.samba.org/bzr/jelmer/bzr-svn/ or your local copy? [00:25] Peng_, locally [00:28] jelmer: Can you try it remotely, just to be sure? [00:29] 980 inconsistent parents, but ok other than that [00:31] ok, reconciled [00:31] Peng_, can you try again? [00:32] Sure [00:32] Still failed [00:32] Mmm, the packing reconcile did made it much faster. :) [00:34] jelmer: bug 263137 filed [00:34] Launchpad bug 263137 in bzr "KeyError pulling bzr-svn's branches" [Undecided,New] https://launchpad.net/bugs/263137 [00:47] Peng_: hmm, reconcile on the server crashes === mark1 is now known as markh [00:49] FWIW, I was able to 'bzr branch http://people.samba.org/bzr/jelmer/bzr-svn/' just a moment ago with bzr r1682, and then 'pull' inside the new branch. [00:50] Er, r3668, I mean. 1682 was the revno for bzr-svn. :) [00:51] Geez, I pasted the wrong URL, too. Add '0.4/' to that. [00:55] Hmm, branching into my shared repo failed, but branching into /tmp succeeded. [00:55] (Sorry for wasting some of your bandwidth, jelmer.) [00:56] I get a KeyError if I use a pack-0.92-subtree shared repo. [00:56] ... and it takes about 72s instead of 20s, most of which is spent with the cpu pegged. [00:56] Heheheh, using a really fast Internet connection is fun. [00:57] ToyKeeper: I can confirm it. [00:57] ToyKeeper: Mind if I update the bug? [01:01] I just tried to confirm it with a tiny test branch, and everything worked fine. [02:16] Peng_: Yeah, sorry, I was away. Since you haven't marked it as confirmed, I may as well. :) [03:58] I seem to have done a checkout rather than a branch, so when I commit it goes directly to the repository instead of making a local commit requiring a later push. [03:58] how can I change my current directory so that I can do local commits and later push? [03:59] can I just remove the bound* variables from my .bzr/branch/branch.conf file? [04:02] nevermind, that seems to have worked [04:02] cr3: "bzr unbind" [06:54] any bzr-svn people around? [06:55] I keep getting bzr: ERROR: exceptions.NameError: global name 'revnum' is not defined [07:04] LaserJock: do you have the latest version? [07:05] of the 0.4 branch yes [07:05] I couldn't find any tarballs [07:05] what file and line number is the exception on? [07:06] revision 1670 of that branch was the recent release - its possible the trunk has an error [07:06] s/trunk/tip/ [07:08] File "/home/mantha/.bazaar/plugins/svn/workingtree.py", line 595, in pull [07:09] looks like a typo in working tree [07:09] that line should say 'revnumber' it seems [07:10] personally I'd go back to r1670 though [07:10] how do I do that? [07:10] hrmph - that seems to have the same problem though [07:13] I'm really not sure why that hasn't been seen before - you could try editing that file, or wait for Jelmer to pop up. [07:17] hmm, I'm getting another error [07:18] bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Unable to lock '/data/projects/avogadro/openbabel/cmake'", 155005) [07:19] hmm, maybe I'm doing this wrong. some branches that I've been using bzr-svn on previously seem to work [12:43] hm, i'm in a mode where several of us are committing changes to our branches on a frequent basis and we have an integration server that we need to update with the changes several times a day ... what should the workflow like that look like ? === fta_ is now known as fta [13:14] rocky: have you seen http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id58 [13:14] gour: i've read through that guide a couple times now ;) [13:18] rocky: what do you think about that workflow with gatekeeper? [13:19] gour: well, that's basicaly what i'm doing now... i guess i could try the automated gatekeeper approach [13:20] rocky: yeah. sounds good for your reqs. i, however, do not have experience with pqm [13:20] neither do i [13:20] and it's a relatively small project... seems like adding pqm is overkill [13:20] right. human gatekeeper is enough then [13:20] do you use LP? [13:21] no [13:21] so, distributed workflow with human integrator sounds good for you [13:25] yeah [14:40] too bad it's not possible to re-upload a deleted package with a different src tarball in ppa :( [14:40] as the tarball is gone from the pool, it should be possible.. [14:43] hrm... if i want to distribute a patch (but not via email) what's the most sensible way to get all info involved? i would have thought "bzr send" but it needs an email addr [14:44] oops; wrong channel, it was meant for #lp [14:45] hi! i got this crash when running bzr log -r : http://pastebin.com/d6ff1c6a1 [14:45] is this a known problem, and do you need the tree in order to debug it? [14:45] hi, can anyone help me out with a merge problem? I would like to merge with anther branch, but I want to decide myself how to resolve (automatically resolvable) conflicts. Bazaar tells me that it has merged all changes successfully, but I do not want to take everything which is in the other branch... [14:46] rocky: bzr send -o filename [14:47] yeah just figured that out ... it's not obvious in the docs though that that option stops the email from occurring [14:47] jonnydee, if you mean that you don't want to take all changesets in the other branch, use 'bzr merge -r [14:48] these bundles produced by "bzr send" don't record the commit msgs tho right? [14:48] of course they do [14:48] they are like normal branches, you can merge/pull from them [14:48] no, it's not dependent on the change sets. I would like to merge in only part of the changes of the last changset existing in the other branch [14:49] luks: oh, is that contained within the "bundle" portion of the file? the bottom part that is base64-encoded? [14:49] rocky: yes [14:50] sven: I wish I could tell bazaar to let me merge in the changes using kdiff3 instead of leaving it to bazaar to merge in the changes automatically [14:50] the "patch" part is actually not used for anything important by bzr [14:50] all is in the bundle part [14:50] jonnydee, sorry, i don't know how to do that... [14:51] sven: no problem, thanks anyway :) [14:52] maybe anyone else has an answer? [14:52] jonnydee: http://erik.bagfors.nu/bzr-plugins/extmerge/ [14:52] oh, actually I'm not sure if that does what you want [14:52] it seems to be only for resolving conflicts [14:53] I've just installed this plugin. Unfortunately, it only allows to resolve conflicts that cannot be resolved automatically by bazaar [14:53] luks: exactly [14:54] actually, what would be needed is to switch off bazaar's automatic conflict resolving strategy and to mark all differences as conflicts [14:55] anyone familiar with loggerhead? [14:56] jonnydee: hm, telling it to mark everything as conflicts shouldn't be hard [14:56] I'm using an auto_publish_folder, and getting lots of "Exception: name 'url' is not defined" [14:56] bazaar tries to be as intelligent as possible in resolving conflicts (which it does indeed very good) but it should also allow to be as dumb as possible [14:56] Hello, is there a separate channel for bzr-svn? [14:56] luks: how can I do that? [14:56] Snaury, Hi [14:56] Snaury, nope, this channel is for bzr-svn as well [14:57] jonnydee: not from the command line, but using a plugin maybe. wait a minute [14:58] I wonder if anybody else has noticed a dramatic speed drop in bzr-svn 0.4.11: bzr 1.5 + bzr-svn 0.4.10 +django trunk = roughly 1 second per revision, bzr 1.6 + bzr-svn 0.4.11 + django trunk = roughly 10-20 seconds per revision. :( [14:58] luks: ok :) [14:58] Snaury: 0.4.11 should actually be significantly faster [14:59] Snaury, any chance you can run with -Dtransport to see what sort of requests it's making? [14:59] jelmer: I know it should, but in fact it is actually dramatically slower [15:01] jelmer: where should I use -Dtransport? bzr update -Dtransport does not show anything. :-/ And I'm on Windows, btw. [15:01] Snaury, it will write to .bzr.log [15:02] jonnydee: nope, too complicated for me :) [15:03] wow, you tried to write a plugin :) well, thanks a lot, anyway!!! Shall I maybe submit a bug regarding this issue? [15:05] jelmer: i just checked out an svn trunk using bzr-svn, then i branched the co, then i tried pushing the branch back as a new branch in svn and it committed the changes i made to the svn trunk instead :( [15:06] rocky: Please file a bug [15:06] * rocky wonders if he's just trying to use bzr in a very unusual way which is why he keeps having problems [15:06] preferably with some way to reproduce this easily [15:07] rocky, what version of bzr-svn are you running? [15:07] jelmer: 0.4.11 final [15:08] jelmer: http://kitsu.ru/bzr-1.6-django.log [15:08] That's two revisions. :) [15:10] rocky, I can't reproduce it here, there must be more in play there [15:12] Snaury, thanks [15:13] jelmer: and here what it looks like on 1.5: http://kitsu.ru/bzr-1.5-django.log [15:19] jelmer: when I added [15:20] jelmer: when I added properties.PROP_IGNORE in fetch.py now log looks like this: http://kitsu.ru/bzr-1.6-django2.log [15:20] Snaury, Ah, I think I've seen this before [15:21] revprop-list is hanging [15:21] I don't remember if it was a server or client-side problem [15:22] same subversion, same tree, bzr 1.5 and bzr-svn 0.4.10 and everything is pretty fast. :? [15:22] yeah, but bzr-svn 0.4.10 didn't use revprop-list [15:22] fetching from django works fine for me (http://code.djangoproject.com/svn/django/trunk/) [15:22] one revision every couple of seconds [15:22] hmm? look at my bzr-1.5 log. :-/ [15:23] it has svn revprop-list -r * lines, every one takes ~2 seconds. [15:25] it's probably doing other things in between those lines as well [15:25] This was a bug in the subversion libraries, but I don't recall the details :-( [15:26] Did you build bzr-svn 0.4.10 yourself? [15:27] Snaury, any chance you can try the latest revision from bzr-svn's 0.4 branch? Ive added more debug statements [15:30] jelmer, sure, just a little later, I made some more mutter calls myself... [15:30] jelmer: and it's definitely not revrop-list, I've added (done) mutter call in finally and it returns after just one second. it is hanging somewhere else. [15:31] Snaury, revprop-list itself wasn't hanging but was delaying the command that follows it [15:31] jelmer: it's lp:bzr-svn? [15:31] http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [15:35] I submitted a bug regarding a "dumb conflict resolution strategy" that marks all differences as conflicts (in essence this means to switch off automatic conflict resolution): https://bugs.launchpad.net/bzr/+bug/263302 [15:35] Launchpad bug 263302 in bzr "No way to switch off Bazaar's automatic conflict resolution" [Undecided,New] [15:37] jelmer: http://kitsu.ru/bzr-1.6-django3.log, as you can see it's not hanging. something is working, just very slowly. [15:38] Snaury, but where is it spending that time? [15:38] I have no clue. :-/ [15:38] Is there any 'full-debug' mode, where it prints maximum info in the log? [15:41] Snaury: there's various -D options [15:42] -Dcache also prints a lot of things [15:42] you may want to try profiling [15:50] jonnydee, Can't you just use the .THIS and .OTHER files? [15:58] jelmer: but the do not show up when bazaar resolves the conflicts successfully. [15:58] jonnydee, ahh === cprov is now known as cprov-lunch [16:21] jelmer: I found that the expensive call that takes so much time is reporter.finish(). looks like while it working it calls lots of callback functions, though I can't figure which ones yet. :-/ [16:35] jelmer: but it takes 10 seconds before it starts calling any callbacks. :-/ And it calls too many of the callbacks, http://kitsu.ru/bzr-1.6-django4.log [16:37] Snaury, what do you mean with too many? [16:37] jelmer, Snaury: I also experience extremely SLOW and also overly network intensive "bzr pull" from a svn repos [16:38] that's with Webkit SVN [16:38] uws, that's a new regression (with bzr-svn 0.4.11 )? [16:38] the traceback in the log file after "ctrl-c" also shows reporter.finish() almost at the bottom [16:38] Well, I'm not an expert, but what I read in svn include files implies that reporter should only call callbacks (i.e. report) changes to what was specified to it. Judging from the number of calls it looks like it reports the whole tree. :-/ [16:39] jelmer: dunno when it got this slow. it's haever been fast, but I remember that it only took a few secs for each revision [16:39] right now it's running >1min and still at the first rev [16:39] [= ] copying revision 1/195 [16:39] last 2 lines of log file: [16:39] 176.514 lookup parents: 'svn-v3-trunk0:268f45cc-cd09-0410-ab3c-d52691b4dbfc:trunk:35809' [16:39] 176.514 revprop list: 35809 [16:40] could it depend on the tree size? [16:40] This is with -Dtransport -Dcache btw [16:40] Snaury, it should only call for the changed files in the tree [16:40] tree is huge in the webkit case [16:40] uws, it's hard to judge without the full log [16:40] jelmer, then look at http://kitsu.ru/bzr-1.6-django4.log (very huge!). that revision changed only *one* file. [16:41] jelmer: http://pastebin.com/m15a35bde [16:41] jelmer: if it should only report changed files, then something is royally wrong somewhere. Maybe in the way reporter is initialized. :-/ [16:41] jelmer: (has 2 logs, first is with Ctrl-c, the latter is the currently running bzr) === uws is now known as uws_ === uws_ is now known as uws [16:51] Snaury, uws: any chance you can try again with the last revision of 0.4 ? [16:51] (r1688) [16:52] that should give more information about what deltas it is trying to retrieve [16:54] jelmer: shows svn update -r8749:8750 [17:04] hmm, that looks right [17:05] hmm, wait.. [17:05] Snaury, what happens if you comment out line 589 to 592 ? [17:05] (in fetch.py) [17:08] bzr: ERROR: LICENSE is already versioned :) [17:09] jelmer: WAAAAAAY faster, e.g. 1 rev / 3 secs now [17:09] so much for "any directories or files not explicitly `set' are assumed to be at the baseline revision originally passed into do_update()" [17:12] Snaury, that only doesn't work on Windows for some reason [17:12] Snaury, A windows user contributed that fix, it's not necessary for *nix [17:13] jelmer, which fix? [17:13] Snaury, to explicitly call set_path [17:13] for more than just the root [17:13] uws, thanks for veryifying that, btw [17:14] jelmer: yw. === mark1 is now known as markh [17:58] is the release notes for bzr 1.6.1rc1 available any place? not on news.html yet it seems [17:59] nvm, found it [18:14] looking to migrate some svn repos to bzr ... anyone know if tailor supports bzr 1.6 or perhaps suggest an alternate preferable tool to tailor? [18:16] rocky: bzr svn-import ? [18:16] heh [18:17] didn't even realize such a thing existed [18:17] it's part of bzr-svn, just makes it easier to run for a full repository [18:17] gotcha [18:17] does it require a rich-root repo? [18:18] yeah, it'll still require a rich-root repo [18:18] how come? [18:19] since it generates repositories that are compatible with bzr-svn [18:19] and it seems pointless to have two different code paths that have to be tested, given that rich root will be the default in bzr soon [18:20] makes sense [18:32] jelmer: is it possible, for a given InventoryEntry, to find its associated svn revision? [18:38] jelmer: could it be that reporter is behaving like that because revision numbers bzr-svn reports to set_path are bigger than what is actually in the repository? [18:40] Snaury: That could cause it to do strange things [18:40] Snaury, but is that actually the case? [18:40] I don't know, that's what I want to try. [18:41] it should be easy to see if a revnum exists remotely by running "svn log -r " [18:48] no, I tried a different thing (passing repo.lookup_revision_id(entry.revision)[1] to reporter.set_path), but it didn't help either. [18:50] jelmer: I'm just out of ideas of what's going on here. :-/ I've been looking at svn_client in how it initializes reporter, and it's basically just that: set_path on every dir/file in the working tree.. [19:01] Snaury, I wonder how this is different from bzr-svn 0.4.10 though [19:01] Snaury, did you build subversion yourself for bzr-svn 0.4.10 ? [19:01] jelmer: no, I just downloaded official 1.5.1 [19:02] jelmer: it's also strange how 0.4.10 managed to work with a single set_path("", ...)... :-/ [19:03] Snaury: same here [19:04] Snaury, is start_empty perhaps set to True? [19:04] no, I checked and it's False. [19:05] hmm [19:07] last resort I guess would be to see what's going on on the wire [19:11] Snaury, ah [19:12] jelmer: what is it? [19:14] Snaury, I thought I'd found something but it turns out to be the same behaviour anyway :-( [19:17] jelmer, I can't help the feeling there is something wrong in the extensions layer. it's very strange how bzr-svn 1.4.10 with pysvn 1.5.1 manages to succeed with a single .set_path for "", and after adding a bunch of mutters I see that it gets a very small delta. [19:17] There is something very wrong somewhere. [19:18] Snaury, Not sure why it would be wrong in the extensions layer then though [19:18] (and imho writing these extensions was a mistake) [19:20] jelmer: because with bzr-svn 1.4.11 it's as if we are updating from revision 0. :-/ Yet python code looks ok (c code, on the other hand, also looks ok, but maybe I wasn't digging deep enough) [19:20] Snaury, the C code layer is very thin and works fine here on Linux, for example [19:21] Snaury, The python code has changed significantly as well between 0.4.10 and 0.4.11 [19:21] jelmer: I'm talking here about two things only: call to reporter.set_path and the methods that get called on the editor inside reporter.finish [19:22] same calls to set_path / finish give different calls on the editor. [19:22] Snaury, those callbacks are called by Subversion [19:22] Snaury, and are just wrapped by the bindings, there's no logic there [19:23] jelmer: I know. And that's why it's strange. Because same calls should lead to same callbacks. Yet with 1.4.11 we get add_file('LICENSE'), which shouldn't be there. [19:26] Snaury, does this problem occur against other repositories as well? [19:28] Snaury, I can't reproduce it, that makes it very hard for me to fix :-/ [19:29] jelmer: I found an interesting bit. 0.4.10 was calling conn.reparent, 0.4.11 no longer does it. Why? [19:29] Snaury, because in 0.4.11 the connection is already at the right URL [19:31] jelmer: are you on Windows? [19:31] Snaury, no, on Linux [19:33] jelmer: I can reproduce it with any subversion tree, when there is a single reporter.set_path for "" only, then it give a whole tree instead of delta. [19:34] Yet that's how 0.4.10 was doing things, and it always worked. [19:36] Snaury, Somebody else reported that the multiple set_path calls were necessary before the bindings were introduced [19:38] Sorry, that was actually after it was introduced [19:42] jelmer: patched 0.4.10 to call reporter.set_path on all items in the inventory. Not only it still works, it also works fast. [19:42] jelmer: I guess I'll just have to keep using bzr 1.5 until I port bzr-svn back to pysvn. :( [19:43] Snaury, bzr-svn needs features that aren't provided by pysvn [19:43] Snaury, that's one of the reasons for going with the bindings [19:44] jelmer: what are those features? [19:45] does anyone have a link to an explaination on how to what are and how to use stacked branches? [19:46] Snaury, https with untrusted certificates, for example [19:46] access of svn working copies [19:47] Snaury, with a bit of luck somebody else will figure out what's going wrong on Windows [19:48] jelmer: or could it be something related to svn 1.5? what subversion version are you testing with? [19:48] I'm using 1.5.1 [19:48] jelmer: unfortunately I couldn't compile bzr-svn against subversion 1.4.5, ld just keeps crashing for some reason. :-/ [19:49] Snaury, can you perhaps add a printf in ra.c:124 to check that path and revision arrive correctly? [19:50] jelmer: gcc version? [19:50] Snaury, 4.3 [19:50] same here... :-/ [19:51] Snaury, 32 bit platform? [19:51] yes [19:54] Snaury, ah [19:54] Snaury, another idea [19:54] Snaury: in stdbool.h, can you change the typedef to "typedef char bool;" ? [19:54] enum will default to int, that may cause strange issues [19:56] God damn it. %) [19:56] I found out the same thing. :) [19:57] that bool start_empty turns out to be always true. :-/ [19:57] does it help to make bool a char? [19:58] Yes indeed. That's the API problem. bool and "b" don't mix. [20:00] Perhaps it works on Linux because it was somehow initialized with zeroes? [20:01] stdbool.h from the system should be included on Linux, rather than the one in the local directory [20:02] Ouch. enum { false, true } is size 4. x_x [20:02] I've pushed a fix that changes it to char [20:04] please let me know if it's indeed the problem [20:04] and if changing it to char helps [20:10] Yeah, it finally works. ;) [20:10] (I also changed to "stdbool.h", because mingw has stdbool.h) [20:12] Ouch. But sizeof(bool) in mingw is 1, so how come it was including the one in current directory?! O.o [20:13] I think there is magic in setup.py to do that if you run it on Windows [20:14] Snaury, yep, it automatically adds "." to the current directory if os.name == "nt" [20:15] s/current directory/include directories/ [20:16] thanks for tracking that bug down though, that was an odd one [20:16] Damn. I wonder if with Visual Studio there would be no problem?.. [20:17] Snaury: It's there as well - the guy who did the patch that calls set_path() for every path in the inventory was working on Visual Studio [20:20] I think it's time for a 0.4.12 release :-) [20:25] Yay for a bzr-svn release. :) [20:26] jelmer: don't suppose you could show me a list of the commands that you would use to setup a bzr repo that has project Foo with trunk, branches, and tags folders that look like how you would do it in svn? :) [20:26] pastebin [20:27] rocky, You mean how I would import into bzr from a repository like that? [20:27] no... no import [20:27] say you're creating a bzr repo from scratch, and you just want to setup a new Foo project and work with it similarly to how you would in svn [20:28] with separate trunk/branches folders [20:28] rocky: bzr init-repo Foo [20:28] cd Foo [20:28] bzr init-repo project; bzr init project/trunk [20:28] ah, that too... :P [20:28] ;) [20:29] rocky: just so you know, you shouldn't really need a tags folder [20:29] what if you're hosting multiple subprojects in that repo ... bzr init-repo base; bzr init Foo; bzr init Foo/trunk; bzr init Bar; bzr init Bar/trunk ? [20:29] rocky, no, just create a directory "Foo", no bzr init [20:30] bzr svn-import will automatically do this for you as well when you import :-) [20:30] of course... but i'm talking about from scratch now ;) [20:30] so why no bzr init Foo for the previous example? [20:30] jelmer: you wouldn't happen to know who's in charge of the OS X installer? [20:30] i'm trying to understand the "whys" ;) [20:30] rocky: because you don't want Foo to be a branch [20:30] rocky: As far as I know, there's not much to be gained by putting multiple projects in the same bzr repo. [20:30] it's merely a folder [20:30] rocky, bzr init is used for branches [20:31] rocky, there is no concept of a "project" in bzr [20:31] Pilky, verterok has something to do with it [20:31] interesting [20:31] Verterok: ping [20:32] jelmer: so if i were using trac-bzr to view what i did above as "base" and then just mkdir Foo and Bar ... they would show up in the trac browser? [20:32] rocky, yeah [20:33] which reminds me, how is trac-bzr these days? :) [20:33] there are a couple of things that need to be updated for 1.6 [20:33] oh :( [20:33] other than that, it's a bit slow but works quite well [20:34] Pilky: pong [20:34] we're using it for BitlBee and ctrlproxy with 1.5 I believe [20:34] Verterok: do you make the OS X installer for bzr? [20:34] wonder how it would scale ... i'm looking at offering bzr support for ClueMapper (cluemapper.org) so when creating new Trac projects it would automatically create matching bzr repos (right now it creates matching svn repos) [20:34] rocky: You might want to read bzr-trunk/doc/en/user-guide/shared_repository_layouts.txt [20:34] ToyKeeper: thanks for the pointer [20:35] Pilky: yes, only for 10.4 [20:35] * Verterok is working on the 1.6 DMG ATM [20:35] do you know who does it for 10.5? [20:36] Pilky: yes, phanatic build the 10.5 DMG [20:36] ah [20:36] Pilky: http://bazaar-vcs.org/MacOSXBundle :) [20:37] I'm just wondering because it seems to take a week or so for the Installers to come out for OS X :P [20:38] was wondering when the 1.6 installers would come out [20:38] Pilky: don't know about phanatic, but I've been quite busy... the past week. I'm trying to get it done for monday [20:40] Pilky: also for the moment, building the installer is almost completely manual :( [20:40] ah, not fun [20:40] Pilky: not at all :p [20:41] ToyKeeper: that info is great at showing you the structure of the options, and shows you when to "bzr init-repo" the toplevel repo, but it doesn't describe when you want "mkdir Foo" VS "bzr init Foo" [20:42] If Foo is a branch, then bzr init Foo. If it's just a directory, then mkdir Foo. [20:43] Like, I have a dir called 'merged' where I move old merged branches to. 'merged' isn't a branch, but the items inside it are. [20:43] Generally, you probably won't need to 'bzr init Foo' much, because you'll be running 'bzr branch trunk Foo' instead. [20:43] right [20:44] that makes sense [20:44] that of course does mean the management of branches (ie moving them around, etc) isn't versioned, but i dunno yet if that matters ;) [20:45] The branch name is recorded for each commit, at least. So, you can see that a branch started out as 'blah' then became 'fnorg' before it was eventually merged. [20:50] jelmer: do you know which branch of bzr-email should I use? (I'm packaging 1.6 for OS X 10.4) [20:50] Verterok, I would just use trunk [20:50] jelmer: ok, thanks :) [20:51] that's at least what I package for Debian [20:52] jelmer: trunk 'll be , thanks :) [20:53] * Verterok wonders if it's time to make a 0.1 release [21:12] jelmer: bzr-svn 0.4.11 works with 1.6? [21:12] Verterok, yep [21:12] thanks [21:12] just asking, because I'm getting some errors with bzr.dev [21:14] with 0.4.11? That's right, bzr.dev broke cloning_metadir() [21:14] yep, exactly that [21:44] * ToyKeeper looks forward to new bzr and bzr-svn packages in debian [21:44] ... I have a few dozen svn repos on my scm server waiting to be converted, and it looks like it can happen soon. :) [21:46] what is the equivalent of git reset --hard HEAD? how can i reset the changes represented in bzr diff? [21:46] dmoerner, bzr revert [21:46] thank you [21:49] ToyKeeper, they're already there [21:51] jelmer: I just updated, and debian/unstable has bzr 1.5-1.1 [21:51] ToyKeeper, ah, you need experimental [21:52] unstable is kept clear for things that will make it into lenny [21:52] Oh yeah, debian always gets funky around release time. [21:53] There it is. I'm running mostly testing, and hadn't added experimental yet. [21:57] * ToyKeeper <3 apt pinning [22:24] ToyKeeper, strange btw, for some reason I was under the impression you were an Ubuntu developer [22:25] Nah, I started but got too distracted to follow through with it. [22:27] Mundane 'real life' issues keep popping up, so I've had to limit myself to drive-by bugfixes and small projects. [22:32] ToyKeeper: the various bits and pieces you've contributed to bzr and subprojects are very much appreciated [22:35] Ooh, sweet. bzr-svn picked up tags when I pulled today. [22:37] yeah, it does that now [22:58] In any case, bzr is a better svn client than svn itself. :) [23:02] hello [23:02] hey jml [23:02] happy monday [23:02] urgh [23:03] * jml doesn't like Mondays. [23:03] actually, that's a lie. [23:03] I don't like *mornings*. [23:06]