| === kiko is now known as kiko-zzz | ||
| lifeless | poolie: I did review your lp_registration patch; it doesn't seem to be in bzr.dev ? | 03:49 |
|---|---|---|
| poolie | lifeless, i may not have merged back 1.2, i'll check | 03:53 |
| lifeless | spiv: ping | 04:40 |
| spiv | lifeless: pong | 04:55 |
| lifeless | I've just sent an updated patch for external ref support | 04:55 |
| lifeless | I'm hoping you can review it as it contains smart server changes | 04:56 |
| lifeless | the old patch is a week old now too; which is the other thing. | 04:56 |
| spiv | I'll take a look. | 04:57 |
| lifeless | spiv: thanks | 04:59 |
| lifeless | done for de day; ciao | 05:25 |
| bob2 | 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 |
| bob2 | that history is no longer linear" | 05:39 |
| thumper | bob2: your issues, or raising someone elses? | 05:40 |
| bob2 | ted t'so's | 05:43 |
| poolie | so there is some tendency that way but it's a bit inaccurate | 06:08 |
| poolie | we show branch points in viz, we just don't show it by default in log | 06:08 |
| fullermd | 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:09 |
| fullermd | 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:10 |
| fullermd | 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:11 |
| fullermd | 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. | 06:12 |
| johnny_ | where are the bzr 1.2 release notes? | 08:27 |
| jabr | johnny_: https://launchpad.net/bzr/1.2/1.2/ ? | 08:40 |
| johnny_ | well they aren't linked on the main page | 08:40 |
| jabr | yes, they are. | 08:40 |
| jabr | linked from the link "full changelog" | 08:41 |
| jabr | :-) | 08:41 |
| johnny_ | oh.. it is fixed now | 08:42 |
| johnny_ | i think i had that window open for a while.. | 08:42 |
| johnny_ | thought i refreshed the thing | 08:42 |
| johnny_ | i'm looking at this bzrarchives blueprint | 08:43 |
| johnny_ | got any other systems you guys are looking at to take inspiration from? | 08:43 |
| johnny_ | people always found that confusing in monotone for sure | 08:44 |
| johnny_ | they use sqlite for the archive storage | 08:46 |
| appcine | hi, bzr push works like 1/5 times. otherwise it just stalls. | 09:35 |
| appcine | ssh/sftp works dandy all the time thouggh | 09:35 |
| appcine | though | 09:35 |
| appcine | I ditched my old svn history and went 100 % bzr, but I really can't work like this. | 09:36 |
| appcine | python goes up to use 99% cpu | 09:36 |
| frsk | It stalls when working on local files? | 09:37 |
| appcine | after a commit, I push the files to a server | 09:37 |
| appcine | using bzr+ssh | 09:37 |
| appcine | and often too.. | 09:37 |
| appcine | now I have to: commit, push, ctrl-c (like 30 times), go to server, break-lock .. push again etc .. until it works | 09:38 |
| appcine | and I hopen I'm alone with this, because I've recommended bzr to A LOT of people :) | 09:41 |
| === weigon__ is now known as weigon | ||
| awilkins | appcine: Are you working on a wireless connection? | 09:52 |
| appcine | awilkins: yes | 09:52 |
| appcine | awilkins: both at work and at home | 09:52 |
| awilkins | 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:53 |
| appcine | it's not very flaky :/ | 09:54 |
| awilkins | How big are your branches? | 09:54 |
| appcine | 120 MB or so, including a lot of media files | 09:58 |
| awilkins | 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. | 09:59 |
| awilkins | On the other hand, 120MB is not too much, I have a partially converted repo with over 900MB of packs in it. | 10:00 |
| appcine | and it's soo weird that it works 1/5 | 10:01 |
| appcine | almost consistently | 10:01 |
| appcine | I get this in my client log: WARNING: This transport does not update the working tree of: ... | 10:02 |
| appcine | but that's quite alright, no? | 10:02 |
| awilkins | That's normal | 10:02 |
| appcine | Just means that I have to update the server | 10:02 |
| awilkins | Do your server repos have a working tree, is it desired? | 10:02 |
| appcine | then Using fetch logic to copy between KnitPackRepository ... | 10:02 |
| appcine | then somethign weir happens | 10:02 |
| appcine | whenever it is going to stall, i see the progressbar | 10:02 |
| awilkins | Why not try rich-root-pack instead? | 10:02 |
| appcine | and I get this in my log: not updating child fraction | 10:02 |
| awilkins | See if that helps at all | 10:03 |
| appcine | rich-root-pack? :) | 10:03 |
| awilkins | Differetn repo format | 10:03 |
| appcine | how do I change that then?, hehe | 10:03 |
| awilkins | You take your branch and bzr upgrade --rich-root-pack | 10:03 |
| dato | awilkins: uhm, KnitPackRepository == packs | 10:03 |
| dato | pack-0.92 I mean | 10:03 |
| awilkins | Ok, proabbly not much differnt then | 10:03 |
| dato | awilkins: and pack-0.92 and rich-root-pack will be the same for performance | 10:04 |
| dato | right | 10:04 |
| awilkins | appcine: I think you should try it over a wired connection | 10:04 |
| awilkins | That will at least eliminate one variable from consideration ; you're going to have to be a detective to isolate the cause. | 10:05 |
| appcine | hehe yeah | 10:09 |
| appcine | plugging cable in | 10:10 |
| sttng359 | hello | 10:10 |
| sttng359 | I am curious if bzr can/will preserve file permissions/ownership in it's database. | 10:11 |
| appcine | same over cable | 10:12 |
| appcine | It just doesn't do anything and .bzr.log is spitting out "not updating child fraction" | 10:13 |
| awilkins | But you feel less doubt and fear, for now you know it isn't your wireless flaking out! | 10:13 |
| appcine | haha, yes! :) | 10:13 |
| appcine | anything else I can try? | 10:14 |
| appcine | It's nice with software that you want to work | 10:14 |
| appcine | Like bzr, it doesn't work for me .. normally I would go use mercurial or back to svn instead | 10:15 |
| appcine | since it's totally disrupting my work | 10:15 |
| appcine | but .. you keep on trying | 10:15 |
| luks | sttng359: no, it can't (by design) | 10:17 |
| appcine | https://lists.ubuntu.com/archives/bazaar/2007q4/035930.html | 10:17 |
| appcine | could that be my problem perhaps? | 10:18 |
| luks | normally when you work with source code, you work with multiple people so preserving the ownership doesn't really makes sense | 10:18 |
| sttng359 | yes, I understand that design principle and why cvs/subversion and others use it | 10:18 |
| sttng359 | 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 |
| appcine | But no, it happens with sftp also for me :( | 10:19 |
| sttng359 | So I am looking for a decent configuration versioning, not source code versioning | 10:19 |
| sttng359 | also, something that could version across hosts would be nice, such as pushing changes for nss_ldap. | 10:20 |
| sttng359 | I just saw a blog of someone mentioning using Bazaar on /etc. | 10:21 |
| === johnny_ is now known as johnny | ||
| dato | sttng359: there is metastore and etckeeper | 10:23 |
| awilkins | I use monotone on my /etc at the moment | 10:24 |
| awilkins | But I may well switch to bzr, mtn is good but not perfect | 10:24 |
| dato | sttng359: though I thought jelmer had added bzr support to etckeeper, but I can't see that being the case | 10:25 |
| johnny | mtn does have soeme nice things tho.. | 10:25 |
| awilkins | 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 |
| ubotu | New bug: #193214 in bzr ""bzr up" in a branch with local commits shows changes twice" [Undecided,New] https://launchpad.net/bugs/193214 | 10:25 |
| awilkins | And I think learning Python for hooks is probably more productive than Lua | 10:26 |
| johnny | the sqlite storage is mtn is neat | 10:26 |
| johnny | in* | 10:26 |
| johnny | and the arbitrary certs | 10:26 |
| awilkins | Are you mining the database for information? | 10:27 |
| johnny | lua is simple enough at least | 10:27 |
| johnny | sometimes.. | 10:27 |
| johnny | we have about 30K revs in mtn across 4 databases | 10:27 |
| johnny | i don't think monotone will every be a big thing tho...all the other vcs will just mine it for information :) | 10:28 |
| johnny | the project that is | 10:29 |
| sttng359 | I mainly just want to track changes in configuration files through package upgrades, or when services stop working. | 10:29 |
| awilkins | Yes, I think it's probably a battle between git and bzr now. | 10:29 |
| johnny | i just use dispatch-conf | 10:29 |
| johnny | in gentoo sttng359 ` | 10:29 |
| sttng359 | Also, a mechanism for pushing common configuration files between servers would greatly help in maintenance. | 10:29 |
| johnny | maybe you want something like cfengine? | 10:29 |
| johnny | or is that too intense? :) | 10:29 |
| awilkins | git has a crack squad of Kernel developers, bzr has a nice easy-to-learn language and popular visibility in the Ubuntu community. | 10:30 |
| awilkins | sttng359: There's a "update tree" plugin for bzr that will do a server-side update after a bzr+ssh push, afaik. | 10:31 |
| sttng359 | Ahh, I remember reading about cfengine a few years ago, but I was not ready for it. | 10:31 |
| sttng359 | Perhaps that's the solution to my needs. | 10:31 |
| appcine | 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 |
| appcine | and now cpu goes to 99% | 10:34 |
| awilkins | Looks like it's probably a known bug if they are adding more debugging information to the messages in newer revisions | 10:34 |
| awilkins | Or at least, a reported / suspected bug | 10:35 |
| appcine | I really wanted to solve this.. | 10:35 |
| appcine | 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 |
| appcine | :) | 10:36 |
| awilkins | 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:36 |
| awilkins | Have you tried setting up a persistent smart server? | 10:37 |
| appcine | No.. but this also fails using just sftp | 10:37 |
| appcine | and the changes I make is a comment in just one file | 10:37 |
| awilkins | Try archiving up the branch on the server, unpacking it to your local filesystem, and pushing to that. | 10:38 |
| awilkins | Then you know if it's a network-protocol problem or a corrupted data problem | 10:38 |
| appcine | good idea | 10:38 |
| appcine | But I really haveto go tow ork .. it's lunch already and I'be been trying to solve this all morning :) | 10:41 |
| awilkins | Fair enough | 10:42 |
| awilkins | Might I recommend SVk for disconnected operation from an SVN repo? | 10:42 |
| awilkins | I recently ditched it for bzr because it had a bug that caused me real problems... and Perl gives me a headache. | 10:43 |
| awilkins | But I was using it for some time without trouble. | 10:43 |
| awilkins | You don't even have to ditch your comfy SVN tools like TortoiseSVN (or whatever you use). | 10:44 |
| luks | I find bzr with bzr-svn much easier to use than svk, and actually even more functional | 10:44 |
| luks | but I mainly use it for only for merges | 10:44 |
| awilkins | Yes, the bzr merging is better | 10:44 |
| awilkins | A merge bug is what lead me to ditch SVK | 10:45 |
| awilkins | 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:46 |
| appcine | svn was working great for me, but I hear bzr branching is better .. and I branch a lot | 10:47 |
| appcine | I get this in my server "bzr info" | 10:47 |
| appcine | Conflict: can't delete apps/new_media because it is not empty. Not deleting. | 10:47 |
| awilkins | 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:47 |
| luks | why do you have a working tree on the server? | 10:48 |
| awilkins | appcine: Try resolving that conflict. And then (thanks luks) nuking the tree. | 10:48 |
| appcine | luks: I have NO idea! :) | 10:48 |
| awilkins | Having a tree is the default. | 10:49 |
| luks | not if you push over sftp/bzr+ssh | 10:49 |
| awilkins | Depends where the branch was created. | 10:49 |
| luks | right | 10:49 |
| appcine | gahhhh | 10:49 |
| appcine | bzr remove-tree | 10:49 |
| appcine | is that safe? | 10:49 |
| awilkins | You might need a --force | 10:49 |
| luks | appcine: if you don't have any local changes there | 10:49 |
| awilkins | Depends if those non-empty files are significant | 10:49 |
| awilkins | They represent local changes you might want to keep (or they might just be build cruft) | 10:50 |
| appcine | I have a dir in my tree: media/user_uploaded/ | 10:50 |
| appcine | that's not version controlled and contains user uploaded data | 10:50 |
| appcine | does remove-tree delete the actual files? | 10:50 |
| appcine | or what does it do? | 10:50 |
| awilkins | remove-tree removes the files from disk, but not the repository storage | 10:51 |
| appcine | I need the files on the disk | 10:51 |
| appcine | otherwise apache can't serve them | 10:51 |
| appcine | :) | 10:51 |
| awilkins | If you are pushing to a common branch there is always a risk of conflict. | 10:51 |
| appcine | I am pushing to our live-server | 10:52 |
| appcine | Working on my laptop, pushing to the server when done. | 10:52 |
| luks | I wouldn't use bzr to push to an apache-served directory | 10:52 |
| appcine | the restart apache and the site is live | 10:52 |
| awilkins | Probably not such a great idea to serve straight from a full branch | 10:52 |
| awilkins | Because you are serving the .bzr repo as well | 10:52 |
| appcine | it's not php | 10:52 |
| awilkins | Paste address | 10:53 |
| appcine | it's a python site and the source code is not avaialble in apache www-root | 10:53 |
| appcine | So, let's start from scratch :) | 10:53 |
| appcine | I used to work like this: work on my laptop, commit to svn server, ssh to web server and update. restart apache | 10:54 |
| luks | appcine: are you updating the working tree manually? | 10:54 |
| luks | or using push-and-update? | 10:54 |
| appcine | Now I: work on laptop, commit, push to web server, ssh to webserver, bzr update and restart apache | 10:54 |
| luks | ah | 10:54 |
| appcine | Now, the bzr remove-tree that I ran, has it destroyed anything? I ctrl-c:ed when I saw what was happening. | 10:55 |
| awilkins | How about you have a no-tree branch on the server and do a bzr export instead? | 10:55 |
| appcine | And, is there something wrong with theat workflow? | 10:55 |
| awilkins | remove-tree will nuke the "working copy" | 10:55 |
| awilkins | It doesn't destroy any revisions | 10:55 |
| appcine | but it will remove files? | 10:55 |
| awilkins | It removes the files from the working copy | 10:55 |
| awilkins | But probably not the unversioned ones | 10:56 |
| luks | bzr reconfigure --tree if you want them back | 10:56 |
| appcine | luks: PHEW.. hehe | 10:56 |
| awilkins | bzr checkout | 10:56 |
| appcine | it removed a lot of user uploaded files | 10:56 |
| dato | appcine: do bzr update | 10:56 |
| appcine | dato: nothing happened | 10:56 |
| dato | er | 10:56 |
| luks | appcine: you version user uploaded files? | 10:56 |
| dato | I arrived late to the party | 10:56 |
| awilkins | bzr update only works if there's a tree | 10:56 |
| appcine | luks: no, but the dirs they were in | 10:57 |
| awilkins | a checkout reconfigures it back to tree and gets the files. | 10:57 |
| dato | awilkins: but he said he ctrl-c'd early | 10:57 |
| luks | I'm quite sure it doesn't touch non-versioned files | 10:57 |
| appcine | awilkins: I can't run checkout because .bzr still exists | 10:57 |
| awilkins | appcine: checkout fetches the files from .bzr into the working tree | 10:58 |
| appcine | luks: It seems like it removed the versioned directory containing the files | 10:58 |
| awilkins | if you jsut go into the branch and do a "bzr checkout" | 10:58 |
| awilkins | appcine: If you can confirm that behaviour, that's bad | 10:58 |
| appcine | bzr: ERROR: File exists: u'/home/appcine/webapps/appcine/.bzr' | 10:58 |
| appcine | when doing bzr checkout | 10:59 |
| * awilkins is confused. | 10:59 | |
| luks | appcine: if I do that I get a conflict telling me that there are unversioned files | 10:59 |
| luks | so I'm not sure what exactly did you run | 11:00 |
| awilkins | There isn't a "force" option either, you'd have to remove them manually to get it to clear the tree | 11:00 |
| appcine | luks: bazaar remove-tree --force .. then, when I noticed what was happening, i hit ctrl-c | 11:00 |
| awilkins | luks: How about if they are in your ignore list,? | 11:00 |
| luks | appcine: "bzr: ERROR: no such option: --force" | 11:01 |
| luks | awilkins: same error if they are ignored | 11:01 |
| luks | appcine: err | 11:01 |
| appcine | but how do I get my site back up now? :) | 11:02 |
| luks | bazaar?? | 11:02 |
| luks | what _exactly_ did you run? | 11:02 |
| appcine | luks: sec | 11:02 |
| appcine | $ bzr remove-tree | 11:02 |
| luks | either way, running random commands your live site is not the greatest idea | 11:02 |
| appcine | I know :) | 11:03 |
| luks | then it complained about non-versioned files in the working tree | 11:03 |
| luks | if you had there any | 11:03 |
| awilkins | My recommended layout ; put a no-trees branch somewhere other than inside your web root. | 11:03 |
| luks | bzr --version? | 11:03 |
| awilkins | THen do a bzr export to the desired location | 11:03 |
| appcine | 1.1.0 | 11:03 |
| appcine | no-trees branch, ok | 11:03 |
| appcine | and then to keep it up-to-date? | 11:03 |
| awilkins | Either make a lightweight checkout for your web app, or use bzr export | 11:04 |
| appcine | Nevermind the deleted user-files, that directory had been renamed | 11:04 |
| appcine | I got so stressed up | 11:04 |
| awilkins | THe lightweight checkout is probably easiest to keep fresh | 11:04 |
| appcine | and the lightweight checkout is something you do from the server? | 11:05 |
| awilkins | Yes | 11:05 |
| appcine | Does my laptop need to have a public ip for that? | 11:06 |
| awilkins | You might be able to hook script it, I'm not up to speed with bzr hooking though | 11:06 |
| awilkins | appcine: No, there's a branch on the server | 11:06 |
| awilkins | appcine: You do your checkout from that | 11:06 |
| appcine | So .. if I start from scratch now | 11:06 |
| awilkins | Work on laptop, push to branch on server, ssh to server, lightweight checkout to web app folder | 11:06 |
| appcine | from client I run: bzr export bzr+ssh://server/project | 11:06 |
| awilkins | From laptop you bzr push bzr+ssh//server/home/me/mywebappdeploymentbranch | 11:07 |
| awilkins | from server bzr checkout --lightweight /home/me/mywebappdeploymentbranch /var/www/webapp | 11:08 |
| awilkins | Then for updates bzr update /var/wwe/webapp after a push | 11:08 |
| appcine | Ah, ok .. | 11:09 |
| appcine | Let me try that | 11:09 |
| awilkins | 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:10 |
| awilkins | But you could splat together a swift deploy script that did the push and an ssh remote bzr update /var/www/webapp | 11:13 |
| awilkins | 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:14 |
| appcine | Updating manually on the server really isn't a problem | 11:16 |
| appcine | I'm usually always logged in there anyway | 11:16 |
| awilkins | 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:16 |
| appcine | And how would that work for local development? | 11:17 |
| === jrydberg__ is now known as jrydberg | ||
| appcine | IE, the link would be different, now? | 11:17 |
| appcine | s/now/no/ | 11:17 |
| awilkins | You could make it a link to the same path clocally | 11:17 |
| * awilkins is on windows and cannot readily test this theory :-) | 11:19 | |
| appcine | Ok, site back up | 11:23 |
| appcine | :) | 11:23 |
| awilkins | 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:23 |
| awilkins | jelmer: (by neither process, I mean svnserve and python bzr) | 11:24 |
| awilkins | jelmer: Would a copy of the svncache help with debugging or would you need more than that? | 11:24 |
| appcine | awilkins: And it seems like my problem has been resolved | 11:25 |
| awilkins | 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 |
| awilkins | But I'm guessing you are the sole "pusher" here | 11:27 |
| appcine | I am | 11:27 |
| awilkins | Those error message could be more helpful.... were you committing on the server? | 11:29 |
| appcine | comitting, pushing on client, update on server | 11:31 |
| appcine | Ok, situation under control. Thanks a lot for the help | 11:33 |
| johnny | hmm.. got loggerhead nearly working now.. something is odd about the public branch url tho.. | 11:34 |
| muffinresearch | 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 | 11:46 |
| === jezdez_ is now known as jezdez | ||
| === Verterok is now known as Verterok_ | ||
| jelmer | awilkins: Are you using 0.4.7 or the 0.4 branch? | 12:02 |
| wortkt | does anyone know is there a hook or something like that to catch push or commit on the remote repository side? | 12:11 |
| wortkt | like when you do bzr push bzr+ssh://remoterep.server/repo | 12:12 |
| wortkt | so that remoterep.server does something like sends an email when this happens | 12:13 |
| jelmer | wortkt: no, you can only use local hooks at the moment afaik | 12:13 |
| wortkt | ok | 12:14 |
| ubotu | New bug: #193250 in bzr "memory error when attempting to copy a branch" [Undecided,New] https://launchpad.net/bugs/193250 | 12:31 |
| grutte_pier | has anyone ever tried to set up a repository/branch accessible over http+access permissions as set in an .htaccess file? | 12:32 |
| grutte_pier | basically: got bzr to handle http code 401 by means of a plugin/experimental path? | 12:33 |
| === mrevell is now known as mrevell-lunch | ||
| grutte_pier | patch* | 12:41 |
| awilkins | jelmer: 0.4 branch | 12:43 |
| jelmer | awilkins: Please try the 0.4.7 branch | 12:44 |
| jelmer | the 0.4 has some severe performance regressions at the moment | 12:44 |
| awilkins | Well, it's not a "performance" problem ; it just sits there doing nothing (no resource consumption), but I'll try. | 12:44 |
| * awilkins reverts to r 877 | 12:46 | |
| jelmer | it iterates over the history unnecessarily | 12:46 |
| jelmer | it's mainly bandwidth usage, not cpu or memory | 12:46 |
| awilkins | I think the reason I moved forward was https://bugs.launchpad.net/bugs/191572 | 12:52 |
| awilkins | ... which is where I am now. | 12:54 |
| awilkins | jelmer: I thought all the history got cached? | 13:05 |
| jelmer | awilkins: the path changes (the paths in "svn log -v") are cached | 13:05 |
| awilkins | 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:07 |
| awilkins | I didn't notice the server even eating 1% of the cpu on the occasions I checked. | 13:08 |
| awilkins | Oh, by the way, since there are no API changes for 1.2, is bzr-svn compatible ? | 13:09 |
| jelmer | awilkins: haven't checked yet | 13:10 |
| awilkins | jelmer: Which bit of libsvn has that humungous memory leak? | 13:12 |
| jelmer | awilkins: the python bindings themselve | 13:12 |
| awilkins | jelmer: It's not entirely solved even by those patches, is it? | 13:15 |
| corporate_cookie | 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:15 |
| jelmer | awilkins: there are several other leaks that are only fixed in 1.5 I think | 13:16 |
| awilkins | jelmer: I should think so, it eats 1.5GB processing the first 300 or so revisions | 13:17 |
| awilkins | 'tis a shame that "pull" doesn't count up revisions, it's not very reassuring :-) | 13:17 |
| jelmer | awilkins: That's not right though | 13:17 |
| jelmer | awilkins: That sounds like it doesn't have *any* memory leak patches applied | 13:17 |
| awilkins | I should be using the windows builds from http://d5190871.u44.websitesource.net/bzr/ | 13:18 |
| * awilkins does some checking | 13:18 | |
| awilkins | 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 |
| jelmer | the size of the files shouldn't matter | 13:20 |
| awilkins | I'm just wondering if the size of the tree is accentuating some of the memleaks. | 13:21 |
| jelmer | what do you mean by large specifically? | 13:22 |
| awilkins | 39,000 files | 13:22 |
| jelmer | in a single tree? | 13:22 |
| awilkins | Yes | 13:22 |
| awilkins | Some of the files are as large as 50MB | 13:22 |
| jelmer | wow, ok | 13:23 |
| awilkins | (not many that large though, they are mostly in the 10-100s of KB range) | 13:23 |
| jelmer | have you tried with native bzr<->bzr with a tree that large | 13:23 |
| jelmer | ? | 13:23 |
| awilkins | jelmer: Nope, but I shall try an export of this tree and branch it. | 13:24 |
| === mrevell-lunch is now known as mrevell | ||
| awilkins | jelmer: Ok, I've done that now ; it tops out at 190MB to either commit or branch this tree (via the filesystem). | 13:58 |
| jelmer | awilkins: that's the same history size / number of files/ size of files as in svn? | 13:59 |
| awilkins | No, alas. | 13:59 |
| awilkins | It's the same files, but I don't have 13,000 revisions of history | 13:59 |
| awilkins | Just one revision | 13:59 |
| awilkins | I'd have to convert the repository to bzr via other means if I wanted all those revisions. | 14:00 |
| awilkins | I could try sv2bzr I suppose | 14:02 |
| awilkins | I don't suppose svn2bzr is compatible with bzr-svn, is it? :-) | 14:03 |
| jelmer | no | 14:03 |
| jelmer | awilkins: You can try the subversion 1.5 binaries if there are any yet | 14:03 |
| jelmer | 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 |
| jelmer | (or python-svn/svn) | 14:04 |
| awilkins | jelmer: I agree, but the difficuly is simulating an identical revision tree without converting it over :-) | 14:04 |
| awilkins | jelmer: svn2bzr shouldn't suffer the same problem since it works from dumpfiles | 14:05 |
| awilkins | So that would be one way of getting an equivalent branch | 14:05 |
| awilkins | I shall instruct the server to make me a dump. | 14:05 |
| jelmer | awilkins: you can also try the 'bzr pull -r...' trick to work around the memory errors | 14:13 |
| awilkins | jelmer: I was just resuming when it crashed, which seems to work well enough until it gets to that KeyError exception | 14:14 |
| awilkins | The latest revisions don't even do that though, they just become inactive and do nothing (as describe further up) | 14:15 |
| jelmer | awilkins: Right, but that's what you get for running a development version :-) | 14:15 |
| jelmer | awilkins: That bug is unrelated to bzr-svn, it's a bzr bug. | 14:16 |
| awilkins | jelmer: Rock >> awilkins << hard place | 14:16 |
| awilkins | 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 |
| awilkins | I just like to torture test things :-) | 14:17 |
| awilkins | jelmer: reading 191731, I may just install 1.2 and try that | 14:20 |
| === kiko-zzz is now known as kiko | ||
| awilkins | jelmer: Much improved in 1.2, but still eating heap big memory. Python is a reference counter, not a garbage collector, yes? | 14:38 |
| jelmer | yes | 14:38 |
| * awilkins again wonders what bzr would be like on IronPython | 14:39 | |
| jelmer | I'm pretty sure bzr-svn doesn't keep a lot of handles open though | 14:39 |
| awilkins | It's still creeping up, but it creeps back down again a lot more than before | 14:40 |
| awilkins | Is there any kind of ?heap? viewer in the debugger ; get an idea of which objects are holding the memory? | 14:40 |
| jelmer | not as far as I'm aware | 14:41 |
| === mw is now known as mw_______ | ||
| === mw__ is now known as mw | ||
| jelmer | it's really tricky to debug this sort of thing with cpython | 14:41 |
| awilkins | 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:41 |
| awilkins | I had a look at the log, they don't seem to correspond to revisions with large deltas | 14:42 |
| jelmer | it may be to do with how packs work | 14:43 |
| jelmer | or perhaps the fact that bzr keeps whole files in memory atm when applying deltas | 14:43 |
| awilkins | It seems to be holding between 1.48 and 1.6 GB | 14:43 |
| awilkins | Yes, I did notice that committing large files to my export/branch test ate memory for the whole file | 14:44 |
| awilkins | Bah, the ceiling went from 1.48 to 1.61 | 14:45 |
| awilkins | s/ceiling/floor/ | 14:45 |
| awilkins | It's managed over 700/9243 revisions so far.... | 14:48 |
| awilkins | Doing much better on 1.2 that 1.1 did | 14:48 |
| * awilkins tries the -r 100 trick :-) | 15:09 | |
| ubotu | 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 | 15:10 |
| === juliank0 is now known as juliank | ||
| unenough | how does bzr compare with mercurial? (i just heard of that one) | 15:13 |
| jdong | unenough: they are quite similar | 15:13 |
| jdong | (though maybe bzr devs will beg to differ!) | 15:13 |
| luks | unenough: I don't think you can get an objective answer here | 15:13 |
| luks | (obviously) | 15:13 |
| unenough | well, i'd like to know what bzr ppl think | 15:14 |
| unenough | i use bzr | 15:14 |
| luks | and I guess the same would apply for #mercurial | 15:14 |
| jdong | unenough: I think both are great tools, but bzr's developer and user community rules | 15:14 |
| luks | I personally have weird feelings about a VCS that doesn't do merges | 15:14 |
| awilkins | Hg doesn't merge? | 15:15 |
| luks | hg uses "merge tools" | 15:15 |
| unenough | well since i'm about to rewrite the software world anyway, i'll just stick to bzr for now | 15:16 |
| jdong | hg merges... | 15:16 |
| jdong | just some of its paradigms are different | 15:16 |
| unenough | :P | 15:16 |
| jdong | to the end user I think it's safe to say it has an analog operation to bzr merge | 15:16 |
| jdong | it handles "shared repositories" differently (more git-like) | 15:16 |
| luks | jdong: like I have to install the rcs package to make it actually merge something? :) | 15:16 |
| jdong | and it (used to be?) significantly faster | 15:17 |
| jdong | luks: I could've sworn when I used hg it merged just fine | 15:17 |
| awilkins | What's Hg written in? | 15:17 |
| jdong | these days I think bzr and hg have similar performance characteristics | 15:17 |
| luks | jdong: it doesn't have built-in merge | 15:17 |
| jdong | awilkins: python, C-extension diff | 15:17 |
| awilkins | Same as bzr then... | 15:17 |
| luks | there is extension that is basically the three-way merge from bzr | 15:17 |
| jdong | luks: hg merge doesn't count? | 15:17 |
| luks | hg merge just starts the hgmerge script | 15:18 |
| jdong | but what is the difference to the end user? | 15:18 |
| luks | you need to have a merge tool | 15:18 |
| luks | like the "merge" program from rcs | 15:18 |
| awilkins | Doe Hg track file renames like bzr? | 15:19 |
| awilkins | And how does it square that with separate merge tools if it does? | 15:19 |
| luks | hg tracks copies+deletes | 15:19 |
| luks | and using file names, not file ids | 15:19 |
| abentley | And doesn't track directory renames, because it doesn't track directories at all. | 15:20 |
| jdong | unenough: but anyway, since you asked us, IMO bzr is better :) | 15:21 |
| awilkins | Hmm, I'm used to directory tracking, I don't think I'd like to give that up | 15:21 |
| awilkins | Although the "content tracking" in git is an appealing idea, it just isn't mature enough on windows | 15:22 |
| luks | I don't think it ever will be | 15:22 |
| awilkins | Too close to the "metal" of VFS | 15:23 |
| luks | I also don't like how hg/git handle unicode | 15:24 |
| luks | "just use the current locale and hope everybody is using the same" | 15:24 |
| luks | which doesn't really work well if you on both windows and linux | 15:25 |
| * awilkins never really figured out encoding on *nix, espuncode support | 15:25 | |
| mruiz | hi all. I want to use 5-a-day package but I got the following error with bzr : http://pastebin.ubuntu.com/4762/ | 15:28 |
| awilkins | Do the "modern" distros come Unicode flavoured out of the box? | 15:28 |
| luks | I think all of them use utf-8 now by default | 15:29 |
| awilkins | mruiz: That's not an error WITH bazaar, that's a lack of bazaar | 15:29 |
| mruiz | awilkins, I'm using bzr 1.2~rc1-1 | 15:30 |
| mruiz | bzr: ERROR: Couldn't import bzrlib and dependencies. | 15:30 |
| luks | python -c 'import bzrlib' | 15:31 |
| luks | does it work? | 15:31 |
| mruiz | luks, no :( ImportError: No module named bzrlib | 15:31 |
| luks | then you are not using 1.2~rc1-1 :) | 15:31 |
| luks | or you have it installed somewhere else | 15:31 |
| luks | how did you install it? | 15:32 |
| awilkins | You should be able to get a full 1.2 release too (not that it's different to the RC AFIK) | 15:33 |
| jdong | mruiz: are you running hardy by any chance? | 15:33 |
| mruiz | jdong, awilkins : I'm using Hardy up to date | 15:34 |
| jdong | mruiz: pycentral, most likely | 15:34 |
| jdong | they broke it | 15:34 |
| jdong | bug 192992 I think | 15:34 |
| ubotu | Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992 | 15:34 |
| theSoftMan | hello... where can i find winBZR ( the BZR client like winCVS) ? ;-) | 15:34 |
| jdong | whoa! I got that right! | 15:34 |
| jdong | I just pulled it off the top of my head | 15:34 |
| jdong | (is that sad?) | 15:34 |
| luks | theSoftMan: there isn't one :) | 15:34 |
| awilkins | There ought to just be a Tortoise<D?VCS> that worked with everything | 15:35 |
| theSoftMan | hello luks... that so unlucky :-) | 15:35 |
| awilkins | They should merge all the various Tortoises and have a backend of plugins | 15:36 |
| rif | hi guys, is there a bzr command to create a file containing history that I can send through email and apply it on a related repo? | 15:40 |
| rif | more than a patch | 15:40 |
| luks | bzr send | 15:40 |
| luks | (too obvious? :)) | 15:40 |
| rif | ;) | 15:40 |
| jdong | awilkins: does that make some sort of giant land turtle? | 15:41 |
| jdong | rif: bzr bundle too | 15:41 |
| awilkins | Heh, yeah "GalapagosVCS, your one-stop integrated Windows VCS tool!" | 15:42 |
| luks | the problem is that all have their own little differences | 15:42 |
| awilkins | This is true, But I bet you could re-use a lot of the GUI, etc, with some well defined interfaces | 15:43 |
| awilkins | Log dialog, tree browser, etc | 15:43 |
| awilkins | Upgrade the log dialog for meged trees, it would still work fine for straight trees. | 15:43 |
| awilkins | And it's an explorer plugin ; having three of the damn things eats more memory than one. And there are issues with overlays (you're only allowed so many, etc) | 15:45 |
| luks | awilkins: I think the status cache is eating way more memory than the explorer plugin | 15:45 |
| jdong | awilkins: yeah and explorer's flaky enough without another massive plugin | 15:46 |
| luks | which runs in the background all the time and watches the whole filesystem | 15:46 |
| awilkins | luks: Ah, yes, it does eat a lot. If you still have it turned on. Which I don't because I have too many large trees. | 15:46 |
| rif | I dont have acces to the branch that I want to create the bundle for, can I specify the last known revision ore something? | 15:47 |
| awilkins | rif: is your current branch a branch of "that one"? | 15:49 |
| rif | yes | 15:49 |
| rif | awilkins: and I know the last revision that "that one" has in common with the current one | 15:50 |
| awilkins | You should be able to use -r [BASE_REV].. | 15:50 |
| rif | awilkins: I use "bzr bundle -r 25 ." | 15:52 |
| rif | and it gives me a very short output | 15:53 |
| rif | I am currently on rev 33 | 15:53 |
| awilkins | Use the ".." in your revision specifier | 15:53 |
| awilkins | -r 25.. | 15:53 |
| awilkins | If there's no patch, just a bunch of base64, it's not worked properly | 15:53 |
| rif | it seem to work like this "bzr bundle -r 25.. ." | 15:55 |
| rif | awilkins: thanks | 15:55 |
| awilkins | do a "bzr help revisionspec" as well, for further tasty hints | 15:56 |
| pygi | hey, me again :) | 15:56 |
| * pygi was wondering will 1.2 go into hardy? | 15:57 | |
| jdong | pygi: hope so | 16:33 |
| * awilkins waits for shite-tastic java code to finish working. | 16:34 | |
| jdong | https://edge.launchpad.net/ubuntu/hardy/+source/bzr/1.2~rc1-1 | 16:34 |
| jdong | looks like it already made it | 16:34 |
| * pygi checks | 16:35 | |
| pygi | jdong, ah, right, sorry ... had packages installed from bzr repo for gutsy, so it didnt upgrade | 16:36 |
| jdong | pygi: ah. well bzrtools and bzr-svn haven't followed yet, but I assume they will in short time | 16:36 |
| pygi | ok, and python-central is broken as well xD | 16:36 |
| * awilkins just pulls plugins into his plugins folder | 16:37 | |
| jdong | pygi: yay. | 16:38 |
| jdong | awilkins: as do I, but a lot of people do use the system installed ones | 16:38 |
| * pygi tries to compensate by switching to main server to see if it's fixed there | 16:40 | |
| jdong | pygi: no still not fixed | 16:40 |
| jdong | AFAICT | 16:40 |
| jdong | bug 192992 | 16:40 |
| ubotu | Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992 | 16:40 |
| pygi | joy | 16:41 |
| awilkins | how can you auto-remove files that have been deleted by something else? | 16:41 |
| pygi | jdong, funny thing ... this bug seems to happen in every dev cycle :P | 16:42 |
| jdong | pygi: at least it's not as fun as the dpkg breakage some days back | 16:48 |
| pygi | jdong, I didnt upgrade when that happened xD | 16:48 |
| jdong | lucky :) | 16:48 |
| pygi | haha, yea ... and I can workaround this issue with pycentral xD | 16:48 |
| === gotgenes is now known as gotgene|away | ||
| awilkins | Is hardy much better than Gutsy? | 16:53 |
| === gotgene|away is now known as gotgenes|away | ||
| awilkins | Just wondering whether I should wait for 2008.04 | 16:54 |
| pygi | awilkins, depends on your needs? :) | 16:54 |
| pygi | right now it's broken xD | 16:55 |
| * awilkins prefers non-b0rked software | 16:55 | |
| pygi | even "Crash report" crashes :) | 16:55 |
| jdong | awilkins: I would recommend waiting unless you like living on the edge | 16:55 |
| jdong | awilkins: I run it on my macbook because the hardware support is significantly better, but it does break and have quirks from time to time which can be distracting (i.e. fixing a vim bug in the middle of writing a large paper) or prohibitive | 16:56 |
| * awilkins likes the edge, but not that much, and not on the WifeTop | 16:56 | |
| jdong | i.e. today pycentral is broken, so if you tried to install anything python... | 16:56 |
| LarstiQ | jdong: oh oh, did you get that vim bug where it would segfault in certain cases when you hit o or O in normal mode? | 16:56 |
| pygi | it can be workarounded, but still .... it takes time :) | 16:56 |
| jdong | LarstiQ: yikes no :) | 16:57 |
| pygi | funny bugs xD | 16:57 |
| jdong | pygi: right, that's the thing. it's not impossible to work with, it just isn't all that convenient | 16:57 |
| LarstiQ | jdong: it was horrible | 16:57 |
| jdong | instead I'd recommend running Gutsy and pulling little things from hardy (i.e. updated packages) where appropriate | 16:57 |
| jdong | LarstiQ: i is next to o, too :D | 16:57 |
| === hexmode` is now known as hexmode | ||
| === Toksyury1l is now known as Toksyuryel | ||
| Bilbek | OMG - bazaar is developed with light speed ;) | 17:38 |
| Bilbek | I have a (frequently asked) question - how to ignore white spaces while merging? | 17:40 |
| Bilbek | I could find anything in bazaar FAQ | 17:40 |
| Bilbek | I'm using 1.0.0 | 17:41 |
| Bilbek | erm | 17:41 |
| Bilbek | I couldn't find how to ignore them in FAQ | 17:41 |
| Bilbek | nor in user's guide | 17:41 |
| * dato heh's at 3152.2.2 | 17:53 | |
| jelmer | Bilbek: I don't think there's a way to do that | 18:05 |
| thatch | Bilbek: I haven't seen that feature either... but how would it behave? Is is so one developer can use tabs and another spaces? | 18:07 |
| Bilbek | jelmer: well - I've found out about aliases, so at least diff won't tell me hundreds of changes when there is just one or two | 18:08 |
| Bilbek | thatch: well - sort of... or one developer uses windows and another linux | 18:08 |
| jelmer | Bilbek: That only works if you use an external diff I think | 18:09 |
| === gotgenes|away is now known as gotgenes | ||
| jdong | hmm would a "close enough" merge be implementable | 18:10 |
| jdong | we can call it sloppy/lazy merge :) | 18:10 |
| thatch | I suggest the Windows develop use a real editor that has selectable line endings :) | 18:12 |
| jelmer | yes, it would certainly be possible to implement a merge algorithm that handled whitespace differently | 18:12 |
| Bilbek | ok, so in short nobody really asked for it ;) | 18:14 |
| thatch | jelmer: I forget, does bzr have a notion of "binary" files? | 18:14 |
| jelmer | thatch: no | 18:14 |
| thatch | Bilbek: I started writing a plugin to _display_ diffs with arbitrary options like that in Jul 07, but never finished it. | 18:15 |
| Bilbek | hm... if I define an alias for diff, will merge use that alias to determine changsets? | 18:16 |
| jelmer | Bilbek: no | 18:17 |
| jelmer | Bilbek: You may be able to use --diff3 somehow | 18:18 |
| Bilbek | jelmer: yes, but I can't see how I can set any additional parameters for external diff3 program | 18:19 |
| jelmer | there isn't | 18:20 |
| jelmer | anyway, back later | 18:20 |
| === mrevell is now known as mrevell-dinner | ||
| Bilbek | ok, thank you for information | 18:27 |
| jdong | does bzr have a commit option similar to git's -v? | 18:27 |
| jdong | in that the diff is shown in the editor window for last minute review? | 18:27 |
| jdong | IMO that's quite useful except when the diff is massive | 18:28 |
| beuno | jdong, you can just do bzr diff and it will do it on the working tree | 18:28 |
| luks | bzr commit --show-diff? | 18:28 |
| jdong | luks: does that exist? | 18:29 |
| luks | yes | 18:29 |
| luks | bzr help commit :) | 18:29 |
| jdong | beuno: yes, but how long does your memory last when $EDITOR clears the scrollback? | 18:29 |
| jdong | luks: ok I'm an idiot | 18:29 |
| luks | but I personally prefer "bzr qci" | 18:30 |
| beuno | jdong, right. It's for a super-powered user target who can remember thousands of lines per seconds I guess :p | 18:30 |
| jdong | luks: what's qci? | 18:31 |
| luks | qcommit from the qbzr plugin | 18:31 |
| jdong | oh cool a qt bzr | 18:32 |
| jdong | didn't know that | 18:32 |
| luks | obviously I'm biased, since I wrote it :) | 18:33 |
| luks | but I like things like text-completion in the commit message editor | 18:33 |
| jdong | sweet | 18:33 |
| abentley | thatch: bzr autodetects binary files according to whether there's a NUL in the first 1K | 18:55 |
| mwhudson | can i get bzrtools 1.2 debs anywhere? | 19:19 |
| Peng | The PPA, once someone uploads them? :) | 19:25 |
| mwhudson | hm, guess so | 19:25 |
| mwhudson | i guess i'll give that "poolie" character a poke when he gets up | 19:25 |
| abentley | nevermind the fact that bzrtools 1.2 was out several days before bzr 1.2... | 19:30 |
| ubotu | New bug: #193412 in bzr-webserve "UI: In inventory, files and directories should have different colors?" [Undecided,New] https://launchpad.net/bugs/193412 | 19:50 |
| === jkakar_ is now known as jkakar | ||
| Peng | I care way too much about ConfigObj than is healthy. | 20:23 |
| * Peng wanders off. | 20:23 | |
| Peng | We don't care about IronPython compatibility, right? | 20:24 |
| === cprov is now known as cprov-out | ||
| awilkins | Peng: I care about IronPython compat | 20:35 |
| Peng | Well, do we try to support IronPython? | 20:35 |
| awilkins | Peng: Any operation that is CPU bound should (?) be faster under IronPython ; and bzr pegs the CPU during most operations for me. | 20:36 |
| * Peng wanders off. | 20:36 | |
| Peng | I'm missing General Hospital. :( | 20:36 |
| * Peng wanders off. | 20:36 | |
| * awilkins has a MythTV box and never misses anything unless it crashes | 20:37 | |
| awilkins | Plus it would be awesomely cool to be able to write Powershell providers for bzr | 20:38 |
| * awilkins reveals himself as a nasty smelly windows user | 20:39 | |
| jdong | does bzr have a way to do a "partial checkout" yet? | 20:51 |
| jelmer | jdong: nope, not yet | 20:51 |
| jdong | aww :( that's a shame | 20:51 |
| jdong | I have acquired these directories of large compressible EPS files | 20:52 |
| jdong | would be nice if I could just stash them in packs and only check out a working copy when needed | 20:52 |
| lifeless | jdong: you can; what dimension of 'partial' did you mean ? | 20:56 |
| awilkins | Gah, I'm already hating older source control systems more every day | 21:00 |
| * awilkins grumbles about stupid evil VCS that don't track renamed files | 21:00 | |
| awilkins | Especially when they are polluting my nice bzr trees... | 21:01 |
| lifeless | awilkins: :) | 21:02 |
| * awilkins is currently rebranching / merging his trees | 21:07 | |
| awilkins | If this works I'll be pleased with my comprehension of things | 21:09 |
| Peng | lifeless: Does bzr try to support IronPython? | 21:10 |
| lifeless | awilkins: what vcs are you working with | 21:10 |
| Debolaz | awilkins: bzr should still in theory be able to deal with that though, since it knows the content of the file and can infer a rename has taken place in many cases. | 21:10 |
| lifeless | Peng: no | 21:10 |
| Peng | Ok. | 21:10 |
| lifeless | Peng: if someone sends in tasteful patches to improve things there - fine. But we don't test or QA against it. | 21:11 |
| awilkins | lifeless: MKS Source Integrity | 21:13 |
| lifeless | awilkins: oooooh thats a beast | 21:13 |
| Peng | Hm. | 21:13 |
| awilkins | Yeah, it's MD hash is "666" | 21:13 |
| lifeless | awilkins: I used to work at a place used that | 21:14 |
| awilkins | Peng: A start would be running bzr selftest in both CPython and IronPython | 21:14 |
| awilkins | Peng: I keep meaning to do it. | 21:15 |
| awilkins | Peng: IronPython 1.1 or 2.0 (alpha 8)? | 21:15 |
| Peng | Err. | 21:18 |
| Peng | I'm just messing around with ConfigObj for fun. | 21:18 |
| Peng | It has a try...except around an import that isn't supported in IronPython and I was wondering if I could remove the try...except. | 21:18 |
| Peng | Anyway, again, I'm just doing it for fun. I won't submit that patch. | 21:19 |
| dato | Peng: what isn't supported by IronPython, you say? | 21:21 |
| Peng | The compiler module. | 21:22 |
| Peng | I didn't confirm it, but that's what ConfigObj says./ | 21:22 |
| dato | ah, ok. | 21:22 |
| jdong | lifeless: ack sorry lost focus... partial as in I want to remove *.eps (or maybe path/images for that matter) from my working copy, and commit doesn't think I've deleted them and remove it... and it'd be nice if update didn't recreate them | 21:26 |
| seb128 | hi | 21:27 |
| seb128 | how do I tell what log format bzr accepts? | 21:27 |
| seb128 | --log-format=ARG Use specified log format. | 21:27 |
| seb128 | not really useful | 21:27 |
| dato | seb128: `bzr help log` | 21:27 |
| lifeless | Peng: if the module isn't supported, removing the try:except: will make loading fail :) | 21:27 |
| seb128 | dato: where do you I got the line I copied? | 21:28 |
| dato | seb128: and three lines below it | 21:28 |
| seb128 | dato: where do you thing I got the line I copied? | 21:28 |
| lifeless | jdong: no, we don't support that at the moment, sorry. | 21:28 |
| Peng | lifeless: Well yeah. But do we care if it fails on IronPython? | 21:28 |
| seb128 | dato: http://paste.ubuntu.com/4788/ | 21:28 |
| seb128 | dato: where? | 21:28 |
| lifeless | Peng: but why do you want to remove the try:except: | 21:28 |
| dato | --line Log format with one line per revision | 21:29 |
| dato | --long Detailed log format | 21:29 |
| dato | --short Moderately short log format | 21:29 |
| * dato shakes his head. | 21:29 | |
| seb128 | so --log-format=--line? | 21:29 |
| seb128 | tha's weird syntax and help description | 21:29 |
| elmo | seb128: no, --line or --log-format=line | 21:29 |
| dato | --log-format=line or --line | 21:29 |
| lifeless | seb128: --line, or --log-format=line | 21:29 |
| elmo | it's spectactulary poor help UI | 21:29 |
| seb128 | ok | 21:29 |
| seb128 | jockey is using a =gnu | 21:29 |
| seb128 | has that being deprecated or is pitti getting that somewhere else? | 21:30 |
| * dato would have never introduced --line, and always forced --log=line | 21:30 | |
| seb128 | I'm trying to be nice and update bzr rather than doing apt-get source, change, upload | 21:30 |
| seb128 | but bzr is not nice to me there ;-) | 21:30 |
| dato | seb128: gnu probably is a plugin | 21:30 |
| dato | s/probably//, even | 21:30 |
| lifeless | http://bazaar-vcs.org/BzrPlugins | 21:31 |
| lifeless | gnulog on there | 21:31 |
| visit0r | is there a way for sending commit emails for the remote branch changes without installing the commit mail plugin to every client? | 21:31 |
| seb128 | ok, I'll just do apt-get source, update, upload | 21:31 |
| seb128 | and explain to pitti tomorrow why I don't like packages maintained in bzr ;-) | 21:32 |
| seb128 | thanks guys | 21:32 |
| lifeless | seb128: he should document his practices more :) | 21:35 |
| lifeless | seb128: I'm not sure why you need gnulog to update the tree though | 21:35 |
| seb128 | we should just have one common interface to change packages | 21:35 |
| seb128 | because he doesn't maintain a ChangeLog but generates one when doing an upload | 21:36 |
| seb128 | and he's using this gnu format when doing that apparently | 21:36 |
| lifeless | seb128: indeed. But we don't - even with 'regular' trees there is much variation | 21:36 |
| lifeless | visit0r: yes, there is a script that checks the branch and sends mail | 21:36 |
| dato | visit0r: http://launchpad.net/bzr-hookless-email | 21:38 |
| dato | visit0r: you'd run that on the server as a daemon, or from cron | 21:38 |
| visit0r | sounds exactly what we need, thanks. did you get that wortkt? | 21:38 |
| dato | visit0r: wortkt->working? | 21:39 |
| dato | visit0r: anyway I use it regularly, and know that several other people do as well. | 21:40 |
| visit0r | yep a collegue of mine, we are transforming from svn to bzr and trying to get things together | 21:40 |
| dato | visit0r: ping me if you get any trouble with the script | 21:40 |
| visit0r | dato: we will, thanks a lot | 21:40 |
| * dato bbl | 21:41 | |
| visit0r | (wortkt is a nick) | 21:43 |
| schierbeck | wow, bzr-avahi kicks ass! | 21:59 |
| jelmer | hey Daniel | 22:00 |
| schierbeck | hi jelmer :) | 22:00 |
| lifeless | spiv: ping | 22:14 |
| poolie | good morning | 22:20 |
| mwhudson | hi poolie | 22:21 |
| poolie | hi | 22:21 |
| mwhudson | poolie: can you make bzrtools 1.2 debs? | 22:21 |
| poolie | that's the first thing for me for today | 22:21 |
| mwhudson | cool :) | 22:21 |
| spiv | lifeless: pong | 22:44 |
| lifeless | spiv: ping-pong on the patch again :) | 22:45 |
| spiv | lifeless: ping-pong-punged | 22:47 |
| === jamesh__ is now known as jamesh | ||
| schierbeck | hi jamesh, nice work on bzr-avahi! | 23:10 |
| schierbeck | just tried it out | 23:10 |
| jamesh | schierbeck: thanks | 23:11 |
| schierbeck | jamesh: is it possible to have a server running, serving only explicitly advertised branches? | 23:12 |
| schierbeck | other than having --directory point to somewhere empty | 23:12 |
| jamesh | schierbeck: I don't think so (although I haven't dug into the bzr server code that much) | 23:12 |
| schierbeck | jamesh: i'm just thinking it would be cool to simply have a config file with the paths to the branches you wish to advertise, and just launching a special server | 23:13 |
| schierbeck | of course, i could just write a script, but it would be cool | 23:14 |
| jamesh | schierbeck: it might be possible with a custom transport that collates a bunch of branches and limits access to others | 23:16 |
| schierbeck | yup | 23:16 |
| jamesh | schierbeck: you can also run multiple servers if you want to restrict what you are sharing too | 23:17 |
| jamesh | schierbeck: passing --port=0 to "bzr serve" will pick a random port to listen on | 23:17 |
| schierbeck | i guess so | 23:17 |
| schierbeck | right now i'm trying using "bzr serve --directory=/dev/null" | 23:17 |
| jamesh | what would you expect that to do? | 23:18 |
| schierbeck | and then just manually advertising the branches i want to share | 23:18 |
| speakman | hi ppl! | 23:19 |
| jamesh | schierbeck: to advertise the branch, you need to both turn on advertising with "bzr advertise" and run a server that covers the branch | 23:19 |
| schierbeck | jamesh: yeah, just found out. that's a bitch. | 23:19 |
| * speakman wants to make a "init-repo" WITH tree, but even with --tree there's no working tree at the remote place. | 23:19 | |
| schierbeck | i was hoping for an opt-in model | 23:19 |
| bob2 | schierbeck: "no working tree" after push? | 23:20 |
| schierbeck | huh? | 23:20 |
| bob2 | er, speakman | 23:20 |
| schierbeck | :) | 23:20 |
| lifeless | schierbeck: we don't ever create trees remotely | 23:20 |
| lifeless | schierbeck: trees are filesystem objects | 23:21 |
| schierbeck | hey! | 23:21 |
| schierbeck | stop it! | 23:21 |
| lifeless | oh. | 23:21 |
| schierbeck | you guys want speakman | 23:21 |
| lifeless | yup sorry | 23:21 |
| schierbeck | hehe, np :) | 23:21 |
| speakman | no working tree after push... | 23:21 |
| speakman | :) | 23:21 |
| lifeless | s/schierback/speakman/gy | 23:21 |
| speakman | ;) | 23:21 |
| schierbeck | jamesh: i guess running multiple servers is the solution, then | 23:21 |
| speakman | I need a tree | 23:21 |
| awilkins | so open a shell on the server and do bzr update | 23:22 |
| schierbeck | and with avahi, you don't need to communicate the port number, so it's not that much harder | 23:22 |
| lifeless | schierbeck: server hooks should tell anything listening about each server | 23:22 |
| speakman | the server havn't got either python nor bzr... | 23:22 |
| awilkins | You can't make a tree from a push, because you can't depend on which push method has been used. | 23:22 |
| jamesh | schierbeck: bzr-avahi should handle non-default ports for the server just fine, so running multiple servers should work okay | 23:22 |
| lifeless | schierbeck: I wouldn't be surprised if it just works; certainly the bzr-dbus and lan-notify plugin will just-work with multiple servers | 23:22 |
| jamesh | schierbeck: although it might get confused if you share the same branch twice | 23:23 |
| schierbeck | cool | 23:23 |
| jamesh | due to naming conflicts | 23:23 |
| bob2 | speakman: maybe rsync'ing everything but .bzr would be an ok workaround? | 23:23 |
| schierbeck | yeah, but all my branches are neatly organized, so it should be fine | 23:23 |
| jamesh | likely one will serve the branch as "foo" and the other as "foo #2" | 23:23 |
| speakman | bob2: no, it has to go with each commit.. :/ | 23:23 |
| schierbeck | jamesh: ohh, you mean aliases | 23:23 |
| schierbeck | yeah, i'm currently namespacing them | 23:24 |
| bob2 | speakman: rsync from a post-commit hook ;) | 23:24 |
| speakman | why can't I just have a working tree at remote? | 23:24 |
| jamesh | schierbeck: no. I mean mDNS name conflict resolution | 23:24 |
| schierbeck | like "bzr-gtk-trunk" | 23:24 |
| schierbeck | jamesh: is that the name you provide with --name? | 23:24 |
| jamesh | schierbeck: if you run two servers that share the same branch, they can't both share it under the same name | 23:24 |
| jamesh | schierbeck: yes. | 23:24 |
| schierbeck | then we're on the same page | 23:24 |
| schierbeck | s/alias/name/g | 23:25 |
| speakman | why is there a argument "--no-tree" when I even CANT have a tree? :D | 23:25 |
| jamesh | schierbeck: if there is a name conflict, the server automatically renames the branch | 23:25 |
| awilkins | speakman: You can have a tree, you just don't get trees from pushing | 23:25 |
| schierbeck | jamesh: i just got a lot of branches named "trunk", so namespacing is required | 23:25 |
| speakman | awilkins: ok, not by commit either then? | 23:25 |
| awilkins | speakman: It's not implemented because it's so much less efficient than having bzr update the tree from the packs | 23:25 |
| schierbeck | jamesh: what characters are illegal in such a name? | 23:26 |
| awilkins | speakman: You have to havea tree to commit.... | 23:26 |
| jamesh | schierbeck: not sure. | 23:26 |
| schierbeck | i'll just run a few through, see if they work | 23:26 |
| awilkins | speakman: If you can't install bzr on your server but you need a tree there, rsync or another file transfer method is your best bet. | 23:27 |
| Peng | push-and-update plugin? | 23:27 |
| Peng | Oh, if bzr isn't on the server, never mind. | 23:27 |
| awilkins | push-and-update requires bzr on the server | 23:27 |
| speakman | okay, what I'm look for is a way to version-control a website, and for each commit all changes are visible in the repo working tree via apache. | 23:27 |
| Peng | Yeah. I just came into the conversation and didn't know that part. | 23:27 |
| * Peng wanders off. | 23:28 | |
| speakman | is there a better way to do that? | 23:28 |
| awilkins | speakman: Without bzr on the server, file transfer is just as effcient anyway ; plus you won't have to transfer the repository | 23:28 |
| schierbeck | jamesh: colon works just fine, cool. now i can name the branch "bzr-gtk:trunk" | 23:28 |
| speakman | awilkins: but we WANT our repo on the server since we're using it as a bzr repor too! :) | 23:28 |
| jamesh | schierbeck: file bugs if you find problems | 23:29 |
| schierbeck | sure | 23:29 |
| awilkins | speakman: You won't get the best performance without bzr on the server anyway ; bzr or bzr+ssh is the best speed. | 23:29 |
| awilkins | speakman: And you won't be getting a tree on the server from the repo without bzr | 23:30 |
| speakman | i see... | 23:30 |
| speakman | the server is running freebsd I'm a Linux guy.. :/ | 23:30 |
| awilkins | speakman: File transfer, as said, is just as effcicient as implementing exactly the same thing in bzr. | 23:30 |
| speakman | awilkins: hm, 66% is using Windows, so it won't be an easy task to automate... | 23:31 |
| speakman | i will consider insatlling bzr on the server though... | 23:32 |
| awilkins | speakman: I'd probably rig the tree-transfer from a single machine to which you push | 23:33 |
| awilkins | speakman: And write a script that did the push, followed by a ssh remote call to the rsync script | 23:33 |
| speakman | maybe a make a cronjob to a "bzr update" on each 5 min or so :) | 23:36 |
| lifeless | awilkins: that script exists; its called 'bzr-push-and-update plugin' | 23:38 |
| jdong | are obsolete-packs safe to delete? | 23:38 |
| speakman | anyone know how to install it on freebsd? | 23:39 |
| lifeless | jdong: bzr will do so itself | 23:39 |
| jdong | lifeless: really? | 23:39 |
| lifeless | jdong: yes | 23:39 |
| lifeless | jdong: the directory must exist | 23:39 |
| jdong | lifeless: during what operation? | 23:39 |
| lifeless | jdong: during commit/pull/merge/push | 23:39 |
| bob2 | the operation /after/ theey become obsolete, right? | 23:40 |
| jdong | lifeless: I just committed and obsolete-packs still contains 4.6MB of data? | 23:40 |
| jdong | bzr 1.2, on bound branch, if that makes any difference | 23:41 |
| lifeless | jdong: thats fine; it will get gc'd automatically. It doesn't make push or pull slower. | 23:41 |
| lifeless | bob2: when we do latency-management packing, we clean obsolete-packs before we put newly obsoleted packs into it. | 23:41 |
| jdong | lifeless: ah, ok, that's cool. But if I am ridiculously tight on space, bzr won't get mad if I remove all the files in there, will it? | 23:42 |
| jdong | (some bad little boy is guilty of borderline-exceeding his quota :D) | 23:42 |
| lifeless | jdong: you can manually trim if you need to; bzr will (rarely) use up to twice the repository size. | 23:42 |
| lifeless | jdong: one of those standard time vs space tradeoffs :) | 23:42 |
| jdong | lifeless: understood, and I agree with the decision :) | 23:42 |
| jdong | it's at 20% of the repository size currently, but 20% is significant on this particular storage location :) | 23:43 |
| jdong | and I can't say enough how much I'm enjoying bzr's performance these days | 23:44 |
| lifeless | jdong: right, so what I'm saying is that you need enough working space for it to peak at 100% | 23:44 |
| lifeless | actually in theory it could peak at 200% additional, when you consider pending uploads. | 23:44 |
| lifeless | but I think thats extremely difficult to trigger. | 23:45 |
| jdong | does the garbage collect also take care of stale uploaded packs or is that more of my job? :) | 23:45 |
| lifeless | no; theres no safe way to that automatically unfortunately; ctrl-C will cleanup stale uploads that that process created. | 23:46 |
| jdong | right, I think most of my stale issues have come out of broken dumb-protocol pushes | 23:46 |
| jdong | over a lossy network | 23:46 |
| lifeless | yeah network lossage sucks | 23:46 |
| lifeless | problem is that a new bzr invocation can't tell that its not a concurrent push | 23:47 |
| lifeless | if you know that no bzr's are pushing, you can clean up that dir safely. | 23:47 |
| jdong | right, I'll just do it manually, since it's really one of those odd rare cases | 23:47 |
| jdong | I just wanted to make sure those two locations were safe to poke by hand ;-) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!