[00:01] ack I just did a revert when I didn't mean to. Can I undo that? [00:02] nv I found a way to fix it [00:17] I would like to know if there is a place where the installation/configuration of loggerhead is documented [00:18] In fact I am looking for a bzr branch explorer [00:18] Based on what I read on Internet it seems that loggerhead is the defacto standard for this === toytoy_ is now known as toytoy [02:28] is there a way to convert an existing repository to use --no-trees? [02:30] yes, bzr remove-tree [03:36] Could one have a ``safepoint'' commit that doesn't show up in the commit log, but only acts as an ``Oh !&^#%, why did I do that... at least I can revert to what I had 5 minutes ago instead of having to revert to the previous commit''... or should I just commit more often? [03:37] Use case: When you're trying to fix something through trial and error [04:49] ryanakca: well, you can commit and then later uncommit then commit again. [04:49] ryanakca: But really, why not just keep the commit? [04:52] spiv: well, if you're going by trial and error, you might endup with 3-4 ``safepoints'' that are absolute rubbish and have no use in a commit log, at least not in a public one :) [04:54] ryanakca: maybe. They might not be totally worthless, and there isn't much harm from leaving them there. [04:54] spiv: *nod* [04:55] ryanakca: especially if this is happening on a branch, when the branch is merged to trunk the details of how that branch evolved aren't very prominent in the history. [04:56] If you're working directly on trunk then that's a different matter, but then I'd argue you should be taking advantage of a DVCS and using branches instead :) [04:56] You could even manage your experimental work on your branch as another branch, but that workflow is probably a bit too heavyweight for what you're after. [05:04] spiv: well, I'm the only one working on it at the moment... but it will eventually end up being used in my school, and most likely other schools in my school board... [05:04] spiv: Anyways, I probably ought to branch when I go by trial and error :) [05:04] G'night :) [05:04] ryanakca: g'afternoon ;) [05:04] (It's a bright and sunny 4pm here in Sydney) === Spaz is now known as Spazscissors === Spazscissors is now known as Spaznuclearbomb === Spaznuclearbomb is now known as Spaz [08:06] * thumper votes for default log to be short (no merge details) [08:07] thumper: bzr alias log="log --short" [08:07] spiv: yes I know# [08:07] :) [08:07] spiv: I'm thinking of all the new users [08:08] all those people who go "gee bzr log is slow compared to xyz" [08:08] "Won't somebody think of the newbies?" [08:08] spiv: that way people can go "bzr log --merges" to show merges (or something) [08:08] (Sunday afternoon perhaps not the best time to get a completely serious opinion from me) [08:09] and they can take the hit of the graph sort or whatever [08:09] * thumper was reading traceback [08:10] We don't get many people saying the log is slow (although we do get some). And arguably the solution there is to make it fast, not change the output. [08:11] spiv: yeah, but one is easier and allows for better comparison of apples [08:11] I do think the default log should make the existence of merges visible, so that the way merges are tracked is reasonably discoverable. [08:11] * thumper goes to make brownies [08:11] Well, we're not trying to build a tool that's the same as $other_vcs, we're trying to build a better tool :) [08:11] So I don't think that's automatically a good reason to change how we work. [08:12] a better tool that interoperates so I can pull stuff from github? [08:12] Personally I use --line most of the time. [08:12] I think someone should check to see who actually cares to see the merges by default [08:12] spiv: I use --line too [08:12] hiredman: that is in progress [08:13] * thumper really leaves now [08:13] I know [08:13] I am just being an asshole today [08:13] And then "bzr viz" for more in-depth exploration of history, but not every user will have the bzr-gtk plugin (or the ability to install it). === jszakmeister is now known as jszakmeister|awa [13:27] Hi, how do I cleanup the .~n~ files? [13:43] $ find . -name '*~*' [13:43] $ find . -name '*~*' | xargs rm === Spaz is now known as Kittens [13:50] better: find . -name "*~*" -print0 | xargs -0 rm [13:56] brb [14:22] beuno: hmm, I wouldn't say I'm the mastermind [14:22] marcus-b: hey! :) [14:24] epsy, marcus-b: `bzr clean-tree --detritus` would also remove the .~n~ files [14:32] LarstiQ: I don't know bzr well, but I do know my unix tools :) [14:32] * LarstiQ nods [15:05] hi hi [15:14] Hello i'm trying to run bzr+ssh. I've created directory on server, and i have entry in authorized-keys to copy files without giving passwords, but when i try to init repo i get error: http://wklej.to/MV3 (when i use scp to copy files it works) === fta_ is now known as fta === jszakmeister is now known as jszakmeister|awa [16:01] I just got a commit error regarding x11 initialisation whilst commiting via SSH [16:01] I installed extdiff earlier. Perhaps that's causing the issues? [16:11] I've got a large branch I've cloned from a remote source, and now i'm wishing I'd created a repository for it to go in. Is too late? Can I create a repo without having to re-fetch all that history? [16:17] create a new repo and then fetch from the one you cloned locally [16:17] oh. of course :) [16:17] my commit actions etc are causing "X11 initialization failed" errors when used via SSH [16:18] CaMason_: no idea, sorry [16:22] it was a problem with dbus. Removing it, as I don't use it [16:28] marcus-b: 'find . -name "*~*" -print0 | xargs -0 rm' vs 'find . -name "*~*" -exec rm {} \;' ? Hmm =/ [16:44] I am attempting to branch from an svn repo on sourceforge, using bzr-svn [16:45] and i'm consistently getting "Could not read response body: Connection reset by peer" after several minutes [16:45] is there something I can do to make bzr not give up so easily? :) [16:45] dash, it's the svn libraries that are giving up [16:45] dash, are you fetching over https? [16:45] jelmer: no. [16:46] your best bet is probably to wait until the sf svn servers are less heavily loaded [16:47] I suspect a contributing factor is that /trunk (which I am branching from) in this repository was moved from a different url in an early revision [16:47] different path, I mean [16:47] that shouldn't be relevant [16:47] well [16:47] it looks like bzr-svn does a lot of PROPFINDs for nonexistent paths [16:47] I didn't know if that mattered. [16:48] you mean it's actually getting 404's back? [16:48] yes [16:49] what's the URL you're trying to import? [16:49] http://posterita.svn.sourceforge.net/svnroot/posterita/trunk [16:51] so i'm seeing a lot of things like "PROPFIND /svnroot/posterita/trial/posterita" [16:51] to which 404s are given [16:52] I'm just guessing that this is making it take longer, so make it have more chance to disconnect :) [16:54] it doesn't ignore unexpected errors like that, I suspect that's all happening deep down in the svn libraries [16:55] right [17:22] dash, it seems to be working with the 0.5 branch for me, though it's very slow because of sf [17:23] aha, the secret version ;) [17:23] well i'm not in a hurry, I just want to get it eventually. [17:25] hmm if that were true I would just wait until 0.5 was released [17:26] I guess I am in a hurry, a little. [17:40] jelmer: so, think I should try 0.5? [19:37] moin [20:33] ah lifeless, you back this week right? [20:35] lifeless: can I have a quick voice call with you? [20:37] sure [20:37] skype, now? [20:38] ok [20:41] ?win 38 === tetha_ is now known as tetha [21:11] Peng: I wonder if I could convince you to do me a favour? [21:11] lifeless: I dunno. What's the favor? :) [21:11] Peng: to decide on a good batch size, I need a graph with two measurements, for different batch sizes, and different project sizes [21:11] the measurements are memory peak, and time [21:12] I did that for a few different sizes on a copy of bzr.dev. [21:12] the axes are group_size and project_size [21:12] Peng_: yah, which I am thankful for, and is why I know I need to fix it [21:13] Peng_: but I don't currently know things like 'how bad is it at 1000 on openoffice' [21:13] Peng_: nor what the minima for bzr.dev is. [21:13] OpenOffice.org? I imagine that's "Peng's machine would die swapping" bad. :P [21:13] Peng_: so I'm thinking of a little script to reindex a branch several times with a different group size, and report the results in csv or similar output [21:14] Peng_: of course, I'll run this on a canonical datacentre machine [21:14] Peng_: the favour is to write the script [21:14] Ah. [21:15] then I can throw it at ooo, at mysql, at bzr, at bzrtools [21:16] Peng_: if you are interested this would be really useful. [21:18] I'm sure I could write some little hack of a script, but I dunno if you'd like it. :P [21:18] I guess it would need to be possible to set group_size. I just edited index.py a bunch of times. [21:19] Peng_: just has to work. Heck, I was considering a massive printf to replace the index.py file [21:19] Peng_: sed would probably be nicer :P [21:22] Or making it an attribute on Index objects that you could change from Python. [21:23] hi poolie [21:23] Peng_: sure. [21:23] Peng_: or even - shock - a global [21:24] so you don't have to get access to a specific index [21:25] Oh, different methods have different group_sizes. [21:26] yeah there are two [21:26] there is 'how many revisions', where the inventory text size will chew up memory [21:27] and there is 'how many file versions at once', where text sizes (isos!) will chew up memory [21:29] I've never changed it in _terms_for_file_terms. [21:29] sure [21:29] whats in my head is to not guess about what works well for users [21:29] but to graph it out, and choose the place that works best [21:30] the two group sizes are independent [21:30] well, not quite. [21:30] Well...do you want to test both, or just the _index_revisions one? [21:30] the file terms is capped by the index revisions one (can't index morefile changes than occured in a given set of revisions) [21:30] I'd start with the index revisions one, that should give plenty of data [21:31] though it may be confounded (a large index revisions one might use little memory, if the file terms one is driving the peak) [21:32] does anyone have any recommendations for good conflict resolution tools? [21:33] guns [21:33] lots and lots of guns [21:33] It worked in the matrix. [21:33] hmm [21:34] i think i want meld and a much larger monitor [21:35] sdiff/ediff in emacs is nice if you already use emacs [21:36] ediff confuses me a bit [21:36] what's sdiff? [21:36] i think the problem is that one branch has moved things around and the other has made small edits to the things being moved [21:37] simple mode that highlights in-file conflicts, with some keybindings to pick one or the other or both for each hunk [21:38] ah, out of that league, then [22:08] spiv: shall we converse? [22:18] lifeless: spiv is away at osdc today [22:18] you and i could talk though [22:18] oh! [22:18] didn't realise osdc was here [22:18] should I go down? [22:19] poolie: you're on leave no? but perhaps a quick call could be useful [22:19] poolie: I'll ring your house? [22:19] poolie: osdc doesn't start till tomorrow? Or is spiv on the org committee or similar? [22:20] yes, call [22:20] osdc starts for realz on wes [22:20] weds [22:21] spiv just took the week off anyway i think [22:26] planning to look at bug 302698 [22:26] Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698 [22:44] lifeless: OK, I wrote an evil little script for the bzr-search thing. I hope you weren't joking about running "sed" over index.py. ;) [22:44] lifeless: Also, if it gets interrupted, things will probably be left in a horrible mess. [22:44] hmm, does anyone here know (and is willing to explain) the difference between a transplant and a normal merge, or do I need to pester #hg? [22:46] mathrick: AIUI, transplants can cherrypick, but it'll create a different revision with different revids and parents and whatever. [22:46] (if we're talking about hg) [23:00] Peng_: hmm, I'll guess I'll just ask the hg guys then [23:02] Good idea. :) [23:14] Peng_: thanks! [23:15] poolie: I need to shoot off to the doctors too today, I forgot to mention it in all the kufuffle [23:16] any idea how hard it'd be to implement "add-on branches" (as mentioned in https://lists.ubuntu.com/archives/bazaar/2008q4/050022.html )? It strikes me as something you'd really want to have to keep your distro work in sync with upstream [23:16] or is there something I'm not seeing that makes it not a good / redundant idea? [23:19] lifeless: http://paste.pocoo.org/show/YkaM3FCdH5ILeNUOlV0h/ -- did I mention that it's an evil dirty hack and you probably won't like it? :) [23:19] * Peng_ is trying to lower expectations as much as possible. [23:19] mathrick: it's probably not technically super hard, more a matter of deciding how you want it to work [23:19] robert's idea of having marks of files or regions would probably be good [23:20] poolie: oh, link? [23:20] also, I was thinking about strands of development a'la threads in loom [23:20] just with the opposite effect on your working area [23:20] mathrick: using a loom and cherrypicking down would do it [23:21] lifeless: could you elaborate? I tried to use loom, but decided it does exactly what I don't want with the history when I change threads [23:21] mathrick: well the root problem you have is that its impossible to do a full merge/push from 'development' to 'mainline' *excluding data*. [23:21] yes [23:21] full merge/push always include everything committed [23:22] so you have to cherrypick repeated - do merges specifying paths to merge, or specific revisions [23:23] yup [23:25] I could do it using loom by hand, but it'd require me to switch between threads to get "development" and "testing" views all the time, which is a pain [23:25] Peng_: sweet [23:25] ie. I couldn't actually run any code when in development thread, and I couldn't edit any when in testing thread [23:26] mathrick: I don't understand why you couldn't run code [23:26] lifeless: sec, lemme sketch that [23:33] lifeless: http://pastebin.com/m23f854c8 [23:37] mathrick: edit and commit in testing [23:37] lifeless: but then the changes will be only visible in testing, which means the pushes won't see them. They will be treated as if they were my local conf changes [23:37] mathrick: when you are done, you can go to main, merge -r testing path1 path2 [23:38] hmm, lemme parse that [23:38] what's path1 and path2? [23:38] mathrick: you have to cherry pick testing to main, regardless of the toolchain you use, for your stated desire [23:38] paths that you want to merge within the branch [23:38] another way of spelling it is [23:38] switch main; merge -r thread:testing [23:38] bzr revert --forget-merges [23:39] bzr revert server.conf [23:39] bzr commit -m 'whatever' [23:39] mathrick: have you considered 'shelve' though? [23:39] right, but that's exactly what I wanted to avoid. It's heaps of manual work, and if I forget it only once, I have unwanted commits in the mainline I have to deal with [23:40] hence the desire to have a tool which keeps track of what I want and don't want to merge for me [23:41] loom is very nice for when you only merge downstream, but it fails to enable a nice workflow for pushes to the upstream without polluting them with distro patches [23:41] mathrick: so, loom isn't finished; I think this would be great to have streamlined in loom [23:41] there are missing components in bzr core to do a *great* job, but a servicable one should be doable [23:42] lifeless: right, I'd love to have it in loom, although it'd really turn it upside down in some regards [23:42] the current theory is that you would keep one or more threads for 'never send upstream' [23:42] as for how you do the commits, I'd like a commit like 'commit -t main' [23:42] to commit a change to a specific thread [23:43] right [23:43] it probably would want to merge-it-up on the fly [23:43] what does merge-it-up mean? [23:44] now, for something completely different, I have a repo that bzr serve completely dies on -- it uses 500+ MB RAM, then dies with some exceptions when clients try to access the repo. How do I debug it? [23:44] merge each thread to the one above, so that the change does not appear as a change any more [23:44] I guess I'll start for finding 1.9 debs for intrepid [23:45] mathrick: well, firstly, newer bzr has fixed some memory issues from 1.6/1.7/1.8 [23:45] mathrick: file a bug with the exceptions though [23:46] lifeless: you mean before I upgrade to 1.9? [23:46] yah [23:46] ok [23:46] if the server side is dying [23:46] (and the server is already running 1.9) [23:46] no, that's the 1.6 [23:46] upgrade the server first then [23:46] I'm trying to serve from my machine [23:47] there are debs in the bzr ppa [23:53] oh, interesting [23:53] it dies right away now [23:54] http://pastebin.com/d73b4f039 [23:55] mathrick: ugh [23:55] mathrick: uhm, can you run with BZR_PDB=1 [23:55] sure [23:55] then you can print self._sockname [23:56] (Pdb) self._sockname [23:56] ('::', 4155, 0, 0) [23:56] humm [23:56] I'd certainly start by filing a bug, but it does look ... odd [23:56] it's getting an ipv6 socket? [23:57] yeah that would fit [23:57] definitely file that bug [23:57] will do [23:57] still, it'd be useful if I could serve in the meantime :) [23:59] comment out that line, or just print the _sockname, rather than prettyising it [23:59] e.g. [23:59] return "%s" % self._sockname