=== kiko is now known as kiko-zzz [03:49] poolie: I did review your lp_registration patch; it doesn't seem to be in bzr.dev ? [03:53] lifeless, i may not have merged back 1.2, i'll check [04:40] spiv: ping [04:55] lifeless: pong [04:55] I've just sent an updated patch for external ref support [04:56] I'm hoping you can review it as it contains smart server changes [04:56] the old patch is a week old now too; which is the other thing. [04:57] I'll take a look. [04:59] spiv: thanks [05:25] done for de day; ciao [05:39] http://thyrsus.com/lists/uvc-reviewers/2008-January/000016.html -> "One of my big complaints about bzr is that it tries to hide the fact [05:39] that history is no longer linear" [05:40] bob2: your issues, or raising someone elses? [05:43] ted t'so's [06:08] so there is some tendency that way but it's a bit inaccurate [06:08] we show branch points in viz, we just don't show it by default in log [06:09] I'd tend to agree more with him, if he could show some way to make a command-line 'log' NOT do so, and still be comprehensible. [06:10] Blatting them out in unannotated partial order (or just plain chronological) sure isn't a solution. mtn's annotated graph output is staggeringly unpleasant too. [06:11] I maintain that the reason gitk and mtn-viz gets pushed so much harder than bzr viz is that you just can't figure things out from the CLI 'log' output. [06:12] Whereas bzr log's linear projection (with the subsidiary forms of action that enable it), while misleading and oversimplified, DOES let you figure things out much better. [08:27] where are the bzr 1.2 release notes? [08:40] johnny_: https://launchpad.net/bzr/1.2/1.2/ ? [08:40] well they aren't linked on the main page [08:40] yes, they are. [08:41] linked from the link "full changelog" [08:41] :-) [08:42] oh.. it is fixed now [08:42] i think i had that window open for a while.. [08:42] thought i refreshed the thing [08:43] i'm looking at this bzrarchives blueprint [08:43] got any other systems you guys are looking at to take inspiration from? [08:44] people always found that confusing in monotone for sure [08:46] they use sqlite for the archive storage [09:35] hi, bzr push works like 1/5 times. otherwise it just stalls. [09:35] ssh/sftp works dandy all the time thouggh [09:35] though [09:36] I ditched my old svn history and went 100 % bzr, but I really can't work like this. [09:36] python goes up to use 99% cpu [09:37] It stalls when working on local files? [09:37] after a commit, I push the files to a server [09:37] using bzr+ssh [09:37] and often too.. [09:38] now I have to: commit, push, ctrl-c (like 30 times), go to server, break-lock .. push again etc .. until it works [09:41] and I hopen I'm alone with this, because I've recommended bzr to A LOT of people :) === weigon__ is now known as weigon [09:52] appcine: Are you working on a wireless connection? [09:52] awilkins: yes [09:52] awilkins: both at work and at home [09:53] Is the signal a bit flaky? The only time I had any trouble with plain BZR (over a shared filesystem) was when the connection was dropping. [09:54] it's not very flaky :/ [09:54] How big are your branches? [09:58] 120 MB or so, including a lot of media files [09:59] It could be the large binaries that are giving you trouble, I've seen warnigns about that in the documentation, although I am no authority on the matter. [10:00] On the other hand, 120MB is not too much, I have a partially converted repo with over 900MB of packs in it. [10:01] and it's soo weird that it works 1/5 [10:01] almost consistently [10:02] I get this in my client log: WARNING: This transport does not update the working tree of: ... [10:02] but that's quite alright, no? [10:02] That's normal [10:02] Just means that I have to update the server [10:02] Do your server repos have a working tree, is it desired? [10:02] then Using fetch logic to copy between KnitPackRepository ... [10:02] then somethign weir happens [10:02] whenever it is going to stall, i see the progressbar [10:02] Why not try rich-root-pack instead? [10:02] and I get this in my log: not updating child fraction [10:03] See if that helps at all [10:03] rich-root-pack? :) [10:03] Differetn repo format [10:03] how do I change that then?, hehe [10:03] You take your branch and bzr upgrade --rich-root-pack [10:03] awilkins: uhm, KnitPackRepository == packs [10:03] pack-0.92 I mean [10:03] Ok, proabbly not much differnt then [10:04] awilkins: and pack-0.92 and rich-root-pack will be the same for performance [10:04] right [10:04] appcine: I think you should try it over a wired connection [10:05] That will at least eliminate one variable from consideration ; you're going to have to be a detective to isolate the cause. [10:09] hehe yeah [10:10] plugging cable in [10:10] hello [10:11] I am curious if bzr can/will preserve file permissions/ownership in it's database. [10:12] same over cable [10:13] It just doesn't do anything and .bzr.log is spitting out "not updating child fraction" [10:13] But you feel less doubt and fear, for now you know it isn't your wireless flaking out! [10:13] haha, yes! :) [10:14] anything else I can try? [10:14] It's nice with software that you want to work [10:15] Like bzr, it doesn't work for me .. normally I would go use mercurial or back to svn instead [10:15] since it's totally disrupting my work [10:15] but .. you keep on trying [10:17] sttng359: no, it can't (by design) [10:17] https://lists.ubuntu.com/archives/bazaar/2007q4/035930.html [10:18] could that be my problem perhaps? [10:18] normally when you work with source code, you work with multiple people so preserving the ownership doesn't really makes sense [10:18] yes, I understand that design principle and why cvs/subversion and others use it [10:19] but I am currently looking for something more suitible for version /etc where large subtree may not even be versioned and preserving permisisons it more important as it's single use only [10:19] But no, it happens with sftp also for me :( [10:19] So I am looking for a decent configuration versioning, not source code versioning [10:20] also, something that could version across hosts would be nice, such as pushing changes for nss_ldap. [10:21] I just saw a blog of someone mentioning using Bazaar on /etc. === johnny_ is now known as johnny [10:23] sttng359: there is metastore and etckeeper [10:24] I use monotone on my /etc at the moment [10:24] But I may well switch to bzr, mtn is good but not perfect [10:25] sttng359: though I thought jelmer had added bzr support to etckeeper, but I can't see that being the case [10:25] mtn does have soeme nice things tho.. [10:25] I can't bring to mind any features that bzr doesn't (not to say there aren't any, just none I care about ) [10:25] New bug: #193214 in bzr ""bzr up" in a branch with local commits shows changes twice" [Undecided,New] https://launchpad.net/bugs/193214 [10:26] And I think learning Python for hooks is probably more productive than Lua [10:26] the sqlite storage is mtn is neat [10:26] in* [10:26] and the arbitrary certs [10:27] Are you mining the database for information? [10:27] lua is simple enough at least [10:27] sometimes.. [10:27] we have about 30K revs in mtn across 4 databases [10:28] i don't think monotone will every be a big thing tho...all the other vcs will just mine it for information :) [10:29] the project that is [10:29] I mainly just want to track changes in configuration files through package upgrades, or when services stop working. [10:29] Yes, I think it's probably a battle between git and bzr now. [10:29] i just use dispatch-conf [10:29] in gentoo sttng359 ` [10:29] Also, a mechanism for pushing common configuration files between servers would greatly help in maintenance. [10:29] maybe you want something like cfengine? [10:29] or is that too intense? :) [10:30] git has a crack squad of Kernel developers, bzr has a nice easy-to-learn language and popular visibility in the Ubuntu community. [10:31] sttng359: There's a "update tree" plugin for bzr that will do a server-side update after a bzr+ssh push, afaik. [10:31] Ahh, I remember reading about cfengine a few years ago, but I was not ready for it. [10:31] Perhaps that's the solution to my needs. [10:34] awilkins: I upgraded from 1.1 to latest trunk, it still hangs, but I get "34.513 not updating child fraction" -- a preceeding float number -- in my logs now [10:34] and now cpu goes to 99% [10:34] Looks like it's probably a known bug if they are adding more debugging information to the messages in newer revisions [10:35] Or at least, a reported / suspected bug [10:35] I really wanted to solve this.. [10:36] I guess I have to merge my current changes back into the svn repos and use that for a few more months until this is fixed. Else my boss will have my head [10:36] :) [10:36] Do a bzr annotate on the file which generates the message - maybe the commit log will give you more information about what's going on. [10:37] Have you tried setting up a persistent smart server? [10:37] No.. but this also fails using just sftp [10:37] and the changes I make is a comment in just one file [10:38] Try archiving up the branch on the server, unpacking it to your local filesystem, and pushing to that. [10:38] Then you know if it's a network-protocol problem or a corrupted data problem [10:38] good idea [10:41] But I really haveto go tow ork .. it's lunch already and I'be been trying to solve this all morning :) [10:42] Fair enough [10:42] Might I recommend SVk for disconnected operation from an SVN repo? [10:43] I recently ditched it for bzr because it had a bug that caused me real problems... and Perl gives me a headache. [10:43] But I was using it for some time without trouble. [10:44] You don't even have to ditch your comfy SVN tools like TortoiseSVN (or whatever you use). [10:44] I find bzr with bzr-svn much easier to use than svk, and actually even more functional [10:44] but I mainly use it for only for merges [10:44] Yes, the bzr merging is better [10:45] A merge bug is what lead me to ditch SVK [10:46] It was a blocker too - it couldn't do a particular merge, I couldn't find a workaround, so I was faced with re-mirroring the SVN repo and waiting for it to happen again, or trying something else. [10:47] svn was working great for me, but I hear bzr branching is better .. and I branch a lot [10:47] I get this in my server "bzr info" [10:47] Conflict: can't delete apps/new_media because it is not empty. Not deleting. [10:47] bzr / SVN branching are equally easy (you might even say that SVN branching is less costly on resources), but bzr MERGING is where it shines [10:48] why do you have a working tree on the server? [10:48] appcine: Try resolving that conflict. And then (thanks luks) nuking the tree. [10:48] luks: I have NO idea! :) [10:49] Having a tree is the default. [10:49] not if you push over sftp/bzr+ssh [10:49] Depends where the branch was created. [10:49] right [10:49] gahhhh [10:49] bzr remove-tree [10:49] is that safe? [10:49] You might need a --force [10:49] appcine: if you don't have any local changes there [10:49] Depends if those non-empty files are significant [10:50] They represent local changes you might want to keep (or they might just be build cruft) [10:50] I have a dir in my tree: media/user_uploaded/ [10:50] that's not version controlled and contains user uploaded data [10:50] does remove-tree delete the actual files? [10:50] or what does it do? [10:51] remove-tree removes the files from disk, but not the repository storage [10:51] I need the files on the disk [10:51] otherwise apache can't serve them [10:51] :) [10:51] If you are pushing to a common branch there is always a risk of conflict. [10:52] I am pushing to our live-server [10:52] Working on my laptop, pushing to the server when done. [10:52] I wouldn't use bzr to push to an apache-served directory [10:52] the restart apache and the site is live [10:52] Probably not such a great idea to serve straight from a full branch [10:52] Because you are serving the .bzr repo as well [10:52] it's not php [10:53] Paste address [10:53] it's a python site and the source code is not avaialble in apache www-root [10:53] So, let's start from scratch :) [10:54] I used to work like this: work on my laptop, commit to svn server, ssh to web server and update. restart apache [10:54] appcine: are you updating the working tree manually? [10:54] or using push-and-update? [10:54] Now I: work on laptop, commit, push to web server, ssh to webserver, bzr update and restart apache [10:54] ah [10:55] Now, the bzr remove-tree that I ran, has it destroyed anything? I ctrl-c:ed when I saw what was happening. [10:55] How about you have a no-tree branch on the server and do a bzr export instead? [10:55] And, is there something wrong with theat workflow? [10:55] remove-tree will nuke the "working copy" [10:55] It doesn't destroy any revisions [10:55] but it will remove files? [10:55] It removes the files from the working copy [10:56] But probably not the unversioned ones [10:56] bzr reconfigure --tree if you want them back [10:56] luks: PHEW.. hehe [10:56] bzr checkout [10:56] it removed a lot of user uploaded files [10:56] appcine: do bzr update [10:56] dato: nothing happened [10:56] er [10:56] appcine: you version user uploaded files? [10:56] I arrived late to the party [10:56] bzr update only works if there's a tree [10:57] luks: no, but the dirs they were in [10:57] a checkout reconfigures it back to tree and gets the files. [10:57] awilkins: but he said he ctrl-c'd early [10:57] I'm quite sure it doesn't touch non-versioned files [10:57] awilkins: I can't run checkout because .bzr still exists [10:58] appcine: checkout fetches the files from .bzr into the working tree [10:58] luks: It seems like it removed the versioned directory containing the files [10:58] if you jsut go into the branch and do a "bzr checkout" [10:58] appcine: If you can confirm that behaviour, that's bad [10:58] bzr: ERROR: File exists: u'/home/appcine/webapps/appcine/.bzr' [10:59] when doing bzr checkout [10:59] * awilkins is confused. [10:59] appcine: if I do that I get a conflict telling me that there are unversioned files [11:00] so I'm not sure what exactly did you run [11:00] There isn't a "force" option either, you'd have to remove them manually to get it to clear the tree [11:00] luks: bazaar remove-tree --force .. then, when I noticed what was happening, i hit ctrl-c [11:00] luks: How about if they are in your ignore list,? [11:01] appcine: "bzr: ERROR: no such option: --force" [11:01] awilkins: same error if they are ignored [11:01] appcine: err [11:02] but how do I get my site back up now? :) [11:02] bazaar?? [11:02] what _exactly_ did you run? [11:02] luks: sec [11:02] $ bzr remove-tree [11:02] either way, running random commands your live site is not the greatest idea [11:03] I know :) [11:03] then it complained about non-versioned files in the working tree [11:03] if you had there any [11:03] My recommended layout ; put a no-trees branch somewhere other than inside your web root. [11:03] bzr --version? [11:03] THen do a bzr export to the desired location [11:03] 1.1.0 [11:03] no-trees branch, ok [11:03] and then to keep it up-to-date? [11:04] Either make a lightweight checkout for your web app, or use bzr export [11:04] Nevermind the deleted user-files, that directory had been renamed [11:04] I got so stressed up [11:04] THe lightweight checkout is probably easiest to keep fresh [11:05] and the lightweight checkout is something you do from the server? [11:05] Yes [11:06] Does my laptop need to have a public ip for that? [11:06] You might be able to hook script it, I'm not up to speed with bzr hooking though [11:06] appcine: No, there's a branch on the server [11:06] appcine: You do your checkout from that [11:06] So .. if I start from scratch now [11:06] Work on laptop, push to branch on server, ssh to server, lightweight checkout to web app folder [11:06] from client I run: bzr export bzr+ssh://server/project [11:07] From laptop you bzr push bzr+ssh//server/home/me/mywebappdeploymentbranch [11:08] from server bzr checkout --lightweight /home/me/mywebappdeploymentbranch /var/www/webapp [11:08] Then for updates bzr update /var/wwe/webapp after a push [11:09] Ah, ok .. [11:09] Let me try that [11:10] I'm inferring from the docs that hooks don't run at the target end of a push, even if you're using the smart server. [11:13] But you could splat together a swift deploy script that did the push and an ssh remote bzr update /var/www/webapp [11:14] I think the problem you've run into is that you have a server folder that fills with unversioned files that you subsequently renamed in your local branch [11:16] Updating manually on the server really isn't a problem [11:16] I'm usually always logged in there anyway [11:16] Maybe you could get around that by using a symlink for your user upload area .. that way bzr should ignore the content (it's only versioning the link) [11:17] And how would that work for local development? === jrydberg__ is now known as jrydberg [11:17] IE, the link would be different, now? [11:17] s/now/no/ [11:17] You could make it a link to the same path clocally [11:19] * awilkins is on windows and cannot readily test this theory :-) [11:23] Ok, site back up [11:23] :) [11:23] jelmer: Something in one of our production repos is producing a deadlock in bzr-svn (ie it sits there and neither process consumes CPU) [11:24] jelmer: (by neither process, I mean svnserve and python bzr) [11:24] jelmer: Would a copy of the svncache help with debugging or would you need more than that? [11:25] awilkins: And it seems like my problem has been resolved [11:27] appcine: I think you're just going to have to be careful on the server with that unversioned content, but with a treeless branch on the server there should be no excuses for pushes failing, if you are pulling/merging any other developers work before you do it. [11:27] But I'm guessing you are the sole "pusher" here [11:27] I am [11:29] Those error message could be more helpful.... were you committing on the server? [11:31] comitting, pushing on client, update on server [11:33] Ok, situation under control. Thanks a lot for the help [11:34] hmm.. got loggerhead nearly working now.. something is odd about the public branch url tho.. [11:46] Anyone had any joy setting up bzr-svn on osx 10.4? I'm following the instructions here http://bazaar-vcs.org/BzrForeignBranches/Subversion but the install is failing with make: *** [subversion/bindings/swig/python/core.c] Error 127 === jezdez_ is now known as jezdez === Verterok is now known as Verterok_ [12:02] awilkins: Are you using 0.4.7 or the 0.4 branch? [12:11] does anyone know is there a hook or something like that to catch push or commit on the remote repository side? [12:12] like when you do bzr push bzr+ssh://remoterep.server/repo [12:13] so that remoterep.server does something like sends an email when this happens [12:13] wortkt: no, you can only use local hooks at the moment afaik [12:14] ok [12:31] New bug: #193250 in bzr "memory error when attempting to copy a branch" [Undecided,New] https://launchpad.net/bugs/193250 [12:32] has anyone ever tried to set up a repository/branch accessible over http+access permissions as set in an .htaccess file? [12:33] basically: got bzr to handle http code 401 by means of a plugin/experimental path? === mrevell is now known as mrevell-lunch [12:41] patch* [12:43] jelmer: 0.4 branch [12:44] awilkins: Please try the 0.4.7 branch [12:44] the 0.4 has some severe performance regressions at the moment [12:44] Well, it's not a "performance" problem ; it just sits there doing nothing (no resource consumption), but I'll try. [12:46] * awilkins reverts to r 877 [12:46] it iterates over the history unnecessarily [12:46] it's mainly bandwidth usage, not cpu or memory [12:52] I think the reason I moved forward was https://bugs.launchpad.net/bugs/191572 [12:54] ... which is where I am now. [13:05] jelmer: I thought all the history got cached? [13:05] awilkins: the path changes (the paths in "svn log -v") are cached [13:07] jelmer: The server process was also doing nothing when it was in this condition ; it sat there for 2 1/2 hours doing nothing. [13:08] I didn't notice the server even eating 1% of the cpu on the occasions I checked. [13:09] Oh, by the way, since there are no API changes for 1.2, is bzr-svn compatible ? [13:10] awilkins: haven't checked yet [13:12] jelmer: Which bit of libsvn has that humungous memory leak? [13:12] awilkins: the python bindings themselve [13:15] jelmer: It's not entirely solved even by those patches, is it? [13:15] I'm attempting to build an RPM for BZR1.2 on RHEL4 and I'm getting "error: file 'bzrlib/_dirstate_helpers_c.pyx' does not exist" ... is this related to Pyrex ? [13:16] awilkins: there are several other leaks that are only fixed in 1.5 I think [13:17] jelmer: I should think so, it eats 1.5GB processing the first 300 or so revisions [13:17] 'tis a shame that "pull" doesn't count up revisions, it's not very reassuring :-) [13:17] awilkins: That's not right though [13:17] awilkins: That sounds like it doesn't have *any* memory leak patches applied [13:18] I should be using the windows builds from http://d5190871.u44.websitesource.net/bzr/ [13:18] * awilkins does some checking [13:20] jelmer: Some of these revisions are very large ; the tree is large, and it has quite a few larger files in it too. [13:20] the size of the files shouldn't matter [13:21] I'm just wondering if the size of the tree is accentuating some of the memleaks. [13:22] what do you mean by large specifically? [13:22] 39,000 files [13:22] in a single tree? [13:22] Yes [13:22] Some of the files are as large as 50MB [13:23] wow, ok [13:23] (not many that large though, they are mostly in the 10-100s of KB range) [13:23] have you tried with native bzr<->bzr with a tree that large [13:23] ? [13:24] jelmer: Nope, but I shall try an export of this tree and branch it. === mrevell-lunch is now known as mrevell [13:58] jelmer: Ok, I've done that now ; it tops out at 190MB to either commit or branch this tree (via the filesystem). [13:59] awilkins: that's the same history size / number of files/ size of files as in svn? [13:59] No, alas. [13:59] It's the same files, but I don't have 13,000 revisions of history [13:59] Just one revision [14:00] I'd have to convert the repository to bzr via other means if I wanted all those revisions. [14:02] I could try sv2bzr I suppose [14:03] I don't suppose svn2bzr is compatible with bzr-svn, is it? :-) [14:03] no [14:03] awilkins: You can try the subversion 1.5 binaries if there are any yet [14:04] awilkins: if it's just one revision, it's not a proper simulation so not really a sign that the memory leak is in bzr-svn [14:04] (or python-svn/svn) [14:04] jelmer: I agree, but the difficuly is simulating an identical revision tree without converting it over :-) [14:05] jelmer: svn2bzr shouldn't suffer the same problem since it works from dumpfiles [14:05] So that would be one way of getting an equivalent branch [14:05] I shall instruct the server to make me a dump. [14:13] awilkins: you can also try the 'bzr pull -r...' trick to work around the memory errors [14:14] jelmer: I was just resuming when it crashed, which seems to work well enough until it gets to that KeyError exception [14:15] The latest revisions don't even do that though, they just become inactive and do nothing (as describe further up) [14:15] awilkins: Right, but that's what you get for running a development version :-) [14:16] awilkins: That bug is unrelated to bzr-svn, it's a bzr bug. [14:16] jelmer: Rock >> awilkins << hard place [14:17] It's not essential, I don't really work on this branch much anymore, most of my projects are in much more manageable branches [14:17] I just like to torture test things :-) [14:20] jelmer: reading 191731, I may just install 1.2 and try that === kiko-zzz is now known as kiko [14:38] jelmer: Much improved in 1.2, but still eating heap big memory. Python is a reference counter, not a garbage collector, yes? [14:38] yes [14:39] * awilkins again wonders what bzr would be like on IronPython [14:39] I'm pretty sure bzr-svn doesn't keep a lot of handles open though [14:40] It's still creeping up, but it creeps back down again a lot more than before [14:40] Is there any kind of ?heap? viewer in the debugger ; get an idea of which objects are holding the memory? [14:41] not as far as I'm aware === mw is now known as mw_______ === mw__ is now known as mw [14:41] it's really tricky to debug this sort of thing with cpython [14:41] It seems to go through big leaps of memory use for certain revisions ; it's almost like it's growing a bloody enormous hash table [14:42] I had a look at the log, they don't seem to correspond to revisions with large deltas [14:43] it may be to do with how packs work [14:43] or perhaps the fact that bzr keeps whole files in memory atm when applying deltas [14:43] It seems to be holding between 1.48 and 1.6 GB [14:44] Yes, I did notice that committing large files to my export/branch test ate memory for the whole file [14:45] Bah, the ceiling went from 1.48 to 1.61 [14:45] s/ceiling/floor/ [14:48] It's managed over 700/9243 revisions so far.... [14:48] Doing much better on 1.2 that 1.1 did [15:09] * awilkins tries the -r 100 trick :-) [15:10] New bug: #193304 in bzr-svn "Unable to start a bazaar branch in a directory containing .svn directories" [Undecided,New] https://launchpad.net/bugs/193304 === juliank0 is now known as juliank [15:13] how does bzr compare with mercurial? (i just heard of that one) [15:13] unenough: they are quite similar [15:13] (though maybe bzr devs will beg to differ!) [15:13] unenough: I don't think you can get an objective answer here [15:13] (obviously) [15:14] well, i'd like to know what bzr ppl think [15:14] i use bzr [15:14] and I guess the same would apply for #mercurial [15:14] unenough: I think both are great tools, but bzr's developer and user community rules [15:14] I personally have weird feelings about a VCS that doesn't do merges [15:15] Hg doesn't merge? [15:15] hg uses "merge tools" [15:16] well since i'm about to rewrite the software world anyway, i'll just stick to bzr for now [15:16] hg merges... [15:16] just some of its paradigms are different [15:16] :P [15:16] to the end user I think it's safe to say it has an analog operation to bzr merge [15:16] it handles "shared repositories" differently (more git-like) [15:16] jdong: like I have to install the rcs package to make it actually merge something? :) [15:17] and it (used to be?) significantly faster [15:17] luks: I could've sworn when I used hg it merged just fine [15:17]