| lifeless | yes, I can understand that | 00:00 |
|---|---|---|
| lifeless | I think its reasonable to write a plugin to encode/decode bad names | 00:00 |
| sportman1280 | ok 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 |
| sportman1280 | so if i can just change the file thats in the svn repository, then thats great | 00:01 |
| lifeless | sportman1280: 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 |
| sportman1280 | lifeless: the plan is to move to it | 00:01 |
| lifeless | sportman1280: I'd look at editing a fastexport dump then, I think its probably best overall | 00:02 |
| sportman1280 | ok. now i have to figure out how to fastexport svn | 00:02 |
| sportman1280 | thanks | 00:02 |
| sportman1280 | btw, i agree there should be a plugin that can handle these situations :( | 00:03 |
| sportman1280 | lifeless: 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 folder | 00:04 |
| lifeless | sportman1280: well, you'll want the svn-fast-export to get your data out | 00:05 |
| lifeless | as for bzr fast-import, what happened when you tried to run it ? | 00:05 |
| lifeless | does the plugin show up in 'bzr plugins' | 00:05 |
| sportman1280 | thats the thing i couldnt get it to run at all | 00:05 |
| sportman1280 | http://pastebin.com/m661c1d68 | 00:07 |
| lifeless | ok, thats the fast-export side | 00:08 |
| lifeless | you need pysvn installed from the look of it | 00:08 |
| sportman1280 | ok done trying again | 00:11 |
| sportman1280 | lifeless: I still get the same error :( | 00:13 |
| lifeless | what does 'python -c import svn' do? | 00:14 |
| lifeless | mwhudson: do you recall which package has the python module 'svn' | 00:14 |
| mwhudson | i think that's the python-subversion bindings that you have to read the C api docs to use | 00:14 |
| lifeless | sportman1280: which precise package did you install; there are multiple python svn bindings | 00:15 |
| mwhudson | (package is called python-subversion iirc) | 00:15 |
| sportman1280 | python-svn is the only one i saw | 00:15 |
| sportman1280 | python -c import svn | 00:16 |
| sportman1280 | File "<string>", line 1 | 00:16 |
| sportman1280 | import | 00:16 |
| sportman1280 | ^ | 00:16 |
| sportman1280 | SyntaxError: invalid syntax | 00:16 |
| lifeless | try 'python-subversion' | 00:16 |
| sportman1280 | lifeless: it can't download from a internet repository can it? | 00:18 |
| lifeless | sportman1280: I don't know | 00:18 |
| sportman1280 | lifeless: dang | 00:18 |
| sportman1280 | ok 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 |
| sportman1280 | now i get svn.core.SubversionException: ("Expected repository format '3' or '5'; found format '9'", 165005) | 00:28 |
| sportman1280 | :( | 00:28 |
| lifeless | sportman1280: :( | 00:34 |
| sportman1280 | lifeless: ok i'll try a little more before giving up | 00:35 |
| sportman1280 | is there another way to dump the data and then import it back into svn? | 00:35 |
| lifeless | svnadmin | 00:36 |
| markh | is 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 |
| spiv | markh: it is, yes. | 02:40 |
| spiv | I'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 |
| lifeless | markh: the brackets look odd | 02:41 |
| markh | bugger - that means I need to look into a lazy_import bug rather than just rearrange the imports ;) | 02:41 |
| lifeless | markh: try | 02:41 |
| lifeless | from bzrlib import ui | 02:41 |
| markh | lifeless: yes, the code in question is a larger block | 02:41 |
| lifeless | in fact | 02:41 |
| lifeless | what is 'from bzrlib import ui.text' *meant* to do | 02:41 |
| markh | in a py2exe environment, 'ui.text' causes an attribute error, and dir(ui) doesn't show a 'text' attribute. all works fine run from source | 02:41 |
| spiv | lifeless: import "bzrlib.ui.text", and add "ui" to the local namespace. | 02:42 |
| lifeless | markh: in bzrlib.ui add a lazy_import of bzrlib.ui.text as text | 02:42 |
| lifeless | markh: lazy_import definitely doesn't know what to do with that import I think | 02:42 |
| markh | it does from source, which is strange. | 02:43 |
| lifeless | markh: I'm fairly sure its being masked | 02:43 |
| spiv | markh: from source something else might be importing it ui.text? | 02:43 |
| jamesh | I don't think the normal Python import statement would know what to do | 02:43 |
| lifeless | I've checked the code and it claims to have support for this | 02:44 |
| spiv | Oh, huh. | 02:44 |
| lifeless | markh: up to you if you want to work around or dig deep | 02:44 |
| * spiv wonders why he thought "from x import y.z" should work | 02:44 | |
| lifeless | lazy_import.py line 168 | 02:44 |
| markh | jamesh appears to be correct - its not valid Python anyway! | 02:44 |
| markh | "from bzrlib import ui, ui.text" is a syntax error | 02:45 |
| markh | lifeless: but you are saying lazy imports *should* support it regardless? | 02:46 |
| lifeless | markh: no | 02:46 |
| lifeless | I'm saying that the docstring in the code claims to support | 02:46 |
| lifeless | from bzrlib import ui.text | 02:46 |
| markh | strangely, it *does* support it! | 02:47 |
| markh | just not in a py2exe environment | 02:47 |
| jamesh | one of the perils of putting code in strings | 02:47 |
| lifeless | jamesh: all code is strings | 02:47 |
| markh | ok, thanks. The code is in qbzr, so I'll take it up with them! | 02:47 |
| lifeless | markh: I would try editing ui.__init__ | 02:48 |
| lifeless | as I suggested before | 02:48 |
| markh | lifeless: 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 |
| lifeless | markh: did you see my suggesetion at 13:39? | 02:49 |
| jamesh | lifeless: well, in this case it'd probably be possible to write a version of lazy_imports that didn't involve embedding code in strings | 02:50 |
| markh | I 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 confusion | 02:51 |
| jamesh | which would let Python parse and syntax check the imports | 02:51 |
| jamesh | and might let other tools see the imports without modifications | 02:51 |
| lifeless | jamesh: suggestions appreciated | 02:52 |
| lifeless | jamesh: I imagine an import hook might allow it but at a very convoluted cost | 02:52 |
| markh | to 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 |
| markh | if it isn't that bzrlib should support it, I'm confused what my edits to __init__ would be aiming for. | 02:53 |
| lifeless | markh: they may work around the problem | 02:53 |
| markh | right - but presumably that woudn't be accepted as a patch? | 02:53 |
| markh | which means it doesn't actually solve the problem I'm having in binary builds that anyone else (eg, John) creates. | 02:54 |
| lifeless | markh: I'd accept it, as lazy importing a deep module like that is plain weird IMO | 02:54 |
| lifeless | markh: and it will provide info on how lazy_import may be failing | 02:54 |
| markh | lifeless: 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 |
| lifeless | markh: uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh | 02:55 |
| lifeless | markh: AIUI you are not getting a barf, you are getting ui.text not imported | 02:55 |
| lifeless | so ui is imported but ui.text isn't | 02:55 |
| markh | my thoughts exactly. I'm confused why the advice isn't simply "fix the wierd code" :) | 02:55 |
| lifeless | 13:41 < lifeless> markh: up to you if you want to work around or dig deep | 02:55 |
| markh | but why would I want to dig deep to support something plain weird? | 02:56 |
| lifeless | if py2exe is failing to copy in ui.text, then jamesh's thoughts about a different style of import hook may be useful long term | 02:56 |
| markh | clearly I should just fix the import to code that would be valid in regular python and everyone is happy! | 02:56 |
| lifeless | markh: sure, I never suggested that you don't change it | 02:57 |
| markh | right - 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 |
| jamesh | lifeless: 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 imports | 02:58 |
| jamesh | tools like py2exe generally handle imports in function bodies just fine | 02:59 |
| markh | yeah - py2exe just uses the modulefinder package, and that does scan the bytecode for imports iiuc. | 03:02 |
| markh | jamesh: 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 |
| jamesh | markh: I'd prefer that the lazy imports syntax mirrored what was possible with normal imports and not more | 03:04 |
| jamesh | having something that is almost but not quite compatible but looks the same is going to cause bugs | 03:04 |
| markh | so that is a "yes" :) | 03:04 |
| jamesh | yeah. | 03:04 |
| markh | ok thanks - just trying to make sure I wasn't *totally* misunderstanding things! | 03:05 |
| lifeless | I don't see any reason for lazy imports to be more than regular import can do | 03:05 |
| markh | lifeless: right - but my example shows they can in some cases, right? | 03:10 |
| lifeless | markh: yes | 03:10 |
| lifeless | markh: however thats in qbzr isn't it? I'm not aware of smartass stuff like that in bzr itself | 03:11 |
| markh | but 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 |
| markh | well - I'd call it plain "wrong" rather than smart-arse :) but yeah... | 03:11 |
| markh | damn - 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 |
| garyvdm | If I do a repository.lock_read() and I *don't* do a repository.unlock() , nothing bad seams to happen. | 04:01 |
| garyvdm | This is surprising! | 04:01 |
| markh | tortoise itself works well with 1.11 though, including 64bit windows, so that's my bzr work for the day done... | 04:02 |
| garyvdm | Is it ok to do that? | 04:03 |
| lifeless | garyvdm: not in general | 04:04 |
| garyvdm | Ok | 04:04 |
| lifeless | markh: cool | 04:04 |
| mwhudson | garyvdm: don't you get a warning printed somewhere when you do that? | 04:05 |
| garyvdm | No | 04:05 |
| garyvdm | I do get a warning if I don't unlock a branch. | 04:06 |
| garyvdm | But not with a repository. | 04:06 |
| poolie | spiv: is bzr+ssh://host/~/thing supposed to work now? | 04:06 |
| spiv | poolie: not yet; there's a quick patch on a bug IIRC. | 04:07 |
| lifeless | garyvdm: not sure why you don't see a warning; likely its because the pack family of repositories does its locking more lazily than branch | 04:12 |
| lifeless | garyvdm: all the same, you should lock/unlock | 04:12 |
| garyvdm | Ok | 04:12 |
| === Mario__ is now known as pygi | ||
| poolie | ok, i just misremembered | 04:14 |
| lifeless | 334 revs to go | 04:16 |
| lifeless | poolie: that evo fix I did at UDS has been committed upstream :) | 04:19 |
| poolie | yay | 04:20 |
| thumper | lifeless: 334 revs to go until what? | 04:27 |
| lifeless | thumper: my local repo has all the bad revs identified and the rest copied to a clean --1.9 repo | 04:27 |
| lifeless | thumper: I need to do this to start dogfooding lp for my bzr branches amongst other things | 04:27 |
| thumper | ah, ok | 04:28 |
| lifeless | poolie: I'm done for the day I think | 04:57 |
| spiv | spm: bzr's pqm appears stuck? | 04:57 |
| spm | spiv: oki, fixoring | 04:57 |
| spiv | spm: ta | 04:58 |
| spm | spiv: cause was another one from vila: "Rev 3934: (vila) Fix bug 315737 by correctly querying the test feature" :-( | 04:59 |
| ubottu | Launchpad bug 315737 in bzr "Test bzrlib.tests.test_osutils.TestChunksToLines fails" [Low,Fix committed] https://launchpad.net/bugs/315737 | 04:59 |
| spm | should be ok again now | 04:59 |
| spiv | spm: thanks. I'm surprised that that change by vila would cause pqm problems. | 05:01 |
| spm | spiv: 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 |
| spiv | Wacky. | 05:02 |
| spm | ie typicaly bloody sysadmins - went things break drag out the Biggest Sledgie you can find and start smashing daemons :-) | 05:03 |
| spm | s/went/when/ . Other grammer errors left alone. | 05:03 |
| poolie | i thought we tracked this down... | 05:06 |
| poolie | :/ | 05:06 |
| poolie | there might be a patch attached to a bug in pqm? | 05:06 |
| poolie | spm, didn't you and me look at this | 05:06 |
| poolie | lifeless: night | 05:06 |
| spm | poolie: I don't recall chasing that down? But you could well be right - I know we have chased other stuff down. :-) | 05:07 |
| vila | hi all | 06:58 |
| bitmonk | i'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 |
| bitmonk | and 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 |
| poolie | i think there's a separate command to create the new branch | 07:21 |
| poolie | dpush? | 07:21 |
| poolie | the repository must already exist | 07:21 |
| bitmonk | trying clone.. | 07:24 |
| bitmonk | the 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 |
| igc1 | hey vila | 07:38 |
| === igc1 is now known as igc | ||
| vila | spm: 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 instead | 07:41 |
| vila | but it's hard to tell from outside :-/ | 07:41 |
| vila | spm: 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 |
| spiv | vila: 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 |
| vila | spiv: I know... | 07:42 |
| vila | And, to me, that sounds like some connection not being gc'ed or something... | 07:43 |
| vila | where both client and server are waiting the other end to say: I'm done | 07:43 |
| vila | especially because when the pqm process is *killed* then my submission is successfully proceeded (sp?) | 07:44 |
| bitmonk | vila: processed | 07:48 |
| bitmonk | (nw) | 07:49 |
| vila | bitmonk: thks | 07:49 |
| bitmonk | np :) | 07:49 |
| bitmonk | assuming 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 |
| bitmonk | if 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 boot | 07:50 | |
| bitmonk | (last) | 07:50 |
| bitmonk | keep in mind that green tea has comparable caffeine to coffee, but is less addictive.. | 07:50 |
| vila | bitmonk: not native but I welcome feedback on any error I can make (language or anything else) | 07:50 |
| * bitmonk broke the coffee adiction year sago | 07:50 | |
| bitmonk | vila: 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 | |
| bitmonk | yah i hear that | 07:51 |
| bitmonk | gotta pick battles | 07:51 |
| * bitmonk has cut back a lot on tobacco but hasnt killed like coffee | 07:51 | |
| bitmonk | i 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 |
| bitmonk | and that said when i used to liv eon coffee i honestly drank a crap load of canadian whiskey every night with my coworkers | 07:52 |
| * bitmonk is pretty sure somewhere in that haze he lost a perfectly good automobile | 07:52 | |
| bitmonk | that light pole had a bad attitude! :-P | 07:52 |
| * bitmonk hides | 07:52 | |
| bitmonk | anyway, 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 |
| vila | poolie: (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 | |
| bitmonk | oh wrong chan ;d | 07:56 |
| vila | bitmonk: the answer should be: "it should", but that's a wild guess, I'm not using xen :-) | 07:58 |
| bitmonk | vila: 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 |
| bitmonk | esp as people on comparable hardware have told me that general kernel build takes around 25-30min (3.0GHz C2D) | 07:59 |
| bitmonk | anyway, way out of scope for #bzr join in ##xen if you want to continue :) | 07:59 |
| bitmonk | maybe 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 |
| bitmonk | also the DomU has like 512M of RAM and Dom0 has like 3.5-4.0 | 08:00 |
| bitmonk | anyway, again, out of scope | 08:00 |
| * bitmonk scuttles off to ##xen | 08:00 | |
| vila | bitmonk: thanks for the offer :-) I may try xen in a couple of months but virtualbox is enough for my needs so far | 08:02 |
| bitmonk | xen i find quite interesting, though i've been a kernel-hearted-fool since high school some years ago ;) | 08:03 |
| * bitmonk heart menuconfig | 08:03 | |
| igc | night all | 08: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 |
| bob2 | --mail-to | 11:31 |
| Haffi___ | Do I have to specify it? | 11:31 |
| bob2 | third last paragraph of 'bzr help send' | 11:31 |
| luks | that's not really accurate | 11:33 |
| luks | the email address is only required for some clients (like the simple editor+smtp one) | 11:33 |
| luks | if you are using a gui client, it's usually optional | 11:33 |
| bob2 | for /to/ or /from/? | 11:33 |
| luks | to | 11:34 |
| luks | e.g. I have it configured to use evolution, I just run bzr send and type the address in evolution's window | 11:35 |
| bob2 | oh | 11: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 |
| bob2 | then you want -o | 11:36 |
| Haffi___ | right, then it's written to file or stdout | 11:36 |
| bob2 | where do you want the bundle then? | 11:37 |
| Haffi___ | It still seems like the changes aren't published | 11:38 |
| bob2 | all 'send' does is produce a bundle and optionally email it somewhere | 11:39 |
| Haffi___ | oh | 11:39 |
| bob2 | it doesn't affect any branches - are you trying to update the branch you branched from? | 11:39 |
| Haffi___ | hehe, yes | 11:39 |
| Haffi___ | I misunderstood the command | 11:39 |
| Haffi___ | which command should I use then? I guess 'merge' is to fetch changes from main branch? | 11:40 |
| luks | bzr push | 11:41 |
| Haffi___ | yep, it worked | 11:44 |
| Haffi___ | thanks | 11:44 |
| Peng_ | Is it valid to have a revision ID "" (I mean, an empty string, not literally two double-quotes)? | 12:15 |
| luks | I don't think revision IDs have any specified format | 12:15 |
| luks | so I'd say it's valid, but I'd expect some code to break on that | 12:16 |
| luks | because NULL revisions used to be represented as None | 12:16 |
| Peng_ | The exception raised is NoSuchRevision. It would likely be something else if it was actually invalid.. | 12:18 |
| spiv | Peng_: At a glance, the code would treat that as a valid revision ID I think. | 12:19 |
| spiv | Why do you want to know? | 12:19 |
| Peng_ | I just wrote an email about it, actually, in Benn Finney's thread. | 12:20 |
| spiv | It'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 |
| spiv | Peng_: 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 |
| spiv | Back before the test suite was as good as it is now at insulating tests from reality. | 12:22 |
| spiv | (and vice versa) | 12:22 |
| spiv | I think it'd be reasonable to disallow "" as a revision ID. | 12:23 |
| spiv | It 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. :P | 12:25 |
| spiv | Well, you already did, by mailing the list ;) | 12:25 |
| Peng_ | Heh, good point. | 12:27 |
| === ubott2 is now known as ubottu | ||
| phinze | is there a quick way to tell bzr: 'add all of the files in the unknown list' ? | 14:26 |
| beuno | phinze, bzr add? | 14:27 |
| phinze | beuno: doh! that was way too easy :) | 14:27 |
| beuno | :) | 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 help | 14:30 | |
| phinze | here's another one... is `bzr co foo; cd foo; bzr unbind` the equivalent of `bzr branch foo` ? | 14:33 |
| beuno | I'm not sure, I don't use checkouts much | 14:34 |
| luks | yes, it is | 14:34 |
| phinze | luks: cool, thanks. just trying to get my head around this stuff | 14:35 |
| abentley | phinze: It is *roughly* the same. "bzr co" won't set the parent location, but "bzr branch" will. | 14:37 |
| phinze | abentley: really, that's interesting, you'd almost think it would be the other way around | 14:38 |
| phinze | that the checkout would be tethered to a parent and the branch would be free floating | 14:38 |
| abentley | phinze: 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 |
| phinze | ahh | 14:39 |
| phinze | so really for the decentralized workflow `bzr branch` is really what you'd want to use | 14:40 |
| phinze | because bzr co + bzr unbind leaves you without a pull source | 14:42 |
| rocky | phinze: yeah but the first time you pull into a branch that has no pull source, it remembers the new source | 14:44 |
| phinze | rocky: okay nice, so there isn't all that much difference between the two in the end | 14:45 |
| rocky | yeah, and you can always change the pull source again with --remember | 14:46 |
| andresmujica | hi are newbies question allowed?? .. :) | 14:51 |
| nDuff | andresmujica, absolutely | 14:51 |
| andresmujica | hehe thks | 14:51 |
| LarstiQ | does anyone here use bzr-hookless-email? | 14:51 |
| andresmujica | i'm using a sw called 5-a-day, as far as i've check it uses bzr internally | 14:52 |
| andresmujica | the problem is that i'm using from 2 different computers | 14:52 |
| andresmujica | so i wonder | 14:52 |
| andresmujica | which is the right procedure to use it | 14:52 |
| andresmujica | when i change computers | 14:52 |
| andresmujica | somehow update the local .bzr before any update?? | 14:53 |
| nDuff | andresmujica, 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 |
| andresmujica | there's a main place (code.kaunchpad.net) | 14:53 |
| andresmujica | both point there | 14:53 |
| nDuff | andresmujica, I think it might be easier to have both of them use bound branches | 14:53 |
| nDuff | ahh | 14:53 |
| andresmujica | but the revisions numbers are different because i mainly work at one of them, and sometimes at the other... | 14:54 |
| andresmujica | so i suspect i've got to merge or pull or something like that before start my work... | 14:54 |
| andresmujica | at the less used computer | 14:54 |
| nDuff | if 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 |
| nDuff | if 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 |
| andresmujica | yeap 5-a-day.. i'm making a mess with my branch :( | 14:57 |
| andresmujica | yeap i've got the keys already in place on both systems | 14:58 |
| seb_kuzminsky | in a distributed workflow with no central server, can i give my team-mates' branches nicknames locally? | 15:14 |
| seb_kuzminsky | i want to be able to say "bzr merge alice", "bzr merge bob", etc | 15:14 |
| seb_kuzminsky | and have "alice" and "bob" expand to the urls of those team mates | 15:14 |
| james_w | seb_kuzminsky: not currently, though you may want to look at the bzr-bookmarks plugin | 15:14 |
| seb_kuzminsky | thanks james_w :-) | 15:15 |
| seb_kuzminsky | bzr-bookmarks is winrar!! :-D | 15:23 |
| rbriggsatuiowa | I am encountering the different rich-root support error while trying to clone | 15:27 |
| rbriggsatuiowa | http://pastie.org/358686 | 15:28 |
| rbriggsatuiowa | I tried the suggestions on https://bugs.launchpad.net/bzr/+bug/272425 | 15:28 |
| ubottu | Ubuntu bug 272425 in bzr ""different rich-root support" error could be clearer" [Low,Confirmed] | 15:28 |
| rbriggsatuiowa | but get an bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. error | 15:28 |
| rbriggsatuiowa | when trying to do a bzr upgrade --rich-root-pack | 15:29 |
| rbriggsatuiowa | bzr co works just fine | 15:31 |
| phinze | hi all i'm in the same spot as rbriggsatuiowa | 15:33 |
| phinze | rbriggsatuiowa: if you bzr init --rich-root-pack foo; cd foo; bzr pull remote-foo; it works | 15:33 |
| phinze | basically bzr clone is creating a repository of format pack-0.92 | 15:34 |
| phinze | which is not right | 15:34 |
| phinze | because the remote bzr server is using rich-root-pack | 15:36 |
| rbriggsatuiowa | stupid gentoo | 15:36 |
| phinze | rbriggsatuiowa: mine's doing it too (ubuntu 8.10, bzr 1.6.1) | 15:37 |
| rbriggsatuiowa | I double-checked the USE flags and don't seem to be missing anything | 15:37 |
| phinze | rbriggsatuiowa: which version you on | 15:43 |
| rbriggsatuiowa | Bazaar (bzr) 1.6.1 | 15:44 |
| phinze | yeah let's try upgrading to 1.10 (which the server is on)... msging you details | 15:44 |
| phinze | yep, the problem was using a 1.6.1 client with a 1.10 remote branch | 15:56 |
| andresmujica | ok, guys. i 've learned how to do it. Thanks for your help!!!! | 16:00 |
| andresmujica | see ya! | 16:00 |
| ollie___ | bzr mv concrete/blocks/autonav/ blocks/autonav | 17: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/autonav | 17:13 |
| ollie___ | so i don't see how it can already be versioned | 17:13 |
| ollie___ | bzr remove blocks/autonav | 17: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 |
| LarstiQ | rsc-: have you made the changes yet? | 17:38 |
| rsc- | yes | 17:38 |
| LarstiQ | rsc-: if so, you could `bzr merge --uncommitted path/to/branch/with/changes` from the one where you want them | 17:38 |
| rsc- | ahh. | 17:39 |
| rsc- | cool :) | 17:39 |
| LarstiQ | did 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 |
| LarstiQ | should be, yeah. | 17:40 |
| rsc- | cool. | 17:40 |
| rsc- | you learn something new everyday. | 17:40 |
| rsc- | thanks :) | 17:40 |
| LarstiQ | Possibly you want to list a couple of files you want the changes from, and not others. | 17:40 |
| adeel | can bzr handle resource forks (found in macs)? | 17:47 |
| LarstiQ | adeel: I don't think it does anything special with them. | 17:48 |
| === asac_ is now known as asac | ||
| LarstiQ | as most things are wont to do. | 17:48 |
| adeel | LarstiQ, 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 same | 17:49 |
| jelmer | adeel, I don't think it handles them at the moment | 17:50 |
| jelmer | at least it doesn't handle extended attributes (Linux) or streams (Windows) | 17:50 |
| LarstiQ | adeel: that doesn't suprise me, almost nothing handles them. | 17:50 |
| adeel | yeah that's what it seems like | 17:51 |
| jelmer | It would actually be interesting to seem them being used to store VCS metadata | 17:52 |
| adeel | all 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 pita | 17:53 |
| === mark1 is now known as markh | ||
| NfNitLoop | adeel: How has bzr been confusing you? | 18:10 |
| jam | jelmer: ping | 18:18 |
| jelmer | jam, pong | 18:18 |
| jam | hi jelmer, for the win32 installers, I went ahead and kept using 0.4.16 | 18:19 |
| jam | Should I be trying to switch to the 0.5 series? | 18:19 |
| jelmer | jam, no, at least not for any production-oriented setups | 18:19 |
| jam | k, that's what I thought, but I figured I'd check, since there wasn't an 0.4.17 yet | 18:19 |
| jelmer | I hope to release another rc in the next couple of days, then maybe 0.5.0 after that | 18:20 |
| jam | jelmer: is 0.5 compatible with an 0.4 conversion? (I'm guessing not, but figured I'd check) | 18:21 |
| jelmer | jam, no, although it does support using 0.4-style mappings if explicitly configured | 18:22 |
| jam | jelmer: but it would create all new revision-ids, right? | 18:23 |
| jelmer | jam, if the 0.4-style mappings are enabled, no | 18:23 |
| jelmer | it would create the same revision ids that 0.4 would | 18:23 |
| jam | so by default 0.5 isn't compatible, but it can be made so? | 18:23 |
| jelmer | jam: yes | 18:23 |
| jam | It would be good to have that well documented for an 0.5 upgrade | 18:23 |
| jelmer | There's a README.UPGRADING file | 18:24 |
| jam | It would probably be important enough to make sure it would get into the NEWS items for whatever bzr starts including it | 18:24 |
| jelmer | jam: yeah, probably | 18:24 |
| jelmer | jam, 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 |
| jelmer | including referncing the right docs about upgrading between bzr-<foreign vcs> mappings | 18:26 |
| rocky | jelmer: 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 |
| jelmer | rocky, not sure | 19:19 |
| jelmer | rocky, I've fixed *some* bugs, not sure if that included yours | 19:19 |
| jelmer | do you remember the bug #? | 19:19 |
| rocky | i dont'... but i did update from bzr-svn 0.5 branch and discovered that it now seems to depend on bzr 1.11 | 19:21 |
| rocky | so that means there won't be a 0.5 version that works on bzr 1.10 ? | 19:21 |
| rocky | regardless, i tried with bzr 1.11rc1 + bzr-svn 0.5 branch (as of a couple days ago) and got the same error ... | 19:21 |
| rocky | jelmer: just try "bzr co svn+https://dev.serverzen.com/svn/collective/Products.eXtremeManagement/trunk" and watch it complain about tags | 19:22 |
| jelmer | rocky, that appears to require a password? | 19:29 |
| rocky | jelmer: oh sorry, try the non https version | 19:33 |
| rocky | that's anonymous use | 19:33 |
| jelmer | ah, thanks | 19:34 |
| jelmer | rocky, that seems to redirect me to the https url | 19:35 |
| LarstiQ | ronny: what does the workingset accomodate? | 19:38 |
| rocky | jelmer: ok, http://svn.plone.org/svn/collective/Products.eXtremeManagement/trunk/ definitely works, i just browsed to it in a browser ;) | 19:43 |
| ronny | LarstiQ: manages a set of n branches, i view heads as branches | 19:44 |
| LarstiQ | ronny: ok | 19:46 |
| ronny | LarstiQ: im not entirely sure on the abstraction | 19:46 |
| LarstiQ | ronny: what prompted you to include it? | 19:46 |
| ronny | LarstiQ: stuff like hg's named branches | 19:47 |
| * LarstiQ looks that up | 19:47 | |
| ronny | LarstiQ: and of course gits moving tag based branches | 19:47 |
| ronny | thats clearly different than bze's directory branches | 19:48 |
| ronny | *bzr | 19:48 |
| ronny | LarstiQ: made a sense out of all stuff? | 20:14 |
| LarstiQ | ronny: I read through http://www.selenic.com/mercurial/wiki/index.cgi/NamedBranches, but that isn't very enlightening | 20:18 |
| ronny | LarstiQ: named branches are basically static tags on a revision | 20:21 |
| ronny | LarstiQ: it can be used for tihngs like separate vendor branches or very long-lifed global branches | 20:21 |
| jelmer | rocky, that's bug 312272, not fixed yet | 20:22 |
| ubottu | Launchpad bug 312272 in bzr-svn "unable to find direct lhs parent" [High,Triaged] https://launchpad.net/bugs/312272 | 20:22 |
| ronny | hmm | 20:22 |
| rocky | jelmer: ah cool ... don't suppose you have an eta? :) | 20:29 |
| === spm_ is now known as spm | ||
| jelmer | rocky, should be pretty soon now | 20:35 |
| rocky | great... it's actually stopping me from getting anymore work done on my eXtremeManagement branch :( | 20:36 |
| rocky | jelmer: btw, will 0.5.0 final run on bzr 1.10 ? | 20:36 |
| jelmer | rocky, no, it will require at least 1.11 | 20:36 |
| rocky | jelmer: that's strange since 0.5rc1 worked on 1.10 | 20:37 |
| rocky | but no biggie | 20:37 |
| jelmer | still quite some things have changed since rc1 | 20:37 |
| jelmer | ~20 bugs have been fixed since rc1 so far, that number will probably end up around 25 | 20:39 |
| rocky | gotcha | 20:39 |
| rocky | no big deal, i don't mind upgrading to bzr 1.11 ... do you know when eta on 1.11 final is? | 20:39 |
| rocky | that one bzr-svn bug is killing me tho | 20:39 |
| jelmer | I think 1.11 final is already out actually | 20:40 |
| jam | jelmer: just 1.11rc1 | 21:22 |
| jam | rocky: 1.11 final is this fri | 21:22 |
| lifeless | hi jam | 21:25 |
| jam | hi lifeless | 21:25 |
| jam | good morning | 21:25 |
| lifeless | jam: how are you going with merging stuff to bbc? | 21:28 |
| jam | I've gotten a few things landed | 21:28 |
| jam | I have a test suite run going to see if there is anything we need to focus on | 21:29 |
| jam | hmmm.. 22 failures 13 errors | 21:29 |
| jam | a lot of them close to trivial | 21:29 |
| jam | like not using "assert" in the code | 21:29 |
| jam | hmm. and a really random error from a piece of code getting a negative number that didn't expect one | 21:31 |
| markh | jam: qbzr is broken in the 1.11rc1 :( | 21:49 |
| markh | (and therefore most of tortoise) | 21:50 |
| jam | Thanks for the heads up. Any idea why? | 21:50 |
| jam | I just used the 0.9.6 release, I can go back to 0.9.5 if you think it is necessary | 21:50 |
| markh | lazy imports :) | 21:51 |
| markh | I mentioned it yesterday in IRC, but the discussion just fizzled out as I'm not sure exactly how to resolve it. | 21:51 |
| jam | so lazy imports don't work with the packaging? | 21:52 |
| markh | in 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 text | 21:52 |
| markh | indeed, that was the only solution I could see - re-arranging the imports in qbzr also failed | 21:53 |
| jam | do you have the tracebacks to why it is failing with py2exe? | 21:54 |
| spiv | Why did rearranging the imports in qbzr fail? | 21:54 |
| jam | It seems like it should be working | 21:54 |
| markh | the 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 |
| jam | And may signify a bug in the lazy import code | 21:54 |
| spiv | markh: submitted code is > unsubmitted code. | 21:54 |
| spiv | markh: (and code with tests > code without tests, but having a patch in the first place is a good start...) | 21:55 |
| markh | spiv: I'm not sure why they failed to be honest, but I assume it was still something related to lazy imports | 21:55 |
| spiv | markh: Hmm. Maybe question that assumption? :) | 21:56 |
| spiv | I'm just guessing. | 21:56 |
| jam | so, for my immediate fix, I can do a 1.11rc1-2 with qbzr 0.9.5 | 21:57 |
| jam | at least people will have something that works | 21:57 |
| jam | markh: I don't see any "import.*ui" or "import.*text" | 22:00 |
| jam | in qbzr | 22:00 |
| jam | (well, aside from the 'gettext' lines) | 22:00 |
| markh | in commands.py | 22:00 |
| igc | morning | 22:00 |
| * markh finds it | 22:00 | |
| markh | mornin' ian | 22:01 |
| jam | ah, there it is | 22:01 |
| jam | lib/commands.py | 22:01 |
| jam | I would guess the problem is doing: | 22:01 |
| spiv | markh: wow, and it's a totally gratuitous lazy_import anyway :) | 22:01 |
| jam | from bzrlib import ( | 22:01 |
| jam | ui, | 22:01 |
| jam | ui.text, | 22:01 |
| jam | ) | 22:01 |
| jam | I wouldn't expect that to be valid | 22:01 |
| markh | yeah, we had this discussion yesterday with lifeless :) | 22:02 |
| jam | from bzrlib import ui.text | 22:02 |
| jam | ^ | 22:02 |
| jam | SyntaxError: invalid syntax | 22:02 |
| markh | yeah | 22:02 |
| jam | That syntax isn't valid python import | 22:02 |
| spiv | jam: right, there's a bug that lazy_import allows that. | 22:02 |
| spiv | (and a bug that qbzr does that) | 22:03 |
| markh | but - 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 |
| spiv | markh: the obvious thing is "from bzrlib.ui.text import TextUIFactory", IMO | 22:03 |
| markh | oh - 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 |
| spiv | markh: no, the code is clearly needing "ui.text" so it can use "ui.text.TextUIFactory" at the moment | 22:04 |
| markh | yes - I was assuming it also used other attributes from that module | 22:05 |
| jam | markh: http://paste.ubuntu.com/104124/ | 22:05 |
| jam | Would be my suggsetion | 22:05 |
| markh | but - 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__.py | 22:05 |
| markh | jam: so just remove them from lazy imports? | 22:06 |
| spiv | markh: actually I'd expect "from bzrlib import ui; import bzrlib.ui.text" in qbzr would work too. | 22:06 |
| markh | s/them/it/ | 22:06 |
| jam | markh: they are used right away | 22:06 |
| hsn_ | is there way to define alias for URL which i can use with bzr push? | 22:06 |
| jam | lazy doesn't do anything | 22:06 |
| jam | hsn_: there is a "bookmarks" plugin | 22:07 |
| jam | lp:bzr-bookmarks IIRC | 22:07 |
| jam | then you get "bm:XXX" | 22:07 |
| markh | yeah - in this case it needs to be fully imported anyway | 22:07 |
| hsn_ | jam: in bzrtools? | 22:07 |
| jam | hsn_: bzr-bookmarks *is* the plugin | 22:07 |
| hsn_ | got it. | 22:09 |
| hsn_ | is there way to checkout just some directories from branch? | 22:10 |
| jam | hsn_: not yet | 22:13 |
| hsn_ | http://bazaar-vcs.org/NestedTreeSupport -> this thing works already? | 22:25 |
| lifeless | o | 22:27 |
| lifeless | no | 22:27 |
| markh | jam: 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 |
| markh | new qbzr release | 22:35 |
| markh | or will you hack the existing qbzr into shape? | 22:36 |
| jam | markh: I just patched 0.9.6 => 0.9.6-win32 with a trivial 'don't make it lazy" fix | 22:37 |
| jam | And I'll send that to the qbzr list | 22:37 |
| markh | awesome - thanks | 22:37 |
| NCommander | I 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 |
| jelmer | NCommander, sure | 22:40 |
| lifeless | NCommander: moar details needed :P | 22:41 |
| jam | poolie: ping | 22:42 |
| NCommander | lifeless, I'm trying to checkout the following SVN repo: | 22:42 |
| NCommander | bzr co svn://uclibc.org/trunk/buildroot | 22:42 |
| NCommander | It bombs out with a UTF error | 22:42 |
| poolie | jam, pong | 22:43 |
| jam | poolie: Are we going to start back up with doing a weekly direct call between you and I? | 22:43 |
| jam | We seemed to have faltered on that after the new year | 22:43 |
| poolie | ah we have a bit | 22:44 |
| NCommander | jelmer, also ^ | 22:44 |
| poolie | that would be good though | 22:44 |
| poolie | should we talk now, or maybe tomorrow morning? | 22:44 |
| jam | poolie: tomorrow would work best, I think | 22:45 |
| jelmer | jam, that reminds me, I've been meaning to ask you what happened to the "This week in Bazaar" blogposts | 22:45 |
| * igc food | 22:46 | |
| jam | I sort of "lost steam" in writing them. Well that and lost statik as my motivator | 22:46 |
| jam | I'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 hear | 22:47 |
| jam | markh: I uploaded 1.11rc1-2 | 22:48 |
| jam | can you give it a shot? | 22:48 |
| markh | sure | 22:48 |
| poolie | hello markh | 22:48 |
| rockstar | jam, I'm still willing to help out on those. | 22:48 |
| markh | hi poolie | 22:48 |
| * NCommander pulsechecks lifeless | 22:49 | |
| jelmer | NCommander, when does it fail, which revision? | 22:49 |
| jelmer | (approx) | 22:49 |
| NCommander | jelmer, after its done importing and starts building the bazaar tree | 22:49 |
| NCommander | jelmer, I'm running the bazaar from Jaunty, so it might be a little behind the current release version | 22:50 |
| lifeless | NCommander: can you get the backtrace from ~/.bzr.log please | 22:50 |
| jam | rockstar: 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 about | 22:51 |
| rockstar | jam, sounds good. | 22:51 |
| lifeless | statik is still alive yes | 22:52 |
| NCommander | lifeless, and jelmer http://paste.ubuntu.com/104142/ | 22:52 |
| jelmer | jam, Ah | 22:52 |
| jelmer | jam, I thought they were quite useful | 22:53 |
| lifeless | thats still in bzr-svn | 22:53 |
| NCommander | oh | 22:54 |
| NCommander | Any ideas how I can fix it, or at least work around it? | 22:54 |
| jelmer | NCommander, I'm trying to reproduce it here | 22:54 |
| NCommander | jelmer, it died for me in the high 22000s | 22:54 |
| jelmer | NCommander: Ah, it died during "fetching revision info" ? | 22:55 |
| markh | jam: now failing due to the svn plugin wanting 1.10 it seems | 22:55 |
| NCommander | yeah, I reran it | 22:55 |
| markh | or maybe bzrtools - its not clear | 22:55 |
| * markh checks the log | 22:55 | |
| jelmer | NCommander, that's not occurring here, so at least this bug is fixed in 0.5 | 22:55 |
| NCommander | someone should update the ubuntu packaging | 22:56 |
| jam | markh: I would expect it to be bzr-svn, just because I did pick bzrtools 0.11.0 | 22:56 |
| jam | but if you could poke a bit closer, I would appreciate it | 22:56 |
| jelmer | NCommander, 0.5.0 isn't out yet | 22:56 |
| NCommander | oh | 22:56 |
| jelmer | debian experimental has a 0.5rc packaged fwiw | 22:56 |
| NCommander | is it available in a PPA? | 22:56 |
| markh | jam: the traceback isn't clear but it looks like svn: | 22:57 |
| markh | 0.313 bzr-svn: using Subversion 1.5.4 () | 22:57 |
| markh | 4.361 Traceback (most recent call last): | 22:57 |
| markh | ... | 22:57 |
| markh | File "bzrlib\api.pyo", line 82, in require_api | 22:57 |
| markh | IncompatibleAPI: 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 |
| jelmer | markh, could very well be bzr-svn | 22:57 |
| markh | certainly as of yesterday, svn failed like that | 22:57 |
| jelmer | markh, that doesn't look like a released version of bzr-svn | 22:57 |
| lifeless | markh: whats the caller above in the backtrace | 22:57 |
| * markh needs glasses :) | 22:58 | |
| markh | 2 entries up is svn's __init__ | 22:58 |
| NCommander | jelmer, where can I find the bzr-svn snapshots or bazaar branch? | 22:58 |
| jelmer | NCommander, http://people.samba.org/bzr/jelmer/bzr-svn/0.5 | 22:58 |
| NCommander | jelmer, empty folder | 22:58 |
| jelmer | NCommander, it's a bzr branch | 22:59 |
| markh | jelmer: is there a bzr-svn jam should be using with the 1.11 windows binaries? | 22:59 |
| jam | markh, jelmer: lifeless originally made a change that bumped the bzrlib api number | 22:59 |
| jam | that was supposed to land in 1.9, I updated it because it landed in 1.11 | 22:59 |
| enigma42 | jelmer: 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 |
| jam | I don't remember what off-hand | 22:59 |
| jelmer | what happened to API-specific versions? :-) | 23:00 |
| jam | ah, it was the "add_inventory_by_delta" change | 23:00 |
| jelmer | ah, ok | 23:01 |
| jelmer | that shouldn't be relevant to bzr-svn | 23:01 |
| jelmer | I'll release a 0.4.17 | 23:01 |
| enigma42 | jelmer: "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 |
| jelmer | enigma42, hmm, that's strange - what version of bzr-svn? | 23:02 |
| jam | jelmer: just make sure your tag propagates to bzr-svn's trunk :) | 23:02 |
| jam | (lp:bzr-svn) | 23:02 |
| enigma42 | jelmer: bzr-svn 0.5 trunk revno 2281 | 23:03 |
| enigma42 | jelmer: Let me pull up to revno 2293 and try again. | 23:03 |
| jelmer | enigma42, the two things should not be related | 23:03 |
| jelmer | enigma42, what file exactly does it give the error about? | 23:04 |
| enigma42 | bzr: ERROR: No such file: ('iovariableplugin.gro-20081110215858-yuu32hfdt8apjga0-1', 'kirby@kirby-ubuntu-dev-20090105202353-tv2de4iskr45pl68') | 23:04 |
| jelmer | enigma42, hmm, in that case it could actually be related | 23:04 |
| jelmer | enigma42, does the repository in question contain any revisions pushed with previous versions of bzr-svn? | 23:04 |
| enigma42 | This is a fresh branched just checked out of svn. | 23:05 |
| markh | jam: 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-candidate | 23:05 |
| enigma42 | jelmer: Yes. | 23:05 |
| enigma42 | enigma42: The *svn* repository contains revisions pushed with the previous version of bzr-svn | 23:05 |
| markh | ack | 23:05 |
| enigma42 | jelmer: But the *bzr* repo was a fresh checkout from svn. | 23:05 |
| markh | jam: actually, maybe scratch that, unless you are also willing to make a trivial change to the .cog | 23:05 |
| enigma42 | Just 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 |
| jelmer | enigma42: 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 sure | 23:08 |
| enigma42 | jelmer: Is there a way I can zap the metadata in SVN? | 23:09 |
| enigma42 | enigma42: I'm fine with loosing merge history in this case. | 23:09 |
| markh | jam: 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 |
| jelmer | enigma42, only by doing a "svnadmin dump" and removing them in the svndump | 23:10 |
| enigma42 | jelmer: Oh boy. | 23:10 |
| enigma42 | jelmer: With 0.5, is that changing? | 23:11 |
| enigma42 | jelmer: Since it will use revision properties instead? | 23:11 |
| jelmer | enigma42, yeah, it's easier with 0.5 indeed (but only if you have subversion 1.5) | 23:11 |
| NCommander | jelmer, so how do I use 0.5, I installed it and now get: No module named foreign | 23:11 |
| jelmer | NCommander, you need bzr 1.11 | 23:11 |
| jelmer | sorry, 1.11rc1 | 23:12 |
| NCommander | I assume no packages exist ... | 23:12 |
| jelmer | I think there may be some in the bzr ppa | 23:12 |
| NCommander | nope | 23:13 |
| NCommander | where do I find the source tarballs :-) | 23:13 |
| NCommander | hey lamont | 23:13 |
| enigma42 | jelmer: Yeah, I get the same "No such file" error with bzr-svn 0.5 trunk revno 2293 | 23:13 |
| enigma42 | jelmer: Do you know of a way of fixing up the bzr repo by hand rather than purging the svn properties? | 23:16 |
| james_w | NCommander: try ~bzr-beta-ppa | 23:16 |
| NCommander | Of course now that I actually have everything installed from source does james_w pop up with the handy to use PPA | 23:16 |
| NCommander | :-P! | 23:16 |
| NCommander | jelmer, and as an aside, the issue fixed in the latest bazaars | 23:18 |
| NCommander | Thanks for the tip | 23:18 |
| jelmer | enigma42, not really - the svn repository contains corrupt metadata, it's impossible to create a bzr branch from that | 23:18 |
| jelmer | I guess we could add a svn-import option to skip reading any bzr-svn metadata | 23:19 |
| enigma42 | jelmer: That would be quite nice. :-) | 23:19 |
| lifeless | james_w: the beta ppa doesn't have bzr-svn | 23:20 |
| spiv | jelmer: thinking of bzr-svn options... | 23:20 |
| enigma42 | jelmer: I don't control the svn server, so I can't do a svn-dump. | 23:20 |
| markh | bb in an hour... | 23:20 |
| spiv | jelmer: 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 directory | 23:20 |
| enigma42 | jelmer: So I guess I'm out-of-luck than. | 23:20 |
| lifeless | spiv: installing bzr-svn by default would fix that | 23:21 |
| spiv | jelmer: it might be nice if there were a way to disable that feature in ~/.bazaar/locations.conf | 23:21 |
| jelmer | spiv, that seems more like something for the bzr format probe logic | 23:21 |
| jelmer | spiv: or do you mean being able to completely turn off support for .svn directories? | 23:24 |
| lifeless | jelmer: 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 |
| jelmer | lifeless, it's always a BzrDir | 23:25 |
| jelmer | whether bzr-svn considers a Branch to be present depend son the repository layout | 23:26 |
| lifeless | jelmer: well, Tree I mean | 23:26 |
| lifeless | jelmer: cause of the .svn dir | 23:26 |
| jelmer | lifeless, same goes for tree | 23:26 |
| lifeless | ok | 23:26 |
| lifeless | so at the root of a tree, the bzr probe should occur first | 23:26 |
| spiv | jelmer: the latter, at least for a given location | 23:26 |
| lifeless | and thus a .bzr dir will win | 23:26 |
| lifeless | in 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 |
| lifeless | without needing special facilities | 23:27 |
| lifeless | spiv: I don't really like the idea of turning it off | 23:27 |
| spiv | jelmer: So I think it'd be possible to make SvnCheckout.probe_transport consult locations.conf before actually probing. | 23:27 |
| jelmer | lifeless, the problem also appears to be that people try to "bzr add" .svn directories | 23:27 |
| lifeless | jelmer: when a svn tree is under a bzr tree? | 23:28 |
| jelmer | lifeless, or at the same location | 23:28 |
| jelmer | that's actually what I've seen happen so far, rather than the use case spiv is mentioning | 23:28 |
| spiv | It'd probably be enough to make .bzr always take precedence over a .svn. | 23:28 |
| spiv | Because people can always use /usr/bin/svn to manipulate .svn dirs. | 23:28 |
| lifeless | jelmer: smart_add will skip .svn dirs if they probe successfully as a branch | 23:31 |
| jelmer | lifeless, what I mean is that people *want* to version the .svn dirs in some cases | 23:32 |
| lifeless | jelmer: oh. they are insane? | 23:33 |
| lifeless | hmm, bzrdir.is_control_filename needs to be pluggable | 23:33 |
| lifeless | jelmer: ^ | 23:33 |
| lifeless | spiv: .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 bug | 23:34 |
| spiv | lifeless: sure. It's definitely been observed by various people that it doesn't necessarily take precedence. | 23:35 |
| lifeless | spiv: 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 right | 23:36 |
| jelmer | spiv, it does when they exist in the same directory, but .svn has control dirs in subdirectories as well, not just the tree root | 23:36 |
| lifeless | jelmer: so whats the use case for versioning .svn ? | 23:36 |
| jelmer | lifeless, poor mans tracking of an upstream branch in svn | 23:37 |
| spiv | lifeless: If everything Just Works, then that's great. | 23:38 |
| lifeless | jelmer: oh | 23:38 |
| spiv | lifeless: 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 |
| lifeless | spiv: IME such toggles become the end result | 23:39 |
| jelmer | jam, 0.4.17 pushed | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!