=== michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === DShepherd [n=dwight@72.252.133.113] has joined #bzr [12:20] bzr is pretty neat.. [12:22] bzr uncommit feature is what I have been wanting for svn for the paste couple days.. [12:24] is it possible to check out an svn branch with bzr? [12:25] yes, with http://bazaar-vcs.org/BzrForeignBranches/Subversion [12:29] aahh sweet [12:34] How can i undo what bzr init does? [12:34] I guess rm .bzr -r [12:35] radix, hmm.. ok [12:35] beware of doing that, though :) [12:35] no fancy command :-) [12:35] radix, why? [12:35] well, .bzr is where everything is kept that bzr knows about it [12:36] if you delete it, you're deleting all history, etc. [12:36] radix, ok thanks for the heads up. [12:37] bzr init-repo #what does that really do? and when is it a good time to do it. [12:37] DShepherd: It creates a shared repository, which there is a document about === DShepherd is a bit confused.. svn guy [12:38] DShepherd: basically it makes it so that if you have a bunch of branches with common revision data, it can be shared in one place [12:38] hmmm.. [12:38] DShepherd: this helps with disk space usage, but more importantly (IMO) network I/O [12:38] radix, ok [12:38] DShepherd: because if you "bzr branch" a remote branch *into* your shared repository, if that branch largely has revisions that you already have, it won't have to download them again [12:38] DShepherd: but yeah, for extension info please read the document on bazaar-vcs.org (I'm sure a search will find it, I don't remember the name) [12:38] kool [12:39] s/extension/extensive/ [12:39] ok kool.. i am going thru the document now.. but its so much nicer to talk to people :-).. thanks for the heads up though === J-Unit [n=jdong@sharkattack.media.mit.edu] has joined #bzr [12:43] does svn even have selective commit?? cause that's kool [12:46] committing individual files instead of the whole tree? [12:46] both bzr and svn have that, with " commit " [12:48] radix, oh.. never used it before === DShepherd apparently is a under-user of svn [12:51] I'm not sure I know of ANY VCS that doesn't do that (I'm sure there are some, but I don't think any of the majors) === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [01:17] morning === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [01:28] hi igc [01:29] morning lifeless - have a good weekend? === asac_ [n=asac@debian/developer/asac] has joined #bzr [01:29] yuo [01:29] hi lifeless [01:29] bucks night; I'm still tired :) [01:29] hi LaserJock [01:30] :-) === Verterok [n=ggonzale@184-220-114-200.fibertel.com.ar] has joined #bzr === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr [01:32] Hi y'all [01:32] hi [01:37] lifeless: Hola! === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === asac_ is now known as asac [01:43] I'm going to start working to add multiple (eclipse) project per branch, to bzr-eclipse (the current implementation only support the branch at the root of the project) [01:43] my idea was to support one level up in the hierarchy, I'ld like to hear your thoughts about it [01:44] with one level, bzr-eclipse would support a branch with multiple eclipse projects as it's childs directories [01:46] I'm just going to run an errand, I'll be back shortly === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [02:10] back === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr === jelmer_ is now known as jelmer === orospakr [n=orospakr@bas4-ottawa23-1096745799.dsl.bell.ca] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === zbrown [n=rufius@unaffiliated/zbrown] has left #bzr [] === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [02:51] hello [02:54] hola poolie [03:18] hi === mw [n=mw@189.146.27.197] has joined #bzr === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [03:27] igc, would you like a call today sometime? [03:28] poolie: yes that would be good. How's 2.30 say? [03:28] or whatever time suits you [03:31] sounds good [03:34] igc: were you going to review the bytes_to_gzip patch ? [03:34] I can yes [03:35] still wrapping up the review of abentley's reconfigure one - when it's done, your patches are next === orospakr_ [n=orospakr@bas4-ottawa23-1096745799.dsl.bell.ca] has joined #bzr === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === luisfelipe [n=lfelipe@201-1-169-95.dsl.telesp.net.br] has joined #bzr [04:01] Hey guys, I need help. I'm using bazaar here on a project, I'm trying to pull some changes another guy did on his repo, but both pull and merge says that there's nothing to pull [04:02] ok === poolie_ is now known as poolie [04:03] luisfelipe: bzr missing can tell you the difference between branches in terms of commits [04:03] luisfelipe, if you run 'bzr log' on his repo, what do you see? [04:04] luisfelipe: I suspect he has not pushed, or you are not pulling/merging from the correct URL for his branch [04:07] the url is correct [04:07] I tried to pull, and it said that the branches had diverged [04:07] then I merged, and some of his changes came, but not all [04:09] oh, I think I've got it [04:09] sorry [04:10] lifeless, he had not pushed, only commited his changes === igc food [04:29] poolie: lol, win65 [04:31] lifeless: No one would buy the first release of win64. Personally, I'm holding out for win67. === jrydberg_ [n=johan@213.115.45.46] has joined #bzr [04:41] :) [04:42] Hmm. I'm getting a traceback when pulling from a knit branch into a pack branch. [04:43] oh ? [04:43] from bzr.dev ? [04:45] Yeah. [04:45] abentley, heh [04:45] Pulling a local copy of bzr.dev. I'm using your repository branch. [04:46] Peng: thats the known data issue [04:46] Peng: use abentley's delta fixing 'bzr check' patch on your copy of bzr.dev first. [04:47] abentley's delta fixing? [04:48] As in not bzr 0.90? [04:48] Peng: yes [04:48] Peng: this was all covered in the list [04:49] Peng: And I know I chatted with you about it before. bzr.dev has delta's that are not referenced from the inventory [04:49] this has to be fixed to use packs on them. [04:50] Okay. [04:51] (I *have* been reading the list, through Gmane's web interface. Guess I haven't gone far enough back?) [04:51] So...what do I need to do? [05:00] easiest is to take a branch of my copy of bzr.dev using packs [05:00] (you are failing on a new pull right ?, or incremental ?) [05:01] bbiab, lunch [05:01] Incremental? [05:02] Easier than using your copy of bzr.dev is simply not keeping a pack copy of bzr.dev. I was just doing it for fun. [05:02] I already have a knit copy. [05:03] ok [05:03] you shouldn't have trouble with any other project in pack form [05:15] !! [05:15] i didn't know '123' in '1234' was true [05:15] but it is [05:16] but only for strings, not other sequences === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === jml [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr [06:04] poolie: yay special casing [06:09] lifeless, can you have a look for me at test_selftest_benchmark_parameter_invokes_test_suite__benchmark__ [06:09] it does not seem to test anything like what the name says [06:11] i think it's a reasonable test but misnamed === Vantage13 [n=Vantage@www.toddcharron.com] has joined #bzr [06:20] igc: ping [06:20] h lifeless [06:20] poolie: are there dots in that name ? [06:20] not in the method name [06:20] hello [06:20] it is in test_selftest.TestSelftest [06:20] igc: does TestWorkingFormat4.test_id2path sound familiar ? [06:20] yes [06:21] is that a leading Q? [06:21] poolie: annotate it; I'll bet its misnamed due to refactoring [06:22] apparently not [06:22] heh [06:22] anyway I agree [06:22] igc: it is. I think that rename_one is buggy [06:22] igc: because it allows a rename to a non-normalized, non-accesible path [06:23] yes - the fix for that is in my patch. Digs ... [06:23] igc: you have a test for rename_one ? [06:23] whats the topic of the mail to search for [06:23] hi, i'm trying to use bzr-cvsps-import to import a cvs repository, but I always get "bzr: ERROR: Must end write groups before releasing write locks.". Any idea what might cause that or how to get more information? [06:24] Vantage13: api skew has affected the plugin [06:24] lifeless: see the end of http://bundlebuggy.aaronbentley.com/request/%3C46DC2EB1.3010901@internode.on.net%3E [06:24] Vantage13: if you use 0.18 it will work; I will try to fix that shortly if I can get a minute spare [06:24] that's the iter_changes commit one [06:24] lifeless: the fix was recommended by jam [06:25] igc: yah, thats the test change needed but its buggy [06:25] in which way? [06:26] rename_one() is broken [06:26] lifeless: You're very likely to be right. There are several emails ... [06:27] between jam and myself (all on list) re this. [06:27] yah, I was asking about the topic :) [06:27] so I could find em [06:27] There was talk about taking out some of the checking also. I'll dig so a moment ... [06:28] --- bzrlib/tests/test_workingtree_4.py 2007-04-26 22:56:01 +0000 [06:28] +++ bzrlib/tests/test_workingtree_4.py 2007-09-17 04:28:02 +0000 [06:28] @@ -420,6 +420,8 @@ [06:28] [06:28] try: [06:28] tree.rename_one('a', u'b\xb5rry') [06:28] + tree.unversion(['a-id'] ) [06:28] + tree.add([u'b\xb5rry'] , ['a-id'] ) [06:28] new_path = u'b\xb5rry' [06:28] that patch demonstrates the problem [06:28] lifeless: thanks. what's the command to grab 0.18? [06:29] clearly it should be a no-op. But it errors. So rename_one is facilitating a buggy api [06:29] That will fail I think [06:29] The problem is that add does extra checking that rename doesn't [06:29] igc: indeed, thats precisely the point, rename_one is allowing broken data into the dirstate. [06:29] yup [06:29] but whether add was being over strict was related [06:30] Vantage13: have a look at http://bazaar-vcs.org/src/releases IIRC [06:30] poolie: I'll call in 5 [06:30] Vantage13: our downloads page links to the tarballs, but the folder is listable; you can just 'tar xzf bzr-0.18.tar.gz && bzr-0.18/bzr' - you can run it without installing it [06:30] igc: so the topic was? [06:31] lifeless: https://lists.ubuntu.com/archives/bazaar/2007q3/030187.html [06:31] gah [06:31] Filename normalisation handling is the topic [06:31] just the topic please [06:31] I have no browser on this terminal ;) [06:31] :-( [06:31] lifeless: is this 0.18 of the bzr-cvsps-import plugin or 0.18 of bazaar? I thought bazaar was 0.90? [06:32] lifeless: Aug 21 from me [06:32] Vantage13: you need 0.18 of bzr, because 0.90 breaks the plugin [06:33] lifeless: That's an odd versioning scheme, isn't it? [06:33] Vantage13: we jumped from 0.18 to 0.90 as we approach 1.0 [06:33] igc: I see no discussion of add or rename_one in that thread [06:35] lifeless: so is this something that will be fixed in bzr or in the plugin? [06:36] Vantage13: Like I said, I will try to get around to fixing the plugin shortly; for now it will work fine if you just use an older bzr [06:37] lifeless: ok. I'm just curious which I'll need to upgrade in the future for the long term fix [06:37] the plugin ;) [06:37] lifeless: I usually use bzr from my distro and pull the plugin separately [06:37] lifeless: thanks! [06:38] poolie: seems to be no bzr-cvs-ps luanhcpad page; or am I searching with bad terms ? [06:38] lifeless: I'll look again. John and I have never discussed rename_one, only add. I'll just call poolie first then look as soon as I'm off the phone [06:38] hmm, Ill just fix it and mail the list [06:38] oh, bzr-cvsps-import got it [06:39] Vantage13: I'm reporting a bug on the plugin for you [06:40] lifeless: excellent. I'm just getting started with bzr and this was my first snag :) [06:42] bug 140048 [06:42] Launchpad bug 140048 in bzr-cvsps-import "needs update to use write groups (incompatible with bzr >= 0.90)" [Undecided,New] https://launchpad.net/bugs/140048 === luisfelipe [n=lfelipe@201-1-169-95.dsl.telesp.net.br] has left #bzr ["Saindo"] [06:50] New bug: #140048 in bzr-cvsps-import "needs update to use write groups (incompatible with bzr >= 0.90)" [Undecided,New] https://launchpad.net/bugs/140048 === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [07:41] igc: ok fixed and mailed. [07:41] igc: the key thing I've done different to you is to figure out the root cause :) [07:41] meh, that sounds wrong. [07:41] harsh but true :-) [07:42] I mean I made the test that was putting bogus data in fail [07:42] my issue was I wasn't sure what the correct behaviour really ought to be [07:42] the names in inventory and dirstate bjects should always be NFC/NKFC normalised [07:43] good ... [07:43] thats what the normalized_filename methods docstring says [07:43] and add enforces [07:43] the problem was that rename_one was not doing the same check as add === jml_ [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [07:44] so as I had suspected, my code (which was failing) was actually correct and the test was actually wrong. I'll look forward to reviewing your change then! :-) [07:45] review away [07:45] but bytes_to_gzip first please, thats blocking other changes for me [07:46] I'm thinking I can save a lot of hash update function calls [07:47] by doing sha1 sum of the byte block rather than sha_strings [07:49] interesting [07:53] 5% difference [07:53] (as a micro-benchmark) === jml_ is now known as jml [08:00] looks like it could be a 1.2% overall win === kgoetz [n=kgoetz@gnewsense/friend/kgoetz] has joined #bzr [08:01] hi all. just wondering if bzr ignores or reads robots.txt files? i have a deny: * line in my websites root directory, but i still want people to be able to checkout my bzr over http [08:02] kgoetz: thats fine [08:02] bzr isn't a robot [08:02] lifeless: sweet. thanks. === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr [08:11] poolie: want a chat ? === g0ph3r [n=g0ph3r@p57A0A0E8.dip0.t-ipconnect.de] has joined #bzr === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:47] lifeless: open_write_stream is dead code can I remove it ? === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [08:50] vila: dead? how so [08:51] lifeless: kidding, just wanted you to quickly page-in related info :) Its introduction broke webdav support [08:51] looking at it I wonder why you didn't define it Transport [08:52] s/it/it in/ [08:52] since it relies on other primitives [08:52] huh? [08:52] colour me confused [08:53] it is a_transport.open_write_stream [08:53] I saw the specific sftp implementation, but I don't understand why you didn't provide a *default* implementation in Transport [08:53] since sftp and memory use the same exact code [08:53] and remote too [08:54] grr s/sftp and memory/ftp and memory/ [08:54] so the FTP implementations ucks [08:54] *sucks* [08:55] anything doing self.append_bytes() as a thunk will perform heinously [08:55] fine for a default implementation by my book [08:56] default implementations should make sense [08:56] if the default is bad, its not a good default [08:56] the only transport that self.append() makes sense for is Memory [08:56] ok, that's the reason then. Fine, but webdav will use the same :-/ [08:57] webdav should definately do a chunked encoded streaming upload [08:57] or if the server is 1.1 [08:57] sorry [08:57] lifeless: chunked encoding is on my TODO list, albeit very deep :-) [08:58] if the next hop is a 1.0 in its signature then it should buffer locally [08:58] we do *thousands* of little writes [08:58] and the api is designed to allow that. [08:58] hmmm, and sftp provides buffering via paramiko ? [08:59] sftp streams [08:59] non blocking writes [08:59] I looked at doing a proper stream for the FTP one but it was going to be tricksy [08:59] IIRC [09:00] RemoteTransport will want to buffer too [09:00] but it doesn't yet [09:00] though RemoteTransport will hopefully not use the api ever as the smart server should kick in [09:01] lifeless: ok thanks for "default implementations should not suck" rationale, that was what I was looking after [09:01] I mostly understood the rest and will fix webdav with a default sucking implementation and a FIXME for buffering [09:03] lifeless: last bit, did you think about some criteria to trigger the buffer flush ? Is there some coherence to ensure about concurrent read or writes by other users ? [09:03] vila: its documented in the docstring [09:04] vila: have a look at the LocalTransport implementation for example [09:06] lifeless: meh, can't find anything on that subject, more precise pointer ? [09:08] LocallTransport.open_write_stream says: See Transport.open_write_stream... which defines the polilcy but local doesn't seem to implement it, still in your private branch only maybe ? [09:08] pydoc bzrlib.transport.Transport.open_write_stream [09:09] lifeless: do you notice a speed difference if the compression level is set to 1 instead of -1? [09:10] vila: look at the get method on local.py [09:10] igc: dunno [09:11] igc: the default (-1) is what hg uses FWIW [09:11] lifeless: ok [09:11] ok === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr [09:26] New bug: #140055 in bzr "socket leak in test suite" [Medium,Triaged] https://launchpad.net/bugs/140055 [09:31] ok, I'm out [09:31] night [09:34] lifeless: night - review just emailed btw [09:39] thanks === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr [09:54] vila: got a moment? [09:54] igc: yup [09:54] Q re bzrdir.open_from_transport ... [09:55] can I comment out the qualified_target = ... line? [09:55] or ... [09:55] should it be return get_transport(qualified_target)? [09:58] the FIXME implies we should return get_transport(qualified_target) *but* it's hard to verify [09:58] redirect can be on other schemes (ftp, sftp, etc) [09:59] ok, so ... [09:59] the problem is really when we are working with the non-default http implementation and the redirect will use the default http implementation [10:00] i.e.: http+pycurl is the default, http+urllib: redirects to http [10:00] code quality wise, what do you suggest given qualified_target is calculated but never used? [10:00] we begin with a urllib transport and ends with a pycurl transport [10:01] the code can be safely commented out, one can even write a test that exhibit the problematic behavior and make it an expected failure [10:02] I'll comment it out then as part of some cleanups to that module I'll submit [10:02] now that ConnectedTransport have been refactored, this bug may be more easy to address, but it may also vanish if we drop pycurl support [10:02] I like your idea of an expected failure test btw [10:02] I think that's the whole story, so in short, comment it out :) [10:03] igc: :) [10:03] thanks [10:03] in spirit the FIXME comment is a lazy way to do that :) === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [10:04] igc: just of out curiosity, how did you arrive there ? [10:04] FIXME grepping ? [10:04] vila: I was reading the bzrdir code as part of me reviewing abentley's reconfigure patch [10:05] I figured I needed to grok it in order to review the pack stuff soon as well [10:06] igc: hmm, bzrdir is hard to grok... [10:07] lots of static methods, I had to read a bunch of plugins for foreign vcs to understand why. [10:07] 44 A4 pages says to me that it ought to be a few modules in a package, not one big one :-) [10:08] moving old formats into a plugin as lifeless has suggested will improve things though [10:08] anyhow, time for some food === igc dinner [10:08] igc: enjoy your meal [10:08] thanks === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === rokahn [n=email@207-237-44-183.c3-0.nyw-ubr3.nyr-nyw.ny.cable.rcn.com] has joined #bzr [10:22] lets drop pycurl :) [10:24] I'm looking for version control system which I can adapt to store and retrieve XML diffs (as opposed to line-based diffs). Would someone on this channel know if Bazaar is a good choice (or what might be a better choice)? We already have software to generate the XML diffs and apply the XML patches so we're looking for a version control system which can be easily modified to use external programs for diff & patch. === fog [n=fog@debian/developer/fog] has joined #bzr === cfbolz [n=cfbolz@p54AB85C8.dip0.t-ipconnect.de] has joined #bzr === alfborge [n=alfborge@bacchus.pvv.ntnu.no] has joined #bzr [10:37] I'm trying to update my local branch against the upstream branch through sftp using bzr pull and bzr merge, but it's taking ages and showing no progress. [10:37] Both are running bazaar 0.90 === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr [10:38] Any idea what I can do to speed it up/find out why it's slow (or not working)? [10:42] The repos is 193M [10:43] (At least that's what it says when I do "du -hs ~/repos" [10:44] jelmer: Sorry for bothering but could you please merge tiny fix for push with overwrite from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? It is pretty straightforward ... TIA === asabil [n=asabil@62.70.2.252] has joined #bzr [10:48] alfborge: networking is still slow; 0.92 will largely fix this [10:48] alfborge: be patient and it will be fine === rml [n=Skippy@78.32.35.169] has joined #bzr === mvo [i=egon@nat/canonical/x-4dba28c88cb7846d] has joined #bzr [10:53] Is there a way to make bzr completely forget files? === metze_away is now known as metze [10:53] I.e. remove all history about the files. === NamNguyen [n=NamNguye@cm103.delta195.maxonline.com.sg] has joined #bzr === herzel93 [i=herzel@gateway/tor/x-ed949d807d176915] has joined #bzr === cfbolz [n=cfbolz@p54AB85C8.dip0.t-ipconnect.de] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr [12:09] alfborge: only madmen and dictators try to change history :) [12:16] Or people who accidentally added an ISO. [12:17] Peng: You can remove information about history (creating ghosts) [12:17] Oh, reallly? Cool. [12:18] Anyway, alfborge was the one who asked. [12:18] I'd like to do it too, but I converted to hg a month ago for speed. [12:18] it's not really exposed at the UI level yet [12:18] so it doesn't matter anymore. [12:18] jelmer: It probably shouldn't be. === Peng wanders off. [12:20] jelmer: Any docs on this? [12:21] alfborge: there's a plugin that allows removing revisions but it's not very efficient [12:21] alfborge: see remove-revisions on the plugin page [12:22] if I'd accidentally added an ISO, I'd just re-check out the verision before that mistake [12:22] but that's obviously not the solution if you want to weed out a file that's been in there for 20 revisions [12:24] Is it possible to check out up to r10, then bundle 12-15 and apply them? Or would it error out because 11 is missing? === Peng wanders off. [12:24] Peng: it would error out. but there may be a way to say "do this anyway" [12:25] Peng: No, that won't work. You could apply those as patches and commit them manually but that would create new revisions. [12:27] matkor: the abs in your latest commit is not correct [12:27] matkor: Negatives are used to indicate that the length of mainline has decreased [12:30] jelmer: OK. I think we need descriptive name for that ... [12:31] "%d revisions removed" "%d revisions added" ? [12:31] matkor: Eventually, we should display all the information in PullResult() [12:31] matkor: bzr pull in bzr itself used to print negatives as well, so I'd rather keep that behaviour until we start using PullResult [12:32] poolie: Hi [12:33] jelmer: OK. I will prepare correct revision and let You know :) [12:34] matkor: Cool, thanks! And thanks for the patch :-) [12:35] matkor: phanatic and I have been discussing ways to improve the development process of bzr-gtk [12:35] we'd like to start using BundleBuggy [12:36] so it'll hopefully become easier to get things merged and so we can have at least some review [12:38] bundlebuggy doesn't merge [12:40] NamNguyen: No, but it means merge requests don't get dropped but are remembered [12:43] jelmer: Whateve suits you best it's ok for me. Just let me know what and when I should do to fit new workflow [12:46] jelmer: I think cut down version of fix is on: https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor [12:47] matkor: it's ok to just create a new commit that reverts the abs() change, no need to keep one revision per feature [12:48] matkor: Thanks, pulled [12:51] jelmer: OK. thank you too :) === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === mrevell is now known as mrevell-afk === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === cfbolz [n=cfbolz@p54AB85C8.dip0.t-ipconnect.de] has joined #bzr === mneisen [n=mneisen@pD9E53D49.dip.t-dialin.net] has joined #bzr === niemeyer [n=niemeyer@200.103.134.216] has joined #bzr === mw [n=mw@189.146.27.197] has joined #bzr [02:25] New bug: #140419 in bzr "selective commit sometimes fails with `parent_id not in inventory` error" [Undecided,New] https://launchpad.net/bugs/140419 [02:26] Peng: any chance you'll come back? Have you tried the C patience matcher - its 10 times faster at diff, which is what was hurting you IIRC. [02:27] good night all, I'll look in scrollback :) === metze is now known as metze_away [02:33] lifeless: Don't worry, I still like Bazaar. But I'm planning to stick with Mercurial for this because converting the branch back would be a pain, Bazaar probably isn't going to beat it in performance any time soon, and I like being able to copy files. [02:35] lifeless: But I am curious to see how much faster Bazaar is, and I'm planning to try it out eventually. [02:49] imho, working tree performance is now acceptable for large trees but network performance is still not quite there yet === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [02:50] In my case, network performance doesn't matter much. === g0ph3r [n=g0ph3r@p57A0AF03.dip0.t-ipconnect.de] has joined #bzr === mrevell-afk is now known as mrevell === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr [03:40] New bug: #140432 in bzr "bzr fails with 'iteration over non-sequence'" [Undecided,New] https://launchpad.net/bugs/140432 === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === jdong [n=root@ubuntu/member/jdong] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === alfborge [n=alfborge@bacchus.pvv.ntnu.no] has left #bzr [] === rml [n=Skippy@78.32.35.169] has joined #bzr === Gacha [n=gacha@81.198.204.153] has joined #bzr [04:37] hi [04:38] How can I tell bazaar to ignore a directory? [04:38] when I type bzr ignore "./my/dir/" [04:39] it says: bzr: ERROR: [Errno 1] Operation not permitted [04:41] sounds like you have permissions problems in your branch [04:43] but the "./my/dir/" is correct? === RichardL [n=Skippy@78.32.35.169] has joined #bzr === RichardL is now known as rml [04:45] Gacha: yes, it is [04:45] the ./ shows that its from the begining of the tree, right? [04:46] yep [04:47] I checked permissions, everything seems to be ok [04:47] I'm using sshmount, maybe that the problem [04:54] Gacha: that sounds very very likely [04:54] ok, I will search for workaround [04:55] lifeless: to drop pycurl we need certificate verification. python-2.6 will have it, I'm still lurking for a way to back port it. === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp017.studby.uio.no] has joined #bzr === BasicOSX [n=BasicOSX@fortress.tanners.org] has joined #bzr === cprov is now known as cprov-lunch === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === rml [n=Skippy@78.32.35.169] has joined #bzr === beuno wonders what Launchpad does differently that it doesn't return that sftp doesn't update the working tree === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr [05:49] beuno: that there is not a working tree at all [05:49] beuno: If there's no working tree remotely, no message will be displayed [05:49] beuno: but that's not launhpad specific [05:51] hm, ok, that won't work for me, would a "cron job updating working trees" be too much of a hack? I'm having all kinds of permission problems using push-and-update plugin [05:54] beuno: that may result in locking errors while pushing every now and then, but other than that, it should work (won't corrupt any data) [05:55] jelmer, what would be a better approach then? [05:55] (if there is one) [05:56] beuno: the push-and-update plugin is the only thing I can think of === sandrot [n=santuri@c-71-199-230-127.hsd1.fl.comcast.net] has joined #bzr [05:57] also, locking collisions won't happen very often - only if the cron job is updating the working tree /and/ somebody is pushing changes [06:00] right, thanks jelmer, dato :D === MADnificent [n=madnific@91.194-136-217.adsl-dyn.isp.belgacom.be] has joined #bzr === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === herzel93 [i=herzel@gateway/tor/x-cb51d554443f6cc0] has joined #bzr === cprov-lunch is now known as cprov [06:43] hmm, the git pack + idx format is quite nice === mvo [i=egon@nat/canonical/x-a03ee738aeced60e] has joined #bzr === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === phanatic [n=phanatic@dsl54028253.pool.t-online.hu] has joined #bzr === mrevell is now known as mrevell-out === BasicOSX [n=BasicOSX@errant.real-time.com] has joined #bzr === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr === metze_away is now known as metze === mvo [i=egon@nat/canonical/x-62c2dade1455e9e3] has joined #bzr [08:17] is there a bug with moving symlinks in bzr 0.90? [08:17] I'm getting a "No WorkingTree exists" error [08:24] radix: moving how exactly? There have been some symlink related bugs in the past (and I have no idea what happened since the start of August) [08:24] hi, btw [08:24] yo :) [08:24] hmm, having trouble reproducing [08:24] maybe it has something to do with the fact that the target of this symlink is outside of the branch [08:24] and in fact it starts with a ../ === radix tries to repro with that [08:25] yeeeah, that seems to be the problem [08:25] or at least, I get a similarish error in my repro environment [08:26] http://rafb.net/p/TTFEQe32.html [08:26] (../foo/bar doesn't exist at all) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [08:27] mkay [08:39] hi LarstiQ. [08:40] heya james_w [08:40] LarstiQ: how are you? [08:40] james_w: ok I think, how about you? [08:40] I'm fine thanks. How was your summer? [08:40] LarstiQ: hey, long time no see, I think [08:41] hi dato [08:42] hi james_w. I tried a build of bzr-builddeb to upload it yesterday, but it died with some error I can't remember. [08:42] dato: aye, dropped of the internet at the beginning of August [08:42]