| CaMason_ | ack I just did a revert when I didn't mean to. Can I undo that? | 00:01 |
|---|---|---|
| CaMason_ | nv I found a way to fix it | 00:02 |
| ym1 | I would like to know if there is a place where the installation/configuration of loggerhead is documented | 00:17 |
| ym1 | In fact I am looking for a bzr branch explorer | 00:18 |
| ym1 | Based on what I read on Internet it seems that loggerhead is the defacto standard for this | 00:18 |
| === toytoy_ is now known as toytoy | ||
| GPHemsley | is there a way to convert an existing repository to use --no-trees? | 02:28 |
| evarlast | yes, bzr remove-tree | 02:30 |
| ryanakca | 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:36 |
| ryanakca | Use case: When you're trying to fix something through trial and error | 03:37 |
| spiv | ryanakca: well, you can commit and then later uncommit then commit again. | 04:49 |
| spiv | ryanakca: But really, why not just keep the commit? | 04:49 |
| ryanakca | 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:52 |
| spiv | ryanakca: maybe. They might not be totally worthless, and there isn't much harm from leaving them there. | 04:54 |
| ryanakca | spiv: *nod* | 04:54 |
| spiv | 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:55 |
| spiv | 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 |
| spiv | 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. | 04:56 |
| ryanakca | 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 |
| ryanakca | spiv: Anyways, I probably ought to branch when I go by trial and error :) | 05:04 |
| ryanakca | G'night :) | 05:04 |
| spiv | ryanakca: g'afternoon ;) | 05:04 |
| spiv | (It's a bright and sunny 4pm here in Sydney) | 05:04 |
| === Spaz is now known as Spazscissors | ||
| === Spazscissors is now known as Spaznuclearbomb | ||
| === Spaznuclearbomb is now known as Spaz | ||
| * thumper votes for default log to be short (no merge details) | 08:06 | |
| spiv | thumper: bzr alias log="log --short" | 08:07 |
| thumper | spiv: yes I know# | 08:07 |
| spiv | :) | 08:07 |
| thumper | spiv: I'm thinking of all the new users | 08:07 |
| thumper | all those people who go "gee bzr log is slow compared to xyz" | 08:08 |
| spiv | "Won't somebody think of the newbies?" | 08:08 |
| thumper | spiv: that way people can go "bzr log --merges" to show merges (or something) | 08:08 |
| spiv | (Sunday afternoon perhaps not the best time to get a completely serious opinion from me) | 08:08 |
| thumper | and they can take the hit of the graph sort or whatever | 08:09 |
| * thumper was reading traceback | 08:09 | |
| spiv | 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:10 |
| thumper | spiv: yeah, but one is easier and allows for better comparison of apples | 08:11 |
| spiv | 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 | |
| spiv | 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 |
| spiv | So I don't think that's automatically a good reason to change how we work. | 08:11 |
| hiredman | a better tool that interoperates so I can pull stuff from github? | 08:12 |
| spiv | Personally I use --line most of the time. | 08:12 |
| thumper | I think someone should check to see who actually cares to see the merges by default | 08:12 |
| thumper | spiv: I use --line too | 08:12 |
| thumper | hiredman: that is in progress | 08:12 |
| * thumper really leaves now | 08:13 | |
| hiredman | I know | 08:13 |
| hiredman | I am just being an asshole today | 08:13 |
| spiv | 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). | 08:13 |
| === jszakmeister is now known as jszakmeister|awa | ||
| epsy | Hi, how do I cleanup the .~n~ files? | 13:27 |
| AfC | $ find . -name '*~*' | 13:43 |
| AfC | $ find . -name '*~*' | xargs rm | 13:43 |
| === Spaz is now known as Kittens | ||
| marcus-b | better: find . -name "*~*" -print0 | xargs -0 rm | 13:50 |
| epsy | brb | 13:56 |
| LarstiQ | beuno: hmm, I wouldn't say I'm the mastermind | 14:22 |
| LarstiQ | marcus-b: hey! :) | 14:22 |
| LarstiQ | epsy, marcus-b: `bzr clean-tree --detritus` would also remove the .~n~ files | 14:24 |
| marcus-b | LarstiQ: I don't know bzr well, but I do know my unix tools :) | 14:32 |
| * LarstiQ nods | 14:32 | |
| pygi | hi hi | 15:05 |
| DimmuR | 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) | 15:14 |
| === fta_ is now known as fta | ||
| === jszakmeister is now known as jszakmeister|awa | ||
| CaMason_ | I just got a commit error regarding x11 initialisation whilst commiting via SSH | 16:01 |
| CaMason_ | I installed extdiff earlier. Perhaps that's causing the issues? | 16:01 |
| dash | 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:11 |
| pbor | create a new repo and then fetch from the one you cloned locally | 16:17 |
| dash | oh. of course :) | 16:17 |
| CaMason_ | my commit actions etc are causing "X11 initialization failed" errors when used via SSH | 16:17 |
| pbor | CaMason_: no idea, sorry | 16:18 |
| CaMason_ | it was a problem with dbus. Removing it, as I don't use it | 16:22 |
| ryanakca | marcus-b: <offtopic> 'find . -name "*~*" -print0 | xargs -0 rm' vs 'find . -name "*~*" -exec rm {} \;' ? </offtopic | 16:28 |
| dash | Hmm =/ | 16:44 |
| dash | I am attempting to branch from an svn repo on sourceforge, using bzr-svn | 16:44 |
| dash | and i'm consistently getting "Could not read response body: Connection reset by peer" after several minutes | 16:45 |
| dash | is there something I can do to make bzr not give up so easily? :) | 16:45 |
| jelmer | dash, it's the svn libraries that are giving up | 16:45 |
| jelmer | dash, are you fetching over https? | 16:45 |
| dash | jelmer: no. | 16:45 |
| jelmer | your best bet is probably to wait until the sf svn servers are less heavily loaded | 16:46 |
| dash | 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 |
| dash | different path, I mean | 16:47 |
| jelmer | that shouldn't be relevant | 16:47 |
| dash | well | 16:47 |
| dash | it looks like bzr-svn does a lot of PROPFINDs for nonexistent paths | 16:47 |
| dash | I didn't know if that mattered. | 16:47 |
| jelmer | you mean it's actually getting 404's back? | 16:48 |
| dash | yes | 16:48 |
| jelmer | what's the URL you're trying to import? | 16:49 |
| dash | http://posterita.svn.sourceforge.net/svnroot/posterita/trunk | 16:49 |
| dash | so i'm seeing a lot of things like "PROPFIND /svnroot/posterita/trial/posterita" | 16:51 |
| dash | to which 404s are given | 16:51 |
| dash | I'm just guessing that this is making it take longer, so make it have more chance to disconnect :) | 16:52 |
| jelmer | it doesn't ignore unexpected errors like that, I suspect that's all happening deep down in the svn libraries | 16:54 |
| dash | right | 16:55 |
| jelmer | dash, it seems to be working with the 0.5 branch for me, though it's very slow because of sf | 17:22 |
| dash | aha, the secret version ;) | 17:23 |
| dash | well i'm not in a hurry, I just want to get it eventually. | 17:23 |
| dash | hmm if that were true I would just wait until 0.5 was released | 17:25 |
| dash | I guess I am in a hurry, a little. | 17:26 |
| dash | jelmer: so, think I should try 0.5? | 17:40 |
| lifeless | moin | 19:37 |
| thumper | ah lifeless, you back this week right? | 20:33 |
| thumper | lifeless: can I have a quick voice call with you? | 20:35 |
| lifeless | sure | 20:37 |
| lifeless | skype, now? | 20:37 |
| thumper | ok | 20:38 |
| lifeless | ?win 38 | 20:41 |
| === tetha_ is now known as tetha | ||
| lifeless | Peng: I wonder if I could convince you to do me a favour? | 21:11 |
| Peng_ | lifeless: I dunno. What's the favor? :) | 21:11 |
| lifeless | 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 |
| lifeless | the measurements are memory peak, and time | 21:11 |
| Peng_ | I did that for a few different sizes on a copy of bzr.dev. | 21:12 |
| lifeless | the axes are group_size and project_size | 21:12 |
| lifeless | Peng_: yah, which I am thankful for, and is why I know I need to fix it | 21:12 |
| lifeless | Peng_: but I don't currently know things like 'how bad is it at 1000 on openoffice' | 21:13 |
| lifeless | Peng_: nor what the minima for bzr.dev is. | 21:13 |
| Peng_ | OpenOffice.org? I imagine that's "Peng's machine would die swapping" bad. :P | 21:13 |
| lifeless | 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:13 |
| lifeless | Peng_: of course, I'll run this on a canonical datacentre machine | 21:14 |
| lifeless | Peng_: the favour is to write the script | 21:14 |
| Peng_ | Ah. | 21:14 |
| lifeless | then I can throw it at ooo, at mysql, at bzr, at bzrtools | 21:15 |
| lifeless | Peng_: if you are interested this would be really useful. | 21:16 |
| Peng_ | I'm sure I could write some little hack of a script, but I dunno if you'd like it. :P | 21:18 |
| Peng_ | I guess it would need to be possible to set group_size. I just edited index.py a bunch of times. | 21:18 |
| lifeless | Peng_: just has to work. Heck, I was considering a massive printf to replace the index.py file | 21:19 |
| lifeless | Peng_: sed would probably be nicer :P | 21:19 |
| Peng_ | Or making it an attribute on Index objects that you could change from Python. | 21:22 |
| lifeless | hi poolie | 21:23 |
| lifeless | Peng_: sure. | 21:23 |
| lifeless | Peng_: or even - shock - a global | 21:23 |
| lifeless | so you don't have to get access to a specific index | 21:24 |
| Peng_ | Oh, different methods have different group_sizes. | 21:25 |
| lifeless | yeah there are two | 21:26 |
| lifeless | there is 'how many revisions', where the inventory text size will chew up memory | 21:26 |
| lifeless | and there is 'how many file versions at once', where text sizes (isos!) will chew up memory | 21:27 |
| Peng_ | I've never changed it in _terms_for_file_terms. | 21:29 |
| lifeless | sure | 21:29 |
| lifeless | whats in my head is to not guess about what works well for users | 21:29 |
| lifeless | but to graph it out, and choose the place that works best | 21:29 |
| lifeless | the two group sizes are independent | 21:30 |
| lifeless | well, not quite. | 21:30 |
| Peng_ | Well...do you want to test both, or just the _index_revisions one? | 21:30 |
| lifeless | 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 |
| lifeless | I'd start with the index revisions one, that should give plenty of data | 21:30 |
| lifeless | though it may be confounded (a large index revisions one might use little memory, if the file terms one is driving the peak) | 21:31 |
| mwhudson | does anyone have any recommendations for good conflict resolution tools? | 21:32 |
| lifeless | guns | 21:33 |
| lifeless | lots and lots of guns | 21:33 |
| lifeless | It worked in the matrix. | 21:33 |
| mwhudson | hmm | 21:33 |
| mwhudson | i think i want meld and a much larger monitor | 21:34 |
| bob2 | sdiff/ediff in emacs is nice if you already use emacs | 21:35 |
| mwhudson | ediff confuses me a bit | 21:36 |
| mwhudson | what's sdiff? | 21:36 |
| mwhudson | 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:36 |
| bob2 | simple mode that highlights in-file conflicts, with some keybindings to pick one or the other or both for each hunk | 21:37 |
| bob2 | ah, out of that league, then | 21:38 |
| lifeless | spiv: shall we converse? | 22:08 |
| poolie | lifeless: spiv is away at osdc today | 22:18 |
| poolie | you and i could talk though | 22:18 |
| lifeless | oh! | 22:18 |
| lifeless | didn't realise osdc was here | 22:18 |
| lifeless | should I go down? | 22:18 |
| lifeless | poolie: you're on leave no? but perhaps a quick call could be useful | 22:19 |
| lifeless | poolie: I'll ring your house? | 22:19 |
| spm | poolie: osdc doesn't start till tomorrow? Or is spiv on the org committee or similar? | 22:19 |
| poolie | yes, call | 22:20 |
| mwhudson | osdc starts for realz on wes | 22:20 |
| mwhudson | weds | 22:20 |
| mwhudson | spiv just took the week off anyway i think | 22:21 |
| poolie | planning to look at bug 302698 | 22:26 |
| ubottu | Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698 | 22:26 |
| Peng_ | 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 |
| Peng_ | lifeless: Also, if it gets interrupted, things will probably be left in a horrible mess. | 22:44 |
| mathrick | 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:44 |
| Peng_ | mathrick: AIUI, transplants can cherrypick, but it'll create a different revision with different revids and parents and whatever. | 22:46 |
| Peng_ | (if we're talking about hg) | 22:46 |
| mathrick | Peng_: hmm, I'll guess I'll just ask the hg guys then | 23:00 |
| Peng_ | Good idea. :) | 23:02 |
| lifeless | Peng_: thanks! | 23:14 |
| lifeless | poolie: I need to shoot off to the doctors too today, I forgot to mention it in all the kufuffle | 23:15 |
| mathrick | 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 |
| mathrick | or is there something I'm not seeing that makes it not a good / redundant idea? | 23:16 |
| Peng_ | 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 | |
| poolie | mathrick: it's probably not technically super hard, more a matter of deciding how you want it to work | 23:19 |
| poolie | robert's idea of having marks of files or regions would probably be good | 23:19 |
| mathrick | poolie: oh, link? | 23:20 |
| mathrick | also, I was thinking about strands of development a'la threads in loom | 23:20 |
| mathrick | just with the opposite effect on your working area | 23:20 |
| lifeless | mathrick: using a loom and cherrypicking down would do it | 23:20 |
| mathrick | 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 |
| lifeless | 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 |
| mathrick | yes | 23:21 |
| lifeless | full merge/push always include everything committed | 23:21 |
| lifeless | so you have to cherrypick repeated - do merges specifying paths to merge, or specific revisions | 23:22 |
| mathrick | yup | 23:23 |
| mathrick | 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 |
| lifeless | Peng_: sweet | 23:25 |
| mathrick | ie. I couldn't actually run any code when in development thread, and I couldn't edit any when in testing thread | 23:25 |
| lifeless | mathrick: I don't understand why you couldn't run code | 23:26 |
| mathrick | lifeless: sec, lemme sketch that | 23:26 |
| mathrick | lifeless: http://pastebin.com/m23f854c8 | 23:33 |
| lifeless | mathrick: edit and commit in testing | 23:37 |
| mathrick | 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 |
| lifeless | mathrick: when you are done, you can go to main, merge -r testing path1 path2 | 23:37 |
| mathrick | hmm, lemme parse that | 23:38 |
| mathrick | what's path1 and path2? | 23:38 |
| lifeless | mathrick: you have to cherry pick testing to main, regardless of the toolchain you use, for your stated desire | 23:38 |
| lifeless | paths that you want to merge within the branch | 23:38 |
| lifeless | another way of spelling it is | 23:38 |
| lifeless | switch main; merge -r thread:testing | 23:38 |
| lifeless | bzr revert --forget-merges | 23:38 |
| lifeless | bzr revert server.conf | 23:39 |
| lifeless | bzr commit -m 'whatever' | 23:39 |
| lifeless | mathrick: have you considered 'shelve' though? | 23:39 |
| mathrick | 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:39 |
| mathrick | hence the desire to have a tool which keeps track of what I want and don't want to merge for me | 23:40 |
| mathrick | 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 |
| lifeless | mathrick: so, loom isn't finished; I think this would be great to have streamlined in loom | 23:41 |
| lifeless | there are missing components in bzr core to do a *great* job, but a servicable one should be doable | 23:41 |
| mathrick | lifeless: right, I'd love to have it in loom, although it'd really turn it upside down in some regards | 23:42 |
| lifeless | the current theory is that you would keep one or more threads for 'never send upstream' | 23:42 |
| lifeless | as for how you do the commits, I'd like a commit like 'commit -t main' | 23:42 |
| lifeless | to commit a change to a specific thread | 23:42 |
| mathrick | right | 23:43 |
| lifeless | it probably would want to merge-it-up on the fly | 23:43 |
| mathrick | what does merge-it-up mean? | 23:43 |
| mathrick | 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 |
| lifeless | merge each thread to the one above, so that the change does not appear as a change any more | 23:44 |
| mathrick | I guess I'll start for finding 1.9 debs for intrepid | 23:44 |
| lifeless | mathrick: well, firstly, newer bzr has fixed some memory issues from 1.6/1.7/1.8 | 23:45 |
| lifeless | mathrick: file a bug with the exceptions though | 23:45 |
| mathrick | lifeless: you mean before I upgrade to 1.9? | 23:46 |
| lifeless | yah | 23:46 |
| mathrick | ok | 23:46 |
| lifeless | if the server side is dying | 23:46 |
| lifeless | (and the server is already running 1.9) | 23:46 |
| mathrick | no, that's the 1.6 | 23:46 |
| lifeless | upgrade the server first then | 23:46 |
| mathrick | I'm trying to serve from my machine | 23:46 |
| lifeless | there are debs in the bzr ppa | 23:47 |
| mathrick | oh, interesting | 23:53 |
| mathrick | it dies right away now | 23:53 |
| mathrick | http://pastebin.com/d73b4f039 | 23:54 |
| lifeless | mathrick: ugh | 23:55 |
| lifeless | mathrick: uhm, can you run with BZR_PDB=1 | 23:55 |
| mathrick | sure | 23:55 |
| lifeless | then you can print self._sockname | 23:55 |
| mathrick | (Pdb) self._sockname | 23:56 |
| mathrick | ('::', 4155, 0, 0) | 23:56 |
| mathrick | humm | 23:56 |
| lifeless | I'd certainly start by filing a bug, but it does look ... odd | 23:56 |
| mathrick | it's getting an ipv6 socket? | 23:56 |
| lifeless | yeah that would fit | 23:57 |
| lifeless | definitely file that bug | 23:57 |
| mathrick | will do | 23:57 |
| mathrick | still, it'd be useful if I could serve in the meantime :) | 23:57 |
| lifeless | comment out that line, or just print the _sockname, rather than prettyising it | 23:59 |
| lifeless | e.g. | 23:59 |
| lifeless | return "%s" % self._sockname | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!