[00:10] poolie: I think so. [00:11] poolie: the hg-fast-export converter may have a few issues but I believe its working well enough for most people making the switch === jfroy|work is now known as jfroy === jfroy is now known as jfroy|work [01:02] igc: Should I follow the pattern of the others and have matching API and blackbox tests for that 'not supported'? [01:02] (or just one or the other) [01:03] fullermd: whatever abentley did [01:03] * igc looks [01:04] Mmm. I didn't see an obvious pattern in the other tests. I did matching pairs for the two success and two failure cases. [01:05] fullermd: just blackbox will do I think [01:09] 'k. I'll submit an update a bit later. [01:09] * fullermd scampers off for a bit. === mark1 is now known as markh [01:56] * igc lunch [02:49] 'k, updated patch in. === Mario__ is now known as pygi [04:41] hello, could I ask a question? [04:42] Of course. [04:42] Let's say I want to separate my branch into two separate branches, because I'm splitting it into separate projects, complete with separate license restrictions. This means that the resulting branches should contain no trace of files from the other one. [04:43] Let's say I create two branches from my branch, and from each one I remove the files that belong in the other one. [04:43] bbl [04:43] How could I remove history so files removed in each are not recoverable from that one? [04:43] At the moment, bzr doesn't have any way to remove some files from your branch history. [04:44] You could possibly use the rebase plugin or filter a fastimport dump to generate a new history without those files. [04:45] I also looked into bzr split, but it seems that wouldn't help me in this situation, correct? It seemed to just reconfigure where the base of the tree is but other files' history is still in the new repository [04:45] Right, bzr doesn't really have any facility for modifying history, basically. [04:46] hmmm I might have a look at the rebase tool, thanks for pointing it out to me [04:46] You're welcome. I don't think it's going to be easy to do what you want, unfortunately. [04:47] Looks complicated. I suppose the other option for me would be to start anew with the new project, ie don't worry about transferring across history for the files I'm pulling out under new license. [04:47] Right. [04:48] * fullermd has mentally meandered from time to time around the idea of building a grammar to describe history modifications... [04:48] ok thansk [04:48] You could at least use "bzr add --file-ids-from ../original-branch" [04:49] Which would at least keep the filename -> file-id mappings the same, which might make attaching more history later a bit easier. [04:49] ah yep I see [04:50] So merging between them in future might be easier [04:51] Yeah. But if you're completely stopping work on the old history and switch completely over to the new one, it's probably a pretty marginal benefit. [04:52] yeah. [05:07] lifeless: ping to make a 1.11 branch please [05:09] spm: uncommitted changes to pqm-config on balleny. [05:09] *spank* [05:10] poolie1: done [05:11] thanks [05:11] lifeless: indeed. ta. Were they mine (implied by the spanking)? [05:11] spm: well, not mine so losa [05:12] heh. oki, will throw to the others for review and commit. [05:12] actually - not a lot of point in review - it's been running for a month and a half.... [05:14] thanks lifeless! iz committed. [05:27] poolie1: I've shoved the lca thing in canonicaladmin [05:28] hero [05:28] maybe you should just write a simple leave/expense system as a bzr plugin? :) [05:29] python: import lca-expense [05:29] ... actually now I think on it. I'm sure there's an emacs key binding already for lca expenses. [05:57] ciao [06:06] bye [06:15] hola [07:01] * spiv -> weekend... [07:01] Is it just me, or is 'help revisionspec' lying? [07:02] ``while "bzr diff -r 3647..3649" includes the changes done in revisions 3647 and 3648, but not 3649.'' [07:02] (I hate the rest of that paragraph anyway, because it's perpetuating thinking of emergant properties as special cases, but...) [07:11] hi all [07:16] hi vila [07:37] fullermd: it's correct [07:37] ah [07:37] no, you're right, it's wrong! [07:37] and confusing [07:38] Yeah. That part I quoted is wrong. Other parts are at least partly wrong. And the whole thing is a bit eye-crossing. [07:40] The closed-vs-open range distinction made me take a mental fault to page in the terminology. [07:41] And then when you do, you realize that its use of precise terms like that is imprecise, since the diff range isn't open, it's half-open. [07:41] Very confuzzling :( [07:49] it's the other way around [07:57] Mmph. See what I mean? That's a meaning of the term I didn't even have in my brain. When I think half-open, it doesn't imply which half. [08:01] Anyway. You wanna just fix it? It seems to trivially correct that it would be ridiculous for me to work up a patch and submit it... [08:09] can you send a patch, i'm in the middle of something... [08:10] 'k [08:10] specifically rolling 1.11rc1 [08:13] Don't roll it too tight. [08:13] Congrats on the release (candidate). :) [08:15] Sent. === poolie1 changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11rc1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [08:23] poolie1: ping [08:52] hi vila === poolie1 is now known as poolie === thekorn_ is now known as thekorn [09:31] hi guys [09:31] $ bzr branch lp:gwibber -Dhpss [09:31] Permission denied (publickey). [09:31] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [09:31] HPSS calls: 1 [09:31] means anything to anyone? [09:33] --> Permission denied (publickey). <-- [09:34] I know! but what that is mean? [09:34] launchpad permission changed? [09:34] or did my key expire? [09:34] That you don't have your key set up on LP (or you're trying to use a different key) [09:35] how do I check what key am I using with brz branch? [09:36] It should just use whichever ssh will grab. [09:38] can you help me debug it, please? [09:40] try: sftp -v YOUR_LP_USERNAME@bazaar.launchpad.net [09:40] I don't really know how to offhand. I've only got one private key. [09:45] http://paste.ubuntu.com/102634/ [09:49] is it any helpful fullermd, luks ? [09:50] it means that neither of the keys matches https://launchpad.net/~bugabundo/+sshkeys [09:50] I only have 1 sshkey [09:51] its the same for years [09:52] you have at least two in ~/.ssh :) [09:53] let me check just to be sure! [09:54] yeah just one private and one public key in there [09:54] AFAICT [09:54] no, two private keys [09:54] one RSA and one DSA [09:54] ahh [09:55] I have an RSA [09:55] 7a:0b:6f:40:da:92:69:30:fe:24:94:37:b7:67:e9:9f [09:55] B767E99F [09:55] well, does the public key you have there look like https://launchpad.net/~bugabundo/+sshkeys ? [09:55] 1024D/A1784EBB [09:56] oh wait [09:56] messing SSH keys with GPG [09:56] I have an expired DSA [09:57] on my ubuntu@BUGabundo.net key [09:57] could be it! [09:59] just re-did the import key process and got : The key B905F0C5B1924A9BA8F77E5A6398A34BA1784EBB has already been imported. [09:59] bah [10:00] could a name change cause this prob luks? [10:00] mine is .ssh/id_rsa.1.pub and not .ssh/id_rsa.pub [10:01] you need a matching private+public key [10:01] fixed! [10:02] some how the key got renamed!!!!!! [10:03] should I file a bug ? [10:03] a bug where? [10:04] maybe gnome-keyring (2.25.4.1-0ubuntu1) jaunty; urgency=low [10:04] got an update today! [10:06] heh, jaunty [10:07] ehehe [10:11] luks by the way... do you know what's up with bzr-beta at LP PPA? [10:12] no, sorry [10:12] getting 404 for a week [10:20] filed here https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/315398 [10:20] Launchpad bug 315398 in gnome-keyring "ssh key renamed (possibly) after upgrade" [Undecided,New] [10:30] Hi all [10:32] beuno: I think you might be interested in the first patch in http://bugs.debian.org/511295 [10:32] It relates to #305985 in Launchpad === james_w` is now known as james_w === EarthLion is now known as Ollie| [11:24] is there something lik Trac for bazaar other than the bzr trac plugin? [11:24] something that I can install on my server, not hosted elsewhere [11:37] "Something like FOO that isn't FOO" <== you'll have to explain what FOO-likeness you want [12:00] LeoNerd: an alternative to Trac that also works with bazaar and isn't offered only as a hosted service. [12:01] Trac does a -lot- of things.. is it just the source browser you wanted? [12:01] Or bug trackign / tickets / wiki / ... [12:01] LeoNerd: bug tracking, tickets and source browser [12:02] timeline [12:02] would be nice [12:11] the new unshelve commands (not bzrtools) fails with 'bzr: ERROR: No such file: None', same as reported in https://bugs.launchpad.net/bzr/+bug/309097, does anybody know if there's any other way of looking at the "shelf" and retreiving what's there as e.g. a patch? [12:11] Launchpad bug 309097 in bzr "bzr unshelve fails with "No such file: None"" [Undecided,New] [12:12] right :) [12:14] bzr shelve --list ? [12:15] vila: nope, not in 1.10 [12:15] that one's omitted [12:15] fdv: Oh yes, you have to upgrade to 1.11 ;-) [12:15] hi [12:16] vila: which, incidentally, is still not out :) [12:16] bzr-git ... can i use that for production yet? [12:16] vila: and I need svn-integration [12:16] i dont need full support. just want to track a single git branch read-only [12:16] fdv: 1.11rc1 release this morning :) (Or a few hours ago, depending on your TZ) [12:17] ooh [12:17] fdv: But anyway, sheve --list couldn't make it in 1.10 and that's really what you want... [12:17] well, yes and no, I guess, as I want the contents of the patch-sets as well [12:18] actually, that's what I want [12:18] hm, maybe try 1.11 locally and see if it [12:18] ...'s able to unshelve for me [12:19] To see the shelf content I think you want 'bzr unshelve --dry-run ' [12:19] vila: yes, but that fails with the above error :p [12:22] fdv: Oh sorry, I don't use shelve myself :-/ Looking at the code, a shelf-id seems do be of the form shelf-([1-9][0-9]*)... [12:22] vila: it apparently finds the correct patch set [12:23] as it reports the message I input [12:23] but it fail :p [12:23] fail_s_ [12:27] crap, same error with 1.11 [12:27] so the contents are presumably broken [12:27] :( [12:28] vila: but thanks for the tip :) [12:29] np [13:21] Lo-lan-do, thanks === asac_ is now known as asac [14:06] beuno: Speaking of loggerhead, how can I know whether caching is used? [14:07] Lo-lan-do, it should create a sqlite db in /tmp [14:10] I see. Any reason not to use the cachepath config entry? [14:11] Lo-lan-do, ah, right, if you use start-loggerhead instead of serve-branches, it does [14:12] for the next release, I'm planning on adding a config file for serve-branches so we can get rid of start-branches all together [14:12] I use serve-branches. [14:13] Oh, maybe I misunderstood. [14:13] right, so serve-branches doesn't use the config file at all [14:13] Okay. [14:13] it will use *a* config file(s) in the next release :) [14:13] But yes please, do get rid of start-loggerhead :-) [14:14] heh, will do! [14:15] Do you use a lot of features from YUI ? [14:15] not at the moment, but we will more and more [14:16] I have a few branches that start using it heavily [14:16] but most of the current javascript is still mootools, so I need to migrate code over [14:16] It's just that I also submitted bugs.debian.org/511286, which is a patch to use the YUI provided by the system. [14:17] And the system currently only provides 2.5, so I wondered whether that would risk breaking because you use more recent features. [14:17] Lo-lan-do, I suspect that libjs-yui isn't going to be YUI3 [14:17] right, 3.x and 2.x are incompatible [14:17] Damn. [14:18] yeah :/ [14:18] I did some testing which seemed to work, but I don't know what YUI is used for so I didn't know what to test. [14:18] in general, we're going to be following YUI3 on the cutting edge [14:18] so as they release new versions, we will probably update the code [14:18] Lo-lan-do, it works because the current code doesn't use YUI at all in trunk ;) [14:19] * Lo-lan-do grumbles about shipping copies of external code === asac_ is now known as asac [14:48] cd [14:54] I have a question about config files in-tree: I have a default config file that I maintain with sensible defaults. When I do a checkout, I often need to change this file for local development. If I ignore the file in development, the .bzrignore gets mingled, and if I don't ignore it I just know I'll end up doing something dumb like publishing my database password. How can I safely avoid transmitting conf file changes without telling the other ... [14:54] ... branches to ignore this file? [14:54] So far I've just been grumbling and doing very selective commits on my development branches, but I just know I'll slip up at some point. [14:55] I usually maintain a separate .template file for that type of thing [14:55] * awilkins was just about to say that [14:55] and remove the live config file from version control [14:57] hmmm. Part of the point of having the defaults is that the app Just Works when you run it [14:57] I also implement this by having the app read both user settings and the defaults [14:57] And having user settings mask defaults [14:58] You can then still have a user config file that you ignore but edit the defaults [14:59] hmm, I was really hoping for a bzr solution [14:59] I mean, i've gone through ways I could change the app, and I'd rather not [14:59] since the behavior of this config file comes from upstream tools [14:59] You're asking for a way to version the file, but not version the file - I think that's a bit much to ask of a version control system :-) [15:00] Spads, what I do, is add the file the first time with example values, commit, ignore [15:00] beuno: and what do you do if you need to update the defaults? [15:00] then, we you want to re-structure it, commit it explicitly [15:00] aha [15:00] okay that sounds like a good way to go about it. [15:00] of course, that won't update the other branches [15:00] because it's ignored [15:00] oh [15:01] well it's defaults [15:01] erm... even if you ignore it, it will still notice changes if it's in the inventory [15:01] awilkins: from a merge or pull? [15:01] ignore only prevents new files being added implicitly [15:01] ah [15:01] I see [15:01] awilkins, ir tracking changes to it [15:01] s/ir/or [15:03] hrm [15:03] beuno: No, ignore does not stop it tracking changes [15:03] you can't ignore a committed file... [15:03] beuno: It only prevents "bzr add" adding it to the inventory [15:04] You can ignore patterns that correspond to inventoried files but it will warn you [15:04] yeap yeap, I was wrong [15:04] And those files continue to be tracked [15:04] Spads, so, 2 options AFAIK: 1. use configfile.example, 2. use a Makefile and have those files ignored by default [15:05] Sad. [15:05] The only solutions to this AFAIK involve i) Being careful with commits (using shelves, looms, and discipline) - that always failes [15:05] awilkins: yeah, basically that's where I'm at. [15:05] ii) Not versioning live config files [15:05] (in source, anyway [15:05] People version /etc and the like, but that's deliberate [15:05] what if in my devel version I did a bzr rm --keep first [15:07] The file will stick around. If it's ignored, it won't be added to the inventory automatically. Changes will not be propagated to downstream branches [15:07] Because they won't be versioned at all. [15:08] I think this may be the safest way to do this then [15:08] rm --keep it in production and development branches, and ignore it [15:08] if that propagates to published branches, no harm no foul [15:08] easily repaired [15:09] no launch codes problems [15:38] are there anybody around who knows the merge / unshelve code? [16:16] our dept switches to bzr today (!) [16:17] so i may be around asking stupid questions :) [17:12] hiya [17:12] bzr is awfully slow to start up [17:13] bzr st on a non-repo takes at least 1.1s, after bzr and all is in the cache [17:13] hg st on the same dir takes 0.7s cold and 0.07s hot :( [17:13] mathrick, what plugins do you have installed? [17:13] beuno: sec [17:14] http://pastebin.com/m5700f537 [17:15] mathrick, try the same without SVN [17:16] beuno: indeed, down to 200ms [17:16] still 2x slower, but it's much better [17:16] :) [17:16] now, why is bzr-svn so slow? [17:16] I'm sure if you run it with --no-plugins or something, it will take even less [17:16] loading plugins takes a bit more time [17:17] I think svn tries to open the branch even if it isn't svn [17:17] yeah, I've had a couple of bugs because of it already [17:18] beuno: surprisingly, it takes 500ms with --no-plugins [17:19] somehow ENOACCESS on ~/.bazaar/plugins is faster [17:19] mathrick, that is suprising [17:20] ...and if I remove it, instead of chmod 000, it goes up to 700ms [17:20] * mathrick files bugs [17:24] hey phinze, great to hear it [18:30] yo [18:31] LarstiQ: sup? [18:31] ronny: almost done with the flu [18:31] ronny: you? [18:31] laptop half broke [18:31] ugh [18:31] ok otherwhise [18:31] but strugling with bzr again [18:32] * LarstiQ tests his brain [18:32] yes, I seem to be able to think again :) [18:32] i still cant find a good idea to map bzr's idea of repo -> directory branch to anyvc [18:32] the model needs to fit well with git and hg [18:33] right, I see. [18:33] going around in cycles atm, but i need support for repo/branch creation, as well as bzrs "unique" view on pull vs merge [18:35] its more fun to play around in prolog [18:35] ronny: shouldn't pull/merge decompose easily over all three considering allowing/disallowing auto ehm, something with forward? [18:35] LarstiQ: on git/bzr you can just pull without merge [18:35] * LarstiQ suspects bazaar giving meaning to the left parent to be more of an issue [18:35] eh git/hg [18:36] ronny: even when diverged? [18:36] yup [18:36] it will just make multiple heads [18:36] oh [18:36] same goes for monotone [18:36] just make a new branch? [18:37] that would be messing with the users directory setup, kinda unacceptable, guess i'll just have to error out [18:37] is the the on disk result of what anyvc does important? [18:37] or will all interaction go through anyvc anyway? [18:37] LarstiQ: never ever implicitly mess with users stuff [18:37] ronny: I don't see hg/git being different here than bzr conceptually [18:37] LarstiQ: also bzr is the only one that merges from a remote [18:38] in git/hg you are in a workdir repo, pull in stuff, then merge heads [18:38] in bzr you merge from the remote side [18:39] (which might occasionaly be a local branch in the same repo, but still a different dir [18:39] right [18:39] and thats a BIG difference to deal with [18:39] if anyvc manages the collection of branches, what is wrong with adding a new one to the collection? [18:39] its not expected to happen implicit [18:40] but didn't the user explicitly say "anyvc-pull"? [18:40] yeah [18:40] but pull != make me a new branch [18:40] i guess i'll have to make pull error out just like bzr pull errors out on that case [18:40] ronny: if you want a unified working, I think it needs to be [18:41] hg/git pull is more like that than bzr pull on a branch [18:41] LarstiQ: from my point of view it would be unacceptable behaviour to create just another branch dir in the repo [18:41] they operate on repositories instead of branches [18:41] ronny: if the user is aware that is what is going to happen, why is it unacceptable? [18:41] the 3 of them do not expose it in the fs, so its ok [18:41] as long as you don't stomp over existing stuff [18:42] i guess i can add a fetch operation that combines pull/merge for git/hg and does a merge for bzr [18:42] can git/hg just pull on one branch? [18:42] and error on divergence? [18:43] they dont error on divergence [18:43] ronny: you need some clearly defined semantics :) [18:43] yeah, guess i'll make up some logic [18:43] hmm [18:45] LarstiQ: its a tricky hell ( [18:46] i'll cook up some prolog things to define the semantics and proof them [18:46] * LarstiQ has no prolog experience [18:46] prolog rocks [18:46] http://ronny.uberhost.de/2009/1/7/how-to-mimic-sql-in-prolog <- my most recent toy [18:47] it took ages to get the operators right [18:47] but its cool :) [18:48] sql in prolog? dude :) [18:48] just the syntax [18:48] i want to add a dml/ddl and do some analysis + a pseude-query-optimizer [18:49] dml = data-modeling-language (ie create *), ddl = data-definition-language (ie insert/update *) [18:49] * LarstiQ nods [18:50] hmm [18:50] ronny: does this have any impact on sqlalchemy? [18:50] no idea, probably not [18:57] can I branch over http on launchpad? [18:58] yes [19:01] LarstiQ: hmm, another weird thing will be monotone [19:02] they have repo + branches together (even unrelated branches) and the workdir is just refering to the repo [19:03] ronny: how is that different from hgit? [19:04] LarstiQ: you have n workdirs for each repo, not just one [19:04] the repo is a sqlite db === beaumonta is now known as abeaumont [19:04] neat, powerfull and slow as hell [19:05] so you have n workdirs, each refering to the _entire_ repo and having b heads? [19:06] LarstiQ: each workdir refers to a revision in the repo [19:07] can you commit in a workdir? [19:07] (I hope so) [19:07] if so, it automatically moves to the new revision? And leaves all the other workdirs where they were? [19:15] LarstiQ: yup, pretty much like that === rocky1 is now known as rocky [19:37] jelmer: ping [19:37] Hi all! [19:37] verterok: pong [19:38] jelmer: bzr-svn makes bzr startup horribly slow [19:38] jelmer: maybe this is of your interest :). Bug #290711 [19:38] yo jelmer [19:38] Launchpad bug 290711 in bzr-xmloutput "bzr-xmloutput memory leak?" [Undecided,New] https://launchpad.net/bugs/290711 [19:38] sup? [19:38] is there any plan to fix that? [19:39] mathrick: are you sure? Last time I checked the majority of the startup time was in the launchpad plugin [19:39] ronny: doesn't that multi-workdir system of theirs cause problems? What problems does it solve, anyway? [19:39] hey ronny [19:39] mathrick: monotone#s multi-workdir system causes no problems [19:40] jelmer: having some issues mapping bzr to anyvc [19:40] verterok: that's a known bug fixed in 0.5 [19:40] differences in the pull/push/merge concepts due to the lack of multiple heads [19:40] jelmer: oh, great! [19:41] ronny: but if you move one workdir, the others will have automatically diverged. That sounds like a recipe for disasters [19:41] verterok: it would only happen by constant trying to open a location as a branch though [19:41] ronny: what do you do for e.g. svn? [19:42] jelmer: yes, the xmlrpc-service stays in memory and accept commands just like the CLI [19:42] jelmer: I'm not sure anymore [19:42] jelmer: so it open the branch each time :/ [19:42] mathrick: but its ok, you just use them like branches [19:42] ronny: oh, so workdirs have their own heads? [19:42] mathrick: there is basically no real difference in usage to a bzr repo with directory branches [19:42] if so, calling them workdirs is misleading [19:42] mathrick: workdirs just point to revs [19:42] the revs are in the shared repos [19:43] sure, but "workdir" for me is files on disk, not anything directly related to any repos or revs [19:43] jelmer: no repo support for svn, it cant deal with most things, and there is no reliable way to deal with branches/tags [19:44] ronny: So fwiw, I've been working on multi-head support in bzr [19:44] ronny: for now, you should be able to just always report a single head [19:45] yup, however i cant yet use the pull;merge workflow [19:45] i guess i'll map it to fetch for now [19:45] (what git/hg do for combined pull/merge [22:52] Hi folks, I'm finding bzr abnormally slow. I have this modest branch with 299 revisions, and I recently moved the remote server to a new location. I setup the new ssh keys and so forth, and tried a test push (a tiny change.) It took 15 minutes! [22:52] Then I committed another tiny change, and pushed again. This time it only took a few seconds. [22:52] What's going on? [22:53] Does bzr detect a new location and scan through the entire remote branch history, or something like that? === Mario__ is now known as pygi [23:01] kumi: Nothing odd should happen if you change the push location. My only guess is that you pushed to the wrong location, so it had to upload everything. (Anyway, I'm going AFK now. Sorry I couldn't really help.) [23:02] kumi: Oh! If it's a large branch, or you're on a horribly slow internet connection, it may have decided to pack the repository, which would involve downloading and re-uploading a potentially significant amount of data. [23:03] kumi: (I mean, it'll pack it occasionally no matter the size of the repository or speed of your connection, but if it's small and you have a fast connection, it shouldn't take long...) [23:04]