[12:08] radix: you can't unmerge [12:08] radix: you need to commit the reverse change; then later use a reverse-merge of your commit that reversed it out [12:09] hsn_: cscvs should be able to convert for you in that case === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [12:09] I think I just figured out how to do it === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [12:11] lifeless: what I did was: cd $TRUNK; bzr merge -r 430..429 .; bzr commit -m "unmerge $CRAPPY_BRANCH"; cd $CRAPPY_BRANCH; bzr merge $TRUNK; bzr revert *; bzr commit -m "HACK commit: merge unmerge without textual changes" [12:11] lifeless: now $CRAPPY_BRANCH is mergeable to trunk again [12:12] (making sure that $CRAPPY_BRANCH and $TRUNK were both up-to-date with other unrelated $TRUNK changes first) [12:14] lifeless: is that how you would've done it? [12:14] (I'm not sure if that's what you meant by "reverse-merge" [12:19] lifeless: pong [12:21] lifeless: you are talking about this? http://www.gnuarch.org/gnuarchwiki/cscvs [12:22] radix: "bzr merge -r 430..429 ." is an example of "reverse merge". [12:22] ah, ok [12:23] so yeah, that's the obvious thing: it's the "merge *that* reverse merge, and then revert the textual changes" that's the tricky bit [12:25] radix: thats close enough === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr [12:26] abentley: hi, tree-reference's always have a reference-revision, its never NULL right ? [12:26] erm None [12:26] (at inventory serialisation) [12:26] hsn_: no, http://launchpad.net/cscvs [12:26] Yes. [12:26] good; I've just grabbed another 10-15% on xml serialisation [12:27] I gambled I had it right :) [12:27] It should be the value of the contained tree's last_revision. [12:27] I've made the serialiser aware of what attributes each kind should have [12:27] so it now requires that field to be non-none on tree-reference kinds, and ignores it otherwise. [12:29] Sounds good. [12:29] unfortunately my time looking into that was a little wasted as there is only a second total to win there [12:30] so I grabbed something like 100ms if I merge it into the pack branch; worth it but not big [12:34] bzr get http://bazaar.launchpad.net/~launchpad/launchpad-cscvs/rocketfuel fails with bzr: ERROR: bzrlib.errors.KnitHeaderError: Knit header error: '\x1f\x8b\x08\x... [12:34] hello [12:35] hsn_, is that a public branch? [12:35] poolie: yes [12:35] poolie: we open sourced our cscvs changes [12:38] lifeless: well, blow me down. I thought I'd never see the day. [12:40] didn't that happen like half a year ago? [12:40] yes [12:40] abentley: about 12 months ago IIRC [12:40] welcome to 2007 guys ;-) === luisbg [n=d33p@26.144.217.87.dynamic.jazztel.es] has joined #bzr [12:43] UnlockableTransport: Cannot lock: transport is read only: why? and why in a commit? [12:43] because you're trying to commit to an http branch [12:43] you may have used checkout when you wanted to use 'branch' [12:45] luisbg: when you checkout, bzr commit pushes the results back to the place you checked out - like svn/cvs [12:46] luisbg: but http is readonly, so it fails. You can either bind to a writable url, if working like svn is what you wanted, or you can unbind to give yourself a stand alone branch, which will operate independently of the source branch [12:46] poolie, you are correct... I did the mistake of checking out and not branch :S [12:47] how do I fix this withour erasing and branching? [12:47] i think just saying 'bzr unbind' in that directory will do it [12:47] lifeless, how do I unbind? [12:47] ahhh cool === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [12:57] Hmm. Tried to check branch a bzr-svn repo onto a windows box, and got an error: [12:57] bzr: ERROR: File exists: u'/.bzr/repository/knits/c1': [Error 183] Cannot create a file when that file already exists [12:57] s/check branch/branch/ [12:58] hmm, why does osutils.split_lines exist, isn't s.splitlines(True) the same ? === herzel [i=herzel@gateway/tor/x-3c3eceee75062418] has joined #bzr [12:58] NfNitLoop: is c1 a file or directory? === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [12:59] morning all [12:59] hi [01:02] lifeless: No. [01:02] s.splitlines() will also split on \r or [01:02] \r\n === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr [01:03] abentley: ah thanks. we should note that [01:04] oh, and [01:04] 0.92: first post! [01:04] It is precisely this issue that made me uncomfortable with your recent patch. [01:04] me too :( [01:04] Because people don't tend to realize that. [01:05] I think the final patch handled it pretty well, though. === johnlr2 [n=johnlr@203-206-162-97.perm.iinet.net.au] has joined #bzr [01:07] cool === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr [01:14] lifeless: a directory. [01:15] NfNitLoop: thats strange then [01:15] NfNitLoop: perhaps the exception raised by python has changed, wasn't alexander mentioning something like that last week ? [01:16] (we expect mkdir to fail when the dir is already made so we catch an exception there) [01:16] NfNitLoop: Not that I recall... but I only vaguely keep watch in here. [01:31] NfNitLoop: what version of python do you have ? [01:31] 2.5.1 [01:31] can you try with 2.5.0 ? [01:31] poolie, and lifeless, thanks a lot =) [01:32] lifeless: Hmmm. I guess so... I can install it in its own directory, right? [01:32] I think so === NfNitLoop tries. [01:35] downloading. lallaa. [01:36] I'm looking forward to svn 1.5 when the python bindings will be fixed across all platforms. :p [01:36] I'm not going to build my own on my windows box. [01:37] So until then I'm (trying) branching off of my linux box to the windows one. all commits back to svn will have to go back through the linux box. [01:38] a bit of a pain, but it's still awesome that that's a viable workflow. :) === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr [01:44] spiv: is chain C or python ? [01:47] lifeless: same error with 2.5.0 [01:48] lifeless: I've successfully done this from Linux -> OSX [01:48] I'm actually now doing it from OSX -> WinXP. Since my mac laptop is handily located next to my computer here. :) [01:48] lifeless: chain? [01:49] so it seems a windows-specific issue. [01:49] lifeless: you mean functools.partial? [01:50] where does .bzr.log go in WIndows? [01:53] NfNitLoop: bzr version will tell you [01:53] spiv: itertools.chain [01:53] NfNitLoop: please file a bug [01:53] NfNitLoop: you can work around by copying the .bzr directory by hand [01:53] lifeless: everything in itertools in CPython is implemented in C. [01:53] spiv: thanks === cprov is now known as cprov-ZzZ === bogdano [n=bogdano@201-40-202-24.ctame704.dsl.brasiltelecom.net.br] has joined #bzr === bogdano [n=bogdano@201-40-202-24.ctame704.dsl.brasiltelecom.net.br] has left #bzr [] [02:16] New bug: #139253 in bzr "bzr branch fails with "File exists" error." [Undecided,New] https://launchpad.net/bugs/139253 === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr [02:25] New bug: #133989 in bzr-svn "svn-import reports a File exists error (dup-of: 139253)" [Undecided,New] https://launchpad.net/bugs/133989 === ion [n=ion@71-223-67-22.phnx.qwest.net] has joined #bzr === mw is now known as mw|out === NamNguyen [n=namnt@203.162.163.50] has joined #bzr === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr === mneptok [n=mneptok@canonical/support/mneptok] has joined #bzr [04:18] Would it be correct to say that Bazaar doesn't depend on RCS (as Git does) because Bazaar has more advanced (ok "different") algorithms for doing and presenting diffs? [04:21] really, Git depends on RCS?! [04:21] it is correct anyhow [04:22] we have a diff algorithm described by Bram Cohen as "by far the best" or something similar [04:22] (lunch) [04:25] poolie: apparently the Debian package does. I seem to recall seeing that from the Git pages. [04:25] Needless to say, I'm going to blog a one liner about that if I can verify my facts. [04:25] New bug: #139273 in bzr "test case leaves behind temporary log files" [Low,Triaged] https://launchpad.net/bugs/139273 [04:30] Maybe it's just the cogito UI that depends on it. Oh well. === igc lunch === asabil [n=asabil@ti0035a340-0084.bb.online.no] has joined #bzr [04:41] the GNOME DistributedSCM page says bzr is lacking guaranteed content history, is that true? [04:51] what does that mean ? [04:52] it means we don't look up revisions via SHAs I think [04:53] we have testaments, they can be signed [04:54] I'm not quite sure what it means. Also talks about (disk?) corruptions in the repository and stuff === pete__c_ [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr [04:54] really, is this imaginary or experienced ? [04:55] jelmer: I think the whole sha1 thing started with monotone [04:56] monotone does heavy checking and verification on the changesets, and the consistensy of its sqlite database [04:57] this can make some sense, because it allows you to know if you database is corrupted (for example after storing it for 5 years on an optical disk) === herzel [i=herzel@gateway/tor/x-e27bba654c5c0914] has joined #bzr [04:58] we have that [04:58] for content we know the sha [04:58] lifeless: looks like somebody confused revids with checksums somewhere [04:58] it also allows to detect if someone was trying to do some funky stuff with a database (trying to corrupt it for example) [04:58] for the content of the tree we have a sha of that [04:59] jelmer: is it a wiki page, can you correct it ? [04:59] yes it is a wiki page, I have been updating it recently [05:00] (I have to admit that there is a huge bias in that page toward git unfortunately :'( ) [05:01] lifeless: yeah, sure, I'll add a comment [05:01] hey, I didn't know git was slower than both bzr and hg on windows... [05:01] not surprising [05:01] git is awful tuned in its design to what linux and ext3 do from everything I've read [05:02] btw, on Wikipedia, signed revision support is listed as 'partial' for Bazaar: see http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Features [05:02] someone needs to write better verification support is all; not huge or hard [05:03] asabil: are you a git advocate? or bzr? [05:03] this whole area was heavily pushed by Linus in his Google talk video as well [05:03] lifeless: I bloody hate git [05:03] :) === orospakr [n=orospakr@CPE001a70d1de84-CM0019474a8676.cpe.net.cable.rogers.com] has joined #bzr [05:04] I have been trying to keep the page unbiased, but there is too much hype around git [05:04] it's life a fashion thing [05:04] :( [05:04] lifeless: still, it's main design goal is speed and it's written in C so I'd expect it to be faster [05:05] I am really wondering if the FOSS community is turning into some fashion oriented community [05:05] jelmer: C is not a panacea; I agree that their priorities are broken [05:06] asabil: check out my new Yves Saint-Laurent wireless card! [05:06] lol [05:07] binary blob drivers, though. they don't want to reveal the WPA subroutine code or the floral extracts they use. :/ [05:08] oh [05:08] lol [05:09] yeah. "free as in cologne." :/ [05:10] jelmer: I was the one putting that bzr is lacking revision verification [05:10] asabil,jelmer,lifeless: there aren't a lot of responses (~100) but I'm a little surprised by the results to date of the Bazaar user survey: http://www.surveymonkey.com/sr.aspx?sm=FDeDsLzaZ0AKNEATuA0QklWayMZKGfHcrP1U4V55jAY%3d [05:10] I removed it now [05:10] asabil: so we have shas from the revisions down; we have a canonical form that gets signed called a testament [05:10] asabil: cool, thanks [05:11] neither Git nor Hg are as liked as much as Subversion by Bazaar users [05:11] asabil: revision ids are not shas because that forces history rewriting if you want partial conversions to be interoperable (e.g. its fugly) [05:11] lifeless: Writing in C may not necessarily make something faster, but writing things on a lower level usually makes it easier to optimize [05:11] (no conversion for bindings involved, no byte-compilation, etc) [05:11] jelmer: I find the reverse :) [05:11] despite that fact that "distributed" is a major reason for choosing Bazaar [05:12] jelmer: After one accounts for the baseline speed difference, I find it easier to make something in python twice as fast as to make something in C twice as fasst [05:12] igc: this is something to put on the Gnome vcs page I think [05:12] asabil: ^ jelmer: ^ [05:12] igc: "What I basically want is the exact same thing, but completely different? Can you do that?" [05:12] mneptok: "Yes" [05:12] *bounce* [05:12] lifeless: http://live.gnome.org/DistributedSCM [05:13] you can read and suggest updates [05:13] asabil: I'm going to let others do that [05:13] right now I'm fighting the key performance battle that currently we're whipped at [05:13] lifeless: yeah I can do it, just give me some feedback [05:13] igc: lol, I am the only one who voted that I know monotone the best :D === mneptok is also not going to update that page for political reasoens [05:13] -e [05:14] :) [05:14] I'm only adding comments, won't change any actual data.. [05:14] igc: I'm surprised at the amount of Windows users [05:15] jelmer: yes, there are quite a few surprising results in there [05:16] what, less users than you expected? [05:17] We decided windows was strategic way back [05:17] lifeless: I always tend to write faster code in C if I write it twice in both Python and C [05:17] lifeless: no, more [05:17] lifeless: 39% (out of 95 people) [05:18] (people can select multiple os'es) [05:18] that feels right to me [05:19] beats everything but ubuntu === jdub_ [n=jdub@home.waugh.id.au] has joined #bzr === jdub_ is now known as jdub === jdub [n=jdub@home.waugh.id.au] has left #bzr [] [05:31] igc: call ? [05:32] sure [05:32] one minute === jml [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr === jml [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr [06:13] igc: split_lines on inventory is 100msec === lifeless goes to fix [06:14] Question: if you rename a versioned subdirectory manually (eg, "ren foo bar" in windows), is bzr supposed to detect that and do something appropriate? [06:16] Stevage: no, but 'bzr rename --after foo bar' should tell bzr about it for you [06:17] Stevage: I think if you have the bzr tortoise plugin I'd expect bzr to be told, or something appropriate [06:17] cool. the documentanio for 'commit' is a bit misleading then [06:17] there's a bzr tortoise plugin?? [06:17] cool :) [06:18] Stevage: hmm, can you point at the misleading bit ? [06:18] http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#commit [06:18] the example at the end of that [06:18] It says "In the example above, the last commit will fail by design. This gives the user the opportunity to decide whether they want to commit the rename at the same time, separately first, or not at all." [06:19] I took that to mean bzr will detect the rename and commit it. [06:19] but actually all that happens is it detects a deletion and an unknown file. [06:19] well [06:19] if you look at the example 'bzr mv' is used to do the rena,e [06:19] oh! [06:19] yeah oops you're right [06:19] thought it was just mv [06:19] ":) [06:20] I still don't get this text from the front page though: [06:20] For that reason, Bazaar is specifically engineered to be as tolerant of user decisions as possible, and to allow ANY operation on your code tree that is possible using UNIX and Windows filesystems. As a primary example, Bazaar is extremely tolerant of renames of directories and files, even when multiple different contributors are renaming files and directories differently in their branches,... [06:20] ...and then merging from one another. [06:21] that was what originally got me thinking that somehow you could just rename files at will and it would detect it === herzel44 [i=herzel@gateway/tor/x-eda7ff93aea44110] has joined #bzr [06:29] Stevage: ah [06:30] Stevage: what we mean is 'when two users of bazaar perform renames [using bazaar] in separate branches, we try very hard to Do The Right Thing' [06:30] what you are trying to do, we are also tolerant of, but we clearly don't /know/ whats happened if you don't tell bzr about it. We can guess, but that generally gives worse results === beuno [n=beuno@201-213-169-167.net.prima.net.ar] has joined #bzr [06:43] yeah, I guess I was just confused by the references to unix/windows filesystems, followed immediately by [Bazaar] renames. [06:44] it's all good. [06:49] is there a way to commit with a date other than today's? (other than changing the system clock...) [06:50] Stevage, there is at the api level, i don't know if it's exposed on the cli [06:51] rather i think it's not [06:51] it would be a trivial addition [06:51] hmm [06:51] I'm trying to do a quick and dirty repository migration here [06:51] might be easier to just set the system clock, but that can have ugly side effects [06:53] that doesn't sound like a really great idea... [06:53] yeah I know :/ [06:53] what do I need to compile/build bzr on winxp? [06:54] if you just want to modify the python source you only need python [06:55] if you want to build the binarios, see http://bazaar-vcs.org/Win32ReleaseChecklist [06:55] or rather http://bazaar-vcs.org/BzrWin32Installer [06:55] Stevage: what format are you trying to convert from ? [06:55] from this ancient system called TLIB [06:55] oh wow, ok [06:55] in python [06:56] if you do 'import bzrlib.workingtree' [06:56] tree = bzrlib.workingtree.WorkingTree.open('path') [06:56] poolie: what do you mean by building binaries? if I'm just rebuilding it for my own purposes, what will I need? [06:56] tree.commit(message=... ) [06:56] sadly I don't know python at all (yet) [06:56] there are parameters (pydoc bzrlib.commit.Commit lists them all) [06:56] Stevage, just python will do, there is no compilation step [06:57] so the python dll that came with bzr is sufficient? [06:57] poolie: well, there is an optional one ;) [06:57] or is there an interpreter? [06:57] yes, there's an interpreter [06:57] i should have said, there's no mandatory compilation step [06:57] if you run the command 'python' [06:57] but if i want to be able to run 'bzr commit' etc from the commandline I'll need to compile? [06:58] no [06:58] do you have bzr installed from a package at present? [06:58] this is xp [06:58] i mean, from one of the windows installers [06:58] yeah [07:03] later all [07:15] ok, so now that I have python installed, how do I compile/interpret bzr? === g0ph3r [n=g0ph3r@p57A0B24A.dip0.t-ipconnect.de] has joined #bzr [07:49] can anyone help me get started running bzr from source on winxp? [07:51] Stevage, I believe now you just have to execute the "bzr" in the folder where the source is [07:52] come to think of it I don't think I actually have the source [07:53] I have /lib and /doc but no /source or anything [07:53] Stevage, were did you download it from? [07:53] bazaar-vcs.org, the 'windows standalone installer' link [07:53] SteveA: You should have 'bzrlib', not 'lib'. [07:53] it's called lib for me [07:54] in lib there are some .pyd's, a .zip and a .dll [07:54] It doesn't sound like you're taking the run-from-source steps. === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [07:54] The standalone installer doesn't install the source AFAIK. [07:54] Stevage, if memory serves me right, you should be able to fire up a command line prompt and execute "bzr", you should know it's a command-line program [07:54] no, I wasn't - I originally downloaded the binaries. now I realise I need the source too. [07:55] All you need is the bzr tarball and python. [07:55] yeah that's ok, I've had bzr running for a couple of days. it's just now that I want to modify the source... [07:55] It installs the compiled .pyc files bundled into a zip file I think. [07:55] Compiling is an optional step-- it increases performance a bit. [07:55] Stevage, then you should download http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz [07:55] yeah just got that [07:56] But that's all compiling does. [07:56] Stevage, then uncompress, edit, go into the folder and execute "bzr", that should be it [07:56] it doesn't need to be compiled to work [07:57] as abentley mentioned, all that does is speed things up a bit [07:57] erm, I'm on windows here, that's not going to work [07:57] bzr. is a shell script [07:57] Stevage, it's a python script, it should run fine [07:58] if it doesn't, then try "python bzr" [07:58] ok that worked [07:59] :D [07:59] there should be a bzr.bat included, since that package is supposed to work on all platforms [07:59] surprising how much effort the bzr devs here put into multi-platform compatibility [08:00] Stevage, it does, and a .bat would be windows-specific [08:00] yeah but there's a "bzr." which is unix specific...? [08:00] Well, that's bundled with windows installers. [08:00] Stevage, nope, the tarball you downloaded is the same for all platforms [08:00] yeah I know [08:00] Sticking it in the main source tree wouldn't kill us, though. [08:01] I'm just saying, there's a unix shell script, but no windows batch file [08:01] No, there's no shell script. [08:01] Stevage, there isn't a unix shell script, it's a python script [08:01] There's only a python script. [08:01] The .bat file is just a more convenient way of running that python script. [08:02] heh, ok it's a python script that starts with #! /usr/bin/env python [08:02] which is code understood by the unix platform but not by windows [08:02] hence, "unix script" [08:02] it doesn't matter anyway [08:02] Shell scripts start with #!/bin/sh [08:02] but you seemed to convince abentley to add the .bat in the main tree, so you made progress ;) [08:02] lol [08:03] Stevage: The last VCS I worked with started as a collection of shell scripts. It wasn't pretty. [08:03] ok so where do I look to add a new command line argument? [08:03] ugh === beuno steps down from this and heads to bed [08:04] you should see what I'm migrating from, it considers directory trees an "advanced feature" [08:04] g'night all [08:04] You would edit bzrlib/builtins.py and find cmd_commit. [08:07] awesome [08:07] if there's a .pyc should I delete it? [08:07] or will it recompile itself automatically? [08:08] It will recompile automatically. [08:10] hey awesome I added a new option and it worked :) [08:10] (well, it doesn't do anything yet...) [08:11] Usage: bzr commit [SELECTED...] [08:11] Options: [08:11] -h, --help Show help message. [08:11] ... [08:11] --date=COMMITDATE Commit as if it were this date. [08:15] New bug: #139247 in launchpad-bazaar "bzr+ssh:// cannot be used to branch" [Low,Invalid] https://launchpad.net/bugs/139247 === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:18] where would I go to add the implementation of that option? [08:19] oh, commit.py duh :) [08:28] well commit.py already has it [08:28] you just need to glue it into the parameters passed to workingtree.commit() in builtins.py [08:29] e.g. all your changes will be in builtins.py + any test changes === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === Peng [n=mnordhof@fl-69-69-148-134.dyn.embarqhsd.net] has joined #bzr [08:54] ok. I'll need to parse a date from the command line, but I can't understand how to add that code to Option.py [08:54] is there already a date parsing function? === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === sverrej [n=sverrej@tul-1x-dhcp017.studby.uio.no] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [09:07] Stevage, i believe there is one in the time module [09:07] Stevage, http://docs.python.org/lib/module-time.html [09:07] see strptime [09:14] ok just found that [09:14] so how does the option parsing stuff work: when an option is set to type 'str', where is the call that makes it get parsed as a string? [09:14] and what is 'str' - an enum, or a language primitive? [09:14] (I don't know Python at all :( ) === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === asabil [n=asabil@ti0035a340-0084.bb.online.no] has joined #bzr [09:34] heading off a bit earlier today [09:34] night all === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr === mvo [n=egon@p54A66406.dip.t-dialin.net] has joined #bzr === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === allenap [n=allenap@dsl82-163-24-141.as15444.net] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === mneisen [n=mneisen@141.13.16.222] has joined #bzr === sverrej [n=sverrej@213.236.208.247] has joined #bzr === jrydberg_ [n=johan@213.115.45.46] has joined #bzr [10:45] New bug: #139318 in bzr "`bzr send --mail-to` failed with UnicodeEncodeError" [Undecided,New] https://launchpad.net/bugs/139318 === metze_away is now known as metze === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr === asabil [n=asabil@89.191.20.67] has joined #bzr === hads [n=hads@reef80.anchor.net.au] has joined #bzr === jrydberg_ is now known as jrydberg === mvo is now known as mvo_ === pitti [n=pitti@ubuntu/member/pitti] has joined #bzr [11:29] hello all [11:29] since the last upgrade of bzr (0.18 to 0.90), pulling from a bzr+ssh:// fails with [Errno 13] Permission denied: '/.bzr.log' [11:30] is that me doing something silly? [11:30] pulling from sftp:// or http:// works [11:30] might also be a problem on the remote end (bzr+ssh://bazaar.launchpad.net) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [11:31] indeed, pull bzr+ssh:// from my own server works === cfbolz [n=cfbolz@p54AB8267.dip0.t-ipconnect.de] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === mvo [n=egon@p54A66406.dip.t-dialin.net] has joined #bzr === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr [12:34] Assuming I have checkout of branch. I want to know if I am up to date with checkout - is it bzr missing right way of checking it ? === gabe_ [n=gabriel@91.84.56.254] has joined #bzr [12:49] matkor: I think you can just do "bzr missing" === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr === allenap [n=allenap@80.187.210.109] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [01:07] Lo-lan-do: I get bzr: ERROR: No peer location known or specified in 0.90 [01:08] Hm. Then yeah, use the full syntax :-) [01:09] Lo-lan-do: Thnx :) === Mez [n=Mez@ubuntu/member/mez] has joined #bzr [01:24] I think I will fill wishlist about that if it so obvious ... [01:29] It is so obvious so there already is wishlist about that ;) === pitti [n=pitti@ubuntu/member/pitti] has left #bzr ["Bye"] === mrevell is now known as mrevell-lunch === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [02:01] I Have checkouted my WT to revno 50. But it indroduces errors. Can I have it back to revno 49 ? TIA === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr === niemeyer [n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === mrevell-lunch is now known as mrevell === mw|out [n=mw@189.146.24.28] has joined #bzr === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === zyga_ [n=zyga@ubuntu/member/zyga] has joined #bzr === allenap [n=allenap@80.187.152.195] has joined #bzr === allenap [n=allenap@80.187.152.195] has joined #bzr === mw|out is now known as mw === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === cypherbios_ [n=cyr@201.21.169.51] has joined #bzr === cypherbios_ is now known as rproenca === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === asabil [n=asabil@ti0035a340-0084.bb.online.no] has joined #bzr === metze is now known as metze_away === pete__c [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr === Zindar [n=erik@stockholm.ardendo.se] has left #bzr [] === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === p4tux [n=p4tux@189.169.70.173] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === juliank [n=juliank@p548AE9F3.dip.t-dialin.net] has joined #bzr === dpm [n=dpm@p54A138F4.dip0.t-ipconnect.de] has joined #bzr === beuno [n=beuno@44-111-231-201.fibertel.com.ar] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr === mrevell is now known as mrevell-tea === mrevell-tea is now known as mrevell === sri [i=[k1wKiGW@onyx.spiritone.com] has joined #bzr === cprov is now known as cprov-lunch === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === jdong [n=root@ubuntu/member/jdong] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [07:11] james_w, siretart: are there any plans in merging the hooks branch for bzr-builddeb? === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr === jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === herzel44 [i=herzel@gateway/tor/x-de00e307b6ac431c] has joined #bzr [07:31] doing a bzr checkout --light-weight, is there a way to convert(?) that to a full branch? [07:32] BasicOSX: A patch was posted to the mailing list yesterday that adds support for doing that [07:32] I don't think it's possible in a released version yet [07:33] that's actually "good" since I as pounding my head abou tit === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === cfbolz [n=cfbolz@p54ABC20A.dip0.t-ipconnect.de] has joined #bzr === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === Jen [n=Jen@gateway.nork.dk] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr [07:59] Hi, I just found Bazaar and is trying it out locally. I read this (great) guide (http://doc.bazaar-vcs.org/latest/en/user-guide/centralized_workflow.html#initial-setup) and is wondering if there is any way to perform a 'hook like' command. When commiting I would like 'centralhost' to update to an folder placed in the webscope. [08:02] Jen, sure, you can write a plugin for that [08:02] their are plenty of existing plugins: http://bazaar-vcs.org/BzrPlugins [08:03] you can look at one of those for examples === mrevell is now known as mrevell-dinner [08:05] beuno: Great. Thank you. Am I right that I whould have to do something like 'bzr checkout sftp://server/tree/branch /webroot/folder' and then 'bzr pull sftp...' when updating? [08:06] The URL should be remembered, so just "bzr pull" should work. [08:06] Jen, if you want to have a svn-like workflow, yes [08:06] I think it's bzr update for checkouts. [08:07] beuno: oh my bad that's wrong. That will checkout the branch to my computer - I would like it to be checked out to a folder on the central server [08:08] dato: thanks ;) [08:09] jelmer: it needs updating. If you have a need for it then I can move it up the TODO list. [08:10] Jen: either ssh to the server and checkout, or you can supply sftp://... as the second argument and do it remotely. [08:10] Jen, you would like to checkout from your PC to a directory on another PC? [08:11] however that will be slow if both ruls are remote. If they are on the same server then doing it after ssh to the server will be a lot faster. [08:11] james_w: There's some C-based packages I have it would be very useful for [08:12] and using bzr+ssh:// will speed it up. [08:12] jelmer: you wanted to run autotools correct? [08:12] james_w: yep [08:13] beuno: no - when I commit I would like 'centralhost' to do a checkout to itself (i.e. move the files to a webscope) [08:13] jelmer: on a native package? [08:14] james_w: nope, in normal mode (with export-upstream) [08:14] Jen, right, I understand, you can hook it and make it do that, it will take some work to make everything run smoothly (specifying where it should checkout, por example), but it's perfectly doable [08:14] jelmer: was your need satisfied by the old branch? I don't even remember if it worked at all for you. [08:14] james_w: yeah, that worked, though I'd rather just specify the command to be run rather than having to create scripts === abadger1991 [n=abadger1@65.78.187.68] has joined #bzr [08:15] beuno: great - thanks for your time [08:15] the use case for hooks probably differs per person though.. [08:15] jelmer: in a config file? [08:15] james_w: yeah [08:15] Jen, no problem, have fun with that :D [08:16] just 'export-upstream-hook = ./autogen.sh' in the same place as where the other bzr-builddeb settings are [08:16] jelmer: I'm not sure how easy that would be to authenticate, but it seems like a reasonable request. [08:16] james_w: where is the authentication stuff for exactly? Don't you have to trust the data in the branch anyway? === abadger1991 is now known as abadger1999 [08:17] I'm not sure how important authentication is as you have to run debian/rules anyway, but I wanted to avoid the surprise of having a hook run and do something nasty. [08:19] ah, k === keir [n=keir@206-248-159-109.dsl.teksavvy.com] has joined #bzr [08:20] hi all [08:21] 'evening keir [08:21] as in someone new to the plugin probably wont know about hooks, but may check debian/rules and still be surprised. I realise it's perhaps a little perverse though. I'll re-evaluate when updating the branch. [08:21] can someone perhaps vote on my patch? http://bundlebuggy.aaronbentley.com/request/%3Cef5675f30709041204j276ce48biaa5095a939bc5749@mail.gmail.com%3E [08:22] it's already approved by aaron, it'd be nice to get it in for .92 [08:25] james_w: it'd at least be nice if it was disableable [08:25] on a per-user basis [08:25] so you enable hooks once and by doing so promise to vet all hooks from then on? [08:27] yeah, something like setting '[builddeb] \ndont-authorize-hooks = True' in ~/.bazaar/bazaar.conf [08:27]