[00:09] <mwhudson> jelmer: still here?
[00:10] <mwhudson> jelmer: anything to be wary of in upgrading to bzr-git and dulwich trunk tips?
[00:12] <jelmer> mwhudson: hi
[00:12] <jelmer> mwhudson: not really, other than making sure you upgrade both at the same time
[00:17] <mwhudson> jelmer: cool, thanks
[00:17] <mwhudson> jelmer: this should fix git imports over http, right?
[00:21] <jelmer> mwhudson: I thought that was already working?
[00:22] <mwhudson> jelmer: it broke again, it seems
[00:23] <jelmer> mwhudson: what's the error?
[00:23] <mwhudson> jelmer: https://bugs.edge.launchpad.net/launchpad-code/+bug/570728
[00:23] <mwhudson> jelmer: i'm sure i saw a commit along the lines of "fix access over http again"
[00:23] <jelmer> mwhudson: ah, right - that's fixed indeed
[00:24] <jelmer> dulwich now can launchpad http test servers, we still need to take advantage of that in bzr-git
[00:24] <lifeless> EPARSE
[00:25]  * james_w suspects muscle memory
[00:26] <jelmer> argh
[00:26] <jelmer> lifeless: :-)
[00:26] <jelmer> I can no longer write launch without adding "pad" onto it
[00:27] <poolie> heh
[00:27] <poolie> i find it very hard to type 'linus'
[00:29] <mwhudson> i tried to type 'lp/core' earlier
[00:31] <thumper> poolie: I'm sure it would be easier if it was your name :)
[01:58] <poolie> hi spiv
[02:00] <spiv> Hey poolie
[02:03] <poolie> how about a brief chat?
[02:03] <poolie> in 5m maybe?
[02:04] <spiv> Sure.
[02:42] <lifeless> lp:~leonardr/lazr.restfulclient/retry_on_502 will help us
[02:42] <lifeless> for pqm
[03:06] <spiv> Hmm, one day left in PyCon Au CFP.
[03:12] <lifeless> indeed
[03:12] <lifeless> it seems.... raid
[03:12] <lifeless> rapid
[03:19] <spiv> poolie: take a look at https://code.edge.launchpad.net/~vila/bzr/320119-exclude-ancestry/+merge/23394, it duplicates its make_branch_with_alternate_ancestries test helper
[03:20] <spiv> poolie: it'd be lovely if your testsubjects patch could provide a natural way to avoid that duplication
[03:21] <spiv> poolie: it might be too much to ask, or maybe the real issue is that bb.test_log and bt.test_log should have a more convenient way to share their helpers.  But it seemed topical :)
[03:47] <poolie> it's highly topical
[03:47] <poolie> and a good place to start
[03:47] <poolie> so istm you could just lift it into a function
[03:48] <poolie> i guess you'd need to pass the test case in to that function so that it can arrange for the cleanup to be called
[03:48] <spiv> poolie: right
[03:48] <lifeless> -> pick up car
[03:49] <spiv> And note that they want to use the test case's get_transport too.
[04:04] <mwhudson> "hmm" http://pastebin.ubuntu.com/423710/
[04:07] <Peng_> Nice.
[04:12] <xnox> jelmer, svn is such a weird beast =)
[04:12]  * xnox officially hates file/revision properties in svn
[04:13] <poolie> spiv, oh, i liked your old doctest blog posts
[04:14] <mwhudson> i think they are also his newest blog posts
[04:17] <spiv> Yeah.
[04:20] <poolie> you should do more
[04:36] <mwhudson> xnox: https://code.edge.launchpad.net/~dmitrij.ledkov/reactos-core/ddk is a slightly strange request
[04:36] <mwhudson> do you really want to import a branch that just has the headers in it?
[04:36] <xnox> mwhudson, i'm working on mingw-w64 projects which is a working crt
[04:37] <xnox> to cross-compile to windows32 & windows64
[04:37] <xnox> they are importing those headers as an svn:external
[04:37] <mwhudson> ah
[04:38] <xnox> I'm currently successfully creating binutils, gcc, mingw-w64 debian packages using gcc-4.5, gcc-4.6, gcc-4.3
[04:38] <mwhudson> xnox: approved then
[04:38] <xnox> mwhudson, to automate this further =) I really really would appreciate those headers imported
[04:38] <xnox> mwhudson, as well as gcc branches =))))))) pleeeeeeeeeeeaaaase =)
[04:39] <poolie> jam, can you tell francis et al about the loggerhead fix?
[04:39] <mwhudson> xnox: i don't see them in the pending review column
[04:39] <mwhudson> xnox: give me some links?
[04:39] <xnox> mwhudson, 1sec
[04:40] <xnox> mwhudson, https://answers.edge.launchpad.net/launchpad-code/+question/108549
[04:40] <xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch/
[04:40] <xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch/
[04:40] <xnox> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch/
[04:40] <xnox> if possible as lp:gcc/4.5
[04:40] <mwhudson> xnox: can you request imports of these?
[04:40] <xnox> ok
[04:41] <jam> poolie: forwarded
[04:44] <xnox> mwhudson, done
[04:45] <mwhudson> xnox: i think you'll need to ping doko to create the 4.4 and 4.5 project series
[04:49] <xnox> mwhudson, ok =)
[04:50] <xnox> mwhudson, thanks a lot =) and I promise I will work hard during my Ubuntu GSoC =)
[05:13] <jbowtie> Just pushed my first merge proposal.
[05:51] <poolie> jbowtie: congratulations
[05:56] <allquixotic> So what is the current status of http://wiki.bazaar.canonical.com/WindowsSymlinkSupport ?
[05:56] <allquixotic> Seems like some good ideas got thrown around but are any implemented?
[06:03] <poolie> allquixotic: i think the best option is the plugin
[06:03] <poolie> not sure, sorry
[06:03] <a212901390231901> meh, projects that want to be portable just shouldn't use 'em
[06:04] <a212901390231901> likewise filenames with backslashes in and other oddness
[06:05] <allquixotic> Well, I have two possible build methods in this project. The GNU Make based build does need symlinks to work right. The MS Visual Studio based build has the required path finagling in the project properties. I guess I can create the symlinks (which are pre-determined and can be referenced by relative path) at build-time with the Makefile, and remove them with clean.
[06:05] <allquixotic> That way, anyone who does a clean before they commit (which they should always do) will rm the symlinks, and they won't get committed -- but if they're building with GNU Make, it will make the symlinks before building.
[06:05] <allquixotic> then everybody's happy.
[06:05] <a212901390231901> sounds sensible to me.
[06:08] <a212901390231901> add the paths to .bzrignore to be on the safe side.
[06:10] <allquixotic> sounds like a good idea
[07:02] <vila> hi all
[07:02]  * fullermd vilas wave.
[07:03] <vila> hey fullermd  ! :)
[07:03] <a212901390231901> pilote again this week
[07:03] <vila> spiv: thks for the review !
[07:04] <vila> a212901390231901: I should say that I really don't recognize your nick :)
[07:05] <vila> spiv: for the record, they are not duplicated, there is a slight variation, but of course your point stands :)
[07:05] <a212901390231901> freenode was annoying me, everything's already registered and I'm not on frequently.
[07:06] <vila> hehe, it doesn't help to match with any other handle you can use though :)
[07:06] <Peng_> Yes, I doubt you'll have trouble getting that nick on other networks. Unless they have length limits.
[07:06] <fullermd> Oh look, an opportunity to flex my numerological muscles...
[07:07] <a212901390231901> I'm one of the peripheral martins.
[07:07] <Peng_> Ooh, another Martin? If you get a job at Canonical, you'll have to change your real name too. :P
[07:07]  * fullermd . o O ( No match for "PERIPHERALMARTINS.COM". )
[07:07] <vila> gz or von Gagern ?
[07:07] <a212901390231901> I just mashed the keyboard in frustration after trying about six other things, fullermd
[07:07] <a212901390231901> gz.
[07:07] <Peng_> Oh hi. :D
[07:07] <a212901390231901> which, unsuprisingly, was taken.
[07:08] <vila> a212901390231901: Hello Martin !!
[07:08] <Peng_> "Martin[gz] is not registered." :D
[07:08]  * vila my first read was peripheral martians :)
[07:08] <a212901390231901> ehehe
[07:09] <fullermd> Makes sense.  You never see martians directly; it's always out of the corner of your shotglass.
[07:09] <fullermd> Eye.  I meant 'eye'.
[07:11] <vila> hehe
[07:12] <spiv> vila: the interesting bits are duplicated :P
[07:12] <vila> spiv: sure !
[07:12] <spiv> vila: unless you mean there is slight variation between the comments and the code? ;)
[07:12] <jbowtie> I fixed lp:146780 on the wiki if anyone's interested in reviewing.
[07:13] <vila> spiv: I indeed started by copy/pasting because I wrote the first test in the wrong place, realized there was a slightly different case to test and left the other one since it was good to have too
[07:13] <vila> spiv: I'll make that clearer
[07:21] <lifeless> poolie: http://www.flickr.com/photos/49692283@N07/4559422361/in/pool-canonical-offices
[07:22] <vila> lifeless: sounds like a good place for the November sprint :-P
[07:22] <lifeless> won't be here in november
[07:22] <lifeless> its a rental for 4 months, time enough to find a longer term residency (e.g. a house to buy)
[07:23] <fullermd> Heck, there's one right up the road from me   ;>
[07:24] <lifeless> fullermd: in a country that won't fingerprint me and treat me like a criminal, just because I want to trave there?
[07:24] <fullermd> That depends on whether you consider the state a separate country.  Opinions vary  ;p
[07:24] <poolie> pretty
[07:24] <vila> poolie: by the way, feel free to upload the pictures you took in Strasbourg there :)
[07:25] <poolie> i like what you did with the exposure and motion blur :)
[07:25] <poolie> ok
[07:25] <lifeless> poolie: android phone - it doesn't do it justice
[07:25] <lifeless> poolie: it was at 8am or so
[07:25] <lifeless> poolie: if you want to bring your camera around to get a proper shot, you're welcome to do so!
[07:28] <idnar> haha
[07:57] <poolie> lifeless: so i fixed and repushed a branch that i think is already queued for merge
[07:57] <poolie> 'components'
[07:57] <poolie> what happens now?
[07:58] <lifeless> poolie: pqm unqueued it when it failed to merge
[07:58] <lifeless> poolie: it put it back to 'approved', because we can't set 'failed to merge' yet [lp bug, I submitted a branch, thumper has half-reviewed it]
[07:58] <lifeless> poolie: so you should requeue it in hydrazine
[08:02] <jbowtie> That's 4 documentation bugs for today; was shooting for 5 but not going to happen. Hopefully someone will review, yes?
[08:02] <poolie> yes :)
[08:02] <poolie> thanks for the fixes
[08:02] <poolie> the one with adding DISABLE_PLUGINS to the table, why was the diff so big?
[08:02] <poolie> you had to rearrange the columns?
[08:02] <fullermd> Oh, FIXES.  I was wondering how it could take that long to create 4 bugs   ;)
[08:03] <jbowtie> poolie: Yes, the columns had to be resized.
[08:04] <jbowtie> fullermd: ha ha - don't worry, I'll be filing some this week about the blank areas/TODOs.
[08:08] <lifeless> wowsers thats a big package - texlive-latex-extra-doc
[08:46] <bignose> is a recent GNOME expected to give ‘bzr-gtk’ errors like this:
[08:46] <bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/keyring.py", line 77, in get_credentials
[08:46] <bignose>     gnomekeyring.ITEM_NETWORK_PASSWORD, attrs)
[08:46] <bignose> bzr 2.1.1 on python 2.5.5 (Linux-2.6.32-3-powerpc64-ppc64-with-debian-squeeze-sid)
[08:46] <bignose> IOError
[08:46] <bignose> Debian Squeeze is currently undergoing a GNOME transition, so I don't know if this is something already reported
[08:47] <bignose> (Launchpad pages don't load properly for me so can't check)
[08:50] <lifeless> ok, this is entertaining: (changelog, larstiq) = find_changelog(tree, False) :)
[08:50] <lifeless> bignose: fixed, bug in bzr-gtk
[08:53] <bialix> heya bzr!
[08:54] <Peng_> Good morning. :D
[08:54] <Peng_> Three people with nicks that start with "bi" at once? Nice.
[08:55] <idnar> they need to change it to "tri"
[08:55] <idnar> oh, actually there's four of them
[08:56] <bialix> Peng_: I see 4
[08:56] <bialix> and 2 Peng
[08:57] <bialix> :-P
[08:57] <bialix> which peng is the right peng?
[09:00] <tetsuo--> does the bazaar explorer client for windows get compiled with msvc?
[09:00] <a212901390231901> it's not compiled.
[09:01] <tetsuo--> then what is it?
[09:01] <Peng_> bialix: I'm Peng's robot clone, but our consciousnesses are linked together, so it doesn't matter.
[09:01] <tetsuo--> "bzr.exe" explorer"
[09:01] <a212901390231901> pyqt can be compiled with either gcc or msvc
[09:01] <Peng_> bialix: If you need help with a move, I'm stronger, but Peng's better with stairs.
[09:01] <bialix> lol
[09:02] <tetsuo--> a212901390231901: whatever the underlaying compiled thing is, it crashes like crazy
[09:02] <a212901390231901> that's just py2exe packing.
[09:02] <bialix> tetsuo--: what is your real question?
[09:02] <bignose> lifeless: thanks
[09:02] <bialix> tetsuo--: pastebin? bug report?
[09:02] <tetsuo--> dont have one right now
[09:02] <a212901390231901> do you mean crash-crash, because people have a bad habit of saying "crash" when they mean "exception thrown"
[09:03] <tetsuo--> ok
[09:03] <Peng> bialix: Jokes aside, I have two IRC clients open. Usually I use Peng but I'm thinking of switching to Peng_ again (and if I do, I'll eventually /nick it to Peng).
[09:03] <tetsuo--> both exceptions and crashes
[09:03] <a212901390231901> exceptions should be logged as bugs, real crashes are harder, but you can try and catch one in a debugger
[09:03] <tetsuo--> all related to bazaar reading or writing to the wrong section of memory
[09:03] <a212901390231901> okay, that does sound bad.
[09:04] <a212901390231901> this is with the standard release installer?
[09:04] <tetsuo--> they would be easy to work-around with 2 simple switches in msvc, or at least reveal their location more exactly
[09:04] <tetsuo--> yes
[09:04] <tetsuo--> standard release installer
[09:04] <a212901390231901> well, one thing to try is to reproduce on trunk bzr with seperate plugins
[09:05] <a212901390231901> then you can compile qt/sip/pyqt however you like
[09:05] <bialix> tetsuo--: I'm not sure how the official installer built it's c-extensions. I've heard there is preffered gcc
[09:05] <a212901390231901> it's a bit of a fag but doable.
[09:05] <tetsuo--> i dont compile myself though :(
[09:06] <bialix> tetsuo--: please, provide a bug report
[09:06] <a212901390231901> alexander, do both sip and qt have prebuilt binaries?
[09:06] <tetsuo--> it would be nice if the bazaar installer for windows (and all the stuff in it) passed the windows logo test
[09:06] <bialix> a212901390231901: нуы
[09:06] <bialix> a212901390231901: нуы
[09:06] <bialix> a212901390231901: yes
[09:06] <tetsuo--> it has very strict guidelines on memory leaks etc...
[09:06] <bialix> rats
[09:06] <bialix> a212901390231901: are you Martin gz?
[09:06] <a212901390231901> yup.
[09:06] <bialix> nice nick
[09:06] <tetsuo--> and if you have a certificate you can log into winqual and download all the crashdumps windows generated for bzr
[09:07] <a212901390231901> I can point you at various things to install seperately to see if you still get memory errors.
[09:07] <bialix> a212901390231901: we're using official distrib from riverbank as I know
[09:07] <tetsuo--> them maybe the problem is upstrea
[09:07] <tetsuo--> m
[09:07] <bialix> tetsuo--: which version of bzr?
[09:08] <a212901390231901> yeah, or with some library interaction on your system, it's a little hard to tell without a detailed report
[09:08] <tetsuo--> current version? 2.2 or something
[09:08] <tetsuo--> i cannot run it right now to make it crash again
[09:09] <tetsuo--> i think pyqt is under heavy refactoring right now
[09:09] <tetsuo--> upstream
[09:09] <a212901390231901> do log something next time it happens.
[09:10] <Peng_> Tracebacks will still be around in .bzr.log even if you can't run it now.
[09:10] <tetsuo--> where does bzr store that on windows?
[09:11] <bialix> tetsuo--: I think 2.2 is a bit broken
[09:11] <bialix> tetsuo--: location of .bzr.log can be seen in the output of `bzr version`
[09:12] <tetsuo--> lol
[09:12] <tetsuo--> bad behaviour there
[09:15] <tetsuo--> just as i thought
[09:16] <tetsuo--> since windows catches the errors there is nothing in the log
[09:17] <tetsuo--> i have the same problem with my project, windows catches 9 out of 10 errors and doesn't generate logable error for me
[09:18] <tetsuo--> so all those crashes get uploaded to winqual, and you need a windows logo cert to get them
[09:18] <bialix> tetsuo--: what is your system?
[09:19] <bialix> I think you'd better downgrade bzr to 2.1.1
[09:19] <tetsuo--> windows 7 x64
[09:19] <tetsuo--> i will do that
[09:19]  * bialix is not sure bzr installer provides 64 bit version
[09:20] <tetsuo--> it doesnt
[09:20] <tetsuo--> luckily on windows that does not matter
[09:20] <bialix> is it possible you have 32-bit related problems?
[09:20] <bialix> ok
[09:21] <tetsuo--> the problem is simple, somewhere in bzr is a buffer overflow that causes a read or write to executable memory, or outside of its memory bubble
[09:21] <tetsuo--> windows 7 x64 catches such things very early
[09:22] <tetsuo--> and chances are very high that the compiler is already warning about that
[09:23] <tetsuo--> whats wierder, should python an qt have a garbage collector etc..?
[09:23] <bialix> well, I can try to provide you compiler log for bzr trunk and py 2.5 and msvc 2003
[09:24] <bialix> tetsuo--: yes, they have gc
[09:24] <tetsuo--> then they should catch any errors/leaks in the python and qt script
[09:24] <bialix> but 2.6 is most likely compiled against py 2.6
[09:24] <tetsuo--> and that means its python or qt itself that is being leaky
[09:25] <bialix> tetsuo--: can you send your question to bzr ML (or bzr-windows ML), and ask about compiler configuration?
[09:25] <tetsuo--> make sense or not?
[09:25] <bialix> tetsuo--: I don't think so
[09:25] <a212901390231901> can do ctypes.windll.kernel32.SetErrorMode(2) to force a bonafide crash rather than getting the "report to microsoft..." thing, but still need a tool to look at the stack
[09:25] <tetsuo--> a212901390231901:  that wont do anything if you dont have the pdb
[09:26] <tetsuo--> debug symbols database for that exact compile
[09:27] <tetsuo--> i dont use email, but i'll consider making a launchpad account and reporting a bug/feature request to pass the windows logo test
[09:28] <tetsuo--> it has testing software that does both dynamic and static code analysis to find these kinds of problems
[09:29] <tetsuo--> (but in vs2003 it really sucks)
[09:30] <tetsuo--> preferably one would compile with vs2010 ultimate and add the following switch /analyse
[09:30] <tetsuo--> oh and /w4
[09:31] <bialix> tetsuo--: you can use gmane or nabble to use bzr ML
[09:32] <a212901390231901> I bet that'd be one annoying log to comb through for things the size of python and qt
[09:33] <tetsuo--> a212901390231901:  it would but almost all of the warnings would be valid
[09:33] <tetsuo--> and especially things like python and qt should be nearly warning free
[09:33] <tetsuo--> so much depends on them
[09:34] <tetsuo--> obviously fixing a warning generated by a windows compiler helps the other platforms too
[09:36] <tetsuo--> but linux has even better tools available
[09:36] <tetsuo--> combined the software could be stable as a rock
[09:37] <idnar> the odds are high that the problem is in a python extension module, not python itself
[09:37] <idnar> it could be in the qt bindings, for example, or in qt itself
[09:39] <a212901390231901> having to remember /D _CRT_SECURE_NO_WARNINGS isn't all that helpful
[09:39] <tetsuo--> i would have guessed that would still be protected by the garbage collector
[09:40] <idnar> tetsuo--: garbage collectors don't protect against any kind of buffer overflow
[09:40] <idnar> they're just a way to manage memory allocation
[09:41] <idnar> an extension module is just regular C code, so there's nothing stopping you from trashing your process's memory, although pure-python code won't (or shouldn't) be able to do that
[09:42] <a212901390231901> anyway, I'm Alexander is right, downgrading should be fine, there have been a couple of issues with the 2.2 prereleases that are likely shallow
[09:42] <a212901390231901> +sure
[09:43] <tetsuo--> ideal swichtes for msvc are /gl /gs /safeseh /dynamicbase /nxcompat /o2 /w4 /analyse /GA /Arch:sse
[09:43] <tetsuo--> fast and secure at the cost of a slightly larger binary
[09:43] <tetsuo--> the arch could be higher or lower depending on the lowest supported target
[09:44] <tetsuo--> yeah im going to downgrade, but that wont fix the problems upstream
[09:45] <tetsuo--> ill try to get some more crashes and report that before downgrading
[09:45]  * tetsuo-- is afk
[10:12] <bignose> Launchpad bug pages simply hang for me.
[10:12] <bignose> lifeless: can you tell me the URL of the bug report for the ‘bzr-gtk’ bug I reported earlier in here?
[10:39] <avu> Is it somehow possible to clone an svn repository with bzr of which I can only access a certain subdirectory, not the repository root? meaning I only have read rights on /repos/root/foo. when I try a normal bzr branch svn+https://user:pass@server/repos/root/foo, I get an error because bzr tries PROPFIND on /repos/root
[10:54] <awilkins> avu, I'm not sure that's possible because of the way that bzr-svn works
[10:57] <avu> awilkins, bummer. Thanks for the info.
[11:01] <cbz> gah
[11:01] <cbz> it seems to me that you end up getting into situations where rebase is unavoidable when using bzr-svn
[11:02] <jelmer> avu: no, that's not possible at the moment - there's an open bug report about it
[11:02] <jelmer> cbz: why?
[11:03] <cbz> So say i've merged my local feature branch back to my local trunk, but the svn repository at that point has additional commits in it
[11:03] <avu> jelmer, ah, good, I'll subscribe to that, thanks
[11:04] <cbz> i can't see what i can do short of uncommmitting my change, rebasing the trunk and then remerging it - which is what rebase would try and do anyway - albeit with less metadata available
[11:10] <avu> jelmer, hm, I have problems finding the right bug on launchpad, could you point me to the right direction?
[12:24] <cbz> jelmet, do my comments make sense?
[12:31] <jelmer> cbz: which ones?
[12:48] <cbz> "it seems to me that you end up getting into situations where rebase is unavoidable when using bzr-svn"
[12:48] <cbz> 11:04 <cbz> i can't see what i can do short of uncommmitting my change, rebasing the trunk and then remerging it - which is what rebase would try and do anyway - albeit with less metadata available
[15:19] <abranches> I created a branch with a bzr pull on the server in directori DIR1. But what I wanted was to create it in DIR1/DIR2. How Can I delete the branch in DIR1, so that I can create the branch in DIR1/DIR2 afterwards.
[15:20] <spiv> Why not just move it directly?  mv DIR1/the-branch DIR1/DIR2
[15:29] <abranches> spiv, I don't have ssh access to the server. But maybe I can ask someone...
[15:31] <Peng_> sftp can rename, can't it?
[15:31] <Peng_> s/, can't it/./
[15:31] <Peng_> Heck, you could even do it using Bazaar's VFS with hitchhiker.
[15:32] <cbz>  jelmer^
[15:33] <abranches> Peng, what commands would you do exactly? I'm not sure about sftp, I'll look at it. Thanks.
[15:34] <jelmer> cbz: Perhaps you're looking for the push_merged_revisions setting?
[15:34] <cbz> possibly - but whats the alternative solution? unmerge my changes and pull and try to commit before someone else commits to the svn repo?
[15:46] <jelmer> cbz: setting push_merged_revisions
[15:46] <cbz> okay
[15:51] <Andrei|2> Hi guys. I've developped a bzr plugin for Visual Studio, anyone wants to try it?
[15:59] <bialix> Andrei|2: yes
[16:00] <Andrei|2> here: http://aigenta.com/downloads/beta/UnifiedSCC_Setup.1.1.beta2.msi
[16:05] <bialix> which one Visual Studio version supported?
[16:05] <bialix> Andrei|2: ^
[16:05] <Andrei|2> all up to 2008
[16:06] <bialix> I'd suggest to announce your plugin in bzr ML or bzr-windows ML, or both
[16:06] <bialix> Andrei|2: and 2003?
[16:07] <Andrei|2> yes, 2003 too. not sure if it works very well, though
[16:07] <Andrei|2> what's ML?
[16:08] <Peng_> mailing list
[16:08] <bialix> ML = mailing list
[16:09] <Andrei|2> ok. is there any wiki to publish links for bzr tools?
[16:10] <bialix> yes, wiki.bazaar.canonical.com
[16:11] <bialix> one sec
[16:11] <bialix> Andrei|2: http://wiki.bazaar.canonical.com/3rdPartyTools
[16:11] <Andrei|2> thanks
[16:12] <bialix> Andrei|2: have an error while trying to add project under version control
[16:12] <Andrei|2> what it says?
[16:12] <bialix> http://pastebin.com/HHZFtyFm
[16:13] <Andrei|2> VS2003?
[16:13] <bialix> yes, I've pushed Test connection button
[16:14] <bialix> tried again, and without Test it works
[16:16] <bialix> Andrei|2: check-in works strange. it commits all files except proj.sln and proj.vssscc, but those files added to version control
[16:18] <Andrei|2> it doesn't show these files in commit window?
[16:19] <bialix> proj.vssscc is not shown
[16:20] <bialix> proj.sln shown in the pending checkins window
[16:21] <Andrei|2> *.vssscc is service file, disregard it
[16:21] <bialix> also I don't have menu item "View History"
[16:22] <bialix> otherwise it looks good
[16:22] <Andrei|2> it's managed by VS.. seek it on the source control toolbar
[16:23] <bialix> ok
[16:24] <bialix> I will try it with more recent VS later
[16:25] <Andrei|2> thanks
[16:42] <cody-somerville> jelmer, When will that support get landed?
[16:43] <cody-somerville> jelmer, and how many other imports are broken now?
[16:55] <rephormat> greetings
[16:56] <rephormat> Why am I getting a cannot build extension error "bzrlib._chk_map_pyx" when using python setup.py install on bzr 2.1.0?
[16:58] <Peng_> Um...got libzlib-dev?
[16:59] <rephormat> THANKS!!
[16:59] <rephormat> I always forget that one
[16:59] <a212901390231901> bug 566923 would resolve this FAQ, hint hint.
[16:59] <rephormat> oh great.
[16:59] <a212901390231901> you did ask the same thing just the other day though ;)
[16:59] <rephormat> thats good that I'm not the only one frustrated with it
[17:00] <rephormat> a212901390231901: Yeah I know. This is on a new system. I'm horrible at remembering things like that.
[17:00] <rephormat> a212901390231901: to my defense I did check the documentation
[17:00] <rephormat> ;-)
[17:02] <bialix> a212901390231901: are your patch approved or blocked?
[17:03] <a212901390231901> vila wanted john to look at the more complicated one again
[17:03] <a212901390231901> which would be a good thing, I'm not super-keen on pyrex
[17:03] <bialix> I can look at pyrex
[17:03] <bialix> link?
[17:03] <rephormat> alright after running python setup.py install it compiled and installed to /usr/loca/bin
[17:04] <rephormat> but its the wrong version still
[17:04] <rephormat> stupid Suse
[17:05] <a212901390231901> bialix: https://code.launchpad.net/~gz/bzr/remove_zlib_double_dependency_pyapi/+merge/23711#review-diff
[17:06] <rephormat> nvm
[17:06] <rephormat> stupid pathing
[17:06] <a212901390231901> I've eyeballed the C it produces and it seems reasonable-ish
[17:07] <a212901390231901> one more favour alexander, do you have a russian copy of windows or an english language one?
[17:15] <bialix> a212901390231901: both
[17:16] <a212901390231901> okay, if you do `os.rename("something_non_existant", "whatever")` on the russian windows, python 2.5 or later, can you paste me the exception it prints?
[17:17] <bialix> a212901390231901: I'm usually checks the generated C file as well ;-)
[17:17] <bialix> a212901390231901: you want russian text?
[17:17] <a212901390231901> yup.
[17:17] <a212901390231901> and the exact bytes, ideally.
[17:17] <a212901390231901> so catch and repr
[17:19] <a212901390231901> repr(e.strerror) that is.
[17:20] <bialix> there will be russian text in cp1251
[17:21] <a212901390231901> that's what I'm hoping.
[17:21] <a212901390231901> I read through the python source to confirm that's what'll happen, I just want a live example for code review
[17:23] <jelmer> cody-somerville: hi
[17:23] <bialix> a212901390231901: on Windows 2000 there is no text at all, and my russian windows xp at home
[17:23] <jelmer> cody-somerville: I'm not sure how many other branches are broken, it's probably best to talk to the code team about that.
[17:24] <bialix> a212901390231901: I'll do this later
[17:24] <bialix> but I can confirm this behavior
[17:24] <bialix> sometimes it's very annoying
[17:27] <bialix> a212901390231901: re your pyrex: why you're using PyInt_AsUnsignedLongMask?
[17:27] <a212901390231901> thanks!
[17:30] <a212901390231901> the crc32 function returned a boxed python integer, that may be -2**31..2**31-1 or 0..2**32
[17:31] <a212901390231901> (changed in some python version I forget)
[17:31] <a212901390231901> this is why the python version does & 0xFFFFFFFF to get a positive value, but has the side effect of upcasting to a long
[17:31] <bialix> a212901390231901: re crc32(<object>bit) -- I feel explicit cast to object is not strictly required here
[17:32] <a212901390231901> PyInt_AsUnsignedLongMask boinks it into a plain unsigned value, which solves the issue
[17:32] <a212901390231901> ^that's an annoying refcounting thing I couldn't find another way of doing
[17:33] <a212901390231901> we get a borrowed reference when we get the value, so that goes in a PyObject* to avoid overhead when it's used in later contexts that don't need to addref
[17:33] <bialix> :-/
[17:33] <a212901390231901> but calling the function with that as a param means we need put it in a tuple, which means we need to addref it
[17:34] <a212901390231901> which apparently pyrex spells by casting to 'object'
[17:35] <bialix> I feel this code looks worse than plain C
[17:35] <bialix> I hope jam will find the time to look on it
[17:36]  * bialix going to home to his russian windows
[17:36] <a212901390231901> yeah, I'm not mad about pyrex/cython as an idea, but john wrote a good post a while back about how much time he reckon it'd saved him with... static tuple I think?... and he's got a lot more experience with it than me
[17:37] <bialix> right
[17:37] <a212901390231901> so perhaps it's possible to learn to love the ugly.
[17:37] <dash> cython is pretty great when you need to write as much or more python-api interacting code as C stuff
[17:37] <Peng_> StaticTuple is not Pyrex.
[17:37] <Peng_> Err, wait.
[17:38] <Peng_> Right. StaticTuple is straight C.
[17:38] <bialix> dash: but bzr using pyrex, not cython
[17:38] <Peng_> bialix: But they're pretty close.
[17:38] <dash> bialix: Ah, pity.
[17:38] <Peng_> bialix: Cython is a fork of Pyrex.
[17:38] <bialix> Peng_: yes, I *know*
[17:39] <bialix> jam several times said he'd better using cython...
[17:39] <bialix> cython has some very nice features
[17:40] <Peng_> Worse, bzr has a few hacks to make certain versions of Pyrex happy.
[17:44] <bialix> ~~~
[17:59] <allquixotic> How efficiently does bzr handle version-controlled binary files that only change slightly between revisions? Is it somewhere on the order of RTpatch or bsdiff, or is it a carte blanche "the file is different so let's store a separate copy"?
[18:01] <xnox> allquixotic, not that well as far as I know
[18:01] <xnox> allquixotic, for example this branch https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/xulrunner-1.9.1/lucid
[18:01] <LeoNerd> Storing binary files in a DVCS is of limited utility anyway
[18:01] <LeoNerd> Half the point is the ability to branch, make changes, merge
[18:02] <xnox> well lp:ubuntu/xulrunner-1.9.1
[18:02] <LeoNerd> You can't merge changes to opaque binary files and haev any hope in hell of not breaking it
[18:02] <xnox> has 16 revisions of xulrunner tarball. The branch is huge I never managed to clone it =)
[18:02] <dash> LeoNerd: sure, but some people only pay attention to the other half of the point of a VCS :)
[18:03] <xnox> on merge conflicts you will get "this.binary or that.binary" and you will have to merge it yourself =) using whatever program edits those binaries
[18:04] <allquixotic> xnox: I see.. so if I choose to simply replace the old binary with the new one, it will literally store an entire copy of the new one, even if the two have very slight differences?
[18:04] <xnox> LeoNerd, you can import & export tarballs efficiently if you are using bzr-builddeb plugin. But that's only if you have mostly text-base src tarballs. You can import/export tarballs using that
[18:05] <LeoNerd> Hrm?
[18:05]  * xnox got the nicks wrong again
[18:05] <xnox> allquixotic, ^^^ where I "talked" to LeoNerd
[18:06] <LeoNerd> Ah. :) That makes more sense now
[18:07] <allquixotic> xnox: Let's just take a hypothetical case of a very complex set of images that are encoded in a simple enough format that changing only a few pixels makes minimal binary diffs between them. "Other VCSes" (such as Mercurial, also a DVCS) can very efficiently handle that diff just like sophisticated binary patch tools that exist outside of the VCS world. Is there a particular reason why bzr can't do that, or is it just
[18:07] <allquixotic>  unimplemented?
[18:08] <allquixotic> I mean, you could easily say "don't do that", but that's really a cop-out. The benefits of having the files version-tracked are enormous on their own. It's a nightmare having "myimg-20090821.png" "myimg-2009-0830.png" and so on and so on. VCS makes that easy on purpose.
[18:08] <xnox> allquixotic,  I'm not experienced enough bzr developer to tell you.
[18:08] <xnox> allquixotic, but I believe you can mark files to be treated as text
[18:09] <xnox> and then bzr should repack, diff them as usual
[18:09] <xnox> i wonder if it does it anyway
[18:09] <xnox> let me browse through source to see any hints
[18:10] <allquixotic> I might try it for fun. I'll commit a 1 MB .png, hex edit it, change one 0 to a 1, commit again, and if it uploads 1 MB again then I'll just have to keep binary files outside of bzr
[18:13] <xnox> allquixotic, after first commit and after second commit run $ bzr pack
[18:13] <xnox> and delete files in .bzr/repository/obsolete_packs/*
[18:14] <xnox> or just ignore obsolete_packs dir when looking at the size of the repository
[18:14] <allquixotic> xnox: if I do those two steps in my local branch before I push (not using a bound branch), will all that extraneous data not get uploaded to the server? :)
[18:14] <xnox> allquixotic, obsolete_packs/* are not uploaded
[18:15] <allquixotic> oh cool
[18:15] <allquixotic> so does it automatically pack before it pushes, then?
[18:15] <xnox> it packs on logarithmic scale with respect to commits/pulls
[18:16] <xnox> so sometimes you end up doing commit and it spawns a repack
[18:17] <xnox> Me is committing ubuntu.iso to a bzr branch
[18:17] <xnox> and I will do $ echo "1" >> iso
[18:17] <xnox> to test this =)
[18:17] <allquixotic> if the repack has some algorithm for handling packing of binary files, I'm happy... even if it isn't as efficient as rtpatch or bsdiff, if it's something other than store two nearly-identical files in full, I'm happy :)
[18:18] <allquixotic> Thanks for investigating that, xnox :)
[18:19] <allquixotic> I'm having another unrelated puzzler at the moment; I may need to ask this on #launchpad, but didn't get a reply there in ~30 mins so I'll repost here.
[18:19] <allquixotic> A colleague is trying to do an Update operation on a launchpad bzr branch in my private (commercial) branch. He's on Windows XP running bzr 2.1.1 standalone. The error: "-> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://my_user@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request." Any
[18:19] <allquixotic>  insight?
[18:22] <xnox> allquixotic, what do you mean "update operation"
[18:22] <xnox> $ bzr upgrade
[18:22] <xnox> or
[18:22] <xnox> $ bzr update
[18:23] <allquixotic> xnox: the "Update" button in bzr explorer, on a bound branch
[18:23] <allquixotic> pretty sure that's bzr update
[18:24] <xnox> allquixotic, i hope (my_user) is a masked username and sshkeys are installed correctly on his machine
[18:24] <allquixotic> my_user is not his actual launchpad id :)
[18:25] <xnox> apart from that. he can try to use bzr+http:// url
[18:25] <allquixotic> he did call launchpad-login with the right username, and has his ssh keys set up
[18:25] <allquixotic> oh, http won't work, because it's a private branch
[18:25] <xnox> that way it's not gonna use ssh and should be still fast
[18:25] <allquixotic> if unauthenticated http works then it's not private
[18:25] <allquixotic> which would be a big deal
[18:26] <xnox> allquixotic, =))))))))) well I have nothing to do with commercial launchpad offerings
[18:26] <xnox> sorry =)
[18:26] <xnox> dunno
[18:26]  * xnox is doing only open-source stuff =)
[18:26] <allquixotic> it seems that many of the Canonical folks who work on launchpad are in Australia or NZ, because i was able to get hold of them at 5 am GMT-5, but i tried just a few minutes ago and they're probably asleep ;)
[18:27] <xnox> allquixotic, as far as I know there are some folks in NZ and some folks in Vancouver Canada
[18:28] <allquixotic> oh well, I will walk my colleague through the steps to check out the branch from scratch and see if that works
[18:28] <xnox> the Vancouver side is running 24h support.... last time I heard
[18:28] <allquixotic> good news is he doesn't have any uncommitted changes, or any local commits queued up
[18:29] <allquixotic> so he can just pull a fresh copy
[18:29] <allquixotic> er, branch, rather... bzr branch
[18:49] <bialix> a212901390231901: ping
[18:51] <bialix> it seems python 2.5.4 broke WindowsErrors + non-ascii texts
[18:55] <bialix> C:\work\Bazaar\plugins\qbzr>python -c "import os; os.unlink('lib')"
[18:55] <bialix> Traceback (most recent call last):
[18:55] <bialix>   File "<string>", line 1, in <module>
[18:55] <bialix> WindowsError: [Error 5] : 'lib'
[18:55] <bialix> a212901390231901: as you can see there is stripped non-ascii characters and only ascii file name left
[18:55] <a212901390231901> ew, that's ugly.
[18:56] <bialix> in previous versions of python 2.5.x there *was* russian text, I swear
[18:56] <a212901390231901> I take it the console is a different codepage from the ACP used for error messages?
[18:56] <bialix> no, chcp has no effect
[18:57] <a212901390231901> okay, so some kind of bad bug fix attempt maybe, wonder if I can track it down.
[19:10] <bialix> a212901390231901: I found something
[19:12] <bialix> a212901390231901: http://pastebin.com/9QFeWf4j
[19:12] <bialix> the russian text said: "unable to create file,"
[19:12] <a212901390231901> ha. but... str(e) strips?
[19:12] <bialix> yep
[19:12] <a212901390231901> what about e.strerror?
[19:13] <bialix> empty s well
[19:13] <bialix> empty as well
[19:13] <a212901390231901> okay, that narrows the search
[19:13] <bialix> ok
[19:15] <a212901390231901> thanks!
[19:16] <bialix> np
[19:43] <a212901390231901> hmph, will have to come back to this later
[19:58] <bendj> my bzr-svn plugin works fine @ branch/pull of source from svn repos.  afaict, however, it does NOT get the svn:externals svn:ignores info, or more importantly, convert then to bzr-speak.
[19:58] <bendj> CAN it?
[20:38] <NfNitLoop> bendj:  I'd answer you, but you left. :p
[20:41] <masmullin> hello I have a (hopefully basic) bzr merge problem.  Is there anyone here who might be able to give me a hand?
[20:41] <dash> quite likely :)
[20:43] <masmullin> Ok here goes there are two development branches that I have loaded onto lauchpad (~masmullin/scintilla-cocoa/makefilework and ~masmullin/scintilla-cocoa/mousewheel)
[20:43] <masmullin> both have the same parent, which is at revision 33
[20:44] <masmullin> I have made 2 commits to each branch, so they are both at revision 35
[20:45] <masmullin> when I do the following command "bzr branch lp:~masmullin/scintilla-cocoa/mousewheel && cd mousewheel && bzr merge lp:~masmullin/scintilla-cocoa/makefilework" bzr responds to me saying "Nothing to do"
[20:45] <masmullin> I want to get the changes from the makefilework branch into the mousewheel branch
[20:45] <masmullin> any ideas?
[20:46] <masmullin> any URLs that describe what I want (I've been searching but haven't found the info I need)
[20:48] <dash> masmullin: Hm
[20:48] <dash> masmullin: try doing 'bzr missing' instead of 'bzr merge'
[20:48] <dash> that'll tell you about differences between the branches
[20:49] <masmullin> it tells me that I have "2 extra revision(s)" and gives me the commit messages from the mousewheel branch
[20:49] <masmullin> it does not tell me anything about the makefilework branch
[20:50] <dash> masmullin: ok
[20:51] <dash> so what bzr thinks is going on is that all the revisions in makefilework are already in your current branch
[20:51] <masmullin> :( unfortunately this is not true.
[20:52] <dash> masmullin: looking at the log on code.launchpad.net your results are a little surprising
[20:52] <masmullin> I should point out that the mousewheel branch is "newer" (time-wise) than the makefilework branch
[20:57] <masmullin> dash: have I run into an unknown bug, or am I using the tool incorrectly?
[20:59] <dash> masmullin: i'm stumped. but i am not an expert :)
[21:00] <masmullin> dash: stumped too... looks like I should file a report
[21:03] <IslandUsurper> masmullin, bzr qlog says that mousewheel has already merged in the two commits from makefilework
[21:03] <IslandUsurper> in revno 34
[21:03] <masmullin> islandusurper: via manual inspection i can tell that this is incorrect
[21:03] <mkanat> masmullin: If bzr says that it's happened, then there was probably some human error along the way.
[21:04] <maxb> masmullin: You have unfortunately made an error when creating the mousewheel branch, and recorded a merge which did not actually occur in the history
[21:04] <masmullin> how do I ifix this?
[21:05] <mkanat> masmullin: If it's the most recent commit, you can uncommit it.
[21:05] <mkanat> masmullin: Did you do "bzr revert ." after merging, or something?
[21:05] <maxb> Ideally? Create a new branch from the existing trunk, port your existing changes to the new branch, and throw away the old mousewheel branch
[21:05] <masmullin> mkanat: not to my knowledge
[21:05] <masmullin> maxh: I can do that... the changes made were small
[21:05] <mkanat> masmullin: Note that if anybody else has pulled from your branch, uncomitting is bad.
[21:06] <maxb> A very important thing to understand is that "bzr revert" and "bzr revert ." have significantly different effects on the history
[21:09] <maxb> masmullin: Do you have the bzr-rewrite extension installed?
[21:10] <lifeless> yeah, I regret that subtle distinction
[21:10] <lifeless> thinking we should make it a flag
[21:10] <masmullin> i dont know... I installed the 2.1.1 for mac and accepted all the plugins that came with that... I have no other plugins installed
[21:10] <masmullin> no worries though... Im 75% done rewriting the change manually
[21:10] <mkanat> lifeless: Yeah, a flag would be way better.
[21:10] <maxb> If so, you can rebuild your changes without the bad history by branching r33 of trunk, and then using 'bzr replay -r34..35 mousewheel'
[21:11] <mkanat> lifeless: I didn't even know about "." until you told me. Maybe --keep-merges.
[21:11] <mkanat> lifeless: Or --remember-merges to make it the opposite of --forget-merges.
[21:12] <maxb> A flag would make sense - going to a pristine tree but keeping pending-merges is a highly specialized operation
[21:12] <maxb> --keep-merges somehow feels more explanatory to me
[21:12] <mkanat> maxb: Me too.
[21:21] <masmullin> alright I got it working nicely now... sorry to take up your time, thank you for the help
[21:44] <kkaefer> how is the lp: alias integrated/defined in bazaar?
[21:49] <Peng_> kkaefer: It's somewhere in bzrlib.plugins.launchpad, using Bazaar's directory service feature.
[22:03] <lifeless> vila: still around ?
[22:03] <lifeless> or jam: ?
[22:03] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/2.0-new-subunit/+merge/24365
[22:04] <jam> lifeless: I'm around
[22:04] <rephormat> What is the best way to use launchpad as a central repository?
[22:04] <lifeless> this should unblock yours and spivs patches that are targeted to 2.0
[22:04] <rephormat> Meaning I do my developing on one machine (bzr push lp:project) and then get the updated source from launchpad on the production machine?
[22:04] <lifeless> rephormat: bzr
[22:05] <lifeless> rephormat: oh sure, or push directly, or whatever your preference is.
[22:05] <jam> lifeless: well, if it gets things working, approve
[22:05] <lifeless> jam: care to clicky clicky it ? :P
[22:05] <jam> lifeless: already done
[22:05] <rephormat> lifeless: lets say I have successfully pushed to launchpad, but want to update the sources on my production machine from launchpad?
[22:05] <lifeless> thanks!
[22:05] <rephormat> how would I do that?
[22:06] <lifeless> rephormat: bzr pull, or bzr update, depending on whether you did 'bzr branch' or 'bzr checkout' on the production machine
[22:06] <rephormat> lifeless: I did bzr branch.. should I have done bzr checkout?
[22:07] <lifeless> rephormat: if you did bzr branch, then use 'bzr pull' to update the sources on your production machine.
[22:07] <rephormat> lifeless: Well #$% I thought I tried that already.
[22:07] <rephormat> lifeless: THANKS! So what is the difference between branch and checkout?
[22:09] <lifeless> rephormat: in a checkout, commits go to the 'master' branch (as do pull, push, uncommit); when the master branch has new work on it use 'update' to get that work to be present locally.
[22:10] <rephormat> AHH!!!
[22:10] <rephormat> so with a branch I can do development locally and then push to the centralized location?
[22:10] <lifeless> rephormat: in a branch, commits/pull/push to this/uncommit affect just the branch, use pull to get new work from some other branch into this branch, or merge + commit if you have been making independent changes.
[22:10] <lifeless> yes
[22:10] <rephormat> SO!!!
[22:11] <rephormat> I would use branch to do "development/feature requests" and prbably checkout for bug fixes on the main branch?!!
[22:11] <lifeless> sure
[22:12] <rephormat> sweet fancy moses!
[22:12] <rephormat> Thanks!!
[22:25] <dash> anybody seen this before with bzr-svn? http://paste.ubuntu.com/424235/
[22:26] <lifeless> not I
[23:26] <jelmer> dash: there's an open bug report about it
[23:32] <dash> jelmer: great
[23:32] <dash> jelmer: i managed to work around it by branching from before my last merge, pulling from svn, then pulling from that into my working branch
[23:37] <bendj> Reading @ jelmer's bzr-svn docs (http://wiki.bazaar.canonical.com/ForeignBranches/Subversion),  I note: "'svn:ignore' is not imported.", and a reference to a spec (https://launchpad.net/bzr/+spec/new-ignore-rules) that says "completed" as of 2007, per mbp.  Unclear whether just the spec was completed, or the feature was ...
[23:38] <bendj> Does bzr-svn support import of svn:ignores?  I _do_ know that bzr-externals handles the svn:externals piece of the equation ...
[23:38] <TresEquis> bendj: the feature isn't in place
[23:38] <bendj> TresEquis: double RATS!
[23:39] <bendj> I am trying sooooo hard to not have to use svn ....
[23:39] <bendj> without monkeying about, anyway :-/
[23:40] <jelmer> bendj: no, neither ignores nor externals are imported at the moment - mainly because there's no good thing to map them to in bazaar
[23:40] <TresEquis> bendj: you can work around that one via a script
[23:40] <TresEquis> jelmer: couldn't bzr just generate a .bzrigonre file?
[23:40] <TresEquis> bzr-svn, I mean
[23:41] <TresEquis> I understand that the externals fix isn't pretty
[23:41] <jelmer> TresEquis: that breaks with roundtripping, since we'd need a way to convert .bzrignore to svn:ignore as well
[23:41] <jelmer> TresEquis: there isn't a fix :-)
[23:42] <TresEquis> heh, I just check the .bzrignore file into svn ;)
[23:42] <bendj> jelmer Arg. I'd though svn:externals was supported -- but digging around, then, still seems this is relevant: http://stackoverflow.com/questions/463275/do-you-have-a-clever-hack-to-work-around-svnexternals-not-being-supported-in-bzr
[23:43] <bendj> ( bendj considerds sticking head in sand until a solution arrives ... )
[23:43] <jelmer> bendj: yes, that's still accurate.
[23:44] <TresEquis> the nested-tree bit is still stalled
[23:44] <bendj> jelmer: thanks for the info, not necessarily for the news.  <rant> sick of being told "just use subversion.  it's a 'real' rcs" </rant>
[23:44] <jelmer> TresEquis: yeah, unfortunately :-/
[23:45] <jelmer> bendj: sorry, can't really help with that. nested trees are a nontrivial project to take on
[23:46] <TresEquis> I get away with (manually) mapping externals onto unrelated checkouts
[23:46] <bendj> Who can we "light a fire under" for nested-tree?  Anyone in particular?  mbp?  Perhaps a community-bucket bribe isreq'd?
[23:46] <TresEquis> which I then tell the paretn to ignore
[23:47] <bendj> TresEquis: Understood.  For serious adoption, though, gotta have ways to deal with existing 'legacy' (== svn,cvs) project code bases.
[23:47] <bendj> . /me waves the bzr cheerleading-flag (miniature, souvenir version ...)
[23:49] <TresEquis> I understand the need
[23:50] <jelmer> bendj: yeah, mbp is probably the best person to talk to.
[23:50] <TresEquis> I've just decided that using bzr to boost my own productivity when working with big SVN repositories is worth the hassle, and the workarounds
[23:50] <bendj> TresEquis: When you say 'manually mapping', do you mean script-based?  ala, extract the svn:{ignores,externals} then have a script do the mapping?  or do you mean by-hand?
[23:51] <bendj> seen mbp
[23:51] <bendj> hrmph.  duzznt work ....
[23:51] <bendj> rubs lamp.  nada.
[23:51] <bendj> aha! whois ...
[23:52] <bendj> grr.  different mbp ...
[23:52] <TresEquis> bendj: I do it by hand, mostly
[23:52] <TresEquis> have a directory full of the "common" externals
[23:52] <TresEquis> which I use for symlinks when making a new bzr branch
[23:52] <bendj> TresEquis: k.  sure, workable. messy ....
[23:53] <TresEquis> yup
[23:54] <xnox> TresEquis, well as long as you are not doing "svn-import for everyone" i did this
[23:54] <TresEquis> hmm?
[23:54] <xnox> $ bzr branch svn://external.server/bla/trunk path/to/where/external/should/be
[23:55] <xnox> $ bzr join path/to/where/external/should/be
[23:55] <xnox> $ bzr ci
[23:55] <xnox> Now you have diverged from both svn's
[23:55] <xnox> but you can do
[23:55] <xnox> $ bzr merge :parent
[23:55] <xnox> to get updates from svn
[23:55] <xnox> and
[23:55] <xnox> $ bzr merge svn://external.server/bla/trunk
[23:55] <xnox> to get updates in the extern subdit
[23:55] <xnox> to get updates in the extern subdir
[23:56] <TresEquis> interesting
[23:56] <xnox> But *actually* commiting
[23:56] <TresEquis> I didn't know about bzr join
[23:56] <xnox> back to svn
[23:56] <xnox> is tricky cause you need to have pristine import somewhere else which you push to from this joined beast
[23:57] <TresEquis> I usually keep a pristine SVN import around anyway
[23:57] <xnox> TresEquis, join & split is the smallest bit of NestedTrees that landed
[23:57] <TresEquis> so I would do your dance inside a branch from that
[23:57] <xnox> it allows you to join & split branches. But once you join it's in your history
[23:57] <xnox> so when you eg $ bzr up -r-100
[23:57] <xnox> your "joined" external is not there
[23:58] <TresEquis> ah
[23:58] <bendj> xnox: interesting.  in the current case, i'm ONLY interested in svn co -- from a parent project -- and I never plan on committing BACK to the parent.
[23:58] <xnox> well then you are fine =)
[23:58] <TresEquis> bendj: you should use 'bzr branch svn+ssh://whatever' then
[23:58] <TresEquis> or do you plan to use 'bzr up' inside your checkout?
[23:59] <xnox> Then I would even join the external at the commit the external was actually introduced and merge it with the current tip
[23:59] <xnox> that way you can use the point revision of the joined tree to revert it independently of the mainline