[00:01] <CaMason_> ack I just did a revert when I didn't mean to. Can I undo that?
[00:02] <CaMason_> nv I found a way to fix it
[00:17] <ym1> I would like to know if there is a place where the installation/configuration of loggerhead is documented
[00:18] <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
[02:28] <GPHemsley> is there a way to convert an existing repository to use --no-trees?
[02:30] <evarlast> yes, bzr remove-tree
[03:36] <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:37] <ryanakca> Use case: When you're trying to fix something through trial and error
[04:49] <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:52] <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:54] <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:55] <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:56] <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.
[05:04] <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)
[08:06]  * thumper votes for default log to be short (no merge details)
[08:07] <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:08] <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:09] <thumper> and they can take the hit of the graph sort or whatever
[08:09]  * thumper was reading traceback
[08:10] <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:11] <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:12] <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:13]  * 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).
[13:27] <epsy> Hi, how do I cleanup the .~n~ files?
[13:43] <AfC> $ find . -name '*~*'
[13:43] <AfC> $ find . -name '*~*' | xargs rm
[13:50] <marcus-b> better: find . -name "*~*" -print0 | xargs -0 rm
[13:56] <epsy> brb
[14:22] <LarstiQ> beuno: hmm, I wouldn't say I'm the mastermind
[14:22] <LarstiQ> marcus-b: hey! :)
[14:24] <LarstiQ> epsy, marcus-b: `bzr clean-tree --detritus` would also remove the .~n~ files
[14:32] <marcus-b> LarstiQ: I don't know bzr well, but I do know my unix tools :)
[14:32]  * LarstiQ nods
[15:05] <pygi> hi hi
[15:14] <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)
[16:01] <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:11] <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:17] <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:18] <pbor> CaMason_: no idea, sorry
[16:22] <CaMason_> it was a problem with dbus. Removing it, as I don't use it
[16:28] <ryanakca> marcus-b: <offtopic> 'find . -name "*~*" -print0 | xargs -0 rm'    vs    'find . -name "*~*" -exec rm {} \;'    ? </offtopic
[16:44] <dash> Hmm =/
[16:44] <dash> I am attempting to branch from an svn repo on sourceforge, using bzr-svn
[16:45] <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:46] <jelmer> your best bet is probably to wait until the sf svn servers are less heavily loaded
[16:47] <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:48] <jelmer> you mean it's actually getting 404's back?
[16:48] <dash> yes
[16:49] <jelmer> what's the URL you're trying to import?
[16:49] <dash>  http://posterita.svn.sourceforge.net/svnroot/posterita/trunk
[16:51] <dash> so i'm seeing a lot of things like "PROPFIND /svnroot/posterita/trial/posterita"
[16:51] <dash> to which 404s are given
[16:52] <dash> I'm just guessing that this is making it take longer, so make it have more chance to disconnect :)
[16:54] <jelmer> it doesn't ignore unexpected errors like that, I suspect that's all happening deep down in the svn libraries
[16:55] <dash> right
[17:22] <jelmer> dash, it seems to be working with the 0.5 branch for me, though it's very slow because of sf
[17:23] <dash> aha, the secret version ;)
[17:23] <dash> well i'm not in a hurry, I just want to get it eventually.
[17:25] <dash> hmm if that were true I would just wait until 0.5 was released
[17:26] <dash> I guess I am in a hurry, a little.
[17:40] <dash> jelmer: so, think I should try 0.5?
[19:37] <lifeless> moin
[20:33] <thumper> ah lifeless, you back this week right?
[20:35] <thumper> lifeless: can I have a quick voice call with you?
[20:37] <lifeless> sure
[20:37] <lifeless> skype, now?
[20:38] <thumper> ok
[20:41] <lifeless> ?win 38
[21:11] <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:12] <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:13] <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:14] <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:15] <lifeless> then I can throw it at ooo, at mysql, at bzr, at bzrtools
[21:16] <lifeless> Peng_: if you are interested this would be really useful.
[21:18] <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:19] <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:22] <Peng_> Or making it an attribute on Index objects that you could change from Python.
[21:23] <lifeless> hi poolie
[21:23] <lifeless> Peng_: sure.
[21:23] <lifeless> Peng_: or even - shock - a global
[21:24] <lifeless> so you don't have to get access to a specific index
[21:25] <Peng_> Oh, different methods have different group_sizes.
[21:26] <lifeless> yeah there are two
[21:26] <lifeless> there is 'how many revisions', where the inventory text size will chew up memory
[21:27] <lifeless> and there is 'how many file versions at once', where text sizes (isos!) will chew up memory
[21:29] <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:30] <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:31] <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:32] <mwhudson> does anyone have any recommendations for good conflict resolution tools?
[21:33] <lifeless> guns
[21:33] <lifeless> lots and lots of guns
[21:33] <lifeless> It worked in the matrix.
[21:33] <mwhudson> hmm
[21:34] <mwhudson> i think i want meld and a much larger monitor
[21:35] <bob2> sdiff/ediff in emacs is nice if you already use emacs
[21:36] <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:37] <bob2> simple mode that highlights in-file conflicts, with some keybindings to pick one or the other or both for each hunk
[21:38] <bob2> ah, out of that league, then
[22:08] <lifeless> spiv: shall we converse?
[22:18] <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:19] <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:20] <poolie> yes, call
[22:20] <mwhudson> osdc starts for realz on wes
[22:20] <mwhudson> weds
[22:21] <mwhudson> spiv just took the week off anyway i think
[22:26] <poolie> planning to look at bug 302698
[22:44] <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:46] <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)
[23:00] <mathrick> Peng_: hmm, I'll guess I'll just ask the hg guys then
[23:02] <Peng_> Good idea. :)
[23:14] <lifeless> Peng_: thanks!
[23:15] <lifeless> poolie: I need to shoot off to the doctors too today, I forgot to mention it in all the kufuffle
[23:16] <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:19] <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:20] <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:21] <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:22] <lifeless> so you have to cherrypick repeated - do merges specifying paths to merge, or specific revisions
[23:23] <mathrick> yup
[23:25] <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:26] <lifeless> mathrick: I don't understand why you couldn't run code
[23:26] <mathrick> lifeless: sec, lemme sketch that
[23:33] <mathrick> lifeless: http://pastebin.com/m23f854c8
[23:37] <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:38] <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:39] <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:40] <mathrick> hence the desire to have a tool which keeps track of what I want and don't want to merge for me
[23:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <lifeless> there are debs in the bzr ppa
[23:53] <mathrick> oh, interesting
[23:53] <mathrick> it dies right away now
[23:54] <mathrick> http://pastebin.com/d73b4f039
[23:55] <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:56] <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:57] <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:59] <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