[00:00] yes, I can understand that [00:00] I think its reasonable to write a plugin to encode/decode bad names [00:00] 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:01] so if i can just change the file thats in the svn repository, then thats great [00:01] 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] lifeless: the plan is to move to it [00:02] sportman1280: I'd look at editing a fastexport dump then, I think its probably best overall [00:02] ok. now i have to figure out how to fastexport svn [00:02] thanks [00:03] btw, i agree there should be a plugin that can handle these situations :( [00:04] 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:05] sportman1280: well, you'll want the svn-fast-export to get your data out [00:05] as for bzr fast-import, what happened when you tried to run it ? [00:05] does the plugin show up in 'bzr plugins' [00:05] thats the thing i couldnt get it to run at all [00:07] http://pastebin.com/m661c1d68 [00:08] ok, thats the fast-export side [00:08] you need pysvn installed from the look of it [00:11] ok done trying again [00:13] lifeless: I still get the same error :( [00:14] what does 'python -c import svn' do? [00:14] mwhudson: do you recall which package has the python module 'svn' [00:14] i think that's the python-subversion bindings that you have to read the C api docs to use [00:15] sportman1280: which precise package did you install; there are multiple python svn bindings [00:15] (package is called python-subversion iirc) [00:15] python-svn is the only one i saw [00:16] python -c import svn [00:16] File "", line 1 [00:16] import [00:16] ^ [00:16] SyntaxError: invalid syntax [00:16] try 'python-subversion' [00:18] lifeless: it can't download from a internet repository can it? [00:18] sportman1280: I don't know [00:18] lifeless: dang [00:25] 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:28] now i get svn.core.SubversionException: ("Expected repository format '3' or '5'; found format '9'", 165005) [00:28] :( [00:34] sportman1280: :( [00:35] lifeless: ok i'll try a little more before giving up [00:35] is there another way to dump the data and then import it back into svn? [00:36] svnadmin [02:39] 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] (with the above in a string used by the normal lazy_import stuff...) [02:40] markh: it is, yes. [02:41] 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] markh: the brackets look odd [02:41] bugger - that means I need to look into a lazy_import bug rather than just rearrange the imports ;) [02:41] markh: try [02:41] from bzrlib import ui [02:41] lifeless: yes, the code in question is a larger block [02:41] in fact [02:41] what is 'from bzrlib import ui.text' *meant* to do [02:41] 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:42] lifeless: import "bzrlib.ui.text", and add "ui" to the local namespace. [02:42] markh: in bzrlib.ui add a lazy_import of bzrlib.ui.text as text [02:42] markh: lazy_import definitely doesn't know what to do with that import I think [02:43] it does from source, which is strange. [02:43] markh: I'm fairly sure its being masked [02:43] markh: from source something else might be importing it ui.text? [02:43] I don't think the normal Python import statement would know what to do [02:44] I've checked the code and it claims to have support for this [02:44] Oh, huh. [02:44] 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] lazy_import.py line 168 [02:44] jamesh appears to be correct - its not valid Python anyway! [02:45] "from bzrlib import ui, ui.text" is a syntax error [02:46] lifeless: but you are saying lazy imports *should* support it regardless? [02:46] markh: no [02:46] I'm saying that the docstring in the code claims to support [02:46] from bzrlib import ui.text [02:47] strangely, it *does* support it! [02:47] just not in a py2exe environment [02:47] one of the perils of putting code in strings [02:47] jamesh: all code is strings [02:47] ok, thanks. The code is in qbzr, so I'll take it up with them! [02:48] markh: I would try editing ui.__init__ [02:48] as I suggested before [02:49] 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] markh: did you see my suggesetion at 13:39? [02:50] 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:51] 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] which would let Python parse and syntax check the imports [02:51] and might let other tools see the imports without modifications [02:52] jamesh: suggestions appreciated [02:52] jamesh: I imagine an import hook might allow it but at a very convoluted cost [02:52] 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:53] if it isn't that bzrlib should support it, I'm confused what my edits to __init__ would be aiming for. [02:53] markh: they may work around the problem [02:53] right - but presumably that woudn't be accepted as a patch? [02:54] which means it doesn't actually solve the problem I'm having in binary builds that anyone else (eg, John) creates. [02:54] markh: I'd accept it, as lazy importing a deep module like that is plain weird IMO [02:54] markh: and it will provide info on how lazy_import may be failing [02:54] 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:55] markh: uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh [02:55] markh: AIUI you are not getting a barf, you are getting ui.text not imported [02:55] so ui is imported but ui.text isn't [02:55] my thoughts exactly. I'm confused why the advice isn't simply "fix the wierd code" :) [02:55] 13:41 < lifeless> markh: up to you if you want to work around or dig deep [02:56] but why would I want to dig deep to support something plain weird? [02:56] 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] clearly I should just fix the import to code that would be valid in regular python and everyone is happy! [02:57] markh: sure, I never suggested that you don't change it [02:57] 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:58] 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:59] tools like py2exe generally handle imports in function bodies just fine [03:02] yeah - py2exe just uses the modulefinder package, and that does scan the bytecode for imports iiuc. [03:03] 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:04] markh: I'd prefer that the lazy imports syntax mirrored what was possible with normal imports and not more [03:04] having something that is almost but not quite compatible but looks the same is going to cause bugs [03:04] so that is a "yes" :) [03:04] yeah. [03:05] ok thanks - just trying to make sure I wasn't *totally* misunderstanding things! [03:05] I don't see any reason for lazy imports to be more than regular import can do [03:10] lifeless: right - but my example shows they can in some cases, right? [03:10] markh: yes [03:11] markh: however thats in qbzr isn't it? I'm not aware of smartass stuff like that in bzr itself [03:11] 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] well - I'd call it plain "wrong" rather than smart-arse :) but yeah... [03:29] 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? [04:01] If I do a repository.lock_read() and I *don't* do a repository.unlock() , nothing bad seams to happen. [04:01] This is surprising! [04:02] tortoise itself works well with 1.11 though, including 64bit windows, so that's my bzr work for the day done... [04:03] Is it ok to do that? [04:04] garyvdm: not in general [04:04] Ok [04:04] markh: cool [04:05] garyvdm: don't you get a warning printed somewhere when you do that? [04:05] No [04:06] I do get a warning if I don't unlock a branch. [04:06] But not with a repository. [04:06] spiv: is bzr+ssh://host/~/thing supposed to work now? [04:07] poolie: not yet; there's a quick patch on a bug IIRC. [04:12] 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] garyvdm: all the same, you should lock/unlock [04:12] Ok === Mario__ is now known as pygi [04:14] ok, i just misremembered [04:16] 334 revs to go [04:19] poolie: that evo fix I did at UDS has been committed upstream :) [04:20] yay [04:27] lifeless: 334 revs to go until what? [04:27] thumper: my local repo has all the bad revs identified and the rest copied to a clean --1.9 repo [04:27] thumper: I need to do this to start dogfooding lp for my bzr branches amongst other things [04:28] ah, ok [04:57] poolie: I'm done for the day I think [04:57] spm: bzr's pqm appears stuck? [04:57] spiv: oki, fixoring [04:58] spm: ta [04:59] spiv: cause was another one from vila: "Rev 3934: (vila) Fix bug 315737 by correctly querying the test feature" :-( [04:59] Launchpad bug 315737 in bzr "Test bzrlib.tests.test_osutils.TestChunksToLines fails" [Low,Fix committed] https://launchpad.net/bugs/315737 [04:59] should be ok again now [05:01] spm: thanks. I'm surprised that that change by vila would cause pqm problems. [05:02] 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] Wacky. [05:03] ie typicaly bloody sysadmins - went things break drag out the Biggest Sledgie you can find and start smashing daemons :-) [05:03] s/went/when/ . Other grammer errors left alone. [05:06] i thought we tracked this down... [05:06] :/ [05:06] there might be a patch attached to a bug in pqm? [05:06] spm, didn't you and me look at this [05:06] lifeless: night [05:07] poolie: I don't recall chasing that down? But you could well be right - I know we have chased other stuff down. :-) [06:58] hi all [07:19] 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:20] 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:21] i think there's a separate command to create the new branch [07:21] dpush? [07:21] the repository must already exist [07:24] trying clone.. [07:24] 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:38] hey vila === igc1 is now known as igc [07:41] 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] but it's hard to tell from outside :-/ [07:42] 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] 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] spiv: I know... [07:43] And, to me, that sounds like some connection not being gc'ed or something... [07:43] where both client and server are waiting the other end to say: I'm done [07:44] especially because when the pqm process is *killed* then my submission is successfully proceeded (sp?) [07:48] vila: processed [07:49] (nw) [07:49] bitmonk: thks [07:49] np :) [07:49] 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:50] 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] (last) [07:50] keep in mind that green tea has comparable caffeine to coffee, but is less addictive.. [07:50] 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] vila: i love non-native english speakers, if only for the opportunity to be helpful when others aren't.. [07:51] * 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] yah i hear that [07:51] gotta pick battles [07:51] * bitmonk has cut back a lot on tobacco but hasnt killed like coffee [07:51] 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:52] 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] that light pole had a bad attitude! :-P [07:52] * bitmonk hides [07:54] 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:55] 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:56] oh wrong chan ;d [07:58] bitmonk: the answer should be: "it should", but that's a wild guess, I'm not using xen :-) [07:59] 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] esp as people on comparable hardware have told me that general kernel build takes around 25-30min (3.0GHz C2D) [07:59] anyway, way out of scope for #bzr join in ##xen if you want to continue :) [08:00] 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] also the DomU has like 512M of RAM and Dom0 has like 3.5-4.0 [08:00] anyway, again, out of scope [08:00] * bitmonk scuttles off to ##xen [08:02] bitmonk: thanks for the offer :-) I may try xen in a couple of months but virtualbox is enough for my needs so far [08:03] 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:46] night all === thekorn_ is now known as thekorn [11:29] 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:30] How do I specify the mail-to address? [11:31] --mail-to [11:31] Do I have to specify it? [11:31] third last paragraph of 'bzr help send' [11:33] that's not really accurate [11:33] the email address is only required for some clients (like the simple editor+smtp one) [11:33] if you are using a gui client, it's usually optional [11:33] for /to/ or /from/? [11:34] to [11:35] e.g. I have it configured to use evolution, I just run bzr send and type the address in evolution's window [11:35] oh [11:36] but does the mail have to be sent? If I just skip sending the mail when evolution opens, does it matter? [11:36] then you want -o [11:36] right, then it's written to file or stdout [11:37] where do you want the bundle then? [11:38] It still seems like the changes aren't published [11:39] all 'send' does is produce a bundle and optionally email it somewhere [11:39] oh [11:39] it doesn't affect any branches - are you trying to update the branch you branched from? [11:39] hehe, yes [11:39] I misunderstood the command [11:40] which command should I use then? I guess 'merge' is to fetch changes from main branch? [11:41] bzr push [11:44] yep, it worked [11:44] thanks [12:15] Is it valid to have a revision ID "" (I mean, an empty string, not literally two double-quotes)? [12:15] I don't think revision IDs have any specified format [12:16] so I'd say it's valid, but I'd expect some code to break on that [12:16] because NULL revisions used to be represented as None [12:18] The exception raised is NoSuchRevision. It would likely be something else if it was actually invalid.. [12:19] Peng_: At a glance, the code would treat that as a valid revision ID I think. [12:19] Why do you want to know? [12:20] I just wrote an email about it, actually, in Benn Finney's thread. [12:20] It's bad enough that bzr's history has a revision "A" ;) [12:20] Haha, how'd that happen? [12:21] "silly commit"? [12:21] ...Creating a file called "b"? [12:22] 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] 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] But if it is a valid revision, that's correct behavior, if not convenient... [12:22] Back before the test suite was as good as it is now at insulating tests from reality. [12:22] (and vice versa) [12:23] I think it'd be reasonable to disallow "" as a revision ID. [12:23] It seems more likely to cause bugs than be helpful. [12:25] I don't disagree, but I don't care strongly enough to do anything about it. :P [12:25] Well, you already did, by mailing the list ;) [12:27] Heh, good point. === ubott2 is now known as ubottu [14:26] is there a quick way to tell bzr: 'add all of the files in the unknown list' ? [14:27] phinze, bzr add? [14:27] beuno: doh! that was way too easy :) [14:27] :) [14:30] * 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:33] here's another one... is `bzr co foo; cd foo; bzr unbind` the equivalent of `bzr branch foo` ? [14:34] I'm not sure, I don't use checkouts much [14:34] yes, it is [14:35] luks: cool, thanks. just trying to get my head around this stuff [14:37] phinze: It is *roughly* the same. "bzr co" won't set the parent location, but "bzr branch" will. [14:38] abentley: really, that's interesting, you'd almost think it would be the other way around [14:38] that the checkout would be tethered to a parent and the branch would be free floating [14:38] 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:39] ahh [14:40] so really for the decentralized workflow `bzr branch` is really what you'd want to use [14:42] because bzr co + bzr unbind leaves you without a pull source [14:44] phinze: yeah but the first time you pull into a branch that has no pull source, it remembers the new source [14:45] rocky: okay nice, so there isn't all that much difference between the two in the end [14:46] yeah, and you can always change the pull source again with --remember [14:51] hi are newbies question allowed?? .. :) [14:51] andresmujica, absolutely [14:51] hehe thks [14:51] does anyone here use bzr-hookless-email? [14:52] i'm using a sw called 5-a-day, as far as i've check it uses bzr internally [14:52] the problem is that i'm using from 2 different computers [14:52] so i wonder [14:52] which is the right procedure to use it [14:52] when i change computers [14:53] somehow update the local .bzr before any update?? [14:53] 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] there's a main place (code.kaunchpad.net) [14:53] both point there [14:53] andresmujica, I think it might be easier to have both of them use bound branches [14:53] ahh [14:54] but the revisions numbers are different because i mainly work at one of them, and sometimes at the other... [14:54] so i suspect i've got to merge or pull or something like that before start my work... [14:54] at the less used computer [14:54] 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:55] 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:56] ...if the more-often-used one doesn't have a superset, do a merge on it before the push. [14:57] ...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] ("the software" == "5-a-day") [14:57] yeap 5-a-day.. i'm making a mess with my branch :( [14:58] yeap i've got the keys already in place on both systems [15:14] in a distributed workflow with no central server, can i give my team-mates' branches nicknames locally? [15:14] i want to be able to say "bzr merge alice", "bzr merge bob", etc [15:14] and have "alice" and "bob" expand to the urls of those team mates [15:14] seb_kuzminsky: not currently, though you may want to look at the bzr-bookmarks plugin [15:15] thanks james_w :-) [15:23] bzr-bookmarks is winrar!! :-D [15:27] I am encountering the different rich-root support error while trying to clone [15:28] http://pastie.org/358686 [15:28] I tried the suggestions on https://bugs.launchpad.net/bzr/+bug/272425 [15:28] Ubuntu bug 272425 in bzr ""different rich-root support" error could be clearer" [Low,Confirmed] [15:28] but get an bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. error [15:29] when trying to do a bzr upgrade --rich-root-pack [15:31] bzr co works just fine [15:33] hi all i'm in the same spot as rbriggsatuiowa [15:33] rbriggsatuiowa: if you bzr init --rich-root-pack foo; cd foo; bzr pull remote-foo; it works [15:34] basically bzr clone is creating a repository of format pack-0.92 [15:34] which is not right [15:36] because the remote bzr server is using rich-root-pack [15:36] stupid gentoo [15:37] rbriggsatuiowa: mine's doing it too (ubuntu 8.10, bzr 1.6.1) [15:37] I double-checked the USE flags and don't seem to be missing anything [15:43] rbriggsatuiowa: which version you on [15:44] Bazaar (bzr) 1.6.1 [15:44] yeah let's try upgrading to 1.10 (which the server is on)... msging you details [15:56] yep, the problem was using a 1.6.1 client with a 1.10 remote branch [16:00] ok, guys. i 've learned how to do it. Thanks for your help!!!! [16:00] see ya! [17:12] bzr mv concrete/blocks/autonav/ blocks/autonav [17:12] bzr: ERROR: Could not move autonav => autonav: blocks/autonav is already versioned. [17:12] could someone tell me why i am getting that message? [17:13] there is currently nothing in blocks/autonav [17:13] so i don't see how it can already be versioned [17:13] bzr remove blocks/autonav [17:13] blocks/autonav does not exist. [17:38] 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] rsc-: have you made the changes yet? [17:38] yes [17:38] rsc-: if so, you could `bzr merge --uncommitted path/to/branch/with/changes` from the one where you want them [17:39] ahh. [17:39] cool :) [17:39] did that help? [17:39] that should be automatic, yeah? no need for my intervention? [17:39] (assuming that both branches are identical) [17:40] (...except that one of them has uncomited changes) [17:40] should be, yeah. [17:40] cool. [17:40] you learn something new everyday. [17:40] thanks :) [17:40] Possibly you want to list a couple of files you want the changes from, and not others. [17:47] can bzr handle resource forks (found in macs)? [17:48] adeel: I don't think it does anything special with them. === asac_ is now known as asac [17:48] as most things are wont to do. [17:49] 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:50] adeel, I don't think it handles them at the moment [17:50] at least it doesn't handle extended attributes (Linux) or streams (Windows) [17:50] adeel: that doesn't suprise me, almost nothing handles them. [17:51] yeah that's what it seems like [17:52] It would actually be interesting to seem them being used to store VCS metadata [17:53] 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 === mark1 is now known as markh [18:10] adeel: How has bzr been confusing you? [18:18] jelmer: ping [18:18] jam, pong [18:19] hi jelmer, for the win32 installers, I went ahead and kept using 0.4.16 [18:19] Should I be trying to switch to the 0.5 series? [18:19] jam, no, at least not for any production-oriented setups [18:19] k, that's what I thought, but I figured I'd check, since there wasn't an 0.4.17 yet [18:20] I hope to release another rc in the next couple of days, then maybe 0.5.0 after that [18:21] jelmer: is 0.5 compatible with an 0.4 conversion? (I'm guessing not, but figured I'd check) [18:22] jam, no, although it does support using 0.4-style mappings if explicitly configured [18:23] jelmer: but it would create all new revision-ids, right? [18:23] jam, if the 0.4-style mappings are enabled, no [18:23] it would create the same revision ids that 0.4 would [18:23] so by default 0.5 isn't compatible, but it can be made so? [18:23] jam: yes [18:23] It would be good to have that well documented for an 0.5 upgrade [18:24] There's a README.UPGRADING file [18:24] It would probably be important enough to make sure it would get into the NEWS items for whatever bzr starts including it [18:24] jam: yeah, probably [18:25] 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:26] including referncing the right docs about upgrading between bzr- mappings [18:56] 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? [19:19] rocky, not sure [19:19] rocky, I've fixed *some* bugs, not sure if that included yours [19:19] do you remember the bug #? [19:21] 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] so that means there won't be a 0.5 version that works on bzr 1.10 ? [19:21] regardless, i tried with bzr 1.11rc1 + bzr-svn 0.5 branch (as of a couple days ago) and got the same error ... [19:22] jelmer: just try "bzr co svn+https://dev.serverzen.com/svn/collective/Products.eXtremeManagement/trunk" and watch it complain about tags [19:29] rocky, that appears to require a password? [19:33] jelmer: oh sorry, try the non https version [19:33] that's anonymous use [19:34] ah, thanks [19:35] rocky, that seems to redirect me to the https url [19:38] ronny: what does the workingset accomodate? [19:43] jelmer: ok, http://svn.plone.org/svn/collective/Products.eXtremeManagement/trunk/ definitely works, i just browsed to it in a browser ;) [19:44] LarstiQ: manages a set of n branches, i view heads as branches [19:46] ronny: ok [19:46] LarstiQ: im not entirely sure on the abstraction [19:46] ronny: what prompted you to include it? [19:47] LarstiQ: stuff like hg's named branches [19:47] * LarstiQ looks that up [19:47]