/srv/irclogs.ubuntu.com/2008/08/15/#bzr.txt

jamI think it would be an incompatible change, or at least a whole lot of shoe-horning to get optimal gc => gc via get_record_stream.00:00
jamlifeless: I guess I've felt like you've been optimizing the knit => gc case, rather than the gc => gc case. And the former is transient until everyone has upgraded, while the latter is an on-going issue.00:02
lifelessjam: I've been hammering on the interface that is used00:06
lifelesswe need gc->gc to work when the source is actually a RemoteRepository00:07
jamlifeless: I suppose I also haven't seen any visibility of your work. I don't know if you just aren't committing, or if you aren't sending emails00:07
jamCertainly I don't see a public URL to get your latest code.00:08
lifeless~lifeless/+junk/bzr-groupcompress on launchpad00:08
lifelessand my btree-graphindex bzr branch00:08
lifelesswhich has outstanding uncommitted work, because I need to fix this api00:09
lifelessI haven't been able to spend time on the core code for a couple weeks now00:09
lifelesshelping with 1.6 stuff, analysing nasty bugs, and thinking about the interface problems00:10
lifelessso I think you're seeing 'robert has not been working on this'00:11
lifelessrather than 'robert has been obsessing about knit->gc'00:11
beunomwhudson, have any idea how/where I can upload the 1.6 tarball in LP?  https://edge.launchpad.net/loggerhead/+download  isn't very helpful00:14
mwhudsonbeuno: i think maybe you go to the release page00:15
mwhudsonbeuno: which you perhaps need to create00:15
beunomwhudson, ah, I see.  Ok, I have to go now, but I'll release 1.6 with NEWS, announcements, etc when I come back (or tomorrow morning), unless you can think of something else we're missing00:16
lifelessjam: before you go, what I need to understand is if you think a hint is _wrong_ or just premature00:17
lifelessjam: if you think its wrong I'll head back to drawing boards, if you think its premature I'll accept we have a different order on the same TODO list00:18
mwhudsonbeuno: awesome00:18
=== mw is now known as mw|out
jamlifeless: just premature, not wrong, I thought I made that somewhat clear.03:45
jamsorry about th delay03:45
lifelessjam: it was getting pretty angsty, I wanted to be sure03:45
lifelessno worries about the delay; life does come first :)03:45
lifelessjam: do you have an opinion on lexer and cc toolchain?03:54
lifelessjam: I'm currently trying antlr303:55
jamlifeless: I do not03:55
jamlifeless: what are you trying to parse?04:03
lifelessdirstate04:04
lifelessinitially that is04:04
jamseems a bit overboard, but if you feel it is merited04:04
jamAs far as one I came across a while ago: http://spirit.sourceforge.net/04:05
jamit is C++ using templates04:05
jamto allow you to write EBNF, I guess04:05
jamboost is a very nice advanced C++ library04:05
jamnot necessarily something you want to use in this context04:05
lifelessyah04:16
lifelessso if we do C++, I'd grab boost, its nice04:16
fullermdHonkin' big.04:17
lifelessbut I think plain C is probably best at this point04:17
jamlifeless: sure, the initial docs for antlr only describe java and c++ output04:19
* spiv doesn't like Fridays.04:19
jamthough it seems they have since implemented several output languages04:19
lifelesshttp://www.antlr.org/api/C/04:21
lifelessspiv: heh04:21
mheldif you had to categorize bzr commands, how would you?04:25
mheldtransfer, edit, info?04:25
Peng_Huh, importing paste is either taking 0.0037 seconds, or 9.5. That makes starting Loggerhead a little slow...04:27
jamPeng_: that seems like a bit of variation.04:27
fullermdYeah.  Do we get to pick which it is?   8-}04:28
jamlifeless: yeah, the problem is that on the download page, they say you can use the binaries for C++, C# or python, when they really mean C...04:28
jamI will also say I have a hard time finding online examples04:30
lifelessPeng_: out of cache?04:34
=== abadger19991 is now known as abadger1999
Peng_lifeless: Yeah, probably.04:39
mwhudsonit's not like paste does all that much when you import it04:41
lifelessmwhudson: 'python'04:41
mwhudsonyeah yeah04:42
lifelesspython, yeah yeah yeah, python, yeah yeah yeah04:44
lifelessso I played with freeze04:44
markhlifeless: in a packet trace, are you only interested in the few frames before and after the error?05:00
lifelessmarkh: I'm not interested in them at all; I want you to look at it ;)05:01
markhheh :)05:01
lifelessmarkh: we're looking for retransmissions, tcp errors etc05:01
fullermdIdeally, you'd probably want at least the last few packets before it goes off in the weeds.05:02
lifelessand to see what happens after05:02
lifelessif it gives up I think it will send a FIN05:02
fullermdRST more likely05:03
lifelessfullermd: yeah mea culpa05:03
lifelessEMEMORY05:03
fullermdOf course, it IS Windows; so it might send just about anything  ;)05:03
lifelessjam: whats up with NEWS05:10
lifelessjam: we seem to be jumping around with sections, I thought we had a fixed set these days ?05:11
jamlifeless: I see the same ones IN DEVELOPMENT as elsewhere, what would you have expected?05:12
jamlifeless: there has been some motion because of things that were in dev that got merged into a release candidate.05:13
jamI tried to keep them in the same sort order, though.05:13
lifelessI only ask because I'm running into conflict-after conflict :P05:13
lifelessjam: also, did you know that buffer() is a zero-copy tool ?05:13
jamlifeless: Is that because we started a new IN DEVELOPMENT?05:13
jamlifeless: yes, but buffer() doesn't make the code more obvious, etc.05:14
lifelessjam: As we work on memory, I expect we'll want more of it05:14
markhI'm not very familar with debugging network traces.  The last packet I see before the timeout is from launchpad and apparently carrying http payload.  The first I see after the timeout is also from launchpad, with the TCP "F" flag set, which apparently means "end of data".05:17
markhI'm using a windows network tool and I'm not sure how to export the data in any meaningful way05:18
fullermdWell, F would be FIN, which means it's shutting down the connection in an orderly fashion ("Done", rather than RST which means more like "broken, WTF?!?")05:18
fullermdYou don't see any packets from you in the middle, though?05:19
markhright05:19
markhnope - I'm filtering by "source=launchpads ip or dest == launchpads ip"05:19
fullermdI don't see how it could FIN unless it had at least seen your ACK of that last packet...05:19
lifelessdoes the sequence number match ?05:19
lifelessfullermd: I think you can FIN on shutdown() regardless of ack-state05:20
lifelessso05:20
* fullermd reached for Stevens.05:20
lifelessI think we should check what the apache front-end has its timeout set to05:20
* lifeless bets 15 minutes05:20
lifelessspm: ping05:21
spmlifeless: pong05:21
fullermdAssuming your ACK did get through, then yeah, it sounds like HTTP keepalive.  LP sent all its data, and considers that you've gotten it, and after 15 minutes of no activity, decides you're gone and closes the session.05:21
lifelessspm: whats the persistent connection timeout configured on bazaar.launchpad.net05:21
fullermd15 minute keepalive timeout sounds insanely long, though.05:21
lifelessfullermd: not really05:21
markhwhat pastbin do you guys use?05:21
markhpastebin05:21
lifelessmarkh: any that works05:22
markhhttp://pastebin.com/m6aed84b0 - but no column headers :(  2nd col is "packet number", 3rd is "time offset", "eden" is my pc05:23
lifelessspm: we have a situation where we are seeing some http data sent to a bzr session05:23
lifelessspm: then nothing for 15 minutes05:23
lifelessspm: then a FIN05:23
spmlifeless: hmm. not good.05:23
lifelessspm: working theory is that packets are going AWOL05:23
lifelessspm: and then apache is timing out the socket gracefully05:24
lifelessspm: finding out the configured timeont on b.l.n will help05:24
spmlifeless: sounds reasonable...05:24
spmlifeless: sure. just getting...05:25
lifelessif its different we can look at other things05:25
lifelessif its not configured, it willbe the default05:25
spmlifeless: looks to be default05:26
lifelessspm: thanks05:26
lifelessDefault:KeepAliveTimeout 1505:27
lifelessSyntax:KeepAliveTimeout seconds05:27
fullermdIt's 5 here.  But either way, it's a long cry from 15 minutes.05:27
* lamont mutters about &%)^%^*_ tar.gz packaging of bzr snapshots, again05:27
markhKeepAlive is different05:27
markhisn't it?05:27
lamont1) orig.tar.gz without debian/; 2) drop debian/.bzr from the source package05:27
lifelessKeepAlive is boolean05:27
markha timeout though05:27
mwhudsonlamont: i'm sure you should be asleep05:28
lifelesslamont: bzr itself?05:28
markhif it has the connection open, that is how long before it will close it even if the client doesnt IIUC05:28
lifelesslamont: you have confused me05:28
fullermdmarkh: No, KeepAlive is just a flag for whether or not persistent connections are allowed.05:28
lamontlifeless: see lauchpad.net/~ppa-bzr-beta/05:28
lamont]+archiuve05:28
markhyes -05:28
fullermdmarkh: KeepAliveTimeout is the time after which it closes even if the client doesn't.05:28
markhand if it is used and the connection remains open, the server has a timeout05:28
lifelesslamont: bzr upstream does not have debian in it05:28
lifelesslamont: but the packaging rules are a bzr branch05:29
lamontthe package in the ppa doesn't _HAVE_ an upstream tarball05:29
markhfullermd: yeah, I think that is what I'm saying :)05:29
markhwhich is a different timeout than we are looking for?05:29
lamontlifeless: which, specifically, is my complaint05:29
lifelesslamont: uploaded as a native package?05:29
lamontyes05:29
fullermd(I don't think there IS a timeout for max length of a persistent session, short of MaxKeepAliveRequests * (KeepAliveTimeout * .9999999)05:29
lamontOTOH, at least 1.6rc2 has dapper source for me :-)05:29
lifelesslamont: file a bug05:29
lifelesslamont: the folk doing these uploads are not DD's05:29
lamontyeah05:30
lamontI'll do it once I'm awake again, as mwhudson so aptly points out05:30
lamontand on that note, bed.05:30
lifelessstill05:31
lifeless1/60th of the time out is still damn suspicious05:31
bvkhi, how do i make a minor edit in an already commited revision, without another commit?05:32
AfCbvk: uncommit05:33
fullermdAnyway.  I'm pretty certain a FIN won't be set if there's outstanding un-ACK'd data, no matter what.  shutdown(2) will send the queued data and wait for it to be ACK'd before doing it's half-close.05:34
bvkAfC: thanks, i will try it out05:35
AfCbvk: (followed by a new commit, of course)05:35
AfCbvk: (assuming, a) that you are trying to fix the most recent revision, and b) that you haven't sent it anywhere public)05:36
bvkAfC: it seems, i cannot go down more than a recent commit and make a fix :-(05:38
fullermdBarring really heroic and unportable measures, I don't think there's any way for userland to 'take back' send(2)'t data; once it goes down there, TCP will reset the connection without any more intervention if it can't get through...05:39
spmmarkh: just been looking at that network trace pastebin. those first two packets (4188/89) appear to be identical? Which seems a tad broken.05:40
bvkAfC: say, i have revisions 1,2 and want to make a minor edit in 1 (but not in 2) revision 2 also needs to be uncommitted05:40
markhshall I go back a few packets?05:41
AfCbvk: yes, which is why you should just be making a fix and committing revision 3.05:41
bvkAfC: is there anything like mercurial patch queues? where i can do hg qpop; hg qpop; edit; hg qrefresh; hg qpush; hg qpush ?05:42
spmmarkh: yeah... something just seems really odd... I'd expect to see more "stuff" happening. retries whatever.05:42
fullermdmarkh: If you can use something like Wireshark, you can do things like show a trace of the HTTP session, which could be helpful in seeing if it really is "all there".05:42
markhthose 2 packets look identical here too05:42
fullermdMmm.  That trace looks all sorts of messy...05:44
mwhudsonbvk: there is the 'loom' plugin05:44
markhhttp://pastebin.com/m78da686f has from the GET request05:44
markhI'll look into wireshark...05:44
fullermdLook at those 4th and 5th lines again.05:45
fullermdFirst, the 4th line is launchpack ACK'ing your packet in the 5th line.  So the order is messed up.05:45
fullermdAnd secondly, those are from a different session than the first 2 lines (can't tell about the 3rd); the local port is different.05:45
bvkmwhudson: i tried loom plugin, but i couldn't get that how to do it right :-( loom doesn't have anything equivalent to hg qrefresh :(05:46
bvkmwhudson: i still need to make a commit for minor fixes and it is recorded as another revision05:47
mwhudsoni don't know what qrefresh does, so can't really answer that :)05:47
lifelessmwhudson: its what commit in aloom thread does05:48
lifelessbvk: in loom you just do a commit on that thread05:48
bvkmwhudson: qrefresh updates the current working patch (in a queue of patches). one patch acts like one revision, so multiple qrefreshes on a single patch will not result in multiple revisions05:48
markhI think only one bzr was running in that trace - I was being careful to wait while the 15 minutes expires and not doo anything else with bzr05:49
markhI'll see how I go with wireshard05:49
markhk05:49
lifelessbvk: looms map revisions into a stack rather than replacing revisions05:50
lifelessbvk: the stack has the delta each revision needs when submitted upstream05:50
fullermdBut yeah, that FIN 15 minutes and 10 seconds later is from a different TCP session (local port 60013 instead of 60012), so it's no relation to the other packets.05:51
fullermdThat first connection apparently disappears totally after that line 7 packet.  Which is absurd; you're running locally, you should be able to see your ACK of it no matter what, even if the other end doesn't.05:52
bvklifeless: um...if i go down-thread, do some edits and did up-thread, will my top thread gets the edits merged?05:52
lifelessso, we were looking at the wrong machine in the DC05:52
lifelessbvk: yes, as a pending merge like normal bzr merges05:52
lifelessbvk: diff -r thread: at any point shows you the overall pending diff05:53
bvklifeless: so, i have to do one more commit in all up-threads from the point of edits?05:53
spmfullermd: agreed - good catch on that. which also begs the "what is actually open" question...05:54
lifelessbvk: yes, there are some plans to streamline this05:54
bvklifeless: ok05:54
fullermd(of course, it's an assumption that that HTTP data packet is part of the 60012 connection, since it doesn't show ports or sequence numbers or whatever on those packets, but I think it's a reasonably good one)05:54
spmmarkh: might be worthwhile seeing how many, if any?, connections you have open to 91.189.90.161; netstat -an | fgrep 91.189.90.16105:55
bvklifeless: one more question, when i do a merge from up-thread, all its revisions are automatically logged in the commit message, can i avoid that with a simple merge notes?05:56
markhnone apparently :)  I'm installing wireshark now05:56
lifelessbvk: they are not logged in the commit message for me; why do you say they are ?05:56
bvklifeless: i saw all revisions logged with some indentation :-(05:58
spmfullermd: yeah, the timing is too tight. but still ... coincidence is possible. :-)05:58
lifelessbvk: thats display05:58
lifelessbvk: try e.g. bzr log --short05:58
lifelesscopying commit messages around like that would be horrible duplication05:59
markhI'm pretty clueless with this :( fullermd - any clues about the syntax for the wireshark filter I'd need?06:00
markhor spm of course :)06:00
fullermd"host 91.189.90.161 and port 80" should do it06:00
fullermd(should show both directions)06:01
spmmarkh: just grab the lot - post filtering with wireshark is a doddle. or ^^ :-)06:01
markhit says thats a syntax error06:01
* markh looks at help06:01
bvklifeless: ok, short is not displaying them :-)06:03
spmmarkh: are you applying that filter as you capture, or post capture? the eg fullermd gave is "as you capture"? The post capture filters are very different syntax.06:04
markhum - in the toolbar "filter" box :) - haven't started capturing yet06:05
spmAh! :-)06:05
spmNo not that one. :-)06:05
spm"start a new live capture"06:05
spm... or "capture options"; should then see a "capture filter" - put the filter in there.06:06
fullermdThe latter is what I always do (make sure you choose the right interface)06:09
markhok, running.  Now to retry a few times until it fails...06:10
markha few "dupe ack" messages are flying by, but its still working...06:18
markhahh - here we go :)  bb in 15 :)06:19
spmmarkh: :-) Once you close the sniffing; go looking for the http GET request that timed out - it should be fairly obvious; select that line; right click; "Follow TCP Stream" - will filter packets to only that connection.06:22
markhnice :)06:22
fullermdI'd save it right off too; that way you have a copy around to work with.06:23
markhfullermd/spm: so I've got a capture - but struggling to get a similar text format out for the selected packets.  What's the best way for you to see the data?06:43
markhupload a .scap somewhere?06:43
fullermdmarkh: Well, you can try filtering down to just that session, then saving that out to a pcap file, and seeing how big that is.06:44
spmmarkh: sure - works for me06:44
lifelessbbs06:44
fullermdIf it's not huge, we can just grab that and poke at it.06:44
fullermd(or if the whole capture isn't too huge, that would work too, with less effort)06:44
markhfullermd/spm: http://starship.python.net/crew/mhammond/bzr-hang-2.zip (151,340 bytes) - it should be from the most recent GET (a few seconds and many packets before the hang), and a dozen or so packets after.06:48
fullermdOK, that's a lot of dupe ACK's in a bunch there.  Couple times.  Weird.06:57
* markh doesn't know what happened to his isp then.06:57
fullermdLot of partial packets there; your MTU is higher than somewhere along the path, which is causing a lot of fragmentation.06:59
fullermdThat shouldn't break anything, but certainly exposes more edges.  And probably messes with your performance a bit.06:59
markhquite possibly my very old dsl modem06:59
fullermdIf we go to packet 687, which is the last one before the pause, right-click and 'Follow TCP Stream' gives a text dump of the session.07:00
fullermdThere's two things to note.07:00
fullermdThe first, is that looking at the very end, it's obviously in the middle of a line, which confirms that you're not actually getting all the expected data.07:00
fullermdThe second, is that there IS a proxy; see the HTTP response header:07:01
fullermdVia: 1.0 proxy3.mel.dft.com.au:80 (squid/2.6.STABLE18)07:01
markhyeah, my isp I believe07:02
fullermdSo, that's suspicious.  HTTP breakage unrelated to proxies happens, but not near as often as related.07:03
fullermdlifeless may know more as to whether there's something particular about that version that might be tripped us up.07:04
lifelessaustralian ISP's as a rule have an intercepting squid07:05
lifelesssquid had a known, serious bug with range requests07:05
markhheh - well there you go :)07:05
markhin that version?07:05
lifelessyes07:07
lifeless.19 fixes it07:07
lifelessbut they should 2.7 or 3 anyhow07:07
lifelesshttp://www.squid-cache.org/Versions/v2/2.6/changesets/11996.patch07:07
markhbugger - here goes another support request that will end up in the same bucket my request for them to upgrade their SpamAssassin did :(07:07
lifelessalso07:08
lifelesshttp://www.squid-cache.org/bugs/show_bug.cgi?id=232907:08
ubottuwww.squid-cache.org bug 2329 in src "Range header is ignored for TCP_HIT" [Normal,Resolved: duplicate]07:08
lifelesswhich is fixed in .2007:08
fullermd(actually, I could be full of crap on my first point above; I guess the range could just end right in the middle of that line)07:09
lifelessfullermd: single ranges can, multi ranges will be multipart wrapped07:09
Peng_Australian ISPs run proxies? Ew.07:09
fullermdIt's multi-part wrapped.  2 ranges.07:10
lifelessfullermd: so cutting off part way == incomplete07:10
fullermdI forgot that it was ranged, so I assumed it would have a full index, which wouldn't fail in middle of the line.07:10
fullermdThe range is a little weird, though...07:10
fullermdRange: bytes=33100-123726,124238-19066507:10
lifelessthats GraphIndex07:10
fullermdWe really care about saving 500 bytes in the middle, when we're pulling >150k?   :p07:10
lifelessno07:10
lifelesswe want a few hundred bytes from 150000+07:11
lifelessand its remote so we expand it to 64K07:11
lifelesswe also want some bytes from a couple of lower spots, apparently07:11
fullermdYeah, it just seems weird to me that they expand to those blocks, but don't just collapse it into a single range.07:12
markhthat squid bug appears to only happen for cached content?07:12
* fullermd does a quickie test of the range07:12
lifelessmarkh: the second bug yes07:13
lifelessmarkh: but note that the first bug will cause the second to show07:13
fullermdOh, I see what you mean.  I missed that it was lacking the MIME boundary marker.07:18
fullermdSo I was right, for the wrong reason   8-}07:18
lifelessmarkh: I'm not convinced squid is the root cause thouh07:20
lifelessmarkh: you are seeing anomalous behaviour07:21
fullermdYeah.  There's enough weirdness in there to go around.07:21
xshelfa quick question: is bzr-fastimport format identical to git-fastimport format?07:22
fullermdAll the dupe ACK's, in several clusters through the trace, are locally generated, rapid-fire.07:22
lifelessxshelf: bzr-fastimport read git-fastexport if thats what you're asking07:22
fullermdThat may or may not be related to the near-total fragmentation.07:22
fullermdI think there's some SACKtion going on, but I don't know SACK well enough to say much about it without a lot more digging than I have time for tonite   :|07:23
xshelflifeless: i was looking at reusing git-p4 for bzr07:23
lifelessxshelf: yes, I believe someone is working on that07:24
lifelessthere is stuff on the list about this07:24
xshelflifeless: i read it in the list, let me followup with that person07:24
jmllifeless: hi.07:46
Peng_jml: bzr+http? :D07:46
jmlPeng_: working on it!07:46
Peng_Cool.07:47
lifelessjml: hi07:56
jmllifeless: so, tomorrow.07:56
jmllifeless: we're missing a *time*07:56
lifelessand a place07:57
lifelessI've been trying to grab Lynne, no luck07:57
jmllifeless: Kensington is the place07:57
lifelessdetails details details; how do I get there?07:57
lifelessmarkh: is there mtrr for windows?08:03
markhno idea!08:23
markhI see rio.py has:      if isinstance(value, str):\n      value = unicode(value) - that is always going to be suspect isn't it?  If the string is utf8 or anything else that's non-ascii, we are doomed08:24
markhsome russian dude is hitting it in 1.5, and it looks like he still might in 1.608:25
lifelesshttp://beerpla.net/2008/05/12/a-better-diff-or-what-to-do-when-gnu-diff-runs-out-of-memory-diff-memory-exhausted/08:27
lifelessagreed08:28
lifelessis there a bug?08:28
markhhttps://bugs.launchpad.net/bzr/+bug/25655008:31
ubottuLaunchpad bug 256550 in bzr "locking fails with non-ascii characters in host/username/something (russian Vista)" [High,Triaged]08:31
markhyep08:31
markhoops :)08:31
* markh answered the bot :)08:31
luksthe problem is not rio, the problem is using non-ascii bytestrings for hostnames08:32
markhone path I can see is _auto_user_id() calls socket.gethostname(), which returns a string and may be non-ascii in that case08:32
markhyes :)08:32
lukspersonally I'd just decode is using the user's locale08:32
markhon windows the encoding would be 'mbcs' (which is also filesystemencoding) - but yeah08:33
markhhard path to test - monkeypatching maybe?08:33
luksno, that's the filesystem encoding08:33
luksit would be cp-something08:33
markhwindows is likely to return a string that went via WideCharToMBCS (or however it is spelt), in which case "mbcs" would be the appropriate encoding to use IIUC08:34
markhthe same value directly from the api via unicode would also be an option08:35
markhwin32api.GetComputerNameEx(0) returns unicode :)08:37
markhbut - rio is still potentially broken in the future.  ISTM it should probably throw an exception for a string08:39
markhas even a utf8 string would blow it up today08:39
lukswell, is does, UnicodeDecodeError :)08:39
markh:) but only when it actually contains non-ascii08:39
markhit should raise an exception *every* time it gets a string, as it means one day a Unicode error will happen that is hard to reproduce :)08:40
luksyeah, I suspect that would break a lot of bzrlib code08:41
markhwell, it could be argued that code is already broken for some users08:41
lukstrue08:41
markhbeer-oclock!08:52
lifelessrio probably wants to be asserting on bytestrings rather than decoding09:06
uwsHmm09:21
uwsWill bzr have something like this:  http://www.gnome.org/~federico/news-2008-08.html#12  and http://treitter.livejournal.com/7769.html   ?09:21
uwsinteractive rebasing/stacking patches09:21
* AfC writes uws a shell script09:23
AfC:)09:23
uwsAfC: Eh, how would that work?09:25
uwsAfC: This is about merging multiple commits into one09:25
uwsso that the history is cleaner when merging into mainline09:25
AfC[Ok, switching back to reality: I know a goodly number of people around here respect (and in some cases, including my own, absolutely worship) the UI that was presented by Darcs. Nothing to do with patch commutation vs tree snapshot issues; but the console UI was bloody brilliant in its interactiveness and consistency]09:25
AfCuws: well, given that rebase is ultimately just a wrapper around `bzr merge -r X..Y ../theirs` (for X not in mine)09:27
AfCuws: it's eminently scriptable09:27
lifelessuws: yes09:27
lifelessuws: there is a bug open on rebase -i09:28
AfC(ok, so rebase has nice logic for moving forward and backwards / continuing as conflicts arise)09:28
lifelessuws: it has somethoughts on how to make it happen09:28
uwslifeless: will that also make it possible to "collapse" multiple commits into one? E.g. a real patch + 2 subsequent typo fixes09:28
lifelessuws: sure09:28
lifelessuws: I mean, its basically uncommit -r -3; commit09:29
lifelessuws: and then rebase replay after that09:29
lifelessuws: note that there is a way to do all that rebase does in terms of presenting things without sacrificing history; for the case where you need to evolve a patch-branch rather than simply fake up work done09:30
uwslifeless: ...which is?09:31
* AfC guesses Robert's loom concept09:32
uwsSomething that helps merging stuff into a branch chunks would also do the job right?09:33
uwsso that if history is like this:09:33
uwsadd-feature-1, fix-typo, fix-typo09:34
uwsadd-feature-2, fix-typo, fix-another-typo09:34
uwsi.e. 6 commits09:34
uwsthat you can create a branch (preferably in place) that is like this:09:34
uwsadd-feature-1 (add-feature-1, fix-typo, fix-typo),  add-feature-2 (add-feature-2, fix-typo, fix-another-typo)09:34
uwswhere the parenthesized commits are merged revisions09:35
AfCuws: this is going to sound silly, but why not just take a branch at point 009:35
uwssomething like "bzr collapse -r 1:3" which will give you an editor with all commit message09:35
uwsso you can assemble a new commit messte from these09:36
AfCuws: then merge from feature-1+fix-typo+fix-typo,09:36
AfCuws: then merge from feature-3+fix-typo09:36
uwsAfC: Yeah, that's the same net effect.09:36
AfCyou'll end up with two left hand side revisions (merges, as it happens) that you can write up to your heart's content.09:36
uwsbut it's cumbersome09:36
AfCMore cumbersome that screwing around with rebase and history erasure?09:36
uwsNo, what I described a few lines back doesn't change history, does it?09:37
uwsit just "groups" a few revisions into a merge, and then does the same again09:37
uwsso that a "bzr log" will list only the 2 groups at the top levle09:37
AfC[as an aside, I have a slightly different problem, which is that the left hand edge merges are NOT what are significant in our project, and I'm getting rather tired of writing the same detailed log message again and again as features get merged up]09:37
AfCuws: {shrug}09:38
AfCuws: that is exactly how Bazaar operates today09:38
AfCuws: so I guess I'm a bit vague on which part you consider cumbersom09:38
AfCe*09:38
uwsAfC: Well, I branch a project09:38
AfC(one possible point that's missing: you can do a merge even if there is no divergence)09:38
AfC(instead of pulling)09:38
uwsAfC: then I start hacking09:39
uwscommit new feature, fix a syntax error09:39
AfCyup09:39
uwsbut when my work goes back into mainline I don't want the typo fix to show up so prominently09:39
uwsI want to present my branch as a few self-contained revisions (which may be merge revisions containing also the tiny typo fixes)09:40
uwsright now it seems I can only do this with a 2nd personal "helper" branch in which I merge selectively09:40
AfCuws: well, you either cherrypick, thereby losing that history completely, or you merge it, and hope that most people don't pay much attention to non-left-hand-edge revisions. (`bzr log` is so biased; `bzr viz` is not)09:40
uwsI don't like cherrypicking that much (for the reasons you stated)09:41
AfCuws: is the source branch a [bzr-svn] checkout in this case?09:42
AfCif it is not,09:42
AfCthen it's already capable of being the staging area for you to create the merges that are "cleaner"09:42
AfCif it is, then really you need a temporary 2nd branch to do the work in before bringing it back to the checkout09:42
* AfC is ignoring the --local capabilities, which he doesn't know anything about unfortunately09:43
uwsAfC: Yes it is09:43
AfCI thought so09:43
AfCIn that case, look at it this way09:43
uwsAfC: --local is just committing without having stuff in the bound branch09:43
AfCthe bzr-svn branch [checkout == slaved to upstream] really wants to be kept pristine as a copy of upstream09:44
uwsnext non-local commit will just push the whole bunch on top of the bound branch09:44
AfCwell there you go09:44
uwsAfC: I have a trunk branch, which I don't hack on (it doesn't have a workign tree)09:44
uwsthen I have my own branch09:44
uwsI keep trunk/ up to date09:44
uwsand then merge trunk into my own branch09:45
AfCuws: anyway, if this is an upstream like, say, GTK where commit permission is only grudgingly granted after long discussions, then you'll need not just somewhere else to stage your patches, but a whole bunch of somewhere elses to stage each feature.09:45
uwsAfC: in this particular case it's a read only bzr-svn checkout/branch09:45
AfCuws: yup, it all sounds sane09:45
uwsbranched over http://09:46
AfCuws: so I guess I'm confused as to why you feel uncomfortable doing the merges of N revisions at a time into your own [writable] copy of trunk vs the place where you are working09:46
AfCuws: let me try a different tack on this:09:47
uwsAfC: My trunk/ access is RO09:47
AfCuws: a place to do merges is a good idea09:47
AfC[I'm talking here not ex-cathedra as a Bazaar hacker, because I am not one; but having been leaning on Bazaar fairly heavily for almost 2 years now (as you know) some patterns have seemed to serve me well]09:48
AfCuws: (if I might suggest, the three branches could be named09:49
AfCuws: 'upstream' (that's the bzr-svn RO checkout), 'trunk' (RW bzr branch which you keep in sync by pulling regularly from ;upstream') and 'working' (or otherwise feature named branches, RW bzr)09:50
AfCuws: and you'd do your merge work in 'trunk')09:50
AfC{shrug} something like that09:50
uwsAfC: Yeah, I'm not a bzr hacker either. Just a regular user. I shove bzr up my colleague's throats as well09:50
uwsso I'd better know what/how because they ask me all the time ;)09:51
uwsAfC: But once I merged my feature into 'trunk'09:51
uwsI won't be able to 'pull' upstream anymore. Just merge09:51
uwsEventually the goals is that my local patches end up upstream after review/chagnes09:52
AfCuws: (or, 'trunk' [bzr-svn], 'working', and feature-braches^N)09:52
AfCuws: realistically, aren't you maybe overthinking this a bit? You're going to be doing09:52
AfC$ bzr diff -r ancestor:../trunk09:53
AfCall the time to extract diffs to show people09:53
AfCand it's not until a patch is accepted that you can go and merge to a RW checkout of trunk - and that merge sums up the other stuff, no?09:53
* AfC thinks uws is going to need a whole plethora of branches each containing a feature. They will be individually diffed against 'trunk' for review, but also will be fairly constantly merged into 'working' which is the branch with a WT which is where you are actually hacking.09:55
uwsAfC: All needing lots of disk space :(09:56
gouruws: shared repo?09:56
AfCI have found myself doing this; except that since I'm doing the creative work in 'working', creating little branches for individual featurettes which may be mergeable means manually copying the changes over to the little branches, creating revisions there, and then merging back to 'working'. Messy, but at least I'm not cherry picking09:56
uwsgour: of course, but still lots of disk space09:57
luksuse treesless shared repository and a single checkout09:57
AfCuws: the branches storing the individual features as they grow don't need Working Trees09:57
uwshmmm. idea: have branches without working trees, and have one checkout which I can "bzr switch" to the feature I'm working on09:57
AfCuws: branches themselves are negligible in size.09:57
uwsAfC: But the working tree is HUGE in this case09:58
AfCuws: that is essentially how I work09:58
uwsAfC: it's like ~600M09:58
AfCuws: that's fine. You only need one (maybe 2 if bzr-svn needs a Working Tree)09:58
uwsand > 50k files09:58
AfCuws: yes, that's fine.09:58
uwsAfC: (it doesn't)09:58
AfCuws: bzr switch should handle it no problem09:58
uwsoh, for reference: we're talking about Webkit here btw09:58
AfCuws: I suspect that reality is that you're going to need 2 Working Trees, then - one for hacking in, and one for doing patch prep & merging09:59
AfCthe later would be the thing you're switching around.10:00
AfCWell, I've said enough. I look forward to hearing how it works out for you.10:00
AfC[600 MB? What on earth have they got in there?]10:01
uwsAfC: millions of tests10:01
uwsAfC: Like >300MB of them10:02
lifelessuws: yes looms are the [partial] implementation of 'edit and manage with history and collaboration]10:04
gourwhat's missing?10:05
robtaylorlifeless: not sure what you mean, gobject code dont get that heavy on memory io.10:05
lifelessgour: polish10:06
lifelessgour: helper routines10:06
robtaylorlifeless: the objects are allocated by a slice allocator10:06
lifelessgour: and, in the core of bzr, seriously cherrypicking [equivalent to darcs]10:06
lifelessrobtaylor: so are python objects, but every ref and deref is a memory write10:06
lifelessrobtaylor: its intrinsic to ref counted systems10:06
robtaylorlifeless: uhhu10:07
robtaylorlifeless: gstreamer has refcounted objects..10:07
robtaylorlifeless: i don;t think its something to worry about10:07
robtaylorlifeless: i thought python keeps a live count for objects anyhow?10:08
gourlifeless: will something of the above happen in 1.7 time frame?10:08
lifelessgour: if someone sends in patches :)10:09
lifelessrobtaylor: I will bet you significant amounts that gstreamer has refcounted external objects, not every internal detail10:10
robtaylorlifeless: GstMiniObject is used for everything10:10
robtaylorlifeless: refcounting happens all along the pipeline10:10
lifelessyes, but thats still very coarse AIUI10:11
lifelessthe objects I am working with are 10's of bytes long10:11
lifelesswith millions in even only moderately large trees10:11
robtaylorlifeless: oh, something like that you just do with structs and slices10:11
robtaylorlifeless: you only need refcounting if your dealing with complex lifetimes10:12
lifelessright, this is kindof my point :)10:12
robtaylorok :)10:12
AfCHow come you're so interested in GObject this week?10:12
robtaylorlifeless: ooi do you always know the size of the objects?10:13
lifelessrobtaylor: for some yes10:16
lifelessrobtaylor: something taseful will arise, I'm sure10:16
lifelessAfC: I think a better question, is, what is robert writing10:16
AfCWhich Robert :)10:17
Jc2kevil twisted things that shut not be spoken about10:17
lifelessYes10:17
Jc2kshould*10:17
lifelessAfC: Yes10:17
Jc2kever10:17
AfC[note that I didn't direct the question in any particular direction :)]10:17
AfCThat's ok. There's no way you have a monopoly on crazy ideas. I've got an R&D project going to examine what would happen if we let the Java VM manage GObject life cycles instead of letting GObject's Ref and ToggleRefs do it.10:18
AfC(so discussion about sizes, access patterns, and what the slab allocator is up to this month are of passing interest)10:19
lifelessahha!10:19
lifelessso I'm writing another C extension10:20
lifelesssomewhat larger than our current ones10:20
lifelessand I want to use low level C diagnostic tools10:20
lifelessso I want no python VM10:20
AfClifeless: (that's what I vaguely suspected)10:20
robtaylorAfC: that crazy R+D project sounds pretty interesting =)10:22
* AfC imagines Robert will have more luck that him :)10:22
AfCrobtaylor: well, it's a couple things [and I am only disucussing something so OT here in so far as it seems conceptually similar to Robert's experiments]10:22
lifelesswell, I have antlr3 running now10:23
AfCrobtaylor: we have the whole ToggleRef thing in place to manage the relationship between our Java Proxy objects and the underlying GObjects. But it gets complicated;10:23
AfCand it's not as effective as I would like, because there is too much lock-step going on between the two sides.10:24
AfCIt *works* (there are zero leaks)10:24
AfC[ok, famous last words. We're pretty good, though]10:24
lifelesshow does gintrospect fit into your bindings?10:24
AfCBut I have encountered situations where not everything is cleaned up at once. The last Ref to a GObject is our ToggleRef; our Java object becomes only weakly reachable and so next GC, ta-da, we drop the ToggleRef and the GObject finalizes.10:26
AfCThat's all good10:26
AfCThe trouble comes that when it's not something violent like a 'delete-event',  (where violent is code paths in GTK that go above and beyond about breaking references)10:26
AfCthen it's only now that some of the child Widgets drop down to being us owning the last ref.10:27
AfCwhich means that they won't get destroyed until the *next* GC cycle.10:27
AfCBah!10:27
AfClifeless: (short answer, not yet)10:28
AfClifeless: (longer term answer, our code generator is nicely abstracted, so the .defs data feeding it can be replaced with introspection data when it comes available. But it needs to be fairly complete before we reach that point. When we're generating the C API for GNOME libraries off of that data, then I think we'll be set)10:29
AfC:)10:29
AfCrobtaylor: so anyway, it occurred to me that this lockstep'edness was occurring because the Java VM doesn't have full information about the relationships. If it did, it could see the closed sets and pow them as a group10:30
AfCrobtaylor: I rather expect that the cost of going across the JNI boundary to reach the Java VM's reference queues instead of using GObject's internal hash tables will be prohibitively expensive, but it's been an interesting exercise so far.10:31
robtaylorAfC: I'd be very interested in having a g_objcet_ref_with_association (object, owner)10:32
robtaylorAfC: i suspect the Vala people would too10:32
strkwhat's that command to show current revno ?10:32
AfCrobtaylor: everyone who is proxying would, I imagine10:32
strkit's not printed in 'bzr help'10:32
robtaylor*nod*10:32
AfCstrk: `bzr revno`10:32
robtaylorAfC: anyhw, the crack project we're working on in our free cycles is http://wizbit.org10:33
strkdoes 'revno' checks revision on remote or local tree ?10:33
Jc2k<h1><u><b><blink>CRACK</blink></b></u></h1>10:33
AfCrobtaylor: I should call you sometime and chat with you about that. It fits in nicely with some areas I'm working in10:34
robtaylorAfC: feel free :)10:34
AfCstrk: so, being pedantic, it will tell you about the "branch"10:34
AfCstrk: if you do `bzr revno` it'll tell you about this Branch (assuming you're in a Branch)10:34
strkdamn. I have two builds from two trees. both trees give same revno, but one works in a way, one doesn't10:35
AfCstrk: if you do `bzr revno bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/` it'll tell you about bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/10:35
AfCstrk: revnos are only meaningful per branch10:35
lifelessstrk: because you can have multiple branches, revno's are only relevant to a brnach10:35
AfCstrk: what you probably need to inspect are the revids (though, in human readable terms, the last few log entries should tell you what's what)10:36
lifelessstrk: if you want the uuid, 'bzr revision-info' is the right command to use. But I generally would use 'bzr missing' instead, because that tells me what commits are in each10:36
AfCstrk: `bzr revision-info`10:36
* AfC gets out of lifeless's way10:36
strkmatches as well10:37
strk(revision-info)10:37
strkBranches are up to date.10:37
AfCstrk: if you `cd ONE` and do `bzr missing --line /path/to/TWO` you should be told what's different10:37
strkstill up to date10:38
AfCrobtaylor: anyway, I'm trying to figure out if I can replace (override) the GObject Ref mechanism. That means hijacking g_object_ref and g_object_unref, and all the ways to do such a thing are nasty.10:38
AfCstrk: silly question, but I assume `bzr diff` shows nothing in each one10:39
lifelessstrk: you have two separate working trees ?10:40
strkright (no diff, two working trees)10:40
AfCrobtaylor: hijacking GObject's memory allocation would be a second step. That's not just crack. That's ice.10:40
AfCAnd enough on that topic.10:40
robtaylorAfC: yeah, pain :/10:41
strkafter 'bzr switch trunk', altought revision-info didn't change, 'make' is doing something10:41
strkthis is Bazaar (bzr) 1.6rc210:42
strkis it supposed to touch files even if nothing changed ?10:42
AfC(it could)10:44
lifelessstrk: bzr revision-info changes for me10:45
lifelessstrk: no, it won't touch files if nothing has changed10:46
lifelessstrk: it will touch files if they *happen* to have the same content but appear changed to bzr10:46
strkit seems a regression was introduced, so I was hoping to figure which revno worked and which not... unfortunately I had the same revno back from the two branches... that's how it all started10:46
strknow it's hard to tell (we don't store revno in binary modules)10:47
strkand bzr viz stopped working :/10:47
strkwould switching to a specific revno require online access or my local branch is enough ?10:48
strkbzr diff -r 9590 -r 9591 # didn't do what I expected, did it ?10:50
strkdiffs between two revisions10:50
strkit seems it gave me diffs from 9590 to current10:51
strkbzr diff -r 9590..9591 # did it, it seems10:52
lamby'lo jelmer .. Curious to why you uploaded bzr-gtk to experimental? :)10:54
strkI hope for me10:55
strkbzr was to experimental (I guess, as I was prompted for upgrade) but since I upgraded, bzr viz stopped working10:55
=== prateeksaxena is now known as prtk
* gour finds 'shelve' command useful...13:13
=== kiko-afk is now known as kiko
pickscrapeshelve is awesome :)13:31
gourright. it keeps my history more 'sane' considering i am coming from darcs world and nice interactive 'darcs record'13:34
Peng_"record" would be even better than shelve though.13:38
* gour agrees13:39
* pickscrape doesn't know anything about record13:40
gourpickscrape: http://www.darcs.net/manual/node8.html#SECTION0086100000000000000013:42
pickscrapeAh, so it's interactive commit?13:43
gouryep13:43
gour..if you want13:44
pickscrapeThat reminds me how I got by without the shelf when using svk: it has interactive commit too.13:44
gourit would be nice to have it in bzr as well13:44
Peng_The first interactive commit-like thing I used was bzr's shelve. When I found hg only had a record plugin, I was disappointed, and it took a while to get used to, but now I hate having to go to the trouble to use "bzr shelve".13:48
Peng_They do have different uses, of course, and I have missed shelving in hg a couple times.13:48
=== ahasenack is now known as ahasenack-flying
* gour uses shelve as poor-man's-interactive commit13:50
lifelessPeng_: install bzr-interactive14:01
Peng_Ooh14:04
Peng_How does bzr-interactive work? Does it add a "record" command? Does it change "commit"?14:05
Peng_I think it adds "record".14:05
lifelessPeng_: also you might like to comment on my tree marks concepts14:17
Peng_lifeless: What's that?14:18
lifelessa concept I'm exploring14:18
lifelessI started a thread about better review support14:18
Peng_lifeless: Thanks for suggesting bzr-interactive. :)14:23
quicksilverwhere do I find information about bzr-interactive? I found the launchpad page but it's a bit bare.14:32
Peng_quicksilver: The source code, I guess. Or "bzr help interactive" after installing it.14:33
Peng_quicksilver: There's not much to say. It adds an -i option to commit.14:33
Peng_It also adds a record-patch command.14:34
quicksilverI found the author's blog post.14:35
quicksilverI have feeling I might consider commit -i harmful.14:35
quicksilverAfter all if you commit -i and commit anything less than all hunks, that suggests that you haven't tested the version you ahve committed.14:35
quicksilverThat sounds like bad practice?14:35
Peng_Hmm, I suppose you're right.14:36
uwsServer does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)14:36
LarstiQquicksilver: now hook up -i code that takes the new tree and runs automated tests on that14:36
uws^^ Why do I get this with 1.5 and 1.6 client?14:36
uwsthere's no newer version, is there?14:36
Peng_uws: There is.14:36
Peng_uws: 1.6 introduces a new network protocol.14:37
Peng_I usually use interactive commits when working on non-code files, so testing is moot.14:37
quicksilverLarstiQ: indeed; but I think you take my point.14:38
uwsPeng_: Ok, didn't know that.14:38
uwsbut 1.6 is not stable so I won't upgrade the server :)14:38
Peng_uws: OK. :)14:39
Peng_uws: You'll have to either downgrade your local bzr to 1.5 or live with that message and the second connection.14:39
=== ahasenack-flying is now known as ahasenack
LarstiQquicksilver: yes, I personally tend to agree, but there are ways to mitigate that risk.14:51
jamLarstiQ, quicksilver: Personally I only make the test suite pass when i'm ready to merge into the next level, so I'm not particularly concerned about the test suite passing on *every* commit.15:30
jamOne of the nice things about having layered branches.15:30
LarstiQjam: right, I didn't mean the *entire* suite. Just test exercising codepaths you've touched.15:31
LarstiQeven that may be too much, ah well.15:31
jamLarstiQ: sure, it is just my new response for partial commits, commit -i, etc, etc.15:37
jamI used to feel it was a bad deal, because you were committing something untested.15:38
jamBut as long as you test it at the time of merging it into the next level.15:38
LarstiQhmja.15:39
LarstiQjam: you're ahead of me in feeling comfortable about it :)15:39
jamLarstiQ: I have come to realize that feature branches are a *better* way of creating that perfect merge patch15:40
jamrather than trying to do it without committing15:40
jamEspecially when I'm exploring the space15:40
jamI'll do snapshots of stuff that I know I'm going to delete15:40
jamjust to have something I can revert to if I decide.15:40
beunojam, hi  :)  I haven't managed to get to the packaging yet, I will try to on the next few hours15:43
jamLarstiQ: I would say the biggest benefit is in development *pace*. I can snapshot as I go, and not fret *too* much about something breaking until I need everything to work15:48
jamIf too much breaks at the end, I can go back via the snapshots to something earlier, and tweeze the changes out from there.15:49
jamSo I commit small changes often15:49
jamand don't wait for the test suite to finish on all of them15:49
jamThough thanks to vila, I *do* tend do run the subset of tests that might be effected15:49
jam-s bzrlib.tests.test_foo is great15:49
jamwe just need to make it shorter :)15:49
LarstiQjust - instead of -s? :)15:50
jamLarstiQ: well, if we could just get it to read my mind instead15:50
jamthen it is just ''15:50
jamI think my current favorite is aliases, so that BT == bzrlib.tests and BP == bzrlib.plugins15:51
=== mw|out is now known as mw
pickscrapeIt would be clever if it picked if you from your working directory (assuming your working directory is a test directory)15:52
pickscrapeDamn, what happened to my English there?15:52
* gour is installing bzr-interactive15:56
james_wvi15:56
LarstiQjam: a stat to see which files got recently changed?15:58
jamLarstiQ: Interesting though I'm not sure if it would be perfect correlation16:01
gourhmm, any idea what's wrong with http://rafb.net/p/6VdGNy88.html ?16:03
jamgour: you logged in and so are pulling from a different URL into a checkout of the http url16:05
jamwhy not just "bzr update"16:05
jam(bzr pull will update both the local branch, and the branch it is bound to, but you are bound to an HTTP branch, and thus updating it fails)16:06
jamI'm guessing you've logged in, because it isn't warning you16:06
jamwhich means that it is pulling from bzr+ssh:///...16:06
jamand thus doesn't know it is the same branch.16:06
beunojam, older versions of bzr don't warn you16:07
beunogour, are you using 1.3.1?16:07
beuno(hardy default)16:07
gourbeuno: no, 1.7dev16:08
beunoah, then it is odd16:09
gourjam: hmm, i just wanted to 'update' upload plugin by pulling latest revs from LP16:09
gour..by pulling from LP to my local machine...strange16:12
VSpikeprobably a dumb question, but I've got a repo on a NTFS partition mounted in linux, and I want to do a commit on it but it shows everything changed because of permission bits (presumably)16:25
VSpikeI was going to copy it to an ext3 fs and then twiddle permissions, so I used cp -r but then bzr said it was not a branch16:27
VSpikeI manually copied .bzr because cp left it behind16:27
VSpikeIs that maybe because it is in a shared repository?16:27
Peng_Well, if your copied branch had no repository, that would cause problems...16:33
Peng_You should use "bzr branch", and maybe "bzr merge --uncommitted" if you want to pull the working copy changes too.16:33
VSpikeI've worked around it by using cp -a on the root of the shared repo16:34
VSpikeHow can I get bzr to show me which file properties have actually changed?16:35
VSpikeI tried using find to remove all permission bits, but that doesn't seem to be it16:35
VSpikeremove all *execute* bits i mean16:35
timnik"bzr diff filename" will show me a diff of filename's changes. How might I tell bzr to use a graphical program such as meld to show me the diff?16:56
timnikUncle google didn't seem to be of much help on this one.16:56
pickscrapebzr diff --using=meld ?16:56
timnikpickscrape, sweeeet :-)16:57
ToyKeepertimnik: bzr alias mdiff='diff --using=meld'   ...  then run 'bzr mdiff'16:57
timnikthanks!!16:57
timnikToyKeeper, oooh, I like :-P16:57
timnikthank you16:57
pickscrapeIsn't the bzr alias command new in 1.6?16:57
* ToyKeeper tries again to figure out how to split a subdir into a new branch, including only the history for that subdir16:58
gimakerpickscrape, correct.16:58
pickscrapeJust in case timnik is running 1.5 and find that doesn't work :)16:58
gimakeryou can still edit edit bazaar.conf manually though16:58
ToyKeeperSo far, it looks like 'bzr split foo/' and then 'bzr remove-revision N' for each unwanted rev N.  :(16:59
gimakerpersonally I like to use what ships with ubuntu, which is 1.3.116:59
TheEricfound a simple solution to our xpattern bug and bzr/lp with the revision history set to 0 - repush the last revision and *poof* everything was back to the way it was.17:01
ToyKeeperbleh, remove-revision seems to be broken.17:08
Necorodoes bzr-svn support stacked branches?17:46
Necoroso that there would not be the need to download large repositories17:46
* beuno releases Loggerhead 1.617:50
=== sm is now known as sm-work
james_wcongratulations beuno and mwhudson17:52
beunojames_w, thanks!  :)17:52
Necorohmm - ok ... atleast it works17:55
Necorowondering how long - or if I'm missing an important point ;)17:55
taconecongrats18:01
jambeuno: good to hear18:03
beunojam, next on my list is packaging bzr. So here I go...18:04
hsn_bzr check reports: 1 incosistent parent, is there way to determine what file/branches/projects are bad? its shared repo between several projects18:05
Peng_hsn_: Just run "bzr reconcile".18:07
PengOoh, Loggerhead 1.6. Congrats!18:07
hsn_Peng: i heard rumours that bzr reconsile takes hours to run18:08
Peng_hsn_: Is your repo gigabytes in size?18:08
hsn_about 0.5gb18:08
Peng_hsn_: Eh. It'll probably take a while then.18:08
Necorohmm ... are stacked branches a good replacement for looms?18:08
Peng_hsn_: A couple inconsistent parents aren't a serious issue. Reconcile will fix it, but you don't really need to bother.18:08
Necoroor not really18:08
Peng_Necoro: Are pencils a good replacement for skateboards?18:09
NecoroPeng_: hmm - then I misunderstood what stacked branches were supposed to do18:10
Peng_Necoro: They allow you to avoid storing the entire repo locally.18:10
Peng_Necoro: Sort of like a lightweight checkout, only it acts like a branch and you can commit locally and everything.18:11
Necorook ... but if you would make stacked branches of the "trunk" stacked branch you would end up with lightweight feature branches, right?18:11
NecoroI just noticed that looms does not work with stacked branches - and I don't want to download this 11k-revs-svn-repo18:12
Necoroso I'm looking for an alternative :)18:12
Necoroand having a stack of branches seemed reasonable ... because looms are a stack too18:13
jambeuno: do you want to send your email to the 'bazaar-announce@' as well. I think it is worthy and I'll "accept it"18:16
beunojam, yes!  I'll send it now, thanks  :)18:17
beunojam, sent18:17
jambeuno: Did you see: https://bugs.launchpad.net/bugs/25816618:18
ubottuLaunchpad bug 258166 in bzr "please package as non-native package" [Undecided,New]18:18
jamlamont feels we are being bad packagers18:18
beunojam, yeah, we talked it over, he's right, etc18:18
beunowe'll need to change the packaging doc a bit18:18
jambeuno: also, update the docs18:18
beuno:)18:19
Necorook ... branching fails if "A" is a stacked branch of an svn-repo and you are trying to create another stacked branch "B" from "A"18:19
Necorothen downloading the 11k revs is the only alternative =|18:20
lamontjam: I wouldn't care so much if it weren't 3MB+ of tarball and my  link being crap18:21
jamNecoro: branching from a stacked branch only creates a stacked branch if you request it18:22
Necorojam: i did: bzr branch --stacked A B18:22
Necoroso I requested it :)18:22
Necorobut I guess the problem lies in bzr-svn18:22
jamI'm surprised, as I believe it is something we implement.18:22
jamBut it may be something that is rough18:22
Necorotells me something about: bzr: ERROR: Connection closed: Connection closed unexpectedly18:23
jambeuno: one thing that would be nice, try to keep a good log of everything it takes you to make a release.18:24
jamI'd *really* like to see it more automated.18:24
jamIt takes far too much dev time to package a new release, considering we want to do 2 per month.18:24
jam(rc & final)18:24
jambeuno: also, it seems the dapper packaging has the old bug #24945218:25
ubottuLaunchpad bug 249452 in bzr "bzr overrides the shell prompt settings" [Critical,Confirmed] https://launchpad.net/bugs/24945218:25
beunojam, ok, I'll try and do it this time18:25
* Necoro just does the 11k revs pull now :)18:26
TheEricso, we fixed our issue with the revision history being set to 1 and not being in sync, but now we're getting the revision emails all over again. All 1264 of them.18:26
jamlifeless: I know you didn't like the workaround in status, but this seems to be the 3rd or 4th bug report of the status bug: bug #25835818:29
ubottuLaunchpad bug 258358 in bzr ""bzr status" errors" [Undecided,New] https://launchpad.net/bugs/25835818:30
* LeoNerd discovers the branch/uncommit/commit/replay method of fixing earlier commits18:36
LeoNerd7 shades of evil, but cute at the same time18:36
jamso what do you guys think about bug #25834918:36
ubottuLaunchpad bug 258349 in bzr "Special character "ß" cannot be used in the commit message." [Low,Triaged] https://launchpad.net/bugs/25834918:36
jamshould I mark it as 'invalid' because it is a limitation of cygwin?18:36
Necorohmm - ok18:41
beunojam, I think it's invalid, as bzr can't really do anything about it18:42
beunojam, btw, it seems the bzr 1.6* announcements are missing in LP18:48
jambeuno: hmm... did I make them?18:48
jamI think you have to do a separate announcement for a release.18:48
jam And it isn't part of the official "releasing.txt" document that reminds us about all that stuff18:49
beunojam, ah, ok. I just saw that 1.5 was the last one announced, so I thought it was18:49
jambeuno: yeah, looks like I manually did that in 1.5 (and for 1.5rc1) I'll go ahead and do it for 1.6rc318:50
jamI know poolie didn't for 1.6rc1 and the betas18:50
jambeuno: could it be that they were automatic when being put into the ~bzr ppa, but aren't because it is the ~bzr-beta-ppa ?18:52
beunojam, nah, poolie did it manually18:52
beunothey don't get done automagically, although that would be a cool feature18:53
Peng_beuno: Thanks for giving me credit in the Loggerhead 1.6 release. I've really enjoyed making my little contributions, and just watching you guys work. :-)18:53
=== ja1 is now known as jam
beunoPeng_, you absolutely deserve the credits, you're part of our test suite!18:54
Peng_Heh.18:55
Necorohmm - is there a way of having a diff of a branch to its parent branch sent per mail? - but not the "bzr send" way of working18:56
Necorojust the patch :) w/o having to do "bzr diff > some.patch" and then attach this to some mail18:56
KinnisonNecoro: You mean you don't want a bundle?18:57
NecoroKinnison: right ... because the project uses svn - and all the bundle information is just unnecessairy18:57
Peng_bzr send has a --no-bundle option. I think t'll still include a bit of meta data, but not that mcuh.18:58
Necoroand "bzr send --no-bundle" needs my branch being publically available18:58
Peng_Oh.18:58
Necorooh - it works, if I use "." as public branch =D18:59
jamNecoro: so as you commit multiple times, you want it to keep growing? Or you don't want this to be automatically done, just as a one-time thing?18:59
Necorojam: just when I finished some work (bug fix for example), I want all commits in one patch sent to the m-l19:00
jamNecoro: is there a reason you don't want the branch metadata included?19:02
jamAs then people can just "save attachment your.patch" "bzr merge ../your.patch"19:03
Necorobecause they do not use bzr19:03
Necoroand it would just be unnecessary noise19:03
Necoroprobably annoying some guys19:03
=== mw is now known as mw|food
NecoroI just noticed that git-send-email, which I took at the model for the functionality, actually needs patches as files19:06
Necorobut I don't want to have tons of patches lying around -.-19:06
Necorojust something like: "bzr send-this-loom --mail-to some@addre.ss"19:07
NecoroI guess, I have to write it by myself19:07
jamNecoro: 'bzr send -r thread:..-1 --no-bundle' though I guess you want to break apart the loom?19:12
jamI think something like that would be more-than-welcomed into the loom plugin.19:12
jamPossibly as a wrapper for the 'bzr send' command itself when you are working in a loom19:12
jam(like is done for 'bzr status' and some other commands)19:13
Necorojam: you need to specify the public branch ... so the correct command would be: bzr send -r thread:..-1 --no-bundle . .19:17
Necoronot the two dots :)19:17
Necoro*notice19:17
Necorobut I think there is still to much bzr-metadata in it19:17
jamNecoro: well, you could set your public_branch location in ~/.bazaar/locations.conf as an alternative19:17
Necorotruw19:18
Necoro*true19:18
jamThough 'bzr send' *is* meant as a way to convey bazaar changes between people (hence a public location if you don't send the metadata, etc.)19:18
Necorojam: yeah - BUT: this is the wrong assumption: not every project is using bzr just because one guy happens to do so ;)19:19
Necoroso for the moment I'll go with the normal "diff && attach to mail"-procedure19:20
Necoroand see if have some time left next month to write a nice "mail-to-non-bzr-users"-plugin :)19:21
=== meteoroid is now known as getmeteored
jamNecoro: I might point you toward bug #22734019:31
ubottuLaunchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Wishlist,Confirmed] https://launchpad.net/bugs/22734019:31
jamwhich at least seems related19:32
Necorojam: thx19:32
beunolamont, ping19:39
lamontbeuno: can I have a couple min first?19:39
* beuno hands a couple of minutes to lamont 19:39
rockstarIf I bzr upgrade a local branch, and then push it up to an existing branch on Launchpad, will that upgrade the branch there as well?19:40
Peng_rockstar: no19:41
Peng_rockstar: You'll have to run upgrade on Launchpad over sftp or (in bzr 1.6) bzr+ssh.19:41
rockstarI didn't think so.  Just trying to plan my upgrade properly.  the latest rc seems to have deprecated this specific format.19:42
lamontbeuno: wassup?19:42
beunolamont, so, I was looking at what I did for the 1.6rc2, and I did name the tarball .orig*19:43
lamontif the version in debian/changelog is FOO-BAR then you need bzr_FOO.orig.tar.gz19:44
lamontso did you name it bzr_1.6~rc2.orig.tar.gz, or something else?19:44
lamontand it needs to be in the parent directory of wherever you do debuild19:44
lamontwhich is to say, in the parent dir of bzr-1.6~rc2319:44
lamonts/3$//19:44
beunolamont, bzr-1.6rc2.orig.tar.gz19:45
beunothe - screwed me over, didn't it?19:45
lamontnote the missing ~19:45
lamontand the dash instead of underscore19:45
lamontonce you have the orig.tar.gz as it needs to be, if you forget the -I.bzr -i.bzr it'll bitch about binary files in the diff... :-)19:46
rockyjelmer: don't suppose you're around?19:46
beunolamont, ok, let's see how this turns out then...19:49
=== mw|food is now known as mw
Peng_rockstar: Yeah. Recent changes ruined the performance of pre-pack repos, so they were deprecated. It was about time anyway, since they're old and inferior.19:53
rockstarPeng_, yea, I knew there were upgrades needed.  I also know that a few of my last attempts didn't work.19:54
* rockstar procrastinates an upgrade19:55
Peng_rockstar: How large is the repo? If it's small or you have a speedy connection, it's no big deal.19:59
beunolamont, debuild -S -sa -i -D20:01
beunois still the correct command, right?20:02
* lamont goes looking for what -D does20:02
beunojam, if LP doesn't take up too much of my time next week, I may attempt to script this, and correct the docs20:03
lamontI expect that -i wants to be -i.bzr OTOH, if that command successfully builds a source package, and the .dsc references bzr_1.6~rc3.orig.tar.gz, then \o/20:03
beunolamont, lintian is now a bit happier than before: https://pastebin.canonical.com/8231/20:05
beunoand: dpkg-source: building bzr using existing bzr_1.6~rc3.orig.tar.gz20:05
lamontdoes debian/rules actually use quilt, or should the build-dep be dropped?20:06
lamontline 2 is "meh"20:06
lamontline 3-4 are expected20:06
beunowell, we don't use quilt in our PPAs, maybe Debian does?20:06
lamontdunno20:07
lamontin short, it's just saying that you claim to need quilt, but aren't seeming to use it20:07
chadmillerHi all.  One of my cow-orkers says his branch/repo reset its revno to zero.  Sure enough, "bzr log" starts with revno 6193, but "bzr revno" says "15".  Any ideas?20:07
lamont--> "meh"20:07
beunolamont, heh, ok. I can either change the standards version and remove quilt, reducing the amount of20:08
beuno"meh"'s20:08
rockstarchadmiller, bzr reconcile20:08
beunoor upload20:08
lamontif you change the standards version, you have to actually go read the cheatsheet to make sure you really are compliant20:08
lamontIOW, upload20:08
rockstarchadmiller, before he does that...20:08
chadmiller"'bzr reconcile' seems to have fixed some things.  I'm running 'bzr check' now."20:08
beunosince you've been so kind to help me, I'll let you decide20:08
chadmillerHe made backups, of course.20:09
rockstarchadmiller, damn.  That's a bzr bug that I know exists and would like to know the cause.20:09
chadmiller'bzr check seems to be hung however in the "checking versionedfile 0/20980"'20:09
* beuno uploads20:09
chadmillerI told him "check" will tak3e a while.20:09
rockstarCan you pastebin the logs ?20:09
rockstarFrom the old branch, the broken one?20:10
beunolamont, thanks a lot for your help, and please poke me if the debs have anymore problems  :)20:10
lamontthanks20:10
chadmillerrockstar: I'm getting them.20:11
chadmillerrockstar: It may be big.  Want it in email?20:11
rockstarchadmiller, that would be awesome20:11
rockstarpaul at canonical com20:12
chadmiller'kay.20:12
beunojam, so, by my calculations, once I've automated everything in my head, uploading bzr to all PPA's, sans bzrtools and other interesting plugins, it takes a bit less than half of my day away.  I wouldn't be surprised if doing it in full takes up a full day20:13
jambeuno: right, and we need someone to do that 2x per month20:16
jamNot to mention all the PQM time gardening a new release branch.20:16
jam(That has gotten better, though)20:17
beunojam, yeah, too much. On the bright side, it should be scriptable, because everything is really automated20:17
jamAnyway, out of 20 working days, killing 2 is 10% of a dev's time spent just getting releases out every moth.20:17
beunobut a script to do it would take a few days work20:17
beunowhich seems like a good investment20:17
jambeuno: sounds like you get paid back in 2 months20:17
jampretty good ROI20:18
beunoabsolutely20:18
jambeuno: *and* if it is automated enough, then *I* can do it, which gives you an even better ROI20:18
beunojam, heh20:18
beunowell, I don't really know if I'll be able to do this. I still don't have a manager, so I'm doing a little bit of everything. That may change enxt week20:19
beunobut I'll certainly try to do it20:19
jambeuno: who do you expect to be your line manager, btw20:19
beunojam, they're still trying to figure that out  :)20:20
beunoI'm hanging around in the lp-bzr team for now, which is where I already know everybody, and can be productive *today*20:20
beunoand I expect to be working on LP for the next few months at least20:21
jambeuno: well, you've been productive in #bzr today as well, so thanks :)20:22
pickscrapebeuno: while you're around, are you aware of any good docs on METAL?20:23
beunojam, happy to help!  :)20:23
rockstarpickscrape, zope's docs are pretty thorough20:23
beunopickscrape, zope has the best ones I think20:23
jambeuno: hey, that's my line :) (At least according to vila)20:23
beunojam, very happy to help  :p20:24
pickscrapebeuno: ok, I'll have a look. The ones google found for me were really sparse on detail and examples20:24
beunopickscrape, http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx20:26
pickscrapebeuno: thanks :)20:26
pickscrapeHopefully I'll be able to make progress on the breadcrumbs tonight. I hit a wall with it not recognising my second template20:27
beunopickscrape, cool!  let me know if you're stuck, I'll be happy to give you a push20:28
beunologgerhead is crack-ish sometimes20:28
beunoas rockstar   :)20:28
* rockstar is indeed crack-ish20:28
pickscrape:) Well, tal etc is completely new to me, so I'm learning as I'm going along20:28
beunoheh20:29
beunoI think I meant "ask rockstar"20:29
beunobut it's friday, and it's been a *very* active week for me20:29
pickscrape:)20:29
rockstarbeuno, by the way, paste has all sorts of profiling goodies.  I'm going to take a whack at it this weekend.20:29
pickscrapeHas the "unification" stuff been merged to trunk yet? If so I'll probably have a bit of fun with conflicts when I merge it :)20:30
beunorockstar, that would be awesome20:30
beunopickscrape, it has20:30
rockstarpickscrape, it has20:30
beunoand you will  :)20:30
pickscrapeok, I'll complete what I'm doing then before merging so I can do it all in one go.20:31
beunopickscrape, it's a great way to learn about resolving conflicts20:31
pickscrapeYeah. I'm used to the svk way (which is actually pretty nice)20:31
beunolamont, out of curiosity. All the other bzr releases had the .bzr dir in them, right?20:39
lamontonly if they were packaged without an orig.tar.gz20:39
beunoso just the last one I uploaded?20:40
beunopoolie removes them?20:40
lamont.bzr has binary files , and .diff.gz doesn't handle them20:40
lamontergo, they're not there, one way or another.20:40
lamont-mix 1520 : cat /home/lamont/.devscripts20:40
lamontDEBUILD_DPKG_BUILDPACKAGE_OPTS="-I.bzr -I.svn -I.git -i.bzr -i.git"20:40
beunoah, so you can leave them, if you do the .orig bit correctly20:40
lamontI tend to just not worry about remembering it. :-)20:41
lamonthow so?20:41
lamont.orig doesn't have a debian/ directory20:41
lamontand debian/.bzr is the bit that kills you20:41
beunoI'm confused20:41
beunodeleting the debian/.bzr isn't in the docs20:41
beunowhich makes me think poolie doesn't remove it20:42
lamontof course, there's no reason that I can think of to ship a stale bzr-1.6/.bzr directory as part of the source, when the current .bzr directory is what everyone wanting to muck with it should be referencing20:42
lamontwith the -I and -i options, you don't have to delete it, it becomes a -x.bzr to the diff command20:42
beunoI see20:43
beunook, so I don't need to add that extra step to the docs20:43
lamontso if you look at poolie's old source packages, you'll find that the diff doesn't have debian/.bzr in it.  exactly _how_ poolie accomplished that, dunno20:43
beunojam, after I finish uploading to PPA's, would you like to help me debug why bzr suddenly is eating *all* my ram + swap bringing my laptop to it's knees, to pull 1 day's worth of the LP source?20:49
beunoI've tried it 3 times now20:49
beunoand it does it every time20:49
beunohave to kill -9 it20:49
jambeuno: sure20:50
jamquid-pro-quo and all20:50
beuno:)20:50
beunolamont, jam, just uploaded the last of 'em. Dapper with the shell fix. I'm off for ~40 minutes, and then I'll check back to fix anything that I might have overlooked, and try to debug my bzr problem if jam is still around21:02
beunojam, nm about the debugging, it was bzr-search still trying to index everything21:04
jambeuno: yeah, first thing I was going to recommend was "--no-plugins" :)21:04
TheEricWhat's the "could not acquire lock" error?21:25
Peng_TheEric: It means whatever you were trying to operate on was locked (i.e. someone else is using it, or was and they crashed).21:29
Peng_TheEric: Or maybe you tried to write to something read-only, like http.21:29
TheEricany way to override that?21:31
TheEricThere was a bit of an error that we -think- was fixed in the revision history where it was out of synch with eveything else.21:32
Peng_TheEric: More details plz.21:35
Peng_TheEric: Locking has nothing to do with history issues.21:35
* meteoroid loses 10lb on the treadmill while branching a couple hundred revisions from fricking slow googlecode svn21:41
meteoroid:-P21:41
mwhudsongooglecode svn is pretty terrible21:42
mwhudson(especially *because it's google!*)21:42
meteoroidi know, i was surprised..21:43
meteoroidlooks like my idea of offering professional hosted, private SCM and other things for people like Trac is not so bad..21:43
meteoroidour svn is really fast, and soon i'll have bzr talking webdav or something fancy so i can use it as my personal primary21:43
lifelessin what way is googlecode's svn worse that $vanilla svn?21:51
jammeteoroid: have you looked at "bzr-webdav" the plugin Vila wrote?21:52
* jam is away for a bit21:52
lifelessbye jam21:52
meteoroidjam: yeah i haven't got the server setup yet21:52
meteoroidand i don't have 1.6 going21:52
mwhudsonlifeless: it's unreliable22:02
mwhudsoncode imports from google code rarely complete if it's more than a few hundred revisions22:02
mwhudson(this is partly because cscvs is terrible, of course, but ...)22:02
meteoroidlifeless: well, it's terribly slow, is the problem.22:07
meteoroid154 revisions and still maybe 75% complete22:07
meteoroidit's been over 20 minutes!22:07
meteoroidthe servers are either overloaded or excessively throttled22:07
meteoroidi mean, i pushed four revisions from bzr into svn at googlecode and it took 5 minutes..22:07
meteoroidfour revisions! a few config files and a python script that downloads code from elsewhere22:08
Peng_I don't have problems with Google Code's svn, but I guess I don't use it for anything large.22:10
Toraninanyone here have a recommended best way to convert a very long-historied (well over 90000 revs) svn repos?  I couldn't get the bzr-svn extension to work (may try again later), and it's looking like svn2bzr (dumpfile version) will end up taking like 2 weeks to make it through the whole thing22:13
Peng_Toranin: You should use bzr-svn, and get help here if you encounter problems.22:14
lifelessToranin: bzr-svn22:14
aquariusI've got one folder which is under bzr control; I've done bzr push to a private sftp repository. If I want to edit it on another machine as well, should I bzr branch sftp://wherever or bzr checkout sftp://wherever ?22:14
lifelessToranin: older versions will leak like a sieve (the bindings to svn were dud, new versions of bzr-svn have their own, and shouldn't leak).22:14
mwhudsonsome kind of fast-import based approach would be the other idea i guess22:14
lifelessToranin: if it does leak, just ctrl-C and resume22:15
mwhudsonbut yeah, bzr-svn would be the thing to try22:15
ToraninI have the new version, but the selftests fail22:15
lifelessaquarius: thats right22:15
Toraninwith the same assertions I see when trying it on the repos22:15
lifelessToranin: please do file a bug22:15
aquariuslifeless: heh. Sorry, my question was "which of those should I use?" I'm a bit unclear on the difference :)22:15
mwhudsonToranin: what version of bazaar22:15
mwhudson?22:15
lifelessaquarius: branch will make a new branch; checkout will let you work on the existing branch directly22:16
ToraninIIRC (this was a few days ago) 1.6rc1, with bzr-svn 1.4rc122:16
meteoroidToranin: do you have access to ubuntu hardy? that's how i keep bzr-svn functional22:16
meteoroidi just suck it out of svn then i can talk to it from plain-jane bzr from any other box22:16
Toraninno, I'm stuck with platform FreeBSD 6.3-RELEASE amd6422:16
aquariuslifeless: so if I checkout, then bzr commit commits straight back to sftp, but if I branch then bzr commit goes locally and I have to bzr push to get it back into sftp?22:17
Toraninbut I do have a jail with separate software22:17
lifelessaquarius: exactly22:17
Toraninso I can keep a functional bzr around without too much trouble22:17
lifelessToranin: so, I think you need bzr 1.6rc3 because there was a patch to bzr Jelmer put in on wednesday or so22:17
aquariuslifeless: ok, I'm starting to get a handle on this, cheers. :)22:17
meteoroidwell if you can get subversion 1.5 with its' python bindings working, you should be home free on bzr-svn22:17
meteoroidand that's the route to go, i think.22:18
lifelessaquarius: excellent22:18
aquariusand...if I already have the code on the second machine, and I bzr branch in that folder, will it cope with some of the files already being there? Or will it chuck some sort of horrible wobbler?22:18
Toraninmeteoroid: old bzr-svn (with svn's python bindings) on svn 1.5 gives an assertion failure and crashes the Python process22:18
Toraninsomething about paths not being allowed to start with a '/'22:18
meteoroidwhen does it give this failure?22:19
Toraninwhenever you attempt to run any command that accesses a repository22:19
Toraninwhether remote or local22:19
meteoroidsample command?22:20
Toraninhmm22:20
Toranin(this was a few days ago when I last tried it)22:20
Toraninbzr log svn+https://url/to/trunk22:20
meteoroidtry something like: bzr svn-import svn+http://some-svn-repo/22:20
meteoroidi had issues with high rev count but if you have the latest bzr-svn it should have a leaking issue fixed..22:21
Toraninmeteoroid: let me get the latest bzr and bzr-svn as of today, and I'll get back to you with results and selftest failures if any22:22
Toraninor to the channel anyway22:22
lifelessaquarius: if you run bzr branch somewhere, it will make a subdirectory and put its own files within that22:23
lifelessaquarius: you can copy your own versions over the result22:24
aquariuslifeless: ah. The folder in question is my home folder...so I wanted to do "bzr branch sftp://blah . "22:30
Toraninmeteoroid: okay, running a svn-import on a svn+file:// of a backup repos22:31
Toraninat 90488 revs22:31
Toraninit's at "determining changes" now, we'll see if it gets past there before I have to leave for the evening22:32
=== menesis1 is now known as menesis
meteoroidright on22:34
meteoroidhow much ram on this box?22:34
meteoroidyou did 'nice' right? heh22:34
meteoroidi found, btw, on a multicore, that branching http from localhost was faster because apache used 30-60% of a core and bzr would stay steady around 60-8022:34
meteoroidotherwise bzr just takes up like 60-80 wit a file://22:34
meteoroidprobably would be faster with svnserve because http is chatty22:35
Toraninno nice on it22:36
Peng_Toranin: You should watch the RAM usage, just to be safe.22:36
Toranin*nods*22:36
Toraninit's not using much22:36
Toraninonly a couple hundred MB so far, I have about 700MB of leeway in free/inactive RAM22:37
Toraninit's spinning at "determining revisions to fetch 0/33" now22:38
Toraninusing virtually no CPU and in BSD "lockd" state22:38
paskyHi! I've read http://bazaar-vcs.org/BzrVsGit#head-826d31d333758d3cd08eb5aeecd8bf77b1025373 and now I'm confused, how is that "far more flexible and powerful" than Git's alternates feature?22:41
bpetersonhi guys!22:44
=== sm-work is now known as sm
bpetersonI was wondering if https://bugs.launchpad.net/bzr/+bug/252212 can be fixed before the 1.6 release22:45
ubottuLaunchpad bug 252212 in bzr "can't stack rich-root-pack repos" [High,New]22:45
lifelesspasky: well its quite different, we also have an alternates-like feature22:45
lifelessI don't know that its "far more flexible and powerful", just a different want of structuring some things; but it is nicer IMO to be able to manage directories as directories22:46
paskyso what's the structural difference to alternates?22:47
paskyI'm sorry, I don't understand "manage directories as directories"22:47
lifelessalternates are pointers to a separate repository22:47
lifelessbzr shared repositories are a single repository which separate branches use for common storage22:48
paskyoh, I see22:48
paskygit can do that too :)22:49
* lamont gets popcorn22:49
paskygit "has" a git-new-workdir command that does pretty much the same thing22:50
lifelesspasky: "directories as directories" I meant to write "branches as directories"22:50
paskythe only catch is in the "has", since it's not part of the official command set (it's in contrib/) and it is pretty much completely undocumented22:51
lifelessgit-new-workdir looks a little raw22:51
lifelessit also needs symlinks which are not portable22:51
paskythat's right22:51
lifelessin a purely technical sense, bzr builds in the capability to do N workdirs -> M branches -> 1 history store, portabilty on windows/macosX/*nix22:52
lifelessmeh, no caffeine yet, please excuse my syntax and spelling glitches22:52
pasky:)22:52
paskyhow would you feel about "Git can achieve the same functionality by a semi-official git-new-workdir extension that has however many usability and portability problems?"22:54
Toraninmeteoroid: in case this wasn't obvious to you, if you point SVN_SSH at a script that looks like 'shift; exec "$@"' you can have it run svnserve locally and talk to it directly22:56
meteoroidthat's pretty neat..22:56
meteoroidit's obvious why it works but yeh i never thought of that22:56
meteoroidi forget that svnserve is just a different name for same executable22:56
meteoroidlike sh/bash22:56
meteoroidvi/vim22:56
Toraninwell, actually in this case the script gets run as "scriptname localhost svnserve -t"22:57
Toraninand it just pops off the localhost (or whatever hostname) and then passes control to svnserve22:57
meteoroidah sure..22:57
lifelesspasky: I don't think its the same functionality22:57
meteoroidthat's pretty clever :)22:58
meteoroidlearn something new every day..22:58
Toraninmine checks if the hostname is localhost and borks if not22:58
lifelesspasky: because there is no constraint linking the workdir to the repository, git can't prevent bad gc actions22:58
meteoroidam always telling people to write their admin scripts with bash instead of perl  because they will learn one-liners that are golden in an emergency22:58
meteoroidi challenge perl to have a decent one-liner with seven subcommands ;d22:59
ToraninI go back and forth between bash and Python depending on how elaborate they get22:59
meteoroidyah i'd tend to choose python if i went over bash22:59
pickscrapeI challenge perl to be readable ;)22:59
meteoroidhad a new client who needed me to clean up tons of deploy scripts22:59
meteoroidand i'm like22:59
ToraninI have an equals sign!22:59
paskylifeless: the refs/ space is shared so this would only cover *quite* a corner case when you have uncommitted objects in your index for more than 14 days, and even in that case it would be usually trivially repairable22:59
meteoroidthis is the same script, with variables changed in each copy22:59
paskylifeless: so I don't know if that's practical concern, unless you have something else on your mind?22:59
meteoroidwhy not set defaults that are for staging build and then have it accept options22:59
Toraninmaybe by the time I leave I will have two, or maybe THREE equals signs on the "determining revisions to fetch"23:00
meteoroideven my bash scripts do that ;d23:00
lifelesspasky: you get a copied index?23:00
meteoroidi mean, sure, chomp is funny sounding, and ~= is cool looking, but there is more to life ;d23:00
paskylifeless: well obviously, each workdir has to have its own index23:00
lifelesspasky: I guessed it would but confirming is useful23:01
lifelesspasky: I'm not a git dev :)23:01
ToraninRAM usage is creeping up, but it still looks heavily I/O bound -- <0.2% cpu use23:01
lifelessIf you wanted to change to the sentence you wrote, I'd be ok with that23:01
paskyso if you git add something and wait 14 days without committing and then git gc in another shared repository, the object will go away23:01
paskyok23:02
lifelessI'm sure other folk will tweak it back and forth23:02
lifelessthese things are dynamic :P23:02
lifelesspasky: while you are here, can you answer a couple of questions about git?23:04
paskysure23:04
paskyBTW, I'm also confused about "Git is not a realistic option on Windows"23:04
lifelesswhen you fetch, and get a pack over the network23:04
paskyI'm now using MSysGit daily and I'd appreciate if yo ucould elaborate on that :)23:05
lifelessIt seems obvious to me that you decompress every text to get its sha1 and index it23:05
lifelessbut do you keep the pack, or unpack to single files?23:05
paskywe don't decompress the text, the object id is part of the header of each object record; and we keep the pack23:06
paskyunpacking to single files is extremely rare operation that is used pretty much only for repairing corrupted packs, I think23:06
lifelessok, so if someone gave you garbage, you'll only notice when you access the object?23:07
paskyinteresting question :) let me check23:07
lifelessI mean e.g. a bit error in an object23:07
lifelessyou could hash the entire pack23:08
paskyok so I was wrong on at least one count, we do unpack to single files if there's less than 100 objects in the pack23:08
lifelessbut that doesn't prevent targeted attacks (not that they can get you to use wrong data, just to make you think you have content you don't)23:09
pasky(which makes sense since having many little packs is not much good, and sooner or later git gc will automatically fire up and collect the objects to a larger pack)23:09
LeoNerdCan I do a   bzr log -r a..b    which starts at the revision -after- a, i.e. the output doesn't include a itself?23:09
LeoNerdI tag all my releases with a 'RELEASED ...' tag, so I have a little script which finds the latest such tag...23:09
lifelessLeoNerd: its half-open by default I think :)23:09
LeoNerdbzr log -r `bzr-find-latest-RELEASED`..    <== includes the released tag itself23:10
paskyon your other question, there is a hash of the entire pack23:11
lifelessLeoNerd: hmm23:11
paskyand I currently don't see your targetted attack scenario?23:11
LeoNerdI vaaaaugely recall a VCS that can do   -r after:somespec   and so on.. is that bzr or something else?23:11
lifelesspasky: its would be just a nuisance23:11
pasky(I'm still reading the code :)23:12
lifelesspasky: take a pack, edit some delta content to nulls, rehash the pack, and then give that when requested23:12
lifelesspasky: you'll have some unreconstructable content and no warning23:12
LeoNerdOooh.. boo23:13
LeoNerdbzr can do  before:tag:whatever   but not after:tag:whatever23:13
LeoNerdFeature request? :)23:13
lifelesspasky: anyhow, the key question I had was about the work done during fetch23:13
paskyhmmm23:13
lifelesspasky: I've read the pack creation code closely23:13
paskythe code is trying to confuse me23:13
paskysince it suggests that objects in fact are uncompressed23:14
lifelessI would expect for correctness a full decompress23:14
paskywhich comes as a surprise to me :)23:14
paskybut I guess it's so23:14
lifelessLeoNerd: uhm, please bring up on list?23:14
LeoNerd"the list"? Ooh.. a mailing list?23:15
LeoNerdI suppose I could add another; I'm only on about 15 already :P23:15
lifelessLeoNerd: yeah, we have one of those :)23:15
LeoNerdYa.. most people do23:15
paskyhm, so yes, we do a full decompress and verify correctness23:15
paskyI currently don't see the code that verifies correctness of delta-based objects but that's probably just because I'm kind of tired :)23:16
lifelessLeoNerd: I think the bug is that log is not half-open when given a range23:16
LeoNerdIt is half-opten23:17
LeoNerdJust at the wrong end23:17
lifelessLeoNerd: no its not23:17
lifelesslog -r 1..223:17
LeoNerdMost people expect that   bzr log -r 10..20   should include 1023:17
paskylifeless: so thanks for teaching me more about git internals ;)23:17
lifelessshows 1 and 223:17
lifelesspasky: :)23:17
LeoNerdOh..23:17
LeoNerdYes..23:17
LeoNerdBut.. I want   bzr log -r 10..    to show 11 onwards, and not 1023:17
LeoNerdI imagine most people would complain23:17
LeoNerdIsn't   after:   easier to add?23:17
LeoNerdbzr log -r after:10..23:18
lifelessLeoNerd: if you can define it sanely23:18
lifelesswe have a graph ;)23:18
LeoNerdafter:10  is 11,   after:anythingelse dies23:18
lifelessLeoNerd: well you want after:tag:foo23:18
LeoNerdYes,..23:18
lifelessbut sure - lets raise23:18
LeoNerdBut tag:foo   is just a "nice" name for 10, no?23:18
lifelessno23:18
lifelessits a nice name for revid:SOME_UUID_HERE23:19
LeoNerdOoh.. hrm...23:19
Peng_Well, what does before: do?23:19
lifelessI'm sure its doable23:19
lifelessPeng_: left hand parent23:19
lifelessLeoNerd: I'm just saying we should take a minute to discuss23:19
LeoNerdRight..23:20
lifelessif we can tweak a fundamental to be more consistent23:20
LeoNerdOK.. I'll take a peek at the ML then23:20
lifelesse.g. merge -r x..y does not include x23:20
lifelessthen we can be simpler23:20
LeoNerdhttps://lists.canonical.com/mailman/listinfo/bazaar  <== this?23:21
lifelessLeoNerd: yes23:21
LeoNerdAww.. I don't get a choice of English (UK) ? :P Boo23:23
james_wbazaar is gone from Debian apparently23:27
LeoNerd?23:27
lifelessLeoNerd: the old C version23:27
LeoNerdOhdear... so you're right.23:27
james_woh yeah, sorry :-)23:28
LeoNerdOh.. ohyes. Got me all in a panic for a moment23:28
* LeoNerd recalls the SAS23:28
lifelesspasky: I can't comment on windows, I put away my windows-hacker cloths some time back23:28
paskylifeless: ok - I've just edited that section too to clarify a bit wrt. current state of msysgit, I look forward to seeing further edits by others :)23:29
paskynow my hands are off again ;)23:29
lifelessok ;)23:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!