[03:49] <lifeless> poolie: I did review your lp_registration patch; it doesn't seem to be in bzr.dev ?
[03:53] <poolie> lifeless, i may not have merged back 1.2, i'll check
[04:40] <lifeless> spiv: ping
[04:55] <spiv> lifeless: pong
[04:55] <lifeless> I've just sent an updated patch for external ref support
[04:56] <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:57] <spiv> I'll take a look.
[04:59] <lifeless> spiv: thanks
[05:25] <lifeless> done for de day; ciao
[05:39] <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:40] <thumper> bob2: your issues, or raising someone elses?
[05:43] <bob2> ted t'so's
[06:08] <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:09] <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:10] <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:11] <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:12] <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.
[08:27] <johnny_> where are the bzr 1.2 release notes?
[08:40] <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:41] <jabr> linked from the link "full changelog"
[08:41] <jabr> :-)
[08:42] <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:43] <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:44] <johnny_> people always found that confusing in monotone for sure
[08:46] <johnny_> they use sqlite for the archive storage
[09:35] <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:36] <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:37] <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:38] <appcine> now I have to: commit, push, ctrl-c (like 30 times), go to server, break-lock .. push again etc .. until it works
[09:41] <appcine> and I hopen I'm alone with this, because I've recommended bzr to A LOT of people :)
[09:52] <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:53] <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:54] <appcine> it's not very flaky :/
[09:54] <awilkins> How big are your branches?
[09:58] <appcine> 120 MB or so, including a lot of media files
[09:59] <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.
[10:00] <awilkins> On the other hand, 120MB is not too much, I have a partially converted repo with over 900MB of packs in it.
[10:01] <appcine> and it's soo weird that it works 1/5
[10:01] <appcine> almost consistently
[10:02] <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:03] <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:04] <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:05] <awilkins> That will at least eliminate one variable from consideration ; you're going to have to be a detective to isolate the cause.
[10:09] <appcine> hehe yeah
[10:10] <appcine> plugging cable in
[10:10] <sttng359> hello
[10:11] <sttng359> I am curious if bzr can/will preserve file permissions/ownership in it's database.
[10:12] <appcine> same over cable
[10:13] <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:14] <appcine> anything else I can try?
[10:14] <appcine> It's nice with software that you want to work
[10:15] <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:17] <luks> sttng359: no, it can't (by design)
[10:17] <appcine> https://lists.ubuntu.com/archives/bazaar/2007q4/035930.html
[10:18] <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:19] <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:20] <sttng359> also, something that could version across hosts would be nice, such as pushing changes for nss_ldap.
[10:21] <sttng359> I just saw a blog of someone mentioning using Bazaar on /etc.
[10:23] <dato> sttng359: there is metastore and etckeeper
[10:24] <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:25] <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:26] <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:27] <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:28] <johnny> i don't think monotone will every be a big thing tho...all the other vcs will just mine it for information :)
[10:29] <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:30] <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:31] <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:34] <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:35] <awilkins> Or at least, a reported / suspected bug
[10:35] <appcine> I really wanted to solve this..
[10:36] <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:37] <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:38] <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:41] <appcine> But I really haveto go tow ork .. it's lunch already and I'be been trying to solve this all morning :)
[10:42] <awilkins> Fair enough
[10:42] <awilkins> Might I recommend SVk for disconnected operation from an SVN repo?
[10:43] <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:44] <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:45] <awilkins> A merge bug is what lead me to ditch SVK
[10:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[11:00] <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:01] <luks> appcine: "bzr: ERROR: no such option: --force"
[11:01] <luks> awilkins: same error if they are ignored
[11:01] <luks> appcine: err
[11:02] <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:03] <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:04] <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:05] <appcine> and the lightweight checkout is something you do from the server?
[11:05] <awilkins> Yes
[11:06] <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:07] <awilkins> From laptop you bzr push bzr+ssh//server/home/me/mywebappdeploymentbranch
[11:08] <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:09] <appcine> Ah, ok ..
[11:09] <appcine> Let me try that
[11:10] <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:13] <awilkins> But you could splat together a swift deploy script that did the push and an ssh remote bzr update /var/www/webapp
[11:14] <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:16] <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:17] <appcine> And how would that work for local development?
[11:17] <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:19]  * awilkins is on windows and cannot readily test this theory :-)
[11:23] <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:24] <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:25] <appcine> awilkins: And it seems like my problem has been resolved
[11:27] <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:29] <awilkins> Those error message could be more helpful.... were you committing on the server?
[11:31] <appcine> comitting, pushing on client, update on server
[11:33] <appcine> Ok, situation under control. Thanks a lot for the help
[11:34] <johnny> hmm.. got loggerhead nearly working now.. something is odd about the public branch url tho..
[11:46] <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
[12:02] <jelmer> awilkins: Are you using 0.4.7 or the 0.4 branch?
[12:11] <wortkt> does anyone know is there a hook or something like that to catch push or commit on the remote repository side?
[12:12] <wortkt> like when you do bzr push bzr+ssh://remoterep.server/repo
[12:13] <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:14] <wortkt> ok
[12:31] <ubotu> New bug: #193250 in bzr "memory error when attempting to copy a branch" [Undecided,New] https://launchpad.net/bugs/193250
[12:32] <grutte_pier> has anyone ever tried to set up a repository/branch accessible over http+access permissions as set in an .htaccess file?
[12:33] <grutte_pier> basically: got bzr to handle http code 401 by means of a plugin/experimental path?
[12:41] <grutte_pier> patch*
[12:43] <awilkins> jelmer: 0.4 branch
[12:44] <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:46]  * 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:52] <awilkins> I think the reason I moved forward was https://bugs.launchpad.net/bugs/191572
[12:54] <awilkins> ... which is where I am now.
[13:05] <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:07] <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:08] <awilkins> I didn't notice the server even eating 1% of the cpu on the occasions I checked.
[13:09] <awilkins> Oh, by the way, since there are no API changes for 1.2, is bzr-svn compatible ?
[13:10] <jelmer> awilkins: haven't checked yet
[13:12] <awilkins> jelmer: Which bit of libsvn has that humungous memory leak?
[13:12] <jelmer> awilkins: the python bindings themselve
[13:15] <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:16] <jelmer> awilkins: there are several other leaks that are only fixed in 1.5 I think
[13:17] <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:18] <awilkins> I should be using the windows builds from http://d5190871.u44.websitesource.net/bzr/
[13:18]  * awilkins does some checking
[13:20] <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:21] <awilkins> I'm just wondering if the size of the tree is accentuating some of the memleaks.
[13:22] <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:23] <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:24] <awilkins> jelmer: Nope, but I shall try an export of this tree and branch it.
[13:58] <awilkins> jelmer: Ok, I've done that now ; it tops out at 190MB to either commit or branch this tree (via the filesystem).
[13:59] <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
[14:00] <awilkins> I'd have to convert the repository to bzr via other means if I wanted all those revisions.
[14:02] <awilkins> I could try sv2bzr I suppose
[14:03] <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:04] <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:05] <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:13] <jelmer> awilkins: you can also try the 'bzr pull -r...' trick to work around the memory errors
[14:14] <awilkins> jelmer: I was just resuming when it crashed, which seems to work well enough until it gets to that KeyError exception
[14:15] <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:16] <jelmer> awilkins: That bug is unrelated to bzr-svn, it's a bzr bug.
[14:16] <awilkins> jelmer: Rock >> awilkins << hard place
[14:17] <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:20] <awilkins> jelmer: reading 191731, I may just install 1.2 and try that
[14:38] <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:39]  * 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:40] <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:41] <jelmer> not as far as I'm aware
[14:41] <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:42] <awilkins> I had a look at the log, they don't seem to correspond to revisions with large deltas
[14:43] <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:44] <awilkins> Yes, I did notice that committing large files to my export/branch test ate memory for the whole file
[14:45] <awilkins> Bah, the ceiling went from 1.48 to 1.61
[14:45] <awilkins> s/ceiling/floor/
[14:48] <awilkins> It's managed over 700/9243 revisions so far....
[14:48] <awilkins> Doing much better on 1.2 that 1.1 did
[15:09]  * awilkins tries the -r 100 trick :-)
[15:10] <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:13] <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:14] <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:15] <awilkins> Hg doesn't merge?
[15:15] <luks> hg uses "merge tools"
[15:16] <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:17] <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:18] <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:19] <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:20] <abentley> And doesn't track directory renames, because it doesn't track directories at all.
[15:21] <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:22] <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:23] <awilkins> Too close to the "metal" of VFS
[15:24] <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:25] <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:28] <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:29] <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:30] <mruiz> awilkins, I'm using bzr 1.2~rc1-1
[15:30] <mruiz> bzr: ERROR: Couldn't import bzrlib and dependencies.
[15:31] <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:32] <luks> how did you install it?
[15:33] <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:34] <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:35] <awilkins> There ought to just be a Tortoise<D?VCS> that worked with everything
[15:35] <theSoftMan> hello luks... that so unlucky :-)
[15:36] <awilkins> They should merge all the various Tortoises and have a backend of plugins
[15:40] <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:41] <jdong> awilkins: does that make some sort of giant land turtle?
[15:41] <jdong> rif: bzr bundle too
[15:42] <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:43] <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:45] <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:46] <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:47] <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:49] <awilkins> rif: is your current branch a branch of "that one"?
[15:49] <rif> yes
[15:50] <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:52] <rif> awilkins: I use "bzr bundle -r 25 ."
[15:53] <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:55] <rif> it seem to work like this "bzr bundle -r 25.. ."
[15:55] <rif> awilkins: thanks
[15:56] <awilkins> do a "bzr help revisionspec" as well, for further tasty hints
[15:56] <pygi> hey, me again :)
[15:57]  * pygi was wondering will 1.2 go into hardy?
[16:33] <jdong> pygi: hope so
[16:34]  * 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:35]  * pygi checks
[16:36] <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:37]  * awilkins just pulls plugins into his plugins folder
[16:38] <jdong> pygi: yay.
[16:38] <jdong> awilkins: as do I, but a lot of people do use the system installed ones
[16:40]  * 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:41] <pygi> joy
[16:41] <awilkins> how can you auto-remove files that have been deleted by something else?
[16:42] <pygi> jdong, funny thing ... this bug seems to happen in every dev cycle :P
[16:48] <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:53] <awilkins> Is hardy much better than Gutsy?
[16:54] <awilkins> Just wondering whether I should wait for 2008.04
[16:54] <pygi> awilkins, depends on your needs? :)
[16:55] <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:56] <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:57] <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
[17:38] <Bilbek> OMG - bazaar is developed with light speed ;)
[17:40] <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:41] <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:53]  * dato heh's at 3152.2.2
[18:05] <jelmer> Bilbek: I don't think there's a way to do that
[18:07] <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:08] <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:09] <jelmer> Bilbek: That only works if you use an external diff I think
[18:10] <jdong> hmm would a "close enough" merge be implementable
[18:10] <jdong> we can call it sloppy/lazy merge :)
[18:12] <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:14] <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:15] <thatch> Bilbek: I started writing a plugin to _display_ diffs with arbitrary options like that in Jul 07, but never finished it.
[18:16] <Bilbek> hm... if I define an alias for diff, will merge use that alias to determine changsets?
[18:17] <jelmer> Bilbek: no
[18:18] <jelmer> Bilbek: You may be able to use --diff3 somehow
[18:19] <Bilbek> jelmer: yes, but I can't see how I can set any additional parameters for external diff3 program
[18:20] <jelmer> there isn't
[18:20] <jelmer> anyway, back later
[18:27] <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:28] <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:29] <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:30] <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:31] <jdong> luks: what's qci?
[18:31] <luks> qcommit from the qbzr plugin
[18:32] <jdong> oh cool a qt bzr
[18:32] <jdong> didn't know that
[18:33] <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:55] <abentley> thatch: bzr autodetects binary files according to whether there's a NUL in the first 1K
[19:19] <mwhudson> can i get bzrtools 1.2 debs anywhere?
[19:25] <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:30] <abentley> nevermind the fact that bzrtools 1.2 was out several days before bzr 1.2...
[19:50] <ubotu> New bug: #193412 in bzr-webserve "UI: In inventory, files and directories should have different colors?" [Undecided,New] https://launchpad.net/bugs/193412
[20:23] <Peng> I care way too much about ConfigObj than is healthy.
[20:23]  * Peng wanders off.
[20:24] <Peng> We don't care about IronPython compatibility, right?
[20:35] <awilkins> Peng: I care about IronPython compat
[20:35] <Peng> Well, do we try to support IronPython?
[20:36] <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:37]  * awilkins has a MythTV box and never misses anything unless it crashes
[20:38] <awilkins> Plus it would be awesomely cool to be able to write Powershell providers for bzr
[20:39]  * awilkins reveals himself as a nasty smelly windows user
[20:51] <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:52] <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:56] <lifeless> jdong: you can; what dimension of 'partial' did you mean  ?
[21:00] <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:01] <awilkins> Especially when they are polluting my nice bzr trees...
[21:02] <lifeless> awilkins: :)
[21:07]  * awilkins is currently rebranching / merging his trees
[21:09] <awilkins> If this works I'll be pleased with my comprehension of things
[21:10] <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:11] <lifeless> Peng: if someone sends in tasteful patches to improve things there - fine. But we don't test or QA against it.
[21:13] <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:14] <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:15] <awilkins> Peng: I keep meaning to do it.
[21:15] <awilkins> Peng: IronPython 1.1 or 2.0 (alpha 8)?
[21:18] <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:19] <Peng> Anyway, again, I'm just doing it for fun. I won't submit that patch.
[21:21] <dato> Peng: what isn't supported by IronPython, you say?
[21:22] <Peng> The compiler module.
[21:22] <Peng> I didn't confirm it, but that's what ConfigObj says./
[21:22] <dato> ah, ok.
[21:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <seb128> and explain to pitti tomorrow why I don't like packages maintained in bzr ;-)
[21:32] <seb128> thanks guys
[21:35] <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:36] <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:38] <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:39] <dato> visit0r: wortkt->working?
[21:40] <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:41]  * dato bbl
[21:43] <visit0r> (wortkt is a nick)
[21:59] <schierbeck> wow, bzr-avahi kicks ass!
[22:00] <jelmer> hey Daniel
[22:00] <schierbeck> hi jelmer :)
[22:14] <lifeless> spiv: ping
[22:20] <poolie> good morning
[22:21] <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:44] <spiv> lifeless: pong
[22:45] <lifeless> spiv: ping-pong on the patch again :)
[22:47] <spiv> lifeless: ping-pong-punged
[23:10] <schierbeck> hi jamesh, nice work on bzr-avahi!
[23:10] <schierbeck> just tried it out
[23:11] <jamesh> schierbeck: thanks
[23:12] <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:13] <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:14] <schierbeck> of course, i could just write a script, but it would be cool
[23:16] <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:17] <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:18] <jamesh> what would you expect that to do?
[23:18] <schierbeck> and then just manually advertising the branches i want to share
[23:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28]  * 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:29] <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:30] <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:31] <speakman> awilkins: hm, 66% is using Windows, so it won't be an easy task to automate...
[23:32] <speakman> i will consider insatlling bzr on the server though...
[23:33] <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:36] <speakman> maybe a make a cronjob to a "bzr update" on each 5 min or so :)
[23:38] <lifeless> awilkins: that script exists; its called 'bzr-push-and-update plugin'
[23:38] <jdong> are obsolete-packs safe to delete?
[23:39] <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:40] <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:41] <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:42] <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:43] <jdong> it's at 20% of the repository size currently, but 20% is significant on this particular storage location :)
[23:44] <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:45] <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:46] <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:47] <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:48] <jdong> I just wanted to make sure those two locations were safe to poke by hand ;-)