lifelessyes, I can understand that00:00
lifelessI think its reasonable to write a plugin to encode/decode bad names00:00
sportman1280ok well question then.  the filename. does it just have to be valid CURRENTLY, or does it have to be valid all trough the repository history.  we have 10,000 revisions....00:00
sportman1280so if i can just change the file thats in the svn repository, then thats great00:01
lifelesssportman1280: if you are converting all your history, it has to be valid for all of history. Are you wanting to evaluate bzr to move to it, or you just want to use it to hack on current code?00:01
sportman1280lifeless: the plan is to move to it00:01
lifelesssportman1280: I'd look at editing a fastexport dump then, I think its probably best overall00:02
sportman1280ok. now i have to figure out how to fastexport svn00:02
sportman1280btw, i agree there should be a plugin that can handle these situations :(00:03
sportman1280lifeless: ok the fast importer. i played with it for hours earlier today. but had no success at even running it. any help?  i have the plugin installed int he .bazaar/plugins folder00:04
lifelesssportman1280: well, you'll want the svn-fast-export to get your data out00:05
lifelessas for bzr fast-import, what happened when you tried to run it ?00:05
lifelessdoes the plugin show up in 'bzr plugins'00:05
sportman1280thats the thing i couldnt get it to run at all00:05
lifelessok, thats the fast-export side00:08
lifelessyou need pysvn installed from the look of it00:08
sportman1280ok done trying again00:11
sportman1280lifeless: I still get the same error :(00:13
lifelesswhat does 'python -c import svn' do?00:14
lifelessmwhudson: do you recall which package has the python module 'svn'00:14
mwhudsoni think that's the python-subversion bindings that you have to read the C api docs to use00:14
lifelesssportman1280: which precise package did you install; there are multiple python svn bindings00:15
mwhudson(package is called python-subversion iirc)00:15
sportman1280python-svn is the only one i saw00:15
sportman1280 python -c import svn00:16
sportman1280  File "<string>", line 100:16
sportman1280    import00:16
sportman1280         ^00:16
sportman1280SyntaxError: invalid syntax00:16
lifelesstry 'python-subversion'00:16
sportman1280lifeless: it can't download from a internet repository can it?00:18
lifelesssportman1280: I don't know00:18
sportman1280lifeless: dang00:18
sportman1280ok thats it. i give up. 7 hours later and the stupid thing still doesn't work. bazaar clearly just isnt meant to be used :(00:25
sportman1280now i get svn.core.SubversionException: ("Expected repository format '3' or '5'; found format '9'", 165005)00:28
lifelesssportman1280: :(00:34
sportman1280lifeless: ok i'll try a little more before giving up00:35
sportman1280is there another way to dump the data and then import it back into svn?00:35
markhis loading submodules a "supported" usecase for lazy imports - eg "from bzrlib import (ui, ui.text,)" - its failing for me in a py2exe environment...02:39
markh(with the above in a string used by the normal lazy_import stuff...)02:39
spivmarkh: it is, yes.02:40
spivI'm not sure that "from x import y.z" is used much in our lazy_imports so far, though, so there may be a bug there.02:41
lifelessmarkh: the brackets look odd02:41
markhbugger - that means I need to look into a lazy_import bug rather than just rearrange the imports ;)02:41
lifelessmarkh: try02:41
lifelessfrom bzrlib import ui02:41
markhlifeless: yes, the code in question is a larger block02:41
lifelessin fact02:41
lifelesswhat is 'from bzrlib import ui.text' *meant* to do02:41
markhin a py2exe environment, 'ui.text' causes an attribute error, and dir(ui) doesn't show a 'text' attribute.  all works fine run from source02:41
spivlifeless: import "bzrlib.ui.text", and add "ui" to the local namespace.02:42
lifelessmarkh: in bzrlib.ui add a lazy_import of bzrlib.ui.text as text02:42
lifelessmarkh: lazy_import definitely doesn't know what to do with that import I think02:42
markhit does from source, which is strange.02:43
lifelessmarkh: I'm fairly sure its being masked02:43
spivmarkh: from source something else might be importing it ui.text?02:43
jameshI don't think the normal Python import statement would know what to do02:43
lifelessI've checked the code and it claims to have support for this02:44
spivOh, huh.02:44
lifelessmarkh: up to you if you want to work around or dig deep02:44
* spiv wonders why he thought "from x import y.z" should work02:44
lifelesslazy_import.py line 16802:44
markhjamesh appears to be correct - its not valid Python anyway!02:44
markh"from bzrlib import ui, ui.text" is a syntax error02:45
markhlifeless: but you are saying lazy imports *should* support it regardless?02:46
lifelessmarkh: no02:46
lifelessI'm saying that the docstring in the code claims to support02:46
lifelessfrom bzrlib import ui.text02:46
markhstrangely, it *does* support it!02:47
markhjust not in a py2exe environment02:47
jameshone of the perils of putting code in strings02:47
lifelessjamesh: all code is strings02:47
markhok, thanks.  The code is in qbzr, so I'll take it up with them!02:47
lifelessmarkh: I would try editing ui.__init__02:48
lifelessas I suggested before02:48
markhlifeless: I'm a bit lost then - you saying it *should* support that even though it would be a syntax error in normal python, and I should edit ui.__init__ to try and make it work in a py2exe env?02:49
lifelessmarkh: did you see my suggesetion at 13:39?02:49
jameshlifeless: well, in this case it'd probably be possible to write a version of lazy_imports that didn't involve embedding code in strings02:50
markhI think we have time skew, but yes.  However, I also saw your comment saying it should not support in the first place given its a syntax error, hence my confusion02:51
jameshwhich would let Python parse and syntax check the imports02:51
jameshand might let other tools see the imports without modifications02:51
lifelessjamesh: suggestions appreciated02:52
lifelessjamesh: I imagine an import hook might allow it but at a very convoluted cost02:52
markhto my mind, the code I quoted is clearly wrong as it would be a syntax error in normal cases.  So I'm still confused if the consensus is bzrlib should support it, or should barf on it...02:52
markhif it isn't that bzrlib should support it, I'm confused what my edits to __init__ would be aiming for.02:53
lifelessmarkh: they may work around the problem02:53
markhright - but presumably that woudn't be accepted as a patch?02:53
markhwhich means it doesn't actually solve the problem I'm having in binary builds that anyone else (eg, John) creates.02:54
lifelessmarkh: I'd accept it, as lazy importing a deep module like that is plain weird IMO02:54
lifelessmarkh: and it will provide info on how lazy_import may be failing02:54
markhlifeless: I'm really confused now :)  You would accept a patch that allows bzr's lazy imports to accept "plain wierd" things, rather than asking the code change to not be wierd?02:54
lifelessmarkh: uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh02:55
lifelessmarkh: AIUI you are not getting a barf, you are getting ui.text not imported02:55
lifelessso ui is imported but ui.text isn't02:55
markhmy thoughts exactly.  I'm confused why the advice isn't simply "fix the wierd code" :)02:55
lifeless13:41 < lifeless> markh: up to you if you want to work around or dig deep02:55
markhbut why would I want to dig deep to support something plain weird?02:56
lifelessif py2exe is failing to copy in ui.text, then jamesh's thoughts about a different style of import hook may be useful long term02:56
markhclearly I should just fix the import to code that would be valid in regular python and everyone is happy!02:56
lifelessmarkh: sure, I never suggested that you don't change it02:57
markhright - I'm confused though why you would consider supporting it if it wasn't changed - but that's fine - I'll just quit while I'm ahead :)02:57
jameshlifeless: if you bung the imports into a function body, you can either (a) disassemble the code to find the imports or (b) run the code with a custom __import__() to catch the imports02:58
jameshtools like py2exe generally handle imports in function bodies just fine02:59
markhyeah - py2exe just uses the modulefinder package, and that does scan the bytecode for imports iiuc.03:02
markhjamesh: you comments above about using Python to check the syntax implies you think the behaviour I described (ie, that my example works anywhere) is actually a bug rather than a feature?03:03
jameshmarkh: I'd prefer that the lazy imports syntax mirrored what was possible with normal imports and not more03:04
jameshhaving something that is almost but not quite compatible but looks the same is going to cause bugs03:04
markhso that is a "yes" :)03:04
markhok thanks - just trying to make sure I wasn't *totally* misunderstanding things!03:05
lifelessI don't see any reason for lazy imports to be more than regular import can do03:05
markhlifeless: right - but my example shows they can in some cases, right?03:10
lifelessmarkh: yes03:10
lifelessmarkh: however thats in qbzr isn't it? I'm not aware of smartass stuff like that in bzr itself03:11
markhbut longer term, the best interests of everyone would imply noone tries to take advantage, let alone extend, the current behaviour and should use valid python syntax.03:11
markhwell - I'd call it plain "wrong" rather than smart-arse :) but yeah...03:11
markhdamn - changing the import to a python compatible "from bzrlib import ui; from bzrlib.ui import text" still doesn't work unless I make the change suggested by lifeless anyway (ie, adding 'import bzrlib.ui.text as text' to the lazy import block in ui\__init__.py).  Should I submit a patch even though I don't have a test case?03:29
garyvdmIf I do a repository.lock_read() and I *don't* do a repository.unlock() , nothing bad seams to happen.04:01
garyvdmThis is surprising!04:01
markhtortoise itself works well with 1.11 though, including 64bit windows, so that's my bzr work for the day done...04:02
garyvdmIs it ok to do that?04:03
lifelessgaryvdm: not in general04:04
lifelessmarkh: cool04:04
mwhudsongaryvdm: don't you get a warning printed somewhere when you do that?04:05
garyvdmI do get a warning if I don't unlock a branch.04:06
garyvdmBut not with a repository.04:06
pooliespiv: is bzr+ssh://host/~/thing supposed to work now?04:06
spivpoolie: not yet; there's a quick patch on a bug IIRC.04:07
lifelessgaryvdm: not sure why you don't see a warning; likely its because the pack family of repositories does its locking more lazily than branch04:12
lifelessgaryvdm: all the same, you should lock/unlock04:12
=== Mario__ is now known as pygi
poolieok, i just misremembered04:14
lifeless334 revs to go04:16
lifelesspoolie: that evo fix I did at UDS has been committed upstream :)04:19
thumperlifeless: 334 revs to go until what?04:27
lifelessthumper: my local repo has all the bad revs identified and the rest copied to a clean --1.9 repo04:27
lifelessthumper: I need to do this to start dogfooding lp for my bzr branches amongst other things04:27
thumperah, ok04:28
lifelesspoolie: I'm done for the day I think04:57
spivspm: bzr's pqm appears stuck?04:57
spmspiv: oki, fixoring04:57
spivspm: ta04:58
spmspiv: cause was another one from vila: "Rev 3934: (vila) Fix bug 315737 by correctly querying the test feature" :-(04:59
ubottuLaunchpad bug 315737 in bzr "Test bzrlib.tests.test_osutils.TestChunksToLines fails" [Low,Fix committed] https://launchpad.net/bugs/31573704:59
spmshould be ok again now04:59
spivspm: thanks.  I'm surprised that that change by vila would cause pqm problems.05:01
spmspiv: it's a resonably common (for a rare occourance) seems to hang on the email sending side for some reason. We just kill off the stuck mailing portion and everything works again.05:02
spmie typicaly bloody sysadmins - went things break drag out the Biggest Sledgie you can find and start smashing daemons :-)05:03
spms/went/when/ . Other grammer errors left alone.05:03
pooliei thought we tracked this down...05:06
pooliethere might be a patch attached to a bug in pqm?05:06
pooliespm, didn't you and me look at this05:06
poolielifeless: night05:06
spmpoolie: I don't recall chasing that down? But you could well be right - I know we have chased other stuff down. :-)05:07
vilahi all06:58
bitmonki'm trying to use bzr-svn, recent from packages on ubuntu 8.10, to push a branch to a new svn location, is this not possible? i get 'http does not support mkdir()'07:19
bitmonkand if i try to point at a local path, i get 'parent of ___ doesn't exist', which makes sense, as it's a subloc of an svn repo with other packages..07:20
pooliei think there's a separate command to create the new branch07:21
pooliethe repository must already exist07:21
bitmonktrying clone..07:24
bitmonkthe repo exists, but i'm pushing to a subdir of a repo, so the file:/// path doesn't actually exist, a portion of it is within an svn repo..07:24
igc1hey vila07:38
=== igc1 is now known as igc
vilaspm: you said "seems to hang on the email sending side"... did you track it down to being *mail* related ? I had only see it occurs when I use a "lp:" url so I thought it was ssh related instead07:41
vilabut it's hard to tell from outside :-/07:41
vilaspm: I also tried to *stop* using "lp:" url (not that masochistic you know...) but pqm then just ignored my submissions without feedback (giving me hope to fix the problem :/)07:42
spivvila: well, the web interface said it got as far as "success: merge lp:~vila/bzr/bzr.integration/ http://bazaar-vcs.org/bzr/bzr.dev"07:42
vilaspiv: I know...07:42
vilaAnd, to me, that sounds like some connection not being gc'ed or something...07:43
vilawhere both client and server are waiting the other end to say: I'm done07:43
vilaespecially because when the pqm process is *killed* then my submission is successfully proceeded (sp?)07:44
bitmonkvila: processed07:48
vilabitmonk: thks07:49
bitmonknp :)07:49
bitmonkassuming you are not a native english speaker, whatever your language is, i'm sure i couldn't say client or server or computer or address or network ;)07:49
bitmonkif you are, well, no offense, i'm glad to help with vocab where your high school left off ;)07:50
* vila needs one lost coffee to finish full boot07:50
bitmonkkeep in mind that green tea has comparable caffeine to coffee, but is less addictive..07:50
vilabitmonk: not native but I welcome feedback on any error I can make (language or anything else)07:50
* bitmonk broke the coffee adiction year sago07:50
bitmonkvila: i love non-native english speakers, if only for the opportunity to be helpful when others aren't..07:50
* vila is already having a hell of a time curing its tobacco addiction, coffee helps in the mean time :)07:51
* bitmonk has often thought of moving out of the USA and can't imagine what it would be like to face the same social and economic challenges without barely knowing how to say "i'm sorry, but my clients have paid late.."07:51
bitmonkyah i hear that07:51
bitmonkgotta pick battles07:51
* bitmonk has cut back a lot on tobacco but hasnt killed like coffee07:51
bitmonki probably drink more than i would if i drank coffee, but i look for other sources of caffeine, whether i'm right or wrong, i dont like the coffay feeling.07:51
bitmonkand that said when i used to liv eon coffee i honestly drank a crap load of canadian whiskey every night with my coworkers07:52
* bitmonk is pretty sure somewhere in that haze he lost a perfectly good automobile07:52
bitmonkthat light pole had a bad attitude! :-P07:52
* bitmonk hides07:52
bitmonkanyway, eh, i still never figurd out how to push something initialized in bzr to svn, i swear i have before, i'll figure it later, for testing sake i just put the code into place with bzr where it's expected to have pulled from svn.07:54
vilapoolie: (reading logs backwards) I thought the pqm-stucked-problem was fixed too... and truth is it didn't manifest itself for sometimes... but no hard numbers there as often when tracking erratic bugs :-/07:55
* bitmonk tries to determine if building his Dom0 kernel in a DomU from the same sources, with same options, will take a comparable amount of time..07:55
bitmonkoh wrong chan ;d07:56
vilabitmonk: the answer should be: "it should", but that's a wild guess, I'm not using xen :-)07:58
bitmonkvila: actually it took just under 8min when it takes almost 30min in Dom0, I must have missed something when mrproper-ing, or left a bunch of stuff out of menuconfig.. this, i find difficult to believe..07:59
bitmonkesp as people on comparable hardware have told me that general kernel build takes around 25-30min (3.0GHz C2D)07:59
bitmonkanyway, way out of scope for #bzr join in ##xen if you want to continue :)07:59
bitmonkmaybe it was helped by LVM having the right blocks cached, as i built the kernel in Dom0, then unmounted the LVM volume, restarted DomU, mounted the xfs vol, and build the same code after a mrproper..08:00
bitmonkalso the DomU has like 512M of RAM and Dom0 has like 3.5-4.008:00
bitmonkanyway, again, out of scope08:00
* bitmonk scuttles off to ##xen08:00
vilabitmonk: thanks for the offer :-) I may try xen in a couple of months but virtualbox is enough for my needs so far08:02
bitmonkxen i find quite interesting, though i've been a kernel-hearted-fool since high school some years ago ;)08:03
* bitmonk heart menuconfig08:03
igcnight all08:46
=== thekorn_ is now known as thekorn
Haffi___Hi, I'm trying to set up bzr on a server, I've published a branch to it via sftp. When I run bzr branch sftp://... and fetch the tree, edit a file, commit the changes, and finally run 'bzr send' then I get this error: bzr: ERROR: No mail-to address specified.11:29
Haffi___How do I specify the mail-to address?11:30
Haffi___Do I have to specify it?11:31
bob2third last paragraph of 'bzr help send'11:31
luksthat's not really accurate11:33
luksthe email address is only required for some clients (like the simple editor+smtp one)11:33
luksif you are using a gui client, it's usually optional11:33
bob2for /to/ or /from/?11:33
lukse.g. I have it configured to use evolution, I just run bzr send and type the address in evolution's window11:35
Haffi___but does the mail have to be sent? If I just skip sending the mail when evolution opens, does it matter?11:36
bob2then you want -o11:36
Haffi___right, then it's written to file or stdout11:36
bob2where do you want the bundle then?11:37
Haffi___It still seems like the changes aren't published11:38
bob2all 'send' does is produce a bundle and optionally email it somewhere11:39
bob2it doesn't affect any branches - are you trying to update the branch you branched from?11:39
Haffi___hehe, yes11:39
Haffi___I misunderstood the command11:39
Haffi___which command should I use then? I guess 'merge' is to fetch changes from main branch?11:40
luksbzr push11:41
Haffi___yep, it worked11:44
Peng_Is it valid to have a revision ID "" (I mean, an empty string, not literally two double-quotes)?12:15
luksI don't think revision IDs have any specified format12:15
luksso I'd say it's valid, but I'd expect some code to break on that12:16
luksbecause NULL revisions used to be represented as None12:16
Peng_The exception raised is NoSuchRevision. It would likely be something else if it was actually invalid..12:18
spivPeng_: At a glance, the code would treat that as a valid revision ID I think.12:19
spivWhy do you want to know?12:19
Peng_I just wrote an email about it, actually, in Benn Finney's thread.12:20
spivIt's bad enough that bzr's history has a revision "A" ;)12:20
Peng_Haha, how'd that happen?12:20
Peng_"silly commit"?12:21
Peng_...Creating a file called "b"?12:21
spivPeng_: I think a test that made a test commit accidentally modified that developer's real bzr.dev repo instead of a throwaway repo.12:22
Peng_Anyway, I wanted to know because of Loggerhead. The URL "/files/" raises an error because it's a nonexistant revision, instead of doing something more useful like showing the index page.12:22
Peng_But if it is a valid revision, that's correct behavior, if not convenient...12:22
spivBack before the test suite was as good as it is now at insulating tests from reality.12:22
spiv(and vice versa)12:22
spivI think it'd be reasonable to disallow "" as a revision ID.12:23
spivIt seems more likely to cause bugs than be helpful.12:23
Peng_I don't disagree, but I don't care strongly enough to do anything about it. :P12:25
spivWell, you already did, by mailing the list ;)12:25
Peng_Heh, good point.12:27
=== ubott2 is now known as ubottu
phinzeis there a quick way to tell bzr: 'add all of the files in the unknown list' ?14:26
beunophinze, bzr add?14:27
phinzebeuno: doh!  that was way too easy :)14:27
* phinze was automatically thinking of subversion where he had to do xargs magic for that sort of thing... and consequently didn't read line 1 of the help14:30
phinzehere's another one... is `bzr co foo; cd foo; bzr unbind` the equivalent of `bzr branch foo` ?14:33
beunoI'm not sure, I don't use checkouts much14:34
luksyes, it is14:34
phinzeluks: cool, thanks. just trying to get my head around this stuff14:35
abentleyphinze: It is *roughly* the same.  "bzr co" won't set the parent location, but "bzr branch" will.14:37
phinzeabentley: really, that's interesting, you'd almost think it would be the other way around14:38
phinzethat the checkout would be tethered to a parent and the branch would be free floating14:38
abentleyphinze: The parent location is used for pulling.  You shouldn't pull in a checkout.  You should update in a checkout, which uses the bound location.14:38
phinzeso really for the decentralized workflow `bzr branch` is really what you'd want to use14:40
phinzebecause bzr co + bzr unbind leaves you without a pull source14:42
rockyphinze: yeah but the first time you pull into a branch that has no pull source, it remembers the new source14:44
phinzerocky: okay nice, so there isn't all that much difference between the two in the end14:45
rockyyeah, and you can always change the pull source again with --remember14:46
andresmujicahi are newbies question allowed?? .. :)14:51
nDuffandresmujica, absolutely14:51
andresmujicahehe thks14:51
LarstiQdoes anyone here use bzr-hookless-email?14:51
andresmujicai'm using a sw called 5-a-day, as far as i've check it uses bzr internally14:52
andresmujicathe problem is that i'm using from 2 different computers14:52
andresmujicaso i wonder14:52
andresmujicawhich is the right procedure to use it14:52
andresmujicawhen i change computers14:52
andresmujicasomehow update the local .bzr before any update??14:53
nDuffandresmujica, are both systems able to connect to each other, or do you want to coordinate through somewhere (any SFTP/WebDAV/FTP/etc. space) they can both get through?14:53
andresmujicathere's a main place (code.kaunchpad.net)14:53
andresmujicaboth point there14:53
nDuffandresmujica, I think it might be easier to have both of them use bound branches14:53
andresmujicabut the revisions numbers are different because i mainly work at one of them, and sometimes at the other...14:54
andresmujicaso i suspect i've got to merge or pull or something like that before start my work...14:54
andresmujicaat the less used computer14:54
nDuffif they're bound, that would make every commit automatically push to the server, and every update automatically check the server... but yes, you're right, you'd want to do some merging while setting it all up.14:54
nDuffif the more-often-used computer has a superset of everything at the less-often-used system, you should be able to do a push to the server, bind the branch there (on the more-often-used system), go to the less-often-used system, do a pull and then bind that one as well.14:55
nDuff...if the more-often-used one doesn't have a superset, do a merge on it before the push.14:56
nDuff...do you have RSA keys or somesuch to get to the remote system? The software may be surprised if it gets prompted for a password during commit/update/etc. if it's written to expect that its repository will always be unbound (and otherwise purely local).14:57
nDuff("the software" == "5-a-day")14:57
andresmujicayeap 5-a-day.. i'm making a mess with my branch :(14:57
andresmujicayeap i've got the keys already in place on both systems14:58
seb_kuzminskyin a distributed workflow with no central server, can i give my team-mates' branches nicknames locally?15:14
seb_kuzminskyi want to be able to say "bzr merge alice", "bzr merge bob", etc15:14
seb_kuzminskyand have "alice" and "bob" expand to the urls of those team mates15:14
james_wseb_kuzminsky: not currently, though you may want to look at the bzr-bookmarks plugin15:14
seb_kuzminskythanks james_w :-)15:15
seb_kuzminskybzr-bookmarks is winrar!!  :-D15:23
rbriggsatuiowaI am encountering the different rich-root support error while trying to clone15:27
rbriggsatuiowaI tried the suggestions on https://bugs.launchpad.net/bzr/+bug/27242515:28
ubottuUbuntu bug 272425 in bzr ""different rich-root support" error could be clearer" [Low,Confirmed]15:28
rbriggsatuiowabut get an bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. error15:28
rbriggsatuiowawhen trying to do a  bzr upgrade --rich-root-pack15:29
rbriggsatuiowabzr co works just fine15:31
phinzehi all i'm in the same spot as rbriggsatuiowa15:33
phinzerbriggsatuiowa: if you bzr init --rich-root-pack foo; cd foo; bzr pull remote-foo; it works15:33
phinzebasically bzr clone is creating a repository of format pack-0.9215:34
phinzewhich is not right15:34
phinzebecause the remote bzr server is using rich-root-pack15:36
rbriggsatuiowastupid gentoo15:36
phinzerbriggsatuiowa: mine's doing it too (ubuntu 8.10, bzr 1.6.1)15:37
rbriggsatuiowaI double-checked the USE flags and don't seem to be missing anything15:37
phinzerbriggsatuiowa: which version you on15:43
rbriggsatuiowaBazaar (bzr) 1.6.115:44
phinzeyeah let's try upgrading to 1.10 (which the server is on)... msging you details15:44
phinzeyep, the problem was using a 1.6.1 client with a 1.10 remote branch15:56
andresmujicaok, guys. i 've learned how to do it.  Thanks for your help!!!!16:00
andresmujicasee ya!16:00
ollie___bzr mv concrete/blocks/autonav/ blocks/autonav17:12
ollie___bzr: ERROR: Could not move autonav => autonav: blocks/autonav is already versioned.17:12
ollie___could someone tell me why i am getting that message?17:12
ollie___there is currently nothing in blocks/autonav17:13
ollie___so i don't see how it can already be versioned17:13
ollie___bzr remove blocks/autonav17:13
ollie___blocks/autonav does not exist.17:13
rsc-hi guys. I have a branch i'm working on. I make some changes, but instead I change my mind -- i want to commit those changes into a NEW branch. how do i do that?17:38
LarstiQrsc-: have you made the changes yet?17:38
LarstiQrsc-: if so, you could `bzr merge --uncommitted path/to/branch/with/changes` from the one where you want them17:38
rsc-cool :)17:39
LarstiQdid that help?17:39
rsc-that should be automatic, yeah? no need for my intervention?17:39
rsc-(assuming that both branches are identical)17:39
rsc-(...except that one of them has uncomited changes)17:40
LarstiQshould be, yeah.17:40
rsc-you learn something new everyday.17:40
rsc-thanks :)17:40
LarstiQPossibly you want to list a couple of files you want the changes from, and not others.17:40
adeelcan bzr handle resource forks (found in macs)?17:47
LarstiQadeel: I don't think it does anything special with them.17:48
=== asac_ is now known as asac
LarstiQas most things are wont to do.17:48
adeelLarstiQ, well i know svn has issues with it...where if i check in a file with a resource fork attached, it won't come out the same17:49
jelmeradeel, I don't think it handles them at the moment17:50
jelmerat least it doesn't handle extended attributes (Linux) or streams (Windows)17:50
LarstiQadeel: that doesn't suprise me, almost nothing handles them.17:50
adeelyeah that's what it seems like17:51
jelmerIt would actually be interesting to seem them being used to store VCS metadata17:52
adeelall i know is that bzr has been confusing the hell out of me...conceptually i get the idea, but actually getting my repo started has been a royal pita17:53
=== mark1 is now known as markh
NfNitLoopadeel: How has bzr been confusing you?18:10
jamjelmer: ping18:18
jelmerjam, pong18:18
jamhi jelmer, for the win32 installers, I went ahead and kept using 0.4.1618:19
jamShould I be trying to switch to the 0.5 series?18:19
jelmerjam, no, at least not for any production-oriented setups18:19
jamk, that's what I thought, but I figured I'd check, since there wasn't an 0.4.17 yet18:19
jelmerI hope to release another rc in the next couple of days, then maybe 0.5.0 after that18:20
jamjelmer: is 0.5 compatible with an 0.4 conversion? (I'm guessing not, but figured I'd check)18:21
jelmerjam, no, although it does support using 0.4-style mappings if explicitly configured18:22
jamjelmer: but it would create all new revision-ids, right?18:23
jelmerjam, if the 0.4-style mappings are enabled, no18:23
jelmerit would create the same revision ids that 0.4 would18:23
jamso by default 0.5 isn't compatible, but it can be made so?18:23
jelmerjam: yes18:23
jamIt would be good to have that well documented for an 0.5 upgrade18:23
jelmerThere's a README.UPGRADING file18:24
jamIt would probably be important enough to make sure it would get into the NEWS items for whatever bzr starts including it18:24
jelmerjam: yeah, probably18:24
jelmerjam, one of the things I hope to do in the future (as part of the effort to make bzr more aware of foreign branch support) is to have a subclass of DivergedBranches that indicates different mappings (but the same foreign revision)18:25
jelmerincluding referncing the right docs about upgrading between bzr-<foreign vcs> mappings18:26
rockyjelmer: remember that bug i showed you a while back with bzr-svn where it couldn't find the parent branch of a tag? don't suppose you've made any progress on that?18:56
jelmerrocky, not sure19:19
jelmerrocky, I've fixed *some* bugs, not sure if that included yours19:19
jelmerdo you remember the bug #?19:19
rockyi dont'... but i did update from bzr-svn 0.5 branch and discovered that it now seems to depend on bzr 1.1119:21
rockyso that means there won't be a 0.5 version that works on bzr 1.10 ?19:21
rockyregardless, i tried with bzr 1.11rc1 + bzr-svn 0.5 branch (as of a couple days ago) and got the same error ...19:21
rockyjelmer: just try "bzr co svn+https://dev.serverzen.com/svn/collective/Products.eXtremeManagement/trunk" and watch it complain about tags19:22
jelmerrocky, that appears to require a password?19:29
rockyjelmer: oh sorry, try the non https version19:33
rockythat's anonymous use19:33
jelmerah, thanks19:34
jelmerrocky, that seems to redirect me to the https url19:35
LarstiQronny: what does the workingset accomodate?19:38
rockyjelmer: ok, http://svn.plone.org/svn/collective/Products.eXtremeManagement/trunk/ definitely works, i just browsed to it in a browser ;)19:43
ronnyLarstiQ: manages a set of n branches, i view heads as branches19:44
LarstiQronny: ok19:46
ronnyLarstiQ: im not entirely sure on the abstraction19:46
LarstiQronny: what prompted you to include it?19:46
ronnyLarstiQ: stuff like hg's named branches19:47
* LarstiQ looks that up19:47
ronnyLarstiQ: and of course gits moving tag based branches19:47
ronnythats clearly different than bze's directory branches19:48
ronnyLarstiQ: made a sense out of all stuff?20:14
LarstiQronny: I read through http://www.selenic.com/mercurial/wiki/index.cgi/NamedBranches, but that isn't very enlightening20:18
ronnyLarstiQ: named branches are basically static tags on a revision20:21
ronnyLarstiQ: it can be used for tihngs like separate vendor branches or very long-lifed global branches20:21
jelmerrocky, that's bug 312272, not fixed yet20:22
ubottuLaunchpad bug 312272 in bzr-svn "unable to find direct lhs parent" [High,Triaged] https://launchpad.net/bugs/31227220:22
rockyjelmer: ah cool ... don't suppose you have an eta? :)20:29
=== spm_ is now known as spm
jelmerrocky, should be pretty soon now20:35
rockygreat...  it's actually stopping me from getting anymore work done on my eXtremeManagement branch :(20:36
rockyjelmer: btw, will 0.5.0 final run on bzr 1.10 ?20:36
jelmerrocky, no, it will require at least 1.1120:36
rockyjelmer: that's strange since 0.5rc1 worked on 1.1020:37
rockybut no biggie20:37
jelmerstill quite some things have changed since rc120:37
jelmer~20 bugs have been fixed since rc1 so far, that number will probably end up around 2520:39
rockyno big deal, i don't mind upgrading to bzr 1.11 ... do you know when eta on 1.11 final is?20:39
rockythat one bzr-svn bug is killing me tho20:39
jelmerI think 1.11 final is already out actually20:40
jamjelmer: just 1.11rc121:22
jamrocky: 1.11 final is this fri21:22
lifelesshi jam21:25
jamhi lifeless21:25
jamgood morning21:25
lifelessjam: how are you going with merging stuff to bbc?21:28
jamI've gotten a few things landed21:28
jamI have a test suite run going to see if there is anything we need to focus on21:29
jamhmmm.. 22 failures 13 errors21:29
jama lot of them close to trivial21:29
jamlike not using "assert" in the code21:29
jamhmm. and a really random error from a piece of code getting a negative number that didn't expect one21:31
markhjam: qbzr is broken in the 1.11rc1 :(21:49
markh(and therefore most of tortoise)21:50
jamThanks for the heads up. Any idea why?21:50
jamI just used the 0.9.6 release, I can go back to 0.9.5 if you think it is necessary21:50
markhlazy imports :)21:51
markhI mentioned it yesterday in IRC, but the discussion just fizzled out as I'm not sure exactly how to resolve it.21:51
jamso lazy imports don't work with the packaging?21:52
markhin short, qbzr does 'from bzrlib import ui.text' in a lazy import block, and while that works from source it fails in py2exe.  A potential solution was to fix bzr itself by having the ui package itself lazily import text21:52
markhindeed, that was the only solution I could see - re-arranging the imports in qbzr also failed21:53
jamdo you have the tracebacks to why it is failing with py2exe?21:54
spivWhy did rearranging the imports in qbzr fail?21:54
jamIt seems like it should be working21:54
markhthe discussion on IRC yesterday stalled after I asked if I should submit a patch even though I don't have tests, but that went unanswered...21:54
jamAnd may signify a bug in the lazy import code21:54
spivmarkh: submitted code is > unsubmitted code.21:54
spivmarkh: (and code with tests > code without tests, but having a patch in the first place is a good start...)21:55
markhspiv: I'm not sure why they failed to be honest, but I assume it was still something related to lazy imports21:55
spivmarkh: Hmm.  Maybe question that assumption? :)21:56
spivI'm just guessing.21:56
jamso, for my immediate fix, I can do a 1.11rc1-2 with qbzr 0.9.521:57
jamat least people will have something that works21:57
jammarkh: I don't see any "import.*ui" or "import.*text"22:00
jamin qbzr22:00
jam(well, aside from the 'gettext' lines)22:00
markhin commands.py22:00
* markh finds it22:00
markhmornin' ian22:01
jamah, there it is22:01
jamI would guess the problem is doing:22:01
spivmarkh: wow, and it's a totally gratuitous lazy_import anyway :)22:01
jamfrom bzrlib import (22:01
jam ui,22:01
jam  ui.text,22:01
jamI wouldn't expect that to be valid22:01
markhyeah, we had this discussion yesterday with lifeless :)22:02
jam     from bzrlib import ui.text22:02
jam                          ^22:02
jam SyntaxError: invalid syntax22:02
jamThat syntax isn't valid python import22:02
spivjam: right, there's a bug that lazy_import allows that.22:02
spiv(and a bug that qbzr does that)22:03
markhbut - it fails if you try the "obvious" thing that is valid Python syntax.  The detaisl escape me now and I'm yet to have my morning coffee :)22:03
spivmarkh: the obvious thing is "from bzrlib.ui.text import TextUIFactory", IMO22:03
markhoh - well, I was trying "from bzrlib.ui import text" under the assumption the text name was needed - but you are probably correct that it isn't.22:04
spivmarkh: no, the code is clearly needing "ui.text" so it can use "ui.text.TextUIFactory" at the moment22:04
markhyes - I was assuming it also used other attributes from that module22:05
jammarkh: http://paste.ubuntu.com/104124/22:05
jamWould be my suggsetion22:05
markhbut - at lifeless' suggestion, the code as written works if you add "import bzrlib.ui.test as text" to the lazy import code in ui\__init__.py22:05
markhjam: so just remove them from lazy imports?22:06
spivmarkh: actually I'd expect "from bzrlib import ui; import bzrlib.ui.text" in qbzr would work too.22:06
jammarkh: they are used right away22:06
hsn_is there way to define alias for URL which i can use with bzr push?22:06
jamlazy doesn't do anything22:06
jamhsn_: there is a "bookmarks" plugin22:07
jamlp:bzr-bookmarks IIRC22:07
jamthen you get "bm:XXX"22:07
markhyeah - in this case it needs to be fully imported anyway22:07
hsn_jam: in bzrtools?22:07
jamhsn_: bzr-bookmarks *is* the plugin22:07
hsn_got it.22:09
hsn_is there way to checkout just some directories from branch?22:10
jamhsn_: not yet22:13
hsn_http://bazaar-vcs.org/NestedTreeSupport -> this thing works already?22:25
markhjam: so the plan is you will re-release with an earlier version of qbzr, and I'll ping the mailing list in the hope of a new release tomorrow?22:35
markhnew qbzr release22:35
markhor will you hack the existing qbzr into shape?22:36
jammarkh: I just patched 0.9.6 => 0.9.6-win32 with a trivial 'don't make it lazy" fix22:37
jamAnd I'll send that to the qbzr list22:37
markhawesome - thanks22:37
NCommanderI was wondering if someone could try and confirm a bug in bzr-svn?22:39
NCommander(I'm not sure if there is something locally thats causing the issue or not)22:39
jelmerNCommander, sure22:40
lifelessNCommander: moar details needed :P22:41
jampoolie: ping22:42
NCommanderlifeless, I'm trying to checkout the following SVN repo:22:42
NCommanderbzr co svn://uclibc.org/trunk/buildroot22:42
NCommanderIt bombs out with a UTF error22:42
pooliejam, pong22:43
jampoolie: Are we going to start back up with doing a weekly direct call between you and I?22:43
jamWe seemed to have faltered on that after the new year22:43
poolieah we have a bit22:44
NCommanderjelmer, also ^22:44
pooliethat would be good though22:44
poolieshould we talk now, or maybe tomorrow morning?22:44
jampoolie: tomorrow would work best, I think22:45
jelmerjam, that reminds me, I've been meaning to ask you what happened to the "This week in Bazaar" blogposts22:45
* igc food22:46
jamI sort of "lost steam" in writing them. Well that and lost statik as my motivator22:46
jamI'm a bit of a too-many-details sort of person, so it worked best to have someone who would know what a community would want to hear22:47
jammarkh: I uploaded 1.11rc1-222:48
jamcan you give it a shot?22:48
pooliehello markh22:48
rockstarjam, I'm still willing to help out on those.22:48
markhhi poolie22:48
* NCommander pulsechecks lifeless 22:49
jelmerNCommander, when does it fail, which revision?22:49
NCommanderjelmer, after its done importing and starts building the bazaar tree22:49
NCommanderjelmer, I'm running the bazaar from Jaunty, so it might be a little behind the current release version22:50
lifelessNCommander: can you get the backtrace from ~/.bzr.log please22:50
jamrockstar: maybe we should give it another go this week. If you have the chance, try to think about things that we might want to talk about22:51
rockstarjam, sounds good.22:51
lifelessstatik is still alive yes22:52
NCommanderlifeless, and jelmer http://paste.ubuntu.com/104142/22:52
jelmerjam, Ah22:52
jelmerjam, I thought they were quite useful22:53
lifelessthats still in bzr-svn22:53
NCommanderAny ideas how I can fix it, or at least work around it?22:54
jelmerNCommander, I'm trying to reproduce it here22:54
NCommanderjelmer, it died for me in the high 22000s22:54
jelmerNCommander: Ah, it died during "fetching revision info" ?22:55
markhjam: now failing due to the svn plugin wanting 1.10 it seems22:55
NCommanderyeah, I reran it22:55
markhor maybe bzrtools - its not clear22:55
* markh checks the log22:55
jelmerNCommander, that's not occurring here, so at least this bug is fixed in 0.522:55
NCommandersomeone should update the ubuntu packaging22:56
jammarkh: I would expect it to be bzr-svn, just because I did pick bzrtools 0.11.022:56
jambut if you could poke a bit closer, I would appreciate it22:56
jelmerNCommander, 0.5.0 isn't out yet22:56
jelmerdebian experimental has a 0.5rc packaged fwiw22:56
NCommanderis it available in a PPA?22:56
markhjam: the traceback isn't clear but it looks like svn:22:57
markh0.313  bzr-svn: using Subversion 1.5.4 ()22:57
markh4.361  Traceback (most recent call last):22:57
markh  File "bzrlib\api.pyo", line 82, in require_api22:57
markhIncompatibleAPI: The API for "<module 'bzrlib' from 'C:\Program Files (x86)\Bazaar\lib\library.zip\bzrlib\__init__.pyo'>" is not compatible with "(1, 10, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)".22:57
jelmermarkh, could very well be bzr-svn22:57
markhcertainly as of yesterday, svn failed like that22:57
jelmermarkh, that doesn't look like a released version of bzr-svn22:57
lifelessmarkh: whats the caller above in the backtrace22:57
* markh needs glasses :)22:58
markh2 entries up is svn's __init__22:58
NCommanderjelmer, where can I find the bzr-svn snapshots or bazaar branch?22:58
jelmerNCommander, http://people.samba.org/bzr/jelmer/bzr-svn/0.522:58
NCommanderjelmer, empty folder22:58
jelmerNCommander, it's a bzr branch22:59
markhjelmer: is there a bzr-svn jam should be using with the 1.11 windows binaries?22:59
jammarkh, jelmer: lifeless originally made a change that bumped the bzrlib api number22:59
jamthat was supposed to land in 1.9, I updated it because it landed in 1.1122:59
enigma42jelmer: I just checked out a branch from svn. After running a "bzr check" on the repo, I get "4 inconsistent parents". Is that bad?22:59
jamI don't remember what off-hand22:59
jelmerwhat happened to API-specific versions? :-)23:00
jamah, it was the "add_inventory_by_delta" change23:00
jelmerah, ok23:01
jelmerthat shouldn't be relevant to bzr-svn23:01
jelmerI'll release a 0.4.1723:01
enigma42jelmer: "And I get a bzr: ERROR: No such file" message when I try to branch over sftp.23:01
enigma42(But not locally, interestingly enough.)23:01
jelmerenigma42, hmm, that's strange - what version of bzr-svn?23:02
jamjelmer: just make sure your tag propagates to bzr-svn's trunk :)23:02
enigma42jelmer: bzr-svn 0.5 trunk revno 228123:03
enigma42jelmer: Let me pull up to revno 2293 and try again.23:03
jelmerenigma42, the two things should not be related23:03
jelmerenigma42, what file exactly does it give the error about?23:04
enigma42bzr: ERROR: No such file: ('iovariableplugin.gro-20081110215858-yuu32hfdt8apjga0-1', 'kirby@kirby-ubuntu-dev-20090105202353-tv2de4iskr45pl68')23:04
jelmerenigma42, hmm, in that case it could actually be related23:04
jelmerenigma42, does the repository in question contain any revisions pushed with previous versions of bzr-svn?23:04
enigma42This is a fresh branched just checked out of svn.23:05
markhjam: seeing you need to make a new build, could you update tsvn too?  I've made some doc improvements yesterday and bumped the version to 0.2-candidate23:05
enigma42jelmer: Yes.23:05
enigma42enigma42: The *svn* repository contains revisions pushed with the previous version of bzr-svn23:05
enigma42jelmer: But the *bzr* repo was a fresh checkout from svn.23:05
markhjam: actually, maybe scratch that, unless you are also willing to make a trivial change to the .cog23:05
enigma42Just to make sure we're both talking about the same "repository" here. ;-)23:06
markh(which would be the s/index.html/*.html/ patch I submitted yesterday that was apparently not looked upon favourably by bundlebuggy)23:07
jelmerenigma42: this error is likely caused by incorrect bzr-svn metadata set by a development version of bzr-svn, but it's hard to say for sure23:08
enigma42jelmer: Is there a way I can zap the metadata in SVN?23:09
enigma42enigma42: I'm fine with loosing merge history in this case.23:09
markhjam: I need to run out for an hour any time in the next hour.  Do you expect to have new builds up soon?  If so, I'll wait and test them before leaving.23:09
jelmerenigma42, only by doing a "svnadmin dump" and removing them in the svndump23:10
enigma42jelmer: Oh boy.23:10
enigma42jelmer: With 0.5, is that changing?23:11
enigma42jelmer: Since it will use revision properties instead?23:11
jelmerenigma42, yeah, it's easier with 0.5 indeed (but only if you have subversion 1.5)23:11
NCommanderjelmer, so how do I use 0.5, I installed it and now get: No module named foreign23:11
jelmerNCommander, you need bzr 1.1123:11
jelmersorry, 1.11rc123:12
NCommanderI assume no packages exist ...23:12
jelmerI think there may be some in the bzr ppa23:12
NCommanderwhere do I find the source tarballs :-)23:13
NCommanderhey lamont23:13
enigma42jelmer: Yeah, I get the same "No such file" error with bzr-svn 0.5 trunk revno 229323:13
enigma42jelmer: Do you know of a way of fixing up the bzr repo by hand rather than purging the svn properties?23:16
james_wNCommander: try ~bzr-beta-ppa23:16
NCommanderOf course now that I actually have everything installed from source does james_w pop up with the handy to use PPA23:16
NCommanderjelmer, and as an aside, the issue fixed in the latest bazaars23:18
NCommanderThanks for the tip23:18
jelmerenigma42, not really - the svn repository contains corrupt metadata, it's impossible to create a bzr branch from that23:18
jelmerI guess we could add a svn-import option to skip reading any bzr-svn metadata23:19
enigma42jelmer: That would be quite nice. :-)23:19
lifelessjames_w: the beta ppa doesn't have bzr-svn23:20
spivjelmer: thinking of bzr-svn options...23:20
enigma42jelmer: I don't control the svn server, so I can't do a svn-dump.23:20
markhbb in an hour...23:20
spivjelmer: I've seen a few people get surprised that bzr-svn will operate on a .svn checkout, specifically when they have .bzr and .svn control dirs for the same directory23:20
enigma42jelmer: So I guess I'm out-of-luck than.23:20
lifelessspiv: installing bzr-svn by default would fix that23:21
spivjelmer: it might be nice if there were a way to disable that feature in ~/.bazaar/locations.conf23:21
jelmerspiv, that seems more like something for the bzr format probe logic23:21
jelmerspiv: or do you mean being able to completely turn off support for .svn directories?23:24
lifelessjelmer: if you probe in a subdir of the root of a svn tree, does bzr get told 'no branch' and keeps probing, or do you 'find' it immediately and return the root?23:24
jelmerlifeless, it's always a BzrDir23:25
jelmerwhether bzr-svn considers a Branch to be present depend son the repository layout23:26
lifelessjelmer: well, Tree I mean23:26
lifelessjelmer: cause of the .svn dir23:26
jelmerlifeless, same goes for tree23:26
lifelessso at the root of a tree, the bzr probe should occur first23:26
spivjelmer: the latter, at least for a given location23:26
lifelessand thus a .bzr dir will win23:26
lifelessin a subdir though, it might be nice for it not to find a ControlDir unless its the root of the tree, that would let colocated .bzr and .svn 'work as expected'23:27
lifelesswithout needing special facilities23:27
lifelessspiv: I don't really like the idea of turning it off23:27
spivjelmer: So I think it'd be possible to make SvnCheckout.probe_transport consult locations.conf before actually probing.23:27
jelmerlifeless, the problem also appears to be that people try to "bzr add" .svn directories23:27
lifelessjelmer: when a svn tree is under a bzr tree?23:28
jelmerlifeless, or at the same location23:28
jelmerthat's actually what I've seen happen so far, rather than the use case spiv is mentioning23:28
spivIt'd probably be enough to make .bzr always take precedence over a .svn.23:28
spivBecause people can always use /usr/bin/svn to manipulate .svn dirs.23:28
lifelessjelmer: smart_add will skip .svn dirs if they probe successfully as a branch23:31
jelmerlifeless, what I mean is that people *want* to version the .svn dirs in some cases23:32
lifelessjelmer: oh. they are insane?23:33
lifelesshmm, bzrdir.is_control_filename needs to be pluggable23:33
lifelessjelmer: ^23:33
lifelessspiv: .bzr should already mostly take precedence; except for when bzr is run in a subdir of a .svn tree I think; I'd aargue that that is a valid bug23:34
spivlifeless: sure.  It's definitely been observed by various people that it doesn't necessarily take precedence.23:35
lifelessspiv: the reason I am con making this toggleable is that its an option that adds complexity, and is pretty clearly only useful if the functionality isn't right23:36
jelmerspiv, it does when they exist in the same directory, but .svn has control dirs in subdirectories as well, not just the tree root23:36
lifelessjelmer: so whats the use case for versioning .svn ?23:36
jelmerlifeless, poor mans tracking of an upstream branch in svn23:37
spivlifeless: If everything Just Works, then that's great.23:38
lifelessjelmer: oh23:38
spivlifeless: Until it does, I'd rather have a toggle that can at least make working the way the user intends possible than not.23:39
lifelessspiv: IME such toggles become the end result23:39
jelmerjam, 0.4.17 pushed23:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!