[00:00] lifeless: thanks, much appreciated! [00:03] lifeless: could you repaste to me or point me to the numbers for gc performance on bzr.dev please? [00:04] http://paste.ubuntu.com/116333/ <- these? [00:05] poolie: or the usertest ones ian did? [00:07] that looks right [00:08] that's the first 1000 commits of bzr? [00:08] So I'm using looms for something at the moment. I have two looms currently, and I have a change to make which belongs between them. Can I do that in any sensible manner? [00:08] poolie: thats more [00:08] poolie: I have the first 1000 stats , one sec [00:08] if this is more that's fine [00:09] so it's something more than 1000 commits of bzr? all of them? [00:09] 7410 [00:09] not sure of the revno [00:11] http://paste.ubuntu.com/117486/ [00:12] thanks [00:15] spiv: woo [00:15] spiv: no new failures, just that one test I discussed with John to tweak, and a 1200 line patch to eyeball :P [00:17] Heh. [00:17] Hmm, overdue for breakfast. [00:29] spiv: [00:29] # branch.sprout(bzrdir) is defined as using the branch format selected [00:30] # by bzrdir; format preservation is achieved by parameterising the [00:30] # bzrdir during bzrdir.sprout, which is where stacking compatibility [00:30] # checks are done. So this test tests that each implementation of [00:30] # Branch.sprout delegates appropriately to the bzrdir which the [00:30] # branch is being created in, rather than testing that the result is [00:30] # in the format that we are testing (which is what would happen if [00:30] # the branch did not delegate appropriately). [00:31] lifeless: +1 [00:31] which reminds me of something [00:31] what's the difference between clone and sprout? [00:31] mwhudson: push and branch [00:31] mwhudson: identical copy vs new line of development [00:32] spiv: so with that explanation, it seems reasonable to me, to say, if (remote), parameterise bzrdir with [arbitrary non-source branch format] [00:32] ok [00:32] spiv: and otherwise leave well enough alone [00:33] lifeless, spiv: pull is giving me grief in brisbane-core saying ... [00:33] "must end write group before releasing wrote lock" [00:34] igc: that means that its breaking in a @write_locked decorator [00:34] I've spent 30 minutes trying to find the problem but no luck so far :-( [00:34] and the code path isn't aborting the write group [generally a bug] [00:35] igc: disable that assertion, you'll see another one pop up; I thought we logged the real one or something, but perhaps not yet [00:35] I've looked at the changes to fetch.py, repository.py and pack_repo.py but nothing stands out to my untrained eye [00:35] spiv: ^ does my plan scan for you ? [00:35] lifeless: ok, I'll try that [00:36] igc: or even (if its nt a blackbox test) a pdb call inside the point that that is raise, would let you look at sys.exc_info [00:37] lifeless: yes, that sounds good [00:39] igc: ah yeah, as lifeless says that's typically like TooManyConcurrentRequests — there's an underlying exception being lost by the failure to abort the write group. If you can change abort_write_group or something to log the current exception first, or just reraise, that might help. [00:42] spiv: ok thats done and passing [00:45] spiv: suggstion: in those acceptance tests we have [00:45] spiv: put a ratchet now on the hpss call count [00:46] * spiv nods [00:52] spiv: bombs away, putting up a bundle - you can pull that to get the final code [00:54] Ok. [00:55] spiv: I think you didn't pair with me on enough of this that you can review it with clear conscience:) [00:57] in the meantime, I'm going to eat, then look at record_stream().next().get_network_bytes conceptually for a bit [00:57] possibly by walking, I think this is a thinking time [01:05] hmm, activity reporting works on svn transports but I'm not sure it should be kept in, it makes svn look slow :-P [01:06] jelmer: why? [01:07] lifeless: average speed is < 100kb/s [01:08] I'm getting much more than that for "native" bzr [01:08] lifeless: I was kidding, it works well [01:08] Hey, maybe there'll be an entirely new and original statement made in this thread about explicitly-vs-not tracking renames... [01:08] I guess I should just do some more optimization [01:10] hey all you wonderful people... [01:10] anybody gonna update the bzrtools package in the PPA? [01:11] I'd like to upgrade my bzr but I can't because it'll uninstall bzrtools, and I use those too much ... :( [01:11] lifeless, spiv: so disabling that exception didn't work, nor did looking at exc_info() via pdb ... [01:11] it does have an exception there about NotABundle but it's a red herring caused by .. [01:12] an attempt to read the location as a bundle early in cmd_pull [01:12] comment that bit out and exc_info is (None,None,None) [01:13] mtaylor: I don't know the answer to your question. [01:13] jml: oh well. [01:13] mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper [01:13] jml: yes. perhaps so. [01:14] jml: or, a release policy that ensures bzrtools goes to the ppa at the same time as bzr - I'd be fine with either [01:14] lifeless, spiv: it might be something dumb on my end - let me keep looking [01:14] cdiff, cbranch & clean-tree are about all I use from it. [01:14] patch sometimes [01:15] shelve [01:15] mtaylor: shelve is in bzr itself these days [01:15] shelve is my savior in many case [01:15] is it? [01:15] cool [01:16] there was also agreement about having clean-tree in bzr itself, but nobody has stepped up yet and actually done it [01:16] heh [01:16] * jml adds a personal todo [01:22] poolie: what are your plans for backports exactly? [01:22] igc: hi [01:22] poolie: addition to PPA or replacement? [01:23] igc: so unlock was being called and no exception had occured? [01:23] igc: what specifici test is doing this? [01:24] jelmer: in addition to the PPA [01:24] maybe not updated immediately when we release, and maybe not done for every release [01:25] igc: (I will run it and give it a shot) [01:25] > jml: mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper [01:25] i agree with jml [01:25] if "everyone has it" as seems to be the case why keep it separate [01:29] so network delta reuse [01:29] I think a sensible approach is: [01:30] each record in a stream has a network representation [01:31] we assume that a stream recipient can use any part of a stream they have seen before, for text extraction [01:31] we assume a stream recipient *will* extract every text, to validate them [01:32] a delta which needs data not introduced as a diff by that delta just includs that in its network representation [01:33] and the stream knows what to include/not include [01:33] finally, we have graph data seperate, but offer a single api call to get the right bytes for serialisation [01:34] this lets compressors like knits and gc which don't embed graph data not have to grow graph data foo [01:34] but lets compressors like weaves which do embed graph data just use the embedded data [01:35] a minor tweak would be to say that record.get_bytes_as(record.storage_kind) if record.storage_kind not in ('chunked', 'fulltext') will return something with inline bytes for graph and raw data [01:35] I'm not clear on what you mean by "a delta which needs data not introduced as a diff by that delta just includs that in its network representation" [01:36] spiv: a knit-delta-gz [01:36] spiv: with include_delta_closure == True [01:37] would just include its parents transitively up to a full text in the blob you get when you ask for the bytes [01:37] Ok. [01:38] so a naive implementation which never recompresses might include the same external parent several times [01:38] So the network representation for record can vary depending on the stream's include_delta_closure flag, and what has gone on the stream prior to that record. [01:38] (when we have include_delta_closure ==True) [01:38] spiv: yes [01:38] Ok. [01:39] spiv: should I start a branch that aims to test this and get it working with knits and weaves? [01:39] Yes please :) [01:39] ok [01:40] Hmm, I need caffeine, but I'm out of beans. [01:40] I have one remaining 'this may be bad' bit - which is that we may need (given this structure) to stash the stream of inventories during a rich root upgrade [01:40] because of the 'can use anything seen before' constraint [01:40] but I think writing a temporary versioned files to disk isn't really so bad [01:40] Ugh. [01:41] alternatively, we window it [01:41] we say 'anything in the last 256 items', and the generator knows that it has to track what parents are available in that window [01:41] Let's just kill non-rich-root already ;) [01:41] * spiv nods [01:41] spiv: well it still applies with xml -> bbc [01:41] I know :) [01:41] spiv: or even bbc-flavour-A to bbc-flavour-B [01:42] And I'm sure we'll be varying the inventory format again one day, we're good at doing that ;) [01:42] because we may need random access to data from the source which is at the far end of the wire [01:42] so we need a contract where the sender can say 'you need these texts to read my shit', here they are [01:42] and the recipient can then access them all [01:43] lifeless: I'm about to grab some food so here's a brain dump .. [01:43] to trigger it ... [01:43] bzr-gcchk init --gc-plain-chk xx [01:43] cd xx [01:44] igc: there isn't a test case that dies? [01:44] bzr-gcchk pull ../some-pack-branch [01:44] bzr-gcchk is brisbane-core with the latest groupcompress plugin [01:44] usertest is dying [01:45] it gets pass 900 revisions being pulled so my theory is ... [01:45] it's something in groupcompress/repofmt.py, around auto-packing say [01:46] bzr.dev is the test branch ? [01:46] I added -Dpack and looked at bzr.log ... [01:46] igc: oh, packing is broken [01:46] igc: I was discussing this with jam [01:46] btw, groupcompress/repofmt.py needs to import trace and use trace.mutter for -Dpack to work :-) [01:47] probably need to disable autopack at the moment [01:47] bzr.log had a message about autopacking to 1000 revs but it wasn't the very last message fwiw [01:48] lifeless: so what's the easiest way to disable autopack? [01:48] bzrlib.repofmt.pack_repo - in there somewhere ;) [01:48] lifeless: np. I disable it in fastimport so I'll do the same thing I do there :-) [01:48] poolie: thanks [01:48] hi - apologies for what's probably a basic question... ;) But - I'm testing bazaar on XP and the tortoise? integration into the explorer shell works fine - but the only major task it doesn't seem to do is rolling back between versions of a file. I can do it from the command line if necessary, but was wondering if I'm just missing something?! [01:49] * igc grabs some lunch [01:52] lifeless: a quick update ... [01:53] I tried the same thing with bzr.dev+groupcompress using gc-plain [01:53] igc: it should break the same way, if you do multiple write groups to it; fetch from a compatible repo won't do that though [01:53] it falls over as well, but in a different place - insert_record_stream inside the group_compress plugin [01:53] doozer__112: I'm not sure, perhaps you could file a bug? (If its not obvious, thats a bug, if its not there, thats a bug too :P) [02:04] poolie: re: performance figures, the insertion time includes disk read IO [02:05] poolie: so its not a reliable figure yet. My observation is that its not wildly off, as each pass thrashes on the same content :P [02:05] igc: a backtrace, and the exception would be good === RAOF_ is now known as RAOF [02:16] lifeless: heh, thanks, just playing with some of the other GTK based GUI's too.. [02:17] spiv: please paste your knit modem code :) [02:22] I'm having troubles with bzr-svn - I am pulling into an existing repostiory, and since upgrading to jaunty (bzr 1.11, bzr-svn 0.5.0), all my revision-ids used to have blahblah:Dir%2Ftrunk: and now they have blahblah:Dir/trunk: [02:22] So it sees the branches as having diverged [02:25] victory747: bzr-svn 0.5 is a fairly big upgrade, I suggest reading the release notes [02:29] lifeless: you mean http://people.ubuntu.com/~andrew/bzr/streaming-push ? [02:29] lifeless: the backtrace from pulling into a gc-plain branch has just been emailed to you [02:29] spiv: just the bencode bits :) [02:30] lifeless: http://rafb.net/p/rIAqn353.html [02:40] lifeless: Thanks - I think I understand now [02:42] igc: ugh, uhm [02:43] === modified file 'repofmt.py' [02:43] --- repofmt.py 2009-02-10 22:08:17 +0000 [02:43] +++ repofmt.py 2009-02-10 22:47:37 +0000 [02:43] @@ -300,6 +300,8 @@ [02:43] self._reconcile_does_inventory_gc = True [02:43] self._reconcile_fixes_text_parents = True [02:43] self._reconcile_backsup_inventory = False [02:43] + # Tell fetch what we require. [02:43] + self._fetch_order = 'topological' [02:43] [02:43] igc: ^ try that [02:43] igc: it shouldn't be needed, but if you have a broken source repo it may help [02:45] spiv: thanks [02:47] what's bzr for "up -r NN" where NN is a few revisions ago? [02:47] kenichi: currently the closest is 'bzr revert -r NN' [02:49] lifeless: that doesn't seem to work the way i'm thinking... i want revert the whole working copy to rNN. [02:50] kenichi: thats what it does [02:50] kenichi: after doing that, 'bzr diff' shows the change from NN to -1 [02:51] ugh.. sorry, i should stop working now... yes, thanks it works. [03:13] igc, the display of merges in the commit template is a good idea but not a post-rc thing i think [03:14] poolie: ok [03:14] poolie: did you see markh's email re tortoise docs? [03:15] he'll like them in 1.12 [03:15] apparently, it was ready for 1.11 but hasn't been landed by anyone [03:20] i landed something related to that... [03:21] is ther an external api reference? http://starship.python.net/crew/mwh/bzrlibapi-oe/ seems down [03:22] tro: you can run pydoctor locally [03:23] mwhudson: ^ [03:23] ah i see it [03:23] tro, lifeless, i'll see if we can run it on escudero [03:23] :) [03:36] Will upgrading my bzr in Intrepid fix this: "Selected-file commit of merges is not supported yet"? [03:36] or, is there a way to merge just one file [03:36] No, and not if you want merge tracking of it. [03:37] Crap. Okay, thanks [03:37] mrooney: you can merge just one file, but it becomes a cherrypick: 'bzr merge branch/FILENAME' [03:37] You can fling around single file changes or the like, but history-wise it's indistinguishable from doing the same thing manually. [03:37] lifeless: will merging again in the future (a full merge) work fine then? [03:37] mrooney: probably [03:38] okay that is what I need then, thanks I'll give it a try! [03:39] tro: http://starship.python.net/crew/mwh/bzrlibapi/ ? [03:40] tro: where is the -oe version linked? [03:41] our main doc server is apparently too old to have a packaged version of pydoctor [03:41] spiv: ping [03:42] lifeless: pong [03:42] spiv: how do you bdecode 'the first item from this long bytestream' [03:42] You don't. [03:42] ah-ha! [03:42] no wonder it was seeming difficult [03:42] At least, not with any bencode.py that anyone has written. [03:42] you could write one fairly easily [03:43] You could in principle do it. [03:43] But honestly, I've written enough network stuff like that in recent times :) [03:43] mwh: should i remove the link to the editable copy? [03:44] poolie: yes, i think so [03:46] spiv: so heres my structure [03:46] I have a NetworkRecordStream calss [03:46] which takes a bytes_iterator [03:47] and has a read() method that returns a generator which reconstitutes the input stream [03:48] I want to dispatch to some code that isn't written yet [03:50] so I want the generating code to output enough data that I can dispatch on it [04:46] spiv: is _length_prefix in bzr.dev? [04:49] lifeless: no, but it's trivial: [04:49] def _length_prefix(bytes): return struct.pack('!L', len(bytes)) [04:56] spiv: its ok for now I'm just handwaving, we can tune Monday [05:23] poolie: spiv: I'm calling it, have a good weekend [05:23] spiv: I have good progress at pushing that down to the VF interface [05:23] spiv: we'll still have to do the ugly vis-a-vis delta closures and so on [05:25] night ll [05:26] lifeless: cool [05:26] lifeless: the write group stuff is looking good too === poolie changed the topic of #bzr to: Bazaar version control system | 1.12 released 13 Feb | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [05:26] poolie: woo [05:34] spiv, can we have a really quick call? [05:36] poolie: I thought you were aiming for the 1234567890 timestamp :) [05:36] not precisely [05:40] Anyway, [05:40] Congratulations to the Bazaar hackers on your continued persistence. [05:44] AfC: even in the face of lengthy mailing list threads? :) [05:47] If it goes on long enough, somebody will say something that hasn't been said the last 50 times the topic was discussed. [05:47] Surely. Statistics alone... [06:38] Hm. The tarball for the 1.12 release is called bzr-1.12rc1.tar.gz ? [06:58] hi all [07:00] mtaylor: Are you having a problem with bzr/bzrtools getting out of sync ? Where are you getting them from ? [07:00] vila: from the ~bzr ppa [07:00] Both will be upgraded today to 1.12 if poolie finish the 1.12 release (which he should ;-) [07:00] vila: deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main [07:00] cool [07:00] In the mean time the bzr-beta-ppa contains both 1.12rc1 [07:01] mtaylor: which TZ are you in ? [07:02] vila: Pacific US [07:03] mtaylor: then you should have then when you wake up tomorrow :) [07:03] vila: yay! (although you are assuming I will go to sleep at a reasonable time...) [07:04] vila: so I _might_ have it before I go to bed! [07:04] mtaylor: now *you're* assuming I can produce them before you go to sleep :) [07:05] Sleep? Didn't we do that LAST week? [07:14] hi vila. Thanks for the review. I'll take a look next week. [07:14] igc: sure, enjoy your week-end, and remember that I like the overall direction, I just disagree on details :) [07:16] vila. cool. today was lost fixing fast-import bugs and trying to get the groupcompress stuff working under usertest [07:16] igc: and don't forget that failing test in usertest :-) [07:17] vila: which one is that? can you email me the details please? [07:17] I think I did in the past, but I'll mail a fresh one anyway :) [07:18] log from bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict [07:18] with a ~440 line output totally opaque to me :-/ [07:19] igc: still there in revno 137 === kiko-afk is now known as kiko [08:12] Hmm.. 1.12 released but tarball not on launchpad? [08:13] seems 1.12rc1 got uploaded again instead.. [08:33] Hi al!!!! === thumper_laptop is now known as thumper [08:39] night all - have a good weekend [08:44] lifeless: it seems so [09:23] is someone going to add bzrtools to the bzr PPA [09:23] so that my update-manager stops telling me I need to do a partial upgrade [09:24] (and so that I can upgrade bzr without removing bzrtools) === mvo__ is now known as mvo [09:45] radix: as soon as poolie fix the source upload, I'd build the ppas for both bzr and bzrtools [09:45] vila: cool, thanks [09:47] I jsut can't upload it myself being currently blocked by a failing test (apparently due to some weirdness in my install as ./bzr selftest bzrlib.tests.tree_implementations.test_path_content_summary.TestPathContentSummary.test_unicode_symlink_content_summary fails for both bzr.dev and bzr-1.12 >-/ [09:50] * fullermd gets a failure there too. [09:51] FAILED (errors=1, known_failure_count=2) [09:51] let's kill a chicken, how can pqm left that pass ? [09:54] I don't even know what it means :p [09:55] fullermd: what python version are you using ? What os version ? 32/64 bits ? [09:55] it suceeds on hardy inside a 32 bits VM but failed on intrepid in 64 bits native [09:56] 2.5.2 FreeBSD/i386 [09:56] 32 bits ? [09:56] Yah. [09:56] * fullermd can't imagine word size has much to do with it though... [09:56] Of course... just when I thought word size couldn't have anything to do with it you confirm that 32bit works :-( [09:57] Hm? It _fails_ for me. [09:57] Oh ! Thanks [09:58] do you have a python-2.4 handy ? [09:58] It would take a lot of sit-around-and-compile. [09:59] fullermd: nevermind, thanks anyway [10:00] Urgh, python-2.5.2 disagree with itself about encondig strings between my two tests 8-( [10:01] FWIW, 1.12rc1 out of the tarball "passes" (via SKIP'ing that test) on 2.5.2 FreeBSD/amd64 [10:01] 2.5.2 on hardy/32bits says: '\u03b2-path', where 2.5.2 on intrepid/64bits says: '\xce\xb2-path' [10:02] Oh, wait, I've got LANG=C on that box... [10:02] Yah, it fails there too with the UTF-8 locale. === Youssef is now known as UbuntuBoy [10:29] lol === thekorn__ is now known as thekorn [10:54] jelmer: I don't know if you committed the fix you mentioned earlier, but a bzr update I did just now took one minute and a half instead of the previous five minutes. Thanks :-) [10:59] jelmer: ping [11:02] brb === kiko is now known as kiko-afk [11:15] (I'm a n00b), what's the correct way to stop having a simple local bzr repository? [11:15] I just deleted the .bzr dir, that worked, but seemed wrong [11:15] Depends what you mean [11:16] Can you elaborate? [11:19] Well, if all you wanted was to abandon your revision control then removing .bzr works [11:19] Kinnison: Yeah, that answers my question :) [11:19] If you wanted something with more complex semantics then it wasn't necessarily the right thing to have done [11:19] Kinnison: is there a bzr command for that? [11:19] Kinnison: or is just ok to rm .bzr? [11:20] personally I'd use bzr export to create a non-controlled copy [11:20] and then tar up and backup the version with the .bzr [11:20] but that's because I don't abandon revision control, if I can help it [11:20] Me, I'd... well, not do it in the first place ;p [11:21] Kinnison: ok clear, thanks [11:21] sometimes I have to translate from one RCS to another, where importing the history isn't an option [11:21] what would be the equivalent of "svn update" in bzr? "bzr update" doesnt seem to do the same [11:21] ..neither "bzr upgrade" [11:21] bzr update does the same thing svn update does. That may not be quite what you want in a given case, though. [11:21] glade88: In a checkout, bzr update ought to work [11:21] Perhaps you want 'bzr pull'. [11:21] glade88: in a branch, you may want bzr pull [11:21] snappish [11:22] it is a Launchpad branch. [11:22] bzr pull LP:ideatorrent ? [11:22] simply 'bzr pull' will pull from the last location IIRC [11:24] damn this "ssh passphrase". can I make it not to ask each time? "ssh add URL" doesnt seem to work for some reason.. [11:24] URL=bzr+ssh://sayakb@bazaar.launchpad.net/~ideatorrent-developers/ideatorrent/devel/ [11:24] ^in my case [11:24] * fullermd didn't know there WAS a 'ssh add'... [11:24] fullermd: any other way to save the passphrase? [11:25] do you mean your ssh password, or your ssh key passphrase? [11:25] bzr doesn't have anything to do with that, TTBOMK. That's all in your ssh client. [11:25] Well, it has to be passphrase where LP is concerned. [11:25] There's a ssh-agent or something like that. [11:25] its my ssh passohrase [11:25] and yes, bzr has nothing to do with that :) [11:25] ssh-add ~/.ssh/id_rsa [11:25] that kind of thing [11:25] since it is the same for svn [11:27] Kinnison: fullermd: thanks, bzr pull works. I'll pondermore on the passphrase thing. [11:27] cheerio [11:28] * Kinnison 's suggested ssh-add commandline is what glade88 wants [11:28] Well, only once you have the agent running. [11:28] Just found this in the user guide (d'oh!): If you accidently put the wrong tree under version control, simply delete the .bzr directory. [11:28] And you need that ancestrally to all your terminal creations (or manual hackery in each) [11:29] fullermd: typically, linux systems start ssh agents as part of the X session [11:29] fullermd: As for other systems, dunno :-( [11:30] * fullermd always has a hand-crafted .xinitrc, so nothing gets started he doesn't order :p [11:30] Kinnison: w00t! yes, darn me I was using "ssh add" not "ssh-add". worksformenow (tm) . ty [11:30] fullermd: How retro :-) [11:31] Oh, that's not retro. What's retro is how the last line starts the window manager, ctwm :p [11:32] Oh dear [11:32] * Kinnison pats fullermd gently on his clearly damaged head :-) [11:32] But it's ctwm with a few of my own local hacks applied, of course. [11:32] Sorta like the web browsing is firefox with my local hacks, and the mail reading is mutt with my local hacks, and... [11:33] * fullermd . o O ( If the world would just cater to me more, things would be so much easier... ) [11:38] Oh dear. Somebody actually _likes_ $Log$? [11:38] fullermd: some even likes log --forward :-) [11:39] log --forward is almost as cool as missing --reverse! [11:40] Don't start *me* on --reverse :-) [11:40] * fullermd reverses vila on --start. [11:40] --start is good :-) [11:40] Hey, we should add stat --backward, to show the merge revs in the opposite order, too. [11:41] Then we'll cover the gamut better! [11:43] urf [11:53] Hi guys! [11:54] I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" please === bac_afk is now known as bac [12:21] (noob question) is it possible to co-develop a website using 2 computers which can't be connected through SSH (or something like it) using bzr? (Something like sending a whole repositorie as a file and merging it locally, and vice versa?) [12:22] nielsbom: Yes, with merge requests sent by email. [12:27] actually you can save a bundle to a file and transport it anyway you fell like it [12:28] for example a pen drive [12:29] Yeah, or a floppy disk or a punched card. I sort of assumed the two computers still had access to *some* net :-) === bac is now known as bac_afk [13:10] Lo-lan-do!? [13:11] I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" how can I do that please? [13:11] Lo-lan-do: you are not paranoid enough :) [13:12] UbuntuBoy: I don't even know what a windows service is... [13:12] lol [13:12] a deamon i u want [13:13] if [13:13] sry [13:13] a deamon if u want [13:13] UbuntuBoy: you know a service is not really a daemon right? [13:13] :p [13:13] yep [13:14] UbuntuBoy: so I'm guessing that if there is no service plugin and windows services are not mentioned on bazaar manual it is not supported [13:14] mmmhhhhh... [13:15] UbuntuBoy: but maybe there is a way to use unix tools or something from microsoft to use a daemon as a service [13:16] UbuntuBoy: why not use IIS and fastcgi? [13:16] because I prefer use directly bzr:// [13:17] its more easy [13:18] it's sry [13:20] UbuntuBoy: I don't really agree... but ok [13:20] :) [13:20] UbuntuBoy: use the unix daemon tools or unix tools that came with your windows server to do it [13:21] unix daemon tools ? [13:21] UbuntuBoy: with IIS you can easily integrate with AD also [13:21] I dunno [13:21] how [13:21] UbuntuBoy: I think it is unix tools [13:21] daemon tools is that thing to run .iso images [13:22] UbuntuBoy: as an Ubuntu boy you probably know how to link LDAP and apache... with IIS is probably even easier to connect to AD for authentication [13:22] authorization will be left as an exercise :D [13:22] hmmm [13:23] hmm... [13:23] i'm not really an ubuntyboy I took this nick becoz i didn't find anything else looooooooool [13:24] or my name === UbuntuBoy is now known as Youssef [13:24] like this [13:24] hihi [13:24] * Youssef put back his deguisment === Youssef is now known as UbuntuBoy [13:25] Youssef was cooler [13:25] Really? [13:25] okay === UbuntuBoy is now known as Youssef [13:25] hihi [13:26] ^^ [13:26] hmmm [13:30] Youssef: windows services for unix is deprecated I think, and don't do what you want [13:30] about what? === bac_afk is now known as bac [13:32] Youssef: I would suggest a post to the ML. [13:33] ML? [13:33] what is it? [13:33] sorry guys im a windows user I try my best to learn the linux world [13:33] it's a bit hard for me the please use full words [13:34] not only those characters lol [13:34] santagada! You said -> and don't do what you want <- what does it means? [13:34] Youssef: Mailing List. [13:34] loooooooooooooooool [13:34] okay okay [13:35] and why would you suggest me to post to the mailing list? [13:35] Youssef: I don't see a way to run a daemon as a service [13:35] hhoo okay okay [13:35] Youssef: because them more people can see your question [13:36] Youssef: and can give you a more complete answer [13:36] ooohhh [13:36] Youssef: or just because your question might become a feature request for a future version of bazaar :D [13:36] okay [13:36] mmhhhh... [13:36] Good luc [13:36] interesting hehe [13:36] luck [13:37] thankyou very much [13:37] guys [13:37] thanks a lot hehe [13:37] but one last question [13:37] where is the mailing list? [13:40] Youssef: https://lists.ubuntu.com/mailman/listinfo/bazaar [13:42] Lo-lan-do: thanks! [13:51] Can anyone tell me how to prevent bzr on windows from using plink for sftp (and get it to fall back to paramiko)? [13:53] I can force it to fallback by renaming plink, but I need plink on my path to edit remote files in emacs. [13:56] whoa, tumbleweeds, huh? [13:57] And crickets. [13:57] I don't know. [13:57] And I can't think who here uses bzr on Windows. [13:58] Fair enough! I might try the mailing list. [13:58] Probably wise [13:59] Cheers! [14:03] eh, I use bzr on windows, but not with sftp [14:04] do you just use it with launchpad? [14:08] no, I use it with bzr-svn and smb [14:20] xtian_: try with set BZR_SSH=paramiko [14:20] aha! Thanks! [14:20] Trying now. [14:21] Is there any reference where I could find that kind of thing in future? [14:22] That worked! Thanks heaps. [14:22] xtian_: I found it the mail list archive, but I'm sure it's in the official docs [14:23] xtian_: if you can't find it in the official docs, please file a bug about it [14:23] Wilco [14:23] Just looking now [14:24] Gah - there it is - I was looking for the wrong keywords. I could find mention of restoring auto-detection of plink in some bug threads, but not that. [14:25] Thanks again!. [14:26] xtian_: np, glad to hlep [14:29] Youssef: There is a tool in the windows resource kit for creating services of arbitrarily programs not having builting service capabilities. [14:33] What's the status of tracking cherrypicks in bzr? [14:43] verterok: that was short :-) [14:43] vila: me netwokr is flaky, hopefully be back at home during the weekend :) [14:44] /me/my === verterok_ is now known as verterok [14:44] s!/me/my!s/me/my/! :-) [14:45] :) [14:45] s,s!/me/my!s/me/my/! :-),s!/me/my!s/me/my/!, [14:45] :) [14:45] * fullermd hopes you don't try that in csh... [14:51] hi [14:52] yenzenz: Hi. :) [14:52] is this a known issue: download link to tgz of 1.12 release is broken at http://bazaar-vcs.org/Download [14:53] yenzenz: I wasn't aware of it. [14:53] Yes, it's known. [14:54] fullermd: ok, thnaks. so just a matter of time :) [14:54] {noob} I start a local repository on my pc (bzr init, bzr add, bzr commit), then I want to send the whole branch including all files to a colleague so he can start development on his own pc and then send patches my way. How do I export my whole dir, incl repository to him? Should I do that with bzr? Or just copy it? [14:55] You can copy the .bzr dir [14:56] Lo-lan-do: yes, I understand that, and also copy all the files in the dir in which my files reside. [14:57] You don't *need* to copy those, since they can be regenerated from the .bzr dir. [14:58] Even if he hasn't had the repo before? [14:59] The .bzr dir contains the full history. So he can just bzr reconfigure --tree and get the working files from that. [14:59] (Or just bzr checkout) [15:00] Well, if you send the .bzr from a dir with a checkout, you'd use revert... [15:00] vila: hi === thunderstruck is now known as gnomefreak [15:01] jelmer: hi [15:01] jelmer: did you see my mail about 1.12 [15:01] jelmer: did you see my mail about 1.12 ? [15:01] vila: Yeah [15:01] vila: Strange it's failing for you :-/ Does it fail both with dirstate C extensions and without? [15:02] It fails *with* C extensions [15:02] does it work without? [15:02] let me check [15:04] It works for me without, and fails with. [15:04] works without [15:04] ... [15:04] gha... [15:05] Lo-lan-do: ok, I'm starting to understand, I think (we're testing it now) [15:05] nielsbom: Maybe you could use the bzr-fast-export.py script from plugins/fastimport if you don't feel comfortable copying a .bzr dir. [15:06] jelmer: does it make sense to you ? [15:06] vila: Not entirely yet, but at least more [15:06] Lo-lan-do: I'm ok with that for starters [15:08] jelmer: with my patch, that's the opposite, fail without extensions, works with [15:11] Lo-lan-do: So I have a local repository, I committed to it, then I copy the .bzr directory to another directory, say example/. I then go to that dir and give the command bzr reconfigure --tree. I get the error "example is already a tree" [15:12] Lo-lan-do: "example/ is already a tree [15:12] vila; Looks like there's an inconsistency in dirstate C extensions / Python [15:12] nielsbom: Try "bzr revert" instead. Apparently the .bzr contains info on what's supposed to be outside itself :-) [15:15] jelmer: yup, we need more tests parametrized on C extension availability or not [15:15] vila, i.e. one already provides unicode, the other provides ascii [15:17] Lo-lan-do: cool, that worked thanks! [15:17] What are the consequences if we revert your patch ? Is bzr-svn impacted ? [15:18] vila: No, bzr-svn is not impacted, but some repositories will be impacted (as it'll break symlinks with unicode names) [15:19] vila, Do you really need to revert it though? Only newly added tests seem to fail [15:20] jelmer: well, I came across it just before a release... I don't think it should block it, but that's for the RM to decide... [15:21] jelmer: plus, it fails only under unclear circumstances... [15:21] jam: ping [15:21] vila: I mean, the alternative would be to just remove the tests added by my patch [15:21] hi vila [15:21] untested code is broken code :-) [15:22] vila, well, that seems to be what's breaking for you [15:23] jelmer: Only because I came across it via the test but I presume I can reproduce it from command line, so our users can too [15:25] vila: this was already broken from the command-line [15:25] my patch was meant to address it [15:25] jelmer: I understand that, don't get me wrong. [15:26] But it the fix seems incomplete then, even if you can't trigger it yourself (or so it seems) because, well, your setup is different [15:26] I can't reproduce it either under hardy/32bits inside a VM, [15:27] I reproduce it only under intrepid/64bits on a real host [15:27] Same python version: 2.5.2 [15:27] I fail to understand why the word size has an impact though.... [15:28] I'll see if I can reproduce on my 64bit machine [15:28] it seems strange indeed that the word size would affect the type of a field in dirstate.. [15:30] It happens for me on i386 and amd64 both. [15:32] fullermd: are you on BSD? [15:32] * jam seems to remember that BSD has different ideas about fs_enc [15:33] What's the thing that makes bzr spit its fs_enc out? [15:35] fullermd: um... python -c 'import bzrlib.osutils; print bzrlib.osutils._fs_enc" ? [15:36] the problem seems to be that the dirstate C extensions call _read_link() with a str argument [15:36] and the native Python code calls it with a unicode argument [15:36] UTF-8 [15:36] so the dirstate code should be using a UTF-8 string (always), which is probably incorrect on some situations [15:36] I note that (if it matters) it's the (PreviewTreePost) variant that fails. (DirStateRevisionTree) and the other options work. [15:37] Well. I assume pass == work. [15:37] jam: the dirstate code should always use unicode internally? [15:37] s/unicode/utf8 [15:39] jelmer: generally, yes [15:39] The paths stored *in* the dirstate file should all be utf-8 [15:39] And 90% of all processing is done via utf-8 strings [15:40] only when finally yielding them to upper layers do we decode it back to Unicode [15:40] and when reading from the OS encoding as _fs_enc? [15:41] jelmer: right [15:41] evening [15:41] hi LarstiQ [15:41] beuno: ping [15:41] hey jam [15:44] Hey LarstiQ [15:44] hi emmajane [15:44] hi jelmer, emmajane :) [15:44] jelmer, hello :) [15:44] LarstiQ, hello as well [15:44] emmajane, thanks for the report wrt the docs on samba.org, btw [15:44] jelmer, no problem. [15:45] jelmer, I wasn't sure if it was meant to work with local files, but not online. Or something. [15:46] emmajane, it's supposed to work, but seems to break from time to time as it's updated automatically [15:46] heh. Yeah. There's 'supposed to' and then there's 'output from scripts' :) [15:47] Does anyone else know if 'loggerhead' is fully plugin-ized now? [15:48] jam: yes, fsvo fullu [15:48] well, is "bundling it with the win32 installer" going to work [15:48] jam: I don't think it does the fancy decorating of 'bzr serve' yet [15:48] I guess is the question [15:48] emmajane, :-) [15:48] jam: ooh, goed question. [15:48] I think it will take a few steps [15:48] as it would also require extra dependencies [15:48] like we have to do with bzr-svn, etc. [15:48] I think I need to put together a spec [15:48] for handling setup issues with bundling plugins [15:49] * LarstiQ cries as selftest slows his netbook to a crawl [15:49] as I'm tired of having to edit bzr's setup.py for each plugin [15:49] vila, jam: So the problem seems to be that py_update_entry() calls _read_link() with a unicode string [15:49] vila, jam: Whereas the C extensions call it with a utf8 string [15:51] hmm... something odd here [15:51] as the C extension just passes through the "abspath" it was given [15:51] which is also what "py_update_entry" does [15:52] So I'm guessing it isn't the 'update_entry' code [15:52] but the _process_entry code [15:52] which is getting something wrong [15:57] And now for something completely different: an on-topic comment! :) [15:57] Next weekend I'm giving a bzr talk at SCaLE. I'm giving essentially the same talk as I gave before. [15:58] jam, pong [15:58] The slides are at: http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation if anyone has comments for add/modify/deletes. [15:58] beuno: on bug #328860, Martin mentions wanting to bundle loggerhead with the win32 installer [15:58] Launchpad bug 328860 in bzr "Win32 Loggerhead installer wanted" [Medium,Confirmed] https://launchpad.net/bugs/328860 [15:58] I was just curious if loggerhead has been fully turned into a "plugin" [15:58] The talk description is at: http://scale7x.socallinuxexpo.org/conference-info/speakers/emma-jane-hogbin (It's just an intro talk) [15:59] so that it would be bundled in the same fashion that bzr-svn, etc. would be [16:00] jam, poolie actually did turn it into a plugin during our sprint [16:00] let me find the merge proposal.. [16:01] https://code.edge.launchpad.net/~loggerhead-team/loggerhead/loggerhead-plugin/+merge/3095 [16:01] jam, ^ [16:01] I'll merge that in today [16:02] beuno: well, I won't change anything for 1.12 [16:02] just thought I'd check where things were at [16:02] Does that also decorate "bzr serve" ? Or is it just "bzr loggerhead-commands"? [16:02] it decorates serve [16:02] which is what prompted jml's work on it === Nicke_ is now known as Nicke [16:06] emmajane, do you have some other format than flash? gnash is not cooperating with me atm [16:06] Ooh look, a 1.12 tarball... [16:07] jelmer, is there an option to download the ODP from that page? [16:08] http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation/download ? [16:08] it gives a PDF, I think. [16:08] beuno: Will you also merge the init script for daemon-like operation? [16:09] emmajane, that seems to require login :-/ [16:09] (You did ask me to pester you :-) [16:09] * fullermd keeps waiting for the day flash joins java applets in the dustbin... [16:09] jelmer, boo to slideshare. [16:09] Lo-lan-do, I may put up a merge proposal for someone with a working brain to review :) [16:09] beuno, and will you remove start-loggerhead ? (-: [16:10] jelmer, not until I get config working with serve-branches :/ [16:11] jelmer, http://bazaar-vcs.org/Talks?action=AttachFile&do=get&target=bzr-intro-template.odp [16:11] emmajane, thanks [16:11] jelmer, thanks for looking! :) [16:13] Things you notice when updating packages: [16:13] bzrtools 1.12.0 is 1 'larger' than bzrtools 1.11.0. Thus, it's fitting that the tarball is also 1 byte larger. [16:13] a single byte, that is quite intriguing [16:14] "Well, it's one louder, innit?" [16:14] But why not make each byte bigger? [16:14] * fullermd nods at jam. [16:14] I thought so. [16:14] -SIZE (bzrtools-1.11.0.tar.gz) = 69765 [16:14] +SIZE (bzrtools-1.12.0.tar.gz) = 69766 [16:15] well, also of interest: [16:15] 3.8M Feb 9 04:42 bzr-1.11.tar.gz [16:15] 3.9M Feb 13 09:53 bzr-1.12.tar.gz [16:15] 1 (100kB) bigger [16:16] Well, not really. It's 39807 bigger. [16:17] s/bigg/loud/ [16:19] Of course, if you subtract that from the curent bzrtools, you get 29959. Subtrace that from the previous bzrtools, you get 9848. [16:19] Would Stackless provide any measurable speed improvements to bzr? [16:19] Sum those digits, you get 29, which starts the pattern. The next digit is the 9 again from the start of 9848. The 59 is one more than the trailing 48. [16:19] So it all works out anyway. [16:20] * fullermd wanders off to smoke some more crack... [16:20] seems to have done a lot for EVE Online, am wondering if bzr can achive similar performance gains [16:21] http://en.wikipedia.org/wiki/Stackless_Python [16:23] Toksyuryel: Without really knowing anything more, I would note that EVE and bzr are fairly different apps. ;) [16:23] Granted, but still :) [16:23] emmajane: seems good to me :-) simple, and quick [16:23] Essentially, I doubt it, because bzr isn't multi-threaded. [16:23] Morning! [16:24] emmajane, why does "bzr tags --sort=time" need special attention? The other commands mentioned seem much more common [16:24] hi jfroy ! [16:24] Is threading planned for a future development? [16:24] Toksyuryel: I don't know. [16:24] jelmer, it's just one that I use a lot myself (tagging what versions I send to the client). I talk a bit about it. [16:25] Perhaps implimenting threading and moving to stackless coule provide performance improvements over the current model? [16:25] *could [16:25] I would tend to doubt it, certainly in the near or mid term. [16:25] jelmer: congrats on 0.5 final [16:25] jelmer, thanks for taking a look. Much appreciated. [16:26] fullermd: I see [16:27] Toksyuryel, what would the benefit of threading be exactly? [16:28] potential speed increases? I'm just wondering and asking. someone's gotta actually answer the question with "yes that would make it faster" or "no it would not make it faster" :D [16:29] Toksyuryel: currently I think our big bottlenecks are stuff like graph walking [16:29] it is pretty hard to come up with efficient walking code [16:29] and even harder to do something that is also parrallel [16:29] One possible place would be text insertion, I guess [16:29] like I said... I am just asking. I am not saying "this would definitely be faster and you should do it right now". [16:30] if you are trying to insert 100 different texts, you could probably farm a couple of those out to different threads [16:30] please stop trying to spin my words to your own ends :) [16:30] I understand that it's not a high priority compared to other things which need to be done [16:31] jam: sorry to botther you but isn't this kind of stuff io bound? [16:31] santagada: some is, some is 'diff' bound [16:31] I expect the place we're most likely to pick up parallelism would be from python-level stuff, really. [16:31] stuff like 'annotate' could benefit [16:32] e.g., list comprehensions are inherently parallelizable. [16:32] Toksyuryel: You're talking about specifics, parallelism can be achieved through more than just threading [16:42] I was just asked by a friend if bzr had an equivalent to git add -p. He tells me it lets you commit a subset of all the changes in the branch, even from the same file. I've never done that in bzr, so I'm not sure. [16:43] You can specify files, you can use shelve to set aside bits before you commit, or... I think somebody wrote a plugin to do a darcs-style record? [16:43] (I don't know if/how well it works) [16:45] jfroy: Yeah, shelve is probably what he's looking for. [16:46] You use it put some of your changes on the 'shelf', commit, then use unshelve to pull them back off. [16:46] It has the advantage of allowing you to confirm that you haven't broken anything with the subset of changes you're committing before you commit them. [16:46] jfroy: it is sort of the "inverse" of add -p, in that you are taking off things you don't want to commit, rather than explicitly listing the things *to* commit [16:46] however, it leaves the tree in a state that you can run "make test" on [16:46] which is generally beneficial [16:49] Can someone tell me how to modify the 1200 second timeout limit in bzr? I'm experiencing a problem on several of our machines where they occasionally time out, not sure if it is because they are behind a firewall or not [16:50] Thank you all. [16:50] lbieber: do you have a .bzr.log of when that happens? [16:51] LarstiQ: one minute let me see if I can dig it up [16:52] lbieber: you can set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS [16:52] though if you are hitting that [16:52] (default is 5 min) [16:52] I'm guessing it is something else. [16:52] LarstiQ: ummmm, where would I find .bzr.log, I'm not seeing it anywhere? [16:53] ~/.bzr.log [16:53] Or if on windows $My Documents/.bzr.log [16:53] bzr --version spells it out for you [16:57] ahhhh - let me fix this first and see if it helps, from the log file - 0.120 WARNING: using slower ElementTree; consider installing cElementTree and make sure it's on your PYTHONPATH [16:58] I was wondering if http://paste.ubuntu.com/117733/ this is an error of bzr, launchpad or me? [16:59] Myrtti: That looks like a bzr problem. Is there any chance you could try with a newer version of bzr? [17:00] Myrtti: that is a known bug with bzr 1.6.1 when using -Dhpss [17:00] what bug happened that caused you to try and use -Dhpss [17:00] as that is the real issue [17:01] (that said, if you upgrade your bzr, it probably all goes away anyway) [17:02] what I did was I removed some of the launchpad projects and tried to rebranch them [17:02] bzr pull worked while the launchpad project working copies were there [17:03] but now http://paste.ubuntu.com/117739/ [17:05] so that looks more like you don't have you ssh keys set up properly [17:05] it may have been working before because you didn't do "bzr launchpad-login" [17:05] (so we were using anonymous http access, rather than authenticated bzr+ssh access) [17:06] Myrtti: OK, so you probably did the inital lp:foo branch before running 'bzr launchpad-login'. So the branches had the http:// location stored (because currently we store the resolved URL, not just the 'lp:foo' bit). Then you ran launchpad-login, and it's now trying to use bzr+ssh. But you haven't set up SSH keys with Launchpad. [17:06] well that's funny, because it gave me that even before I had logged in [17:06] and now that there is a proper ssh key at launchpad, it still doesn't work. [17:07] or that's what I think [17:07] Myrtti: What does 'ssh @bazaar.launchpad.net' give you? [17:08] Agent admitted failure to sign using the key. [17:08] Permission denied (publickey). [17:08] Ah, the seahorse-agent bug. [17:09] great [17:11] bug 328127 [17:11] Launchpad bug 328127 in gnome-keyring "gnome-keyring-daemon returns Agent admitted failure to sign using the key." [Low,Triaged] https://launchpad.net/bugs/328127 [17:12] that's funny [17:12] I'm on intrepid. [17:12] >___< [17:13] So am I, I have the same problem :/ [17:13] * Myrtti checks [17:14] gnome-keyring: Installed: 2.24.1-0ubuntu1 [17:15] Really odd. [17:15] I'm on xfce4 though [17:16] and I know about these things about as much as my guinea pigs know about particle physics [17:19] Myrtti: Try "SSH_AUTH_SOCK= ssh @bazaar.launchpad.net". [17:19] and presto it works [17:22] Odd_Bloke: thanks [17:23] abentley: from the standup reports you're not yet in nested territory? [17:23] LarstiQ: No. Hopefully next week. [17:25] Myrtti: :) [17:25] Myrtti: Adding a comment on the bug with your version details might be helpful. :) [17:26] abentley: k, I'm paging through a full test suite run log now, deferring most things for later, almost got myself convinced to commit/push the current status [17:26] LarstiQ: Great. [17:28] Odd_Bloke: done :-) thanks [17:29] Is bzr-1.12 compatible with bzr-loom 1.4? [17:30] I'm getting this when running bzr status: bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose' [17:31] The backtrace refers to /usr/lib/python2.5/site-packages/bzrlib/plugins/loom/commands.py [17:31] pickscrape1: Could you pastebin a more complete error? [17:31] sure [17:31] Is there one for this channel, or should I just paste anywhere? [17:32] any pastebin works [17:33] http://pastebin.ca/1336235 [17:33] pickscrape1: try updating your plugin I'm pretty sure it has been fixed on trunk [17:33] I was running it direct from apt... I'll uninstall that and grab it manually [17:33] pickscrape1: yup, seeing the traceback I'm even more sure :) [17:35] Is bzr-loom available in a PPA anywhere? [17:36] I don't think so [17:36] Do you get 1.12 from bzr-ppa ? [17:36] Did you get 1.12 from bzr-ppa ? [17:36] vila: yes [17:36] pickscrape1: did you get bzrtools too ? [17:37] I had to uninstall bzrtools because 1.11 was never uploaded to the PPA, so currently I have that installed manually [17:38] pickscrape1: could you try to install bzrtools from bzr-ppa ? [17:38] vila: yes, I will once I've fixed etckeeper, which has also just started complaining :) [17:38] pickscrape1: argh, no wait, the builds aren't finished yet :-/ [17:40] OK, using loom trunk has fixed the problem: thanks :) [17:40] etckeeper needed BZR_COMMIT_OPTIONS="--unchanged" === bac is now known as bac_lunch [18:11] woops, unlocking other_tree once too many [18:36] pickscrape1: bzrtools-1.12 available in bzr-ppa, can you try it ? [18:37] vila: I just did, and it seems to work fine :) [18:37] Thanks for your help [18:37] pickscrape1: great, thanks for your test :) [18:37] pickscrape1: which os/version/arch are you using ? [18:38] vila: jaunty amd64 and intrepid x86 (tested on both) [18:39] pickscrape1: you're my man, two birds with one stone :) [18:39] :) === serg_ is now known as serg === NfNitLoo` is now known as NfNitLoop [19:23] jelmer: I was wondering if you had some experience to share with setting up bi-directional bzr-svn syncing. === bac_lunch is now known as bac [19:55] jelmer: sup? [19:57] ronny: I believe he's away ATM. [19:58] hmm [19:58] -9 to 1234554321 ( 1234554330 19:45:30 UTC ) [19:58] [20:45] MinceR | A4Tech: no u [19:58] ops [19:58] touchpads + broken syndaemon are hellish [20:02] jfroy|work: I'm usung bzr-svn, maybe I can be of help? [20:04] Lo-lan-do: ok, so here's the use case. Project A is hosted in a Subversion repository over which I have little or no control. I want to introduce a Bazaar bridge, of sort, to allow some developers to use Bazaar as their main VCS. However, it is likely some other will continue using Subversion. [20:04] I'm only interested in syncing one branch, the trunk, [20:05] vila: ping [20:05] That is, the Subversion trunk with a Bazaar branch, from which Bazaar-using developers would pull and push from. [20:05] when I init-repo after I already have branches checked out, can I make them part of the repository, or they I need to re-clone? [20:05] miracle2k: check 'bzr reconfigure' I think it has some flags for that [20:06] jfroy|work: I think it's simpler for everyone if people just use bzr as a Subversion client then. [20:06] jfroy|work: I believe doing: [20:06] miracle2k: AFAIK you need to branch into the repo to get the branch to store its history data in it [20:06] bzr co svn+ssh://path/to/trunk [20:06] Should "just work" [20:06] as in, the developers can commit there, and it will update the subversion trunk [20:07] That's exactly what I'm doing, and it seems to works well. [20:07] Lo-lan-do: I see. So each developer would maintain their own Subversion trunk checkout. [20:07] jam, jfroy|work: There's a reconfigure --use-shared which I'm gonna try. Thanks. [20:07] miracle2k: ah, good to know, didn't know that existed :) [20:07] jam: thanks for the tip [20:07] jfroy|work: it is certainly the easiest way [20:07] there are always others [20:07] you can also [20:07] cd my-local-trunk [20:08] bzr pull ../my-branch [20:08] and if that succeeds (branches aren't diverged) [20:08] it should be the same as doing "bzr push svn://...." [20:35] Was a release email sent out for 1.12? [20:42] pickscrape1: I don't think so [20:43] Or it was sent, but Martin forgot to approve his email [20:43] Let me check [20:43] I just enjoy reading the release notes is all :) [21:08] pickscrape1: http://doc.bazaar-vcs.org/bzr.1.12/en/release-notes/NEWS.html#bzr-1-12-1234567890-2009-02-13 [21:08] Or to see the on-going one: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html [21:08] jam: thanks [21:28] lifeless: to your earlier question, "groups" do not get +junk branches: [21:28] bzr: ERROR: Permission denied: "/~bzr/+junk/bzr-groupcompress": : +junk branches are only available for individuals. Please consider registering a project for collaborating on branches: https://help.launchpad.net/Projects/Registering [21:29] bzr 1.12 and olive? i get errors on my ubuntu box. for example the log windows are shown, but the log itself is never shown [21:30] as such, I went ahead and created: https://edge.launchpad.net/bzr-groupcompress [21:31] since I needed to do a couple patches to the plugin === kiko is now known as kiko-afk [22:44] ronny: hi [22:44] jfroy|work: hi [22:45] hey [22:45] As you can read in your history, my question was mostly answered, unless you have something to add to Lo-lan-do's recommendation. [22:54] jfroy|work: ah, sorry, hadn't seen that [22:54] jfroy|work: yeah, his answer seems to cover it all - just pretend the svn branch is a bzr branch and all should be well [22:55] re [22:56] jelmer: just need to make sure the other developers who wish to use bzr understand they really need to not use a bound branch for daily work, because operations on that branch will be *slow*. [22:56] Your standard "train them a bit" situation, I suppose. [22:58] jelmer: im at the final point of vcs unhappyness, all reasonable vcs's have at least one major pain point i dont want to be brothered with [23:16] jfroy|work: just tell them to use 0.5.1, which will be lightning-fast [23:16] ronny: yeah, it's tricky to get right :-/ a task-specific API is probably easier than a generic one like anyvc [23:17] jelmer: nah, also all common vcs's have at least one fail that makes me hate them [23:23] jelmer: is that so? [23:24] (this is a worst case scenario, the svn server is still 1.4 with no plan to upgrade to 1.5 anytime soon :p ) [23:41] so.. [23:41] is there a irc hannel for paramiko?