[12:02] unlockable, sounds like an old tre format too [12:03] we don't use oslocks anymore except in dirstate, and there we don't use the transport api to them [12:15] is bzr compatible with my relaxed and debonair lifestyle? [12:15] because it turn out my lifesyle has library issues with Reality 2.4 [12:16] I just uninstalled Reality. I don't really have any use for it. [12:17] i gave up trying to port it years ago, but after a few weeks talking to our customers, sabdfl pretty much insisted i update. [12:17] lifeless, so i'm implementing iter_entries() [12:17] lifeless, what's the expected behaviour if a key is missing? [12:18] hmm, I would like to contribute a small patch to bzr [12:18] and am lazy to send it to the ML [12:19] any developer wanna help me in my laziness :D ? [12:20] lifeless, it appears from the tests it is skipped in the resulting iterator. correct? [12:27] anyone ? [12:27] keir: it gets skipped [12:27] asabil: file a bug with it then [12:27] asabil: it still has to be reviewed [12:28] list is probably easier for you, just bzr diff > foo [12:28] and send a mail [MERGE] thing, attach foo to the mail [12:28] lifeless: I created a bundle [12:28] lifeless: it i a tiny feature, basically adds branch description support [12:28] asabil: or you could just bzr send --mail-to bazaar@lists.canonical.com [12:32] asabil: with tests? [12:32] asabil: e.g. does push/pull propogate it, does 'branch' reset it ? [12:32] asabil: documentation as well ? [12:33] with tests [12:33] is the branch nick propagated ? [12:34] lifeless: it is implemented in the same way as branch nick [12:35] that's what someone suggested to me yesterday, is that wrong ? [12:35] nick isn't propogated anyhwere... [12:36] asabil: its not a matter of right or wrong [12:36] :/ [12:36] its a matter of deciding how it should work and making that clear to the user [12:37] I would have prefered if it was propagated [12:37] if its undefined its hard for writers to document it [12:37] also it will need a new branch format [12:37] I will patch my bundle to the ML [12:37] and maybe we can have some discussions over there [12:37] no ? [12:38] I guess Im' saying in short - 'chances are you are not finished yet; you should be the one to take it to the list as you will need to be involved in further discussions' [12:39] yeah will do [12:39] thanks for the tips :) [12:40] sent to the ML [12:40] lifeless, iter_entries() can return the items in arbitrary order, correct? [12:42] good night all [12:45] keir: yes [12:46] excellent [12:47] what i've written does one pass over the keys, collecting any blocks it needs to read [12:47] any keys that are already there get yielded [12:47] then it iterates until no one is reading [12:47] so it's breadth first, but this is the right thing for reducing round trips [12:49] right [12:49] the interface was crafted to allow this sort of optimisation :) [12:50] real 1m38.122s [12:50] user 1m30.430s [12:50] sys 0m4.600s [12:50] sneaking down [12:51] is it insane to write mykeys = set(keys)? that copies the list of keys, but i need to store which ones are still incomplete [12:54] profile profile profile [12:54] its very hard to predict just what will or won't be faster in python [12:54] if keys is a set, copying it is probably quite speedy === ionstorm [n=ion@71-35-60-24.phnx.qwest.net] has joined #bzr === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [01:02] morning === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr [01:04] hi igc [01:04] real 1m38.122s [01:04] user 1m30.430s [01:04] sys 0m4.600s [01:04] latest figures [01:05] wow! [01:08] softly softly catchee monkee === mw is now known as mw|out === fullermd had never considered using bzr for such a task. [01:12] lifeless: Do I recall correctly that since/aside from that adding-fields-to-index change, the pack disk format has been stable? [01:13] fullermd: yes. planned future changes are annotation d isabling (which is where those figures come from) and a new index layer === keir waves :) [01:14] :) [01:23] i have unit tests, but they are not really hardcore grind-the-implementation-into-the-ground type tests [01:23] if i swap in my own graphindex code, are the existing tests pretty good at puking when there's a data format error? [01:25] lifeless, fullermd, I'm starting to translate bzr's documentation to spanish for internal use in my company, are you considering including other languages for docs? Because if you are, I'll just translate it all, and probably in a more formal way [01:35] beuno: yes we are [01:35] keir: the current tests are two-layered; physical layer, and logical layer [01:35] lifeless, great, so I should create an "es" dir under docs, add em' and send for merging? [01:36] yes please [01:36] lifeless, perfect, will be sending the first bit in a few days then, thanks :D [01:37] keir: I suggset you look at the first class in the test_index.py file, which covers teh physical layer, and transcribe those tests to your physical layer (where they make sense) as well as considering outher things that could go wrong in your index [01:39] keir: the logical layer tests test the overall behaviour and *may* be sufficient for you; but do have a look/think about the ways it could go wrong [01:40] that sounds wonderful beuno - can't wait! [01:41] igc, :D I didn't know translations where welcome already, I'll try and poke other translators and see if we can get other languages in too [01:42] cool === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [01:43] beuno, the tree is setup to accommodate multiple languages for all the main documentation set [01:43] each language should have it's own index ... [01:43] for docs not translated, point back to the English ones I think [01:44] igc, yeah, it certainly looked that way, but I think I recall someone saying that it wasn't the time yet [01:44] could of been six months ago though :p [01:44] it depends on the maturity of the various docs ... [01:44] the main one still needing work is the User Guide ... [01:44] which unfortunately is the one most people would want translated :-( [01:45] so doing the User Reference first (for example) may be better? [01:45] yes, I'm planning to get some work done on the english ones too, but after looking at it, I'm not sure I enough understanding of bzr to do such a thing [01:45] the Mini Tutorial and Quick Summary are ready to translate as well [01:46] I already have some parts of the user-guide translated, mainly the conflicts and configuration, the ones people have requested most in here [01:47] that's great [01:47] I'm not saying don't translate the User Guide stuff ... [01:47] I'm saying expect some churn there in coming months [01:47] the index for other languages would be index.XX.txt, right? === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr [01:48] or XX/index.txt might work as well [01:48] poolie might have an opinion on that [01:48] igc, understood, it will be easier to edit the parts that have changed then to start from scratch, so I think most of the work won't be thrown away [01:49] yes - agreed [01:49] alright, I'm going out on my daily run, I'll read the backlog when I come back :D [01:49] the issue with the User Guide isn't extra content, it's lack therefof [01:55] major major mistake in a file, haven't committed it, how can I got back to the committed version? [01:56] bzr revert [01:56] bzr revert to only revert the particular file. === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by poolie at Wed Sep 12 03:35:03 2007 [04:19] lifeless: have you seen http://glyf.livejournal.com/72505.html ? === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr [04:40] spiv: I hadn't, but it lookslike he gets it === poolie [n=mbp@86.228.233.220.exetel.com.au] has joined #bzr === spiv nods [04:49] igc: [04:49] real 1m35.311s [04:49] user 1m28.602s [04:49] sys 0m4.600s [04:49] 16 seconds to go [04:50] sweet - let me know later today when you've pushed the branch and I'll test here [04:51] lifeless: your merges are spamming the ML btw [04:51] I've got one 4 or 5 times now [04:51] es [04:51] actually you have had pairs [04:51] new, last [04:51] several times [04:52] its a bug in bzr send [04:52] I saw that [04:52] I see at least one fourple. Dup from your mail server, hop out to internode is getting new ones. [04:52] if I review tuned_gzip.bytes_to_gzip, will you stop emailing it to me :-) [04:54] fullermd: bleh evo suckification [04:54] igc: as I'm not the one sending it I make no assertions [04:54] Heh. === fullermd builds a totem of lifeless's server in an attempt to appease it. [04:56] even lsprof runs are under 2m now [04:57] lifeless: I'm curious about incremental commit ... [04:58] your branch had a bug where shas were always coming back as '' [04:58] I don't see much point moving onto incremental until initial is sorted [04:58] yes thats right [04:59] its pushed [04:59] once that's fixed, many of the wins you're making will improve both [04:59] feel free to fix that :) [05:00] I'd love to - I'm reviewing abentley's reconfigure stuff right now though [05:01] k === igc food [05:05] poolie: I have a trivial patch to rearrange where CommitBuilder is that would be useful to merge to reduce conflicts [05:06] lifeless: around now. [05:09] abentley: I have forgotten what it was about; I've probably handled it in a patch I sent in anyhow [05:09] Okay. [05:10] BTW, were you saying there's a bug in bzr send? === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [05:13] yah, its in lp [05:13] evolution specific AFAICT [05:19] Are you using the direct evo implementation or xdg-email? [05:19] how do I tell [05:21] Do you have "mail_client" set to "evolution" in bazaar.conf? [05:21] I haven't put any setting in [05:22] Then it must be using xdg-email. [05:22] You could try setting mail_client, to see if that works any better. [05:23] ok, just mail_client=evolution ? [05:24] Yeah. [05:25] Or mail_client=editor if you want to go old-skool ;-) [05:28] meep [05:28] no I want evo so it goes to my imap folder [05:30] hurry up and wait time :) [05:30] poolie: I'm wrapping up shortly, do you want another call ? === pygi [n=mario@83-131-0-93.adsl.net.t-com.hr] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [06:10] hah! [06:10] another second bytes the dust [06:10] real 1m39.626s [06:10] user 1m27.449s [06:10] sys 0m4.528s [06:10] spiv: please pass that onto poolie [06:10] and with that, I'm out for the weekend. Damn early start:) [06:10] lifeless: done [06:10] cool === herzel44 [i=herzel@gateway/tor/x-28af533e74a995b5] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [06:24] well done lifeless - enjoy the weekend === ionstorm [n=ion@71-35-60-24.phnx.qwest.net] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === metze_away is now known as metze === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [08:21] hi all [08:23] Stevage: hi [08:23] spiv: hi [08:23] can anyone help with the traceback I just sent to the list? [08:23] spiv, it was pretty blustery but seems to have blown over [08:23] Stevage, i'll look [08:23] it's this one: TypeError: sequence item 1: expected string, NoneType found [08:24] also, is it normal that when I do a commit after some local commits, it first attempts to delete all the files I've added? [08:24] poolie: it rained pretty hard here, but only for a few minutes. [08:24] ie, add a file. commit --local. then update. immediately it deletes the file I added, then fails with that traceback. [08:25] (should have said, "when I do an update" rather than a commit...) [08:28] Stevage: ok, i see the traceback, i'm looking at the corresponding code [08:28] thanks [08:28] there's nothing weird in my sequnce of actions is there? [08:29] init, checkout, add, commit --local, update (in original directory) === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr [08:30] steveage, those commands look ok === Stevage nods === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:33] ok, so for anyone else who might be looking at it, the error happens because the dirstate thinks its first parent is None [08:33] ah [08:34] Stevage: are there any commits in the branch that you're bound to? [08:34] no, that .bzr.log is complete [08:34] it starts from a clean slate [08:34] right [08:34] ok, i bet the bug is today with trying to update to the null revision [08:34] s/today/todo [08:35] s//to do [08:35] so should I try adding and committing a file prior to all this? [08:35] just let me see if that's correct... [08:36] bang [08:36] that's it [08:36] Stevage: well, how about if you just commit the files, rather than committing --local? [08:37] well, I do actually want it to do it this way eventually [08:37] because I want the grouped commits [08:37] oh, you're using this to represent changesets that come from tlib? [08:37] as in, I want to commit each file once, then commit a group of files [08:37] yep [08:38] if I only commit at the higher level, I won't have as much precise information on each individual file, like the revision number it represented in TLIB [08:38] though I could always fake that if necessary [08:38] i think making one commit on the main branch before you start committing locally will avoid the problem [08:38] even if it's just [08:39] bzr commit --unchanged -m 'nothing' [08:40] yeah trying that now [08:40] is that really odd doing a checkout from an empty branch? [08:40] yep that worked! [08:41] i don't think getting the checkout is odd, but doing an update from it is... [08:41] well, it's a reasonable thing to do, but [08:41] well bzr won't let me commit until I've done the update [08:41] i guess it just wasn't tested [08:41] really? [08:41] yeah [08:41] it says I'm out of date [08:41] which is kind of bizarre by itself [08:41] that is === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [08:48] Stevage: ok, that's the best workaround for now then i guess [08:48] i'll file bugs about the two aspects of it [08:48] great thanks [08:48] that solves my problem anyway [08:49] oh it looks like this is already known, bug 120968, reported by spiv [08:49] Launchpad bug 120968 in bzr ""bzr update" in checkout of empty branch tracebacks" [Medium,In progress] https://launchpad.net/bugs/120968 [08:49] heh, when I click on "bug 120968" it goes to bugzilla's bugzilla [08:49] or rather, mozilla's bugzilla [08:50] hm, well, click the one ubotu said [08:51] yeah [08:52] hard to fix do you think? [08:52] Stevage: wouter may be online later, he currently has this bug assigned [08:52] no, i think it should be fairly straightforward === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr === pygi [n=mario@83-131-0-93.adsl.net.t-com.hr] has left #bzr ["Leaving"] === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === mdke [i=mdke@ubuntu/member/mdke] has joined #bzr [09:07] is there no way to commit just changes to a particular directory in the tree? bzr seems to be forcing me to commit all changes in the working copy [09:07] mdke, you can, except not after a merge [09:08] argh [09:09] poolie: is that going to be fixed? the merge and my working copy changes were completely separate in this case, it would have been nice to commit them together [09:09] i mean, not to [09:11] ah, I can still get a diff, that's ok [09:12] it's better to commit in your wc before you merge [09:13] poolie: in this case I did a merge yesterday, encountered a conflict, left it along because I didn't have time, then only remembered it when I had already made other changes to another part of the tree this morning and tried to commit them [09:15] anyone know how to get tortoisebzr going? [09:15] I'm getting "No module named win32com.server" [09:24] Stevage: that suggests you haven't got the pywin32 package installed. (http://sourceforge.net/project/showfiles.php?group_id=78018) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [09:26] ok thanks === mdke [i=mdke@ubuntu/member/mdke] has left #bzr ["goodbye!"] [09:36] Stevage: so it does work to get a checkout, then immediately commit [09:36] you'd hope so [09:36] yep, even with a blank commit [09:36] ok === jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr [09:55] New bug: #139549 in bzr "commit to empty master branch after local commits fails" [Undecided,New] https://launchpad.net/bugs/139549 [09:56] have a good weekend all [10:01] hi, how do i apply a merge-directive? [10:01] NamNguyen: `bzr merge ../path/to/merge_directive.diff` [10:02] NamNguyen: or you can try `bzr pull` first if you'd like [10:02] can it read from https? [10:02] ah, it can [10:02] awesome === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === mrevell_ [n=matthew@82-47-122-108.cable.ubr05.wolv.blueyonder.co.uk] has joined #bzr === cfbolz [n=cfbolz@p54AB83CE.dip0.t-ipconnect.de] has joined #bzr === mrevell_ is now known as mrevell === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr === phanatic [n=phanatic@dsl54009CE5.pool.t-online.hu] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === mvo [n=egon@p54A66616.dip.t-dialin.net] has joined #bzr [10:31] phanatic: Hi ! It would be easier here instead of exchanging emails [10:32] hey matkor, indeed :) [10:32] phanatic: Should I comment out revision details code (I would like save it for my futher reference), or delete completly that source part ? [10:33] I have not seen much commented out code in olive-gtk [10:34] commenting it out should be fine, as i've suggested in my last mail === fog [n=fog@debian/developer/fog] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [10:43] phanatic: OK, pushed [10:44] gnah === Theuni sighs [10:44] matkor: thanks, i'll merge it as soon as it syncs to http :) [10:46] I'm not quite sure what I'm doing wrong, but I keep loosing my committed revisions because I loose track of branches ... bah. [10:46] phanatic: Any idea how hunt those: "/home/users/matkor/.bazaar/plugins/gtk/checkout.py:148: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()" ? === g0ph3r [n=g0ph3r@p57A08C21.dip0.t-ipconnect.de] has joined #bzr [10:47] matkor: no idea, i don't get any warnings like this [10:48] phanatic: 2) Do You also have menus: branch/ initialize get checkout dimmed but allowed to select when out of working tree ? [10:49] I have to start olive-gtk inside WT and than go up out of WT to see it ... [10:50] matkor: no, they work as expected for me... [10:50] they should be inactive in a working tree [10:52] they are [10:52] but pls check my scenario. Start olive-gtk in WT, go up out of it, are they working but dimmed ? [10:54] matkor: checked. started olive-gtk in a WT, went up one level (no WT), and they are working + not dimmed [10:54] phanatic: Tnx, seems sth fuxored here, not much hurt to me though ;) [10:55] hehe :) [10:57] phanatic: OK. I am leaving to my work - thanks for help (and TIA for merge ;) ) [10:57] c'ya [10:57] matkor: thanks for helping out, laters :) === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === allenap [i=allenap@nat/canonical/x-c9a6c0ccee4e4bc3] has joined #bzr [11:30] phanatic: Any idea how to work that case out: Unable to obtain lock ... locked 1 hour, 58 minutes ago Will continue to try until 11:32:15 in olive-gtk ? [11:30] Wait for two more minutes :-) [11:33] Lo-lan-do: yeah... gui users will be delighted with frozen app ;) [11:34] matkor: there is a wishlist bug filed by jelmer to implement some GUI stuff for breaking locks [11:34] but no progress on that i guess... === jix [n=jix@dyndsl-091-096-040-028.ewe-ip-backbone.de] has joined #bzr [11:42] phanatic: Does bzrlib calls return with info about held locks ? Or hold control and wait to next try ? [11:43] i guess (but i'm not sure) that bzrlib raises an exception if something is locked and cannot be accessed === mvo [n=egon@p54A66616.dip.t-dialin.net] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr [11:57] hi guys [11:58] hey schierbeck [11:58] i'm making some fixes to bzr-gtk, but this is the first time i've used bzr for such a purpose, and i just want to know how to go about submitting my fixes [11:58] i've registered a branch on launchpad, but should i let the devs merge from that branch or give them a bundle? [11:59] schierbeck: here's the workflow i'm using for bzr-gtk: 1) create your own branch of trunk 2) modify it locally 3) push it to lauchpad as your own branch 4) request merge [11:59] giving the pointer to the branch is enough [12:00] phanatic: thanks, i'll do that === mvo_ [n=egon@p54A66616.dip.t-dialin.net] has joined #bzr === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === asabil [n=asabil@62.70.2.252] has joined #bzr === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === scorpioxy [n=alaasalm@85.112.67.147] has joined #bzr [01:06] Hey guys. I have a question, i branched from a repo on Launchpad and i need to update the branch with the changes. Isn't the proper way to do that is via a bzr pull? [01:08] Depends if you made local commits. [01:08] If you did, you need bzr merge. If you didn't, bzr pull will work. [01:09] nope, nothing. I just want a copy of the development. [01:09] but bzr pull complains about a location [01:09] why doesn't it just use the branching location? [01:09] You can bzr pull --remember once, and it'll reuse it later [01:10] Well, i did that and it threw a stack trace at me. The error was that the transport is read only. Let me try that again maybe i got the url wrong. [01:11] yup. I just checked [01:11] scorpioxy: did you do `bzr branch http://...` or `bzr checkout http://...` ? [01:12] oh by the way, it was a check out not a branch at the first operation [01:12] right. so you want `bzr update`, not `bzr pull` [01:12] Ah. It should be bzr update then, I think. [01:12] ok, so a bzr update also throws the same error [01:13] transport is read only [01:16] Its for the awn project on launchpad, so nothing really strange here. So am i doing something wrong? === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === mrevell is now known as mrevell-lunch === mw|out [n=mw@189.146.24.28] has joined #bzr === mrevell-lunch is now known as mrevell === NamNguyen [n=namnt@203.162.163.50] has joined #bzr === niemeyer [n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === allenap [i=allenap@nat/canonical/x-7feee93864d0217e] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === mw|out is now known as mw === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === mrevell is now known as mrevel-brb === mrevel-brb is now known as mrevell === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === jix [n=jix@dyndsl-080-228-189-008.ewe-ip-backbone.de] has joined #bzr === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr === spiv [n=andrew@canonical/launchpad/spiv] has joined #bzr === metze is now known as metze_away === RichardL_ [n=Skippy@78.32.35.169] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has joined #bzr === g0ph3r [n=g0ph3r@p57A08C21.dip0.t-ipconnect.de] has joined #bzr === RichardL_ is now known as rml === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === asak [n=alexis@201-26-55-48.dsl.telesp.net.br] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === cprov is now known as cprov-lunch === bialix [n=F1@77-109-18-154.dynamic.peoplenet.ua] has joined #bzr === bialix [n=F1@77-109-18-154.dynamic.peoplenet.ua] has left #bzr [] === jprieur [n=jprieur@ARennes-256-1-95-199.w90-32.abo.wanadoo.fr] has joined #bzr === cprov-lunch is now known as cprov [06:38] is there anyway I can *just* push a working tree? I would like to upload websites without having to double their space usage by having the repository online too [06:38] Well, I do it with make :p [06:40] yeah, make & rsync here. === mvo [n=egon@p54A66616.dip.t-dialin.net] has joined #bzr [06:40] so "not with bzr" would be my choice, right? === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [06:41] yes [06:41] gotta use the right tool for each thing [06:41] Considering there's no way to push a working tree period, I doubt there a way to push _just_ a WT... [06:41] what do you use "make" for? the rsync part I can understand... [06:42] to type 'make' instead of 'rsync --foo --bar --baz hihi haha:hoho' [06:42] Well, I don't use rsync. 95%+ of my deployals I have local access to, so I use install(1) wrapped with make. [06:42] 'make upload' is the usual suggestion [06:42] I have gone as far as saving which was the last revision I pushed, ran a bzr log -vv to find out which files had changed and uploaded those, but it seems like too many points of failuer [06:42] Recursive, with Makefiles at each level of the tree defining which files are to be installed and any special perms etc. [06:43] s/failuer/failure [06:44] That's why I charge double-time for anything I have to talk to over ftp... [06:44] anyone mind pasting my an example Makefile for that? [06:44] rsync is good enough to be able to cope with not pushing the same files again if they're not changed === mrevell is now known as mrevell-dinner [06:47] Mine don't tend to be good examples. They're pretty intricate, and rather specialized to my peculiar needs. === jprieur [n=jprieur@ARennes-256-1-95-199.w90-32.abo.wanadoo.fr] has left #bzr ["Ex-Chat"] [06:48] fullermd, no worries, thanks, I'll bang my head at it for a while [06:50] Essentially, there's a Makefile.inc at the root with all the target defs to installing (and comparing my tree against the live location, to see what I'm about to do, etc), and each subdir has a Makefile that lists the files, the subdirs, any special adjustments that dir needs, and the like. [06:50] Then an 'install' type target installs all the files, and recurses into the subdirs. [06:53] fullermd, sounds like a lot to explain to a web gfx designer, I need something that requieres *no* interaction on their part [06:54] just click a nice button on the web interface which uploads what they've pushed to the repo [06:54] is it possible to 'generate' test cases? [06:54] Just toss 'em an neon-colored iPod once in a while, that'll keep 'em happy. === fullermd gives more snark for your buck. [06:54] You could just make the button fire off 'make install'. [06:55] aka, i want to run one test case for a bunch of different index block sizes; but they're really seperate tests. i'd rather have the test suite report the particular failing, rather than the whole test [06:55] py.test and nose have something for this, but i'm not sure if unittest does [06:55] hahaha, instead of reproducing mp3, the ipods can read em the "make" manual [06:56] fullermd, the thing is, if they add a new file/dir, they will have to touch makefiles, eeeewwwwwwww [06:56] beuno: is the structure of the tree in the repo equal to the structure in the web? [06:57] dato, yeap, I just need to exclude some files/dirs automagically [06:57] then I'd recommend rsync [06:58] with --recursive and --exclude, it should do what you want, but try it with care to make sure it really does [06:59] dato, sounds like the right tool, for some reason I didn't think of it, I was convinced I could/should do it with bzr [06:59] dato, thanks :D [07:00] sure :) === dato leaves now === mvo [n=egon@p54A66616.dip.t-dialin.net] has joined #bzr === luks [i=lukas@unaffiliated/luks] has joined #bzr === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr [07:39] is there an RPM for bzr-90 ? [07:41] looks like fedora provides the rpm, not bazaar-vcs.org... [07:41] You should look into your dists repository, I guess [07:43] ... i've been trying to build on ... but i'm running into some problems with bzrlib/_dirstate_helpers_c.c [07:43] some deep seeded gcc magic which I do not understand : ) === welterde [n=welterde@trujillo.srv.pocoo.org] has joined #bzr === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 and 0.91rc2 are out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by poolie at Wed Sep 12 03:35:03 2007 [10:07] (keir/#bzr) lifeless: when you're up, if you have a minute, i'd like to to take a gander at the CompactDictionary code. it's all working. i'm currently implementing GraphIndex. [10:07] (beuno/#bzr) asac, I don't like that either, causes me all kinds of headaches [10:08] yeah [10:08] i accidentially now committed and publised a .moved file [10:08] thats stupid [10:09] asac, yes, and the fun thing is when some random person keeps on pushing & updating until you have 17 .moved.moved.moved.moved..... === beuno hates his gfx designers [10:09] ;) === rml [n=Skippy@78.32.35.169] has joined #bzr === cfbolz [n=cfbolz@p54ABB920.dip0.t-ipconnect.de] has joined #bzr [10:15] It doesn't add the .moved file. It just moves it. [10:18] fullermd, the first time, then it starts creating .moved.moved.moved.moved.moved [10:18] it's fun when someone calls me "bzr did something weird" [10:18] Only if you had more conflicts. [10:18] fullermd, they just keep on pushing until they decide it's enough [10:18] so resolving all that tends to be fun :D [10:18] And it never adds, it just moves. Path conflicts aren't created just for fun, they're created because you have conflicts :p [10:20] right, I'll try and get together a few reproducible steps to show you how to end up with 46 .moved.moved files :D === cpro1 [n=cprov@189.0.16.189] has joined #bzr [10:29] jelmer: any idea whats going wrong here? http://paste.debian.net/37140 === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr [10:33] jelmer: ignore me === cpro1 is now known as cprov [10:40] New bug: #139688 in bzr "BzrDirFormat.__str__ assumes last character of format_string is \n" [Undecided,New] https://launchpad.net/bugs/139688 === herzel44 [i=herzel@gateway/tor/x-4ba3550f71349908] has joined #bzr [10:50] New bug: #139691 in bzr "converter relies on control dir being named '.bzr'" [Undecided,New] https://launchpad.net/bugs/139691 === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr === GreenDad [i=shalom@bzq-88-155-43-26.red.bezeqint.net] has joined #bzr [11:16] I want to use bzr in a large organization. My main bottleneck is the ticket-management program. Have you had experience in deploying bzr in a large organization? [11:32] siretart, ok :-) [11:33] GreenDad, not sure I understand your question. Where is the size of the organization important? [11:33] Perhaps I should rephrase. [11:33] Or do you mean large history, etc? [11:34] The size is not relevant, but its management style. They're basically looking for something equivalent to ClearQuest for process-control. [11:35] The only alternative is trac, and I have the feeling it's not ready for primetime. [11:36] GreenDad: you're looking for ticket-management systems that integrate well with bzr? [11:37] *integrates [11:37] jelmer, Yup. [11:37] GreenDad: My employer (100 Greendad: trac is the only I'm aware of that has bzr support, but it's not really used for process control. [11:38] GreenDad: do you just want to prevent merges without a valid / signed-off ticket# attached, or stronger requirements (like folks locking files before they're allowed to change them)? [11:39] GreenDad, launchpad also integrates with bzr, but I'm not sure whether it supports non-public projects [11:39] nDuff, Nah. File locking is just annoying. I'm looking for a ticket-management system, like trac, only not trac. :) [11:39] We use a human PQM. [11:39] That is, all changes must go through the reviewr, and he performs the merge himself with the mainline branch. [11:40] GreenDad: I'd urge you to rethink the "only not trac", at least as long as the bzr integration tests out as being usable. [11:40] GreenDad: trac is quite stable, and with the next release out (w/ its workflow customization features) will have just about every major feature on our wishlist. [11:41] nDuff, A missing major feature is the ability to customize your own ticket fields. [11:41] But I can implement that myself [11:41] GreenDad: that's there. [11:41] GreenDad: you don't need to implement it yourself, it's there in the current released version [11:42] Oh? [11:42] Cool. [11:42] BTW, has anyone used StarTeam? [11:43]