#bzr 2008-02-18
<jelmer> lifeless: shouldn't 192743 be reassigned to bzr?
<lifeless> jelmer: not sure; may want to wontfix it
<ubotu> New bug: #162970 in trac-bzr "bzr not reconized" [Undecided,Incomplete] https://launchpad.net/bugs/162970
<lifeless> yay @ first stacked test passing.
<lifeless> lunch
<jelmer> lifeless: congrats!
<ubotu> New bug: #192803 in bzr-svn "Presence of bzr-svn plugin causes BzrDir.find_branches to leak memory" [Undecided,New] https://launchpad.net/bugs/192803
<mwhudson> say, does anyone want to explain InterRepository._walk_to_common_revisions() to me?
<lifeless> mwhudson: sure
<mwhudson> lifeless: specifically i want to understand when it raises errors.NoSuchRevision
<lifeless> mwhudson: it starts from a set of revisions and walks back the graph until it has found all the common points
<mwhudson> (i'm trying to diagnose the InstallFailed oopses we're seeing, at least a little bit)
<lifeless> mwhudson: NoSuchRevision is raised when you ask for some revision R which is not in the target, nor in the source.
<mwhudson> hmm
<mwhudson> but here, revision_ids == [target.last_revision()] i think
<lifeless> right
<mwhudson> so walking out from there to something that is not in the target seems a bit eccentric
<lifeless> not true
<mwhudson> ok
<lifeless> target_branch.last_revision()==R does not always imply target_branch.repository.has_revision(R)
<lifeless> its invalid for it to fail to imply it
<mwhudson> i mean, there could be ghosts, but that doesn't seem super-likely here
<lifeless> _walk_to_common is used when we're not looking for ghosts; but adjacent and absent revisions are collected
<mwhudson> lifeless: sorry i don't understand your last line there
<lifeless> so we get local ghosts but not deep ghosts, if that makes sense
<lifeless> mwhudson: race conditions, quote the line
 * mwhudson thinks
<lifeless> I have to switch battery sooin
<mwhudson> lifeless: let me worry about another confusing problem for a bit then, can i bug you in 10-20 minutes?
<lifeless> sure
 * lifeless does the suspend-resume dance
<mwhudson> ta
<lifeless> back
<lifeless> mwhudson: -> code; will look back in every test or so
<mwhudson> lifeless: so, i would like to understand "target_branch.last_revision()==R does not always imply target_branch.repository.has_revision(R)"
<lifeless> mwhudson: bzr init-repo foo
<lifeless> mwhudson: bzr init-repo bar
<lifeless> bzr init foo/branch
<lifeless> bzr commit -m 'f' foo/branch
<lifeless> cp -a foo/branch bar/branch
<mwhudson> lifeless: oh right
<mwhudson> lifeless: that shouldn't have happened on the supermirror though :)
<lifeless> mwhudson: who knows what has happened
<lifeless> mwhudson: but this is why the bzr code does what it does
<lifeless> mwhudson: what problem are thou incurring?
<mwhudson> lifeless: occasionally the upload branch puller craps out with one of these exceptions
<lifeless> this is for importd?
<mwhudson> (raising InstallFailed from InterPackFetcher)
<mwhudson> lifeless: no
<lifeless> hosted branches?
<mwhudson> lifeless: yes
<lifeless> does it recur on the same branch?
<lifeless> I saw a hosted branch the other day with this problem
<mwhudson> no
<lifeless> someone had managed to set a last_revision_id not in the branch's repository
<lifeless> and it was (naturally) not mirroring; and other users (group branch) couldn't merge from the hosted side either
<lifeless> is it possibly a bug in the sftp or smart server glue ?
<lifeless> I'm assuming bzr is perfect
<BasicOSX> hi here too
<mwhudson> lifeless: i was wondering that, but it seems a bit unlikely
<lifeless> hi BasicOSX
<lifeless> mwhudson: that bzr is perfect?
<mwhudson> lifeless: no, that a bug in the smart server glue would show up in this way
<lifeless> mwhudson: I suggest that you change the puller so that the next time this occurs a cp -R of the branch is made
<lifeless> mwhudson: (of the source branch)
<mwhudson> yeah, i guess that makes sense
<mwhudson> jml: hello
<jml> mwhudson: hi
<mwhudson> jml: what do you think of lifeless's idea above?
<jml> mwhudson: I think it will definitely help us figure out what's going on and that's it's kind of yucky.
<jml> but I can't think of anything better.
<mwhudson> right
* beuno changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! w00t! | http://bazaar-vcs.org/releases/src/bzr-1.2.tar.gz
 * beuno goes to bed now
<Peng_> Oh, cool. 1.2.
<ubotu> New bug: #192859 in bzr "AttributeError on parent.children in add when adding a symlink" [Undecided,New] https://launchpad.net/bugs/192859
<appcine> hi! just transitioned to bzr from svn and I'm experiencing some problems. whenever I push an update to the server, there's a 70 % chance that the push just hangs and nothing happens. If i ctrl-c it, I get a SFTPError: Garbage package received.
<appcine> Anything I can do on my end?
<appcine> I mean, I get this almost ALL the time
<appcine> but sftping in works fine every time
<appcine> Using bzr+ssh seems to work better, but is there a way to store BZR_REMOTE_PATH for just one project?
<spiv> appcine: yes, you can set bzr_remote_path in your ~/.bazaar/locations.conf
<spiv> appcine: e.g, I have:
<spiv> [bzr+ssh://host/]
<spiv> bzr_remote_path=/home/andrew/bzr.dev/bzr
<spiv> in mine.  (where "host" is something different, obviously...)
<appcine> spiv: Ah, sweet. Thanks :)
<appcine> Hmm, using bzr+ssh really didn't solve my woes. It's terrible slow to send a two-line change over two files. It just stalls on 0/0 (the dash that's spinning isn't .. spinning)
<appcine> ssh/sftp works fine though
<pygi> hey folks
<pygi> will anyone request freeze exception for Bzr-1.2 ?
<hsn_> anybody works on netbeans plugin?
<jelmer> hsn_: there is nobody working on one, or at least they haven't publicly announced so
<ubotu> New bug: #192924 in bzr "quick-start-summary.svg missing in Python based installer for windows" [Undecided,New] https://launchpad.net/bugs/192924
<appcine> hmm, pushing my updates to the server is constantly crashing on me .. both bzr+ssh and scp.. the cursor just hangs on 0/0 and nothing happens.
<appcine> I can't even control-c out of it when using bzr+ssh
<appcine> The connection is established - I need to break-lock on the server to try again. Ssh and scp directly works like a charm
<appcine> "TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x1644390>' has reached its concurrent request limit."
<appcine> Is what I get when the push finally fails
<appcine> (using ssh=
<appcine> anything I can solve on my end?
<Peng> appcine: Does .bzr.log on either the client or server say anything interesting?
<Peng> appcine: Maybe the server kills processes that consume any resources.
<appcine> Peng:  nothing intresting on server, but "not updating child fraction" in my client's .. A LOT! :)
<appcine> It's like it's spit into my bzr.log until my ctrl-c finally has any effect
<fullermd> Probably unrelated.  That's to do with the progress bar updating, IIRC.
<appcine> it works sometimes, sometimes it doesn't
<thatch> hmm, is 1.2 released or not? The webpage says yes, the changelog says 1.2rc1 is still in development, and doc.b-v.org doesn't have a dir for it.
<Peng> thatch: There are a couple debs up in the PPA.
<thatch> Peng: I also see the tarball... however, there's no changelog entry for 1.2 actually being out :)
<jdong> thatch: yeah the wiki has not been updated to point to the right changelog but 1.2 has been out for a few days
<jdong> you can find the changelog in NEWS of the tarball
<appcine> seriously. nothing i can further investigate to solve my stalling push problem? I can't work :P
<thatch> jdong: here's the first real heading in NEWS of bzr.dev.
<thatch> bzr 1.2rc1 (not released yet)
<Peng> What about NEWS of bzr.1.2?
<thatch> Peng: aha, it's in there.
<thatch> so if https://launchpad.net/bzr/1.2/1.2/ also contains the changelog... why have an outdated changelog link on the front page of the wiki?
<beuno> thatch, changed, thanks
<thatch> beuno: great!
<BigMadWolf> Hello all, I have an issue with the bzr eclipse plugin. Is someone using it?
<beuno> BigMadWolf, sure, what seems to be the problem?
<BigMadWolf> I think I have properly installed bzr-xmloutput and the bzr plugin for eclipse according to the documentation, but when I click on "Synchronize Bazaar" in Eclipse, I can't do anything.
<BigMadWolf> I can only click on "Finish" and not on "Next", so nothing happens.
<beuno> BigMadWolf, what OS are you on?
<BigMadWolf> Ubuntu Gutsy
<beuno> BigMadWolf, can you run: bzr plugins
<beuno> in a terminal
<beuno> just to see if bzr-xmloutput is correctly installed
<BigMadWolf> jeremy@laptop-jeremy:~$ bzr plugins
<BigMadWolf> /usr/lib/python2.5/site-packages/bzrlib/plugins/xmloutput [0.4.0]
<BigMadWolf>         This plugin provides xml output for status, log, annotate, missing, info, version and plugins
<BigMadWolf> /usr/lib/python2.5/site-packages/bzrlib/plugins/multiparent.pyc [unknown]
<BigMadWolf>         Implementation of multiparent diffs for versionedfile-like storage
<BigMadWolf> /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
<BigMadWolf>         Launchpad.net integration plugin for Bazaar.
<BigMadWolf> yep, sounds ok
<beuno> BigMadWolf, and you've got the branch in the top dir of the project?
<BigMadWolf> hoho, I think the issue is solved... :o
<BigMadWolf> I was clicking on windows-> open persepctive -> team  then synchronize
<BigMadWolf> but when I click on the root of my project, then team -> share project, it seems ok
<BigMadWolf> I'm goin' to check if everything works well, I will let you know if it is okay
<BigMadWolf> mmh, it sucks, I can't do any commit when clicking on $PROJECT -> Team
<BigMadWolf> before doing that, I did "Share project" using the existing .bzr dir
<BigMadWolf> do you know how can I remove the bzr support of my project in eclipse?
 * fullermd thinks the format list in init-repo's help should be a little less...
<jam> well, it would seem that --metaweave should be hidden by now
<jam> and probably --weave
<jam> and maybe --knit
<jam> I might hide --rich-root for only --rich-root-pack
<jam> because if you are going for --rich-root you are incompatible with pre-packs anyway
<jelmer> "New in 0.15" should probably be "Since 0.15" :-)
<jelmer> jam: I think there was actually one release with one but not the other
<jam> jelmer: pff not enough for me to care
<jam> not right now anyway
<jam> And the help doesn't clarify that
<jelmer> hmmno, looks like I'm wrong
<jelmer> +1 on removing --rich-root
<jam> well, they both say "New in 1.0"
<jelmer> I think rich-root-pack was marked experimental longer
<jelmer> but that doesn't matter now
<fullermd> Well, not so much that.  But rather than a lot of them don't make sense for init-repo.
<bob2> is --rich-root-pack at the "safe to use as default for people who don't mind reporting bugs" stage?
<fullermd> Like --weave, which is totally impossible.  And --dirstate and --dirstate-tags don't make any sense, since they're no different from --knit at the repo level.
<jam> yeah
<jam> --dirstate changes the WT, and --dirstate-tags changes the Branch
<jam> bob2: I think it is more stable than that, even
<fullermd> metaweave should be hidden all over, I'd say.
<lifeless> jam: actually, pulling into rich-root-pack from non-rich roots breaks inventory sha1's still.
<lifeless> I filed a bug.
<fullermd> Does that break just pull, or upgrade too?
<jam> afaik it doesn't actually break anything, it just has data which isn't strictly valid
<jam> but last I checked we never validated it
<jam> and that was true for -subtree as well
<beuno> Verterok, check out logs, someone was here with all kinds of questions about bzr-eclipse
<beuno> (and hi)
<Verterok> hi
<Verterok> beuno: thanks, I'll.
<lifeless> jam: check tries to validate it, but there is a bug in the API
 * beuno -> out
<lifeless> jam: when the inventory sha doesn't match the inventory I consider it broken.
<lifeless> jam: its a bug that we don't check that always.
<ubotu> New bug: #177890 in bzr-svn "bzr-svn badly horks svn repository if pushing a changeset which includes a new symlink" [High,Fix released] https://launchpad.net/bugs/177890
<ubotu> New bug: #160085 in bzr-svn (universe) "push over svn+ssh:// crashes" [Undecided,Fix released] https://launchpad.net/bugs/160085
<igc> morning
<poolie> good morning
<ubotu> New bug: #193089 in bzr "UnicodeDecodeError exception in bzr whoami" [Undecided,New] https://launchpad.net/bugs/193089
<lifeless> jam: ping
<poolie> lifeless, i feel like we are having a "get it done" vs "done right" distinction
<poolie> on plugins
<lifeless> poolie: to some degree; I feel there is a difference between 'doing part wrong' and 'getting it done'.
<lifeless> poolie: which is to say - I think we have agreed on 'get it done' up to a point
<lifeless> poolie: beyond that, I'm arguing against some particular things, because I think they will cause problems we don't have today.
<lifeless> and that we don't have to have.
#bzr 2008-02-19
<lifeless> poolie: I did review your lp_registration patch; it doesn't seem to be in bzr.dev ?
<poolie> lifeless, i may not have merged back 1.2, i'll check
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> I've just sent an updated patch for external ref support
<lifeless> I'm hoping you can review it as it contains smart server changes
<lifeless> the old patch is a week old now too; which is the other thing.
<spiv> I'll take a look.
<lifeless> spiv: thanks
<lifeless> done for de day; ciao
<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
<bob2> that history is no longer linear"
<thumper> bob2: your issues, or raising someone elses?
<bob2> ted t'so's
<poolie> so there is some tendency that way but it's a bit inaccurate
<poolie> we show branch points in viz, we just don't show it by default in log
<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.
<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.
<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.
<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.
<johnny_> where are the bzr 1.2 release notes?
<jabr> johnny_: https://launchpad.net/bzr/1.2/1.2/ ?
<johnny_> well they aren't linked on the main page
<jabr> yes, they are.
<jabr> linked from the link "full changelog"
<jabr> :-)
<johnny_> oh.. it is fixed now
<johnny_> i think i had that window open for a while..
<johnny_> thought i refreshed the thing
<johnny_> i'm looking at this bzrarchives blueprint
<johnny_> got any other systems you guys are looking at to take inspiration from?
<johnny_> people always found that confusing in monotone for sure
<johnny_> they use sqlite for the archive storage
<appcine> hi, bzr push works like 1/5 times. otherwise it just stalls.
<appcine> ssh/sftp works dandy all the time thouggh
<appcine> though
<appcine> I ditched my old svn history and went 100 % bzr, but I really can't work like this.
<appcine> python goes up to use 99% cpu
<frsk> It stalls when working on local files?
<appcine> after a commit, I push the files to a server
<appcine> using bzr+ssh
<appcine> and often too..
<appcine> now I have to: commit, push, ctrl-c (like 30 times), go to server, break-lock .. push again etc .. until it works
<appcine> and I hopen I'm alone with this, because I've recommended bzr to A LOT of people :)
<awilkins> appcine: Are you working on a wireless connection?
<appcine> awilkins: yes
<appcine> awilkins: both at work and at home
<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.
<appcine> it's not very flaky :/
<awilkins> How big are your branches?
<appcine> 120 MB or so, including a lot of media files
<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.
<awilkins> On the other hand, 120MB is not too much, I have a partially converted repo with over 900MB of packs in it.
<appcine> and it's soo weird that it works 1/5
<appcine> almost consistently
<appcine> I get this in my client log: WARNING: This transport does not update the working tree of: ...
<appcine> but that's quite alright, no?
<awilkins> That's normal
<appcine> Just means that I have to update the server
<awilkins> Do your server repos have a working tree, is it desired?
<appcine> then Using fetch logic to copy between KnitPackRepository ...
<appcine> then somethign weir happens
<appcine> whenever it is going to stall, i see the progressbar
<awilkins> Why not try rich-root-pack instead?
<appcine> and I get this in my log: not updating child fraction
<awilkins> See if that helps at all
<appcine> rich-root-pack? :)
<awilkins> Differetn repo format
<appcine> how do I change that then?, hehe
<awilkins> You take your branch and bzr upgrade --rich-root-pack
<dato> awilkins: uhm, KnitPackRepository == packs
<dato> pack-0.92 I mean
<awilkins> Ok, proabbly not much differnt then
<dato> awilkins: and pack-0.92 and rich-root-pack will be the same for performance
<dato> right
<awilkins> appcine: I think you should try it over a wired connection
<awilkins> That will at least eliminate one variable from consideration ; you're going to have to be a detective to isolate the cause.
<appcine> hehe yeah
<appcine> plugging cable in
<sttng359> hello
<sttng359> I am curious if bzr can/will preserve file permissions/ownership in it's database.
<appcine> same over cable
<appcine> It just doesn't do anything and .bzr.log is spitting out "not updating child fraction"
<awilkins> But you feel less doubt and fear, for now you know it isn't your wireless flaking out!
<appcine> haha, yes! :)
<appcine> anything else I can try?
<appcine> It's nice with software that you want to work
<appcine> Like bzr, it doesn't work for me .. normally I would go use mercurial or back to svn instead
<appcine> since it's totally disrupting my work
<appcine> but .. you keep on trying
<luks> sttng359: no, it can't (by design)
<appcine> https://lists.ubuntu.com/archives/bazaar/2007q4/035930.html
<appcine> could that be my problem perhaps?
<luks> normally when you work with source code, you work with multiple people so preserving the ownership doesn't really makes sense
<sttng359> yes, I understand that design principle and why cvs/subversion and others use it
<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
<appcine> But no, it happens with sftp also for me :(
<sttng359> So I am looking for a decent configuration versioning, not source code versioning
<sttng359> also, something that could version across hosts would be nice, such as pushing changes for nss_ldap.
<sttng359> I just saw a blog of someone mentioning using Bazaar on /etc.
<dato> sttng359: there is metastore and etckeeper
<awilkins> I use monotone on my /etc at the moment
<awilkins> But I may well switch to bzr, mtn is good but not perfect
<dato> sttng359: though I thought jelmer had added bzr support to etckeeper, but I can't see that being the case
<johnny> mtn does have soeme nice things tho..
<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 )
<ubotu> New bug: #193214 in bzr ""bzr up" in a branch with local commits shows changes twice" [Undecided,New] https://launchpad.net/bugs/193214
<awilkins> And I think learning Python for hooks is probably more productive than Lua
<johnny> the sqlite storage is mtn is neat
<johnny> in*
<johnny> and the arbitrary certs
<awilkins> Are you mining the database for information?
<johnny> lua is simple enough at least
<johnny> sometimes..
<johnny> we have about 30K revs in mtn across 4 databases
<johnny> i don't think monotone will every be a big thing tho...all the other vcs will just mine it for information :)
<johnny> the project that is
<sttng359> I mainly just want to track changes in configuration files through package upgrades, or when services stop working.
<awilkins> Yes, I think it's probably a battle between git and bzr now.
<johnny> i just use dispatch-conf
<johnny> in gentoo sttng359 `
<sttng359> Also, a mechanism for pushing common configuration files between servers would greatly help in maintenance.
<johnny> maybe you want something like cfengine?
<johnny> or is that too intense? :)
<awilkins> git has a crack squad of Kernel developers, bzr has a nice easy-to-learn language and popular visibility in the Ubuntu community.
<awilkins> sttng359: There's a "update tree" plugin for bzr that will do a server-side update after a bzr+ssh push, afaik.
<sttng359> Ahh, I remember reading about cfengine a few years ago, but I was not ready for it.
<sttng359> Perhaps that's the solution to my needs.
<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
<appcine> and now cpu goes to 99%
<awilkins> Looks like it's probably a known bug if they are adding more debugging information to the messages in newer revisions
<awilkins> Or at least, a reported / suspected bug
<appcine> I really wanted to solve this..
<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
<appcine> :)
<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.
<awilkins> Have you tried setting up a persistent smart server?
<appcine> No.. but this also fails using just sftp
<appcine> and the changes I make is a comment in just one file
<awilkins> Try archiving up the branch on the server, unpacking it to your local filesystem, and pushing to that.
<awilkins> Then you know if it's a network-protocol problem or a corrupted data problem
<appcine> good idea
<appcine> But I really haveto go tow ork .. it's lunch already and I'be been trying to solve this all morning :)
<awilkins> Fair enough
<awilkins> Might I recommend SVk for disconnected operation from an SVN repo?
<awilkins> I recently ditched it for bzr because it had a bug that caused me real problems... and Perl gives me a headache.
<awilkins> But I was using it for some time without trouble.
<awilkins> You don't even have to ditch your comfy SVN tools like TortoiseSVN (or whatever you use).
<luks> I find bzr with bzr-svn much easier to use than svk, and actually even more functional
<luks> but I mainly use it for only for merges
<awilkins> Yes, the bzr merging is better
<awilkins> A merge bug is what lead me to ditch SVK
<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.
<appcine> svn was working great for me, but I hear bzr branching is better .. and I branch a lot
<appcine> I get this in my server "bzr info"
<appcine> Conflict: can't delete apps/new_media because it is not empty.  Not deleting.
<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
<luks> why do you have a working tree on the server?
<awilkins> appcine: Try resolving that conflict. And then (thanks luks) nuking the tree.
<appcine> luks: I have NO idea! :)
<awilkins> Having a tree is the default.
<luks> not if you push over sftp/bzr+ssh
<awilkins> Depends where the branch was created.
<luks> right
<appcine> gahhhh
<appcine> bzr remove-tree
<appcine> is that safe?
<awilkins> You might need a --force
<luks> appcine: if you don't have any local changes there
<awilkins> Depends if those non-empty files are significant
<awilkins> They represent local changes you might want to keep (or they might just be build cruft)
<appcine> I have a dir in my tree: media/user_uploaded/
<appcine> that's not version controlled and contains user uploaded data
<appcine> does remove-tree delete the actual files?
<appcine> or what does it do?
<awilkins> remove-tree removes the files from disk, but not the repository storage
<appcine> I need the files on the disk
<appcine> otherwise apache can't serve them
<appcine> :)
<awilkins> If you are pushing to a common branch there is always a risk of conflict.
<appcine> I am pushing to our live-server
<appcine> Working on my laptop, pushing to the server when done.
<luks> I wouldn't use bzr to push to an apache-served directory
<appcine> the restart apache and the site is live
<awilkins> Probably not such a great idea to serve straight from a full branch
<awilkins> Because you are serving the .bzr repo as well
<appcine> it's not php
<awilkins> Paste address
<appcine> it's a python site and the source code is not avaialble in apache www-root
<appcine> So, let's start from scratch :)
<appcine> I used to work like this: work on my laptop, commit to svn server, ssh to web server and update. restart apache
<luks> appcine: are you updating the working tree manually?
<luks> or using push-and-update?
<appcine> Now I: work on laptop, commit, push to web server, ssh to webserver, bzr update and restart apache
<luks> ah
<appcine> Now, the bzr remove-tree that I ran, has it destroyed anything? I ctrl-c:ed when I saw what was happening.
<awilkins> How about you have a no-tree branch on the server and do a bzr export instead?
<appcine> And, is there something wrong with theat workflow?
<awilkins> remove-tree will nuke the "working copy"
<awilkins> It doesn't destroy any revisions
<appcine> but it will remove files?
<awilkins> It removes the files from the working copy
<awilkins> But probably not the unversioned ones
<luks> bzr reconfigure --tree if you want them back
<appcine> luks: PHEW.. hehe
<awilkins> bzr checkout
<appcine> it removed a lot of user uploaded files
<dato> appcine: do bzr update
<appcine> dato: nothing happened
<dato> er
<luks> appcine: you version user uploaded files?
<dato> I arrived late to the party
<awilkins> bzr update only works if there's a tree
<appcine> luks: no, but the dirs they were in
<awilkins> a checkout reconfigures it back to tree and gets the files.
<dato> awilkins: but he said he ctrl-c'd early
<luks> I'm quite sure it doesn't touch non-versioned files
<appcine> awilkins: I can't run checkout because .bzr still exists
<awilkins> appcine: checkout fetches the files from .bzr into the working tree
<appcine> luks: It seems like it removed the versioned directory containing the files
<awilkins> if you jsut go into the branch and do a "bzr checkout"
<awilkins> appcine: If you can confirm that behaviour, that's bad
<appcine> bzr: ERROR: File exists: u'/home/appcine/webapps/appcine/.bzr'
<appcine> when doing bzr checkout
 * awilkins is confused.
<luks> appcine: if I do that I get a conflict telling me that there are unversioned files
<luks> so I'm not sure what exactly did you run
<awilkins> There isn't a "force" option either, you'd have to remove them manually to get it to clear the tree
<appcine> luks: bazaar remove-tree --force .. then, when I noticed what was happening, i hit ctrl-c
<awilkins> luks: How about if they are in your ignore list,?
<luks> appcine: "bzr: ERROR: no such option: --force"
<luks> awilkins: same error if they are ignored
<luks> appcine: err
<appcine> but how do I get my site back up now? :)
<luks> bazaar??
<luks> what _exactly_ did you run?
<appcine> luks: sec
<appcine> $ bzr remove-tree
<luks> either way, running random commands your live site is not the greatest idea
<appcine> I know :)
<luks> then it complained about non-versioned files in the working tree
<luks> if you had there any
<awilkins> My recommended layout ; put a no-trees branch somewhere other than inside your web root.
<luks> bzr --version?
<awilkins> THen do a bzr export to the desired location
<appcine> 1.1.0
<appcine> no-trees branch, ok
<appcine> and then to keep it up-to-date?
<awilkins> Either make a lightweight checkout for your web app, or use bzr export
<appcine> Nevermind the deleted user-files, that directory had been renamed
<appcine> I got so stressed up
<awilkins> THe lightweight checkout is probably easiest to keep fresh
<appcine> and the lightweight checkout is something you do from the server?
<awilkins> Yes
<appcine> Does my laptop need to have a public ip for that?
<awilkins> You might be able to hook script it, I'm not up to speed with bzr hooking though
<awilkins> appcine: No, there's a branch on the server
<awilkins> appcine: You do your checkout from that
<appcine> So .. if I start from scratch now
<awilkins> Work on laptop, push to branch on server, ssh to server, lightweight checkout to web app folder
<appcine> from client I run: bzr export bzr+ssh://server/project
<awilkins> From laptop you bzr push bzr+ssh//server/home/me/mywebappdeploymentbranch
<awilkins> from server bzr checkout --lightweight /home/me/mywebappdeploymentbranch /var/www/webapp
<awilkins> Then for updates bzr update /var/wwe/webapp after a push
<appcine> Ah, ok ..
<appcine> Let me try that
<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.
<awilkins> But you could splat together a swift deploy script that did the push and an ssh remote bzr update /var/www/webapp
<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
<appcine> Updating manually on the server really isn't a problem
<appcine> I'm usually always logged in there anyway
<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)
<appcine> And how would that work for local development?
<appcine> IE, the link would be different, now?
<appcine> s/now/no/
<awilkins> You could make it a link to the same path clocally
 * awilkins is on windows and cannot readily test this theory :-)
<appcine> Ok, site back up
<appcine> :)
<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)
<awilkins> jelmer: (by neither process, I mean svnserve and python bzr)
<awilkins> jelmer: Would a copy of the svncache help with debugging or would you need more than that?
<appcine> awilkins: And it seems like my problem has been resolved
<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.
<awilkins> But I'm guessing you are the sole "pusher" here
<appcine> I am
<awilkins> Those error message could be more helpful.... were you committing on the server?
<appcine> comitting, pushing on client, update on server
<appcine> Ok, situation under control. Thanks a lot for the help
<johnny> hmm.. got loggerhead nearly working now.. something is odd about the public branch url tho..
<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
<jelmer> awilkins: Are you using 0.4.7 or the 0.4 branch?
<wortkt> does anyone know is there a hook or something like that to catch push or commit on the remote repository side?
<wortkt> like when you do bzr push bzr+ssh://remoterep.server/repo
<wortkt> so that remoterep.server does something like sends an email when this happens
<jelmer> wortkt: no, you can only use local hooks at the moment afaik
<wortkt> ok
<ubotu> New bug: #193250 in bzr "memory error when attempting to copy a branch" [Undecided,New] https://launchpad.net/bugs/193250
<grutte_pier> has anyone ever tried to set up a repository/branch accessible over http+access permissions as set in an .htaccess file?
<grutte_pier> basically: got bzr to handle http code 401 by means of a plugin/experimental path?
<grutte_pier> patch*
<awilkins> jelmer: 0.4 branch
<jelmer> awilkins: Please try the 0.4.7 branch
<jelmer> the 0.4 has some severe performance regressions at the moment
<awilkins> Well, it's not a "performance" problem ; it just sits there doing nothing (no resource consumption), but I'll try.
 * awilkins reverts to r 877
<jelmer> it iterates over the history unnecessarily
<jelmer> it's mainly bandwidth usage, not cpu or memory
<awilkins> I think the reason I moved forward was https://bugs.launchpad.net/bugs/191572
<awilkins> ... which is where I am now.
<awilkins> jelmer: I thought all the history got cached?
<jelmer> awilkins: the path changes (the paths in "svn log -v") are cached
<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.
<awilkins> I didn't notice the server even eating 1% of the cpu on the occasions I checked.
<awilkins> Oh, by the way, since there are no API changes for 1.2, is bzr-svn compatible ?
<jelmer> awilkins: haven't checked yet
<awilkins> jelmer: Which bit of libsvn has that humungous memory leak?
<jelmer> awilkins: the python bindings themselve
<awilkins> jelmer: It's not entirely solved even by those patches, is it?
<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 ?
<jelmer> awilkins: there are several other leaks that are only fixed in 1.5 I think
<awilkins> jelmer: I should think so, it eats 1.5GB processing the first 300 or so revisions
<awilkins> 'tis a shame that "pull" doesn't count up revisions, it's not very reassuring :-)
<jelmer> awilkins: That's not right though
<jelmer> awilkins: That sounds like it doesn't have *any* memory leak patches applied
<awilkins> I should be using the windows builds from http://d5190871.u44.websitesource.net/bzr/
 * awilkins does some checking
<awilkins> jelmer: Some of these revisions are very large ; the tree is large, and it has quite a few larger files in it too.
<jelmer> the size of the files shouldn't matter
<awilkins> I'm just wondering if the size of the tree is accentuating some of the memleaks.
<jelmer> what do you mean by large specifically?
<awilkins> 39,000 files
<jelmer> in a single tree?
<awilkins> Yes
<awilkins> Some of the files are as large as 50MB
<jelmer> wow, ok
<awilkins> (not many that large though, they are mostly in the 10-100s of KB range)
<jelmer> have you tried with native bzr<->bzr with a tree that large
<jelmer> ?
<awilkins> jelmer: Nope, but I shall try an export of this tree and branch it.
<awilkins> jelmer: Ok, I've done that now ; it tops out at 190MB to either commit or branch this tree (via the filesystem).
<jelmer> awilkins: that's the same history size / number of files/ size of files as in svn?
<awilkins> No, alas.
<awilkins> It's the same files, but I don't have 13,000 revisions of history
<awilkins> Just one revision
<awilkins> I'd have to convert the repository to bzr via other means if I wanted all those revisions.
<awilkins> I could try sv2bzr I suppose
<awilkins> I don't suppose svn2bzr is compatible with bzr-svn, is it?  :-)
<jelmer> no
<jelmer> awilkins: You can try the subversion 1.5 binaries if there are any yet
<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
<jelmer> (or python-svn/svn)
<awilkins> jelmer: I agree, but the difficuly is simulating an identical revision tree without converting it over :-)
<awilkins> jelmer: svn2bzr shouldn't suffer the same problem since it works from dumpfiles
<awilkins> So that would be one way of getting an equivalent branch
<awilkins> I shall instruct the server to make me a dump.
<jelmer> awilkins: you can also try the 'bzr pull -r...' trick to work around the memory errors
<awilkins> jelmer: I was just resuming when it crashed, which seems to work well enough until it gets to that KeyError exception
<awilkins> The latest revisions don't even do that though, they just become inactive and do nothing (as describe further up)
<jelmer> awilkins: Right, but that's what you get for running a development version :-)
<jelmer> awilkins: That bug is unrelated to bzr-svn, it's a bzr bug.
<awilkins> jelmer: Rock >> awilkins << hard place
<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
<awilkins> I just like to torture test things :-)
<awilkins> jelmer: reading 191731, I may just install 1.2 and try that
<awilkins> jelmer: Much improved in 1.2, but still eating heap big memory. Python is a reference counter, not a garbage collector, yes?
<jelmer> yes
 * awilkins again wonders what bzr would be like on IronPython
<jelmer> I'm pretty sure bzr-svn doesn't keep a lot of handles open though
<awilkins> It's still creeping up, but it creeps back down again a lot more than before
<awilkins> Is there any kind of ?heap? viewer in the debugger ; get an idea of which objects are holding the memory?
<jelmer> not as far as I'm aware
<jelmer> it's really tricky to debug this sort of thing with cpython
<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
<awilkins> I had a look at the log, they don't seem to correspond to revisions with large deltas
<jelmer> it may be to do with how packs work
<jelmer> or perhaps the fact that bzr keeps whole files in memory atm when applying deltas
<awilkins> It seems to be holding between 1.48 and 1.6 GB
<awilkins> Yes, I did notice that committing large files to my export/branch test ate memory for the whole file
<awilkins> Bah, the ceiling went from 1.48 to 1.61
<awilkins> s/ceiling/floor/
<awilkins> It's managed over 700/9243 revisions so far....
<awilkins> Doing much better on 1.2 that 1.1 did
 * awilkins tries the -r 100 trick :-)
<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
<unenough> how does bzr compare with mercurial? (i just heard of that one)
<jdong> unenough: they are quite similar
<jdong> (though maybe bzr devs will beg to differ!)
<luks> unenough: I don't think you can get an objective answer here
<luks> (obviously)
<unenough> well, i'd like to know what bzr ppl think
<unenough> i use bzr
<luks> and I guess the same would apply for #mercurial
<jdong> unenough: I think both are great tools, but bzr's developer and user community rules
<luks> I personally have weird feelings about a VCS that doesn't do merges
<awilkins> Hg doesn't merge?
<luks> hg uses "merge tools"
<unenough> well since i'm about to rewrite the software world anyway, i'll just stick to bzr for now
<jdong> hg merges...
<jdong> just some of its paradigms are different
<unenough> :P
<jdong> to the end user I think it's safe to say it has an analog operation to bzr merge
<jdong> it handles "shared repositories" differently (more git-like)
<luks> jdong: like I have to install the rcs package to make it actually merge something? :)
<jdong> and it (used to be?) significantly faster
<jdong> luks: I could've sworn when I used hg it merged just fine
<awilkins> What's Hg written in?
<jdong> these days I think bzr and hg have similar performance characteristics
<luks> jdong: it doesn't have built-in merge
<jdong> awilkins: python, C-extension diff
<awilkins> Same as bzr then...
<luks> there is extension that is basically the three-way merge from bzr
<jdong> luks: hg merge doesn't count?
<luks> hg merge just starts the hgmerge script
<jdong> but what is the difference to the end user?
<luks> you need to have a merge tool
<luks> like the "merge" program from rcs
<awilkins> Doe Hg track file renames like bzr?
<awilkins> And how does it square that with separate merge tools if it does?
<luks> hg tracks copies+deletes
<luks> and using file names, not file ids
<abentley> And doesn't track directory renames, because it doesn't track directories at all.
<jdong> unenough: but anyway, since you asked us, IMO bzr is better :)
<awilkins> Hmm, I'm used to directory tracking, I don't think I'd like to give that up
<awilkins> Although the "content tracking" in git is an appealing idea, it just isn't mature enough on windows
<luks> I don't think it ever will be
<awilkins> Too close to the "metal" of VFS
<luks> I also don't like how hg/git handle unicode
<luks> "just use the current locale and hope everybody is using the same"
<luks> which doesn't really work well if you on both windows and linux
 * awilkins never really figured out encoding on *nix, espuncode support
<mruiz> hi all. I want to use 5-a-day package but I got the following error with bzr : http://pastebin.ubuntu.com/4762/
<awilkins> Do the "modern" distros come Unicode flavoured out of the box?
<luks> I think all of them use utf-8 now by default
<awilkins> mruiz: That's not an error WITH bazaar, that's a lack of bazaar
<mruiz> awilkins, I'm using bzr 1.2~rc1-1
<mruiz> bzr: ERROR: Couldn't import bzrlib and dependencies.
<luks> python -c 'import bzrlib'
<luks> does it work?
<mruiz> luks, no :(  ImportError: No module named bzrlib
<luks> then you are not using 1.2~rc1-1 :)
<luks> or you have it installed somewhere else
<luks> how did you install it?
<awilkins> You should be able to get a full 1.2 release too (not that it's different to the RC AFIK)
<jdong> mruiz: are you running hardy by any chance?
<mruiz> jdong, awilkins : I'm using Hardy up to date
<jdong> mruiz: pycentral, most likely
<jdong> they broke it
<jdong> bug 192992 I think
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<theSoftMan> hello... where can i find winBZR ( the BZR client like winCVS) ? ;-)
<jdong> whoa! I got that right!
<jdong> I just pulled it off the top of my head
<jdong> (is that sad?)
<luks> theSoftMan: there isn't one :)
<awilkins> There ought to just be a Tortoise<D?VCS> that worked with everything
<theSoftMan> hello luks... that so unlucky :-)
<awilkins> They should merge all the various Tortoises and have a backend of plugins
<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?
<rif> more than a patch
<luks> bzr send
<luks> (too obvious? :))
<rif> ;)
<jdong> awilkins: does that make some sort of giant land turtle?
<jdong> rif: bzr bundle too
<awilkins> Heh, yeah "GalapagosVCS, your one-stop integrated Windows VCS tool!"
<luks> the problem is that all have their own little differences
<awilkins> This is true, But I bet you could re-use a lot of the GUI, etc, with some well defined interfaces
<awilkins> Log dialog, tree browser, etc
<awilkins> Upgrade the log dialog for meged trees, it would still work fine for straight trees.
<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)
<luks> awilkins: I think the status cache is eating way more memory than the explorer plugin
<jdong> awilkins: yeah and explorer's flaky enough without another massive plugin
<luks> which runs in the background all the time and watches the whole filesystem
<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.
<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?
<awilkins> rif: is your current branch a branch of "that one"?
<rif> yes
<rif> awilkins: and I know the last revision that "that one" has in common with the current one
<awilkins> You should be able to use -r [BASE_REV]..
<rif> awilkins: I use "bzr bundle -r 25 ."
<rif> and it gives me a very short output
<rif> I am currently on rev 33
<awilkins> Use the ".." in your revision specifier
<awilkins> -r 25..
<awilkins> If there's no patch, just a bunch of base64, it's not worked properly
<rif> it seem to work like this "bzr bundle -r 25.. ."
<rif> awilkins: thanks
<awilkins> do a "bzr help revisionspec" as well, for further tasty hints
<pygi> hey, me again :)
 * pygi was wondering will 1.2 go into hardy?
<jdong> pygi: hope so
 * awilkins waits for shite-tastic java code to finish working.
<jdong> https://edge.launchpad.net/ubuntu/hardy/+source/bzr/1.2~rc1-1
<jdong> looks like it already made it
 * pygi checks
<pygi> jdong, ah, right, sorry ... had packages installed from bzr repo for gutsy, so it didnt upgrade
<jdong> pygi: ah. well bzrtools and bzr-svn haven't followed yet, but I assume they will in short time
<pygi> ok, and python-central is broken as well xD
 * awilkins just pulls plugins into his plugins folder
<jdong> pygi: yay.
<jdong> awilkins: as do I, but a lot of people do use the system installed ones
 * pygi tries to compensate by switching to main server to see if it's fixed there
<jdong> pygi: no still not fixed
<jdong> AFAICT
<jdong> bug 192992
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<pygi> joy
<awilkins> how can you auto-remove files that have been deleted by something else?
<pygi> jdong, funny thing ... this bug seems to happen in every dev cycle :P
<jdong> pygi: at least it's not as fun as the dpkg breakage some days back
<pygi> jdong, I didnt upgrade when that happened xD
<jdong> lucky :)
<pygi> haha, yea ... and I can workaround this issue with pycentral xD
<awilkins> Is hardy much better than Gutsy?
<awilkins> Just wondering whether I should wait for 2008.04
<pygi> awilkins, depends on your needs? :)
<pygi> right now it's broken xD
 * awilkins prefers non-b0rked software
<pygi> even "Crash report" crashes :)
<jdong> awilkins: I would recommend waiting unless you like living on the edge
<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
 * awilkins likes the edge, but not that much, and not on the WifeTop
<jdong> i.e. today pycentral is broken, so if you tried to install anything python...
<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?
<pygi> it can be workarounded, but still .... it takes time :)
<jdong> LarstiQ: yikes no :)
<pygi> funny bugs xD
<jdong> pygi: right, that's the thing. it's not impossible to work with, it just isn't all that convenient
<LarstiQ> jdong: it was horrible
<jdong> instead I'd recommend running Gutsy and pulling little things from hardy (i.e. updated packages) where appropriate
<jdong> LarstiQ: i is next to o, too :D
<Bilbek> OMG - bazaar is developed with light speed ;)
<Bilbek> I have a (frequently asked) question - how to ignore white spaces while merging?
<Bilbek> I could find anything in bazaar FAQ
<Bilbek> I'm using 1.0.0
<Bilbek> erm
<Bilbek> I couldn't find how to ignore them in FAQ
<Bilbek> nor in user's guide
 * dato heh's at 3152.2.2
<jelmer> Bilbek: I don't think there's a way to do that
<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?
<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
<Bilbek> thatch: well - sort of... or one developer uses windows and another linux
<jelmer> Bilbek: That only works if you use an external diff I think
<jdong> hmm would a "close enough" merge be implementable
<jdong> we can call it sloppy/lazy merge :)
<thatch> I suggest the Windows develop use a real editor that has selectable line endings :)
<jelmer> yes, it would certainly be possible to implement a merge algorithm that handled whitespace differently
<Bilbek> ok, so in short nobody really asked for it ;)
<thatch> jelmer: I forget, does bzr have a notion of "binary" files?
<jelmer> thatch: no
<thatch> Bilbek: I started writing a plugin to _display_ diffs with arbitrary options like that in Jul 07, but never finished it.
<Bilbek> hm... if I define an alias for diff, will merge use that alias to determine changsets?
<jelmer> Bilbek: no
<jelmer> Bilbek: You may be able to use --diff3 somehow
<Bilbek> jelmer: yes, but I can't see how I can set any additional parameters for external diff3 program
<jelmer> there isn't
<jelmer> anyway, back later
<Bilbek> ok, thank you for information
<jdong> does bzr have a commit option similar to git's -v?
<jdong> in that the diff is shown in the editor window for last minute review?
<jdong> IMO that's quite useful except when the diff is massive
<beuno> jdong, you can just do bzr diff and it will do it on the working tree
<luks> bzr commit --show-diff?
<jdong> luks: does that exist?
<luks> yes
<luks> bzr help commit :)
<jdong> beuno: yes, but how long does your memory last when $EDITOR clears the scrollback?
<jdong> luks: ok I'm an idiot
<luks> but I personally prefer "bzr qci"
<beuno> jdong, right. It's for a super-powered user target who can remember thousands of lines per seconds I guess  :p
<jdong> luks: what's qci?
<luks> qcommit from the qbzr plugin
<jdong> oh cool a qt bzr
<jdong> didn't know that
<luks> obviously I'm biased, since I wrote it :)
<luks> but I like things like text-completion in the commit message editor
<jdong> sweet
<abentley> thatch: bzr autodetects binary files according to whether there's a NUL in the first 1K
<mwhudson> can i get bzrtools 1.2 debs anywhere?
<Peng> The PPA, once someone uploads them? :)
<mwhudson> hm, guess so
<mwhudson> i guess i'll give that "poolie" character a poke when he gets up
<abentley> nevermind the fact that bzrtools 1.2 was out several days before bzr 1.2...
<ubotu> New bug: #193412 in bzr-webserve "UI: In inventory, files and directories should have different colors?" [Undecided,New] https://launchpad.net/bugs/193412
<Peng> I care way too much about ConfigObj than is healthy.
 * Peng wanders off.
<Peng> We don't care about IronPython compatibility, right?
<awilkins> Peng: I care about IronPython compat
<Peng> Well, do we try to support IronPython?
<awilkins> Peng: Any operation that is CPU bound should (?) be faster under IronPython ; and bzr pegs the CPU during most operations for me.
 * Peng wanders off.
<Peng> I'm missing General Hospital. :(
 * Peng wanders off.
 * awilkins has a MythTV box and never misses anything unless it crashes
<awilkins> Plus it would be awesomely cool to be able to write Powershell providers for bzr
 * awilkins reveals himself as a nasty smelly windows user
<jdong> does bzr have a way to do a "partial checkout" yet?
<jelmer> jdong: nope, not yet
<jdong> aww :( that's a shame
<jdong> I have acquired these directories of large compressible EPS files
<jdong> would be nice if I could just stash them in packs and only check out a working copy when needed
<lifeless> jdong: you can; what dimension of 'partial' did you mean  ?
<awilkins> Gah, I'm already hating older source control systems more every day
 * awilkins grumbles about stupid evil VCS that don't track renamed files
<awilkins> Especially when they are polluting my nice bzr trees...
<lifeless> awilkins: :)
 * awilkins is currently rebranching / merging his trees
<awilkins> If this works I'll be pleased with my comprehension of things
<Peng> lifeless: Does bzr try to support IronPython?
<lifeless> awilkins: what vcs are you working with
<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.
<lifeless> Peng: no
<Peng> Ok.
<lifeless> Peng: if someone sends in tasteful patches to improve things there - fine. But we don't test or QA against it.
<awilkins> lifeless: MKS Source Integrity
<lifeless> awilkins: oooooh thats a beast
<Peng> Hm.
<awilkins> Yeah, it's MD hash is "666"
<lifeless> awilkins: I used to work at a place used that
<awilkins> Peng: A start would be running bzr selftest in both CPython and IronPython
<awilkins> Peng: I keep meaning to do it.
<awilkins> Peng: IronPython 1.1 or 2.0 (alpha 8)?
<Peng> Err.
<Peng> I'm just messing around with ConfigObj for fun.
<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.
<Peng> Anyway, again, I'm just doing it for fun. I won't submit that patch.
<dato> Peng: what isn't supported by IronPython, you say?
<Peng> The compiler module.
<Peng> I didn't confirm it, but that's what ConfigObj says./
<dato> ah, ok.
<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
<seb128> hi
<seb128> how do I tell what log format bzr accepts?
<seb128>      --log-format=ARG    Use specified log format.
<seb128>  not really useful
<dato> seb128: `bzr help log`
<lifeless> Peng: if the module isn't supported, removing the try:except: will make loading fail :)
<seb128> dato: where do you I got the line I copied?
<dato> seb128: and three lines below it
<seb128> dato: where do you thing I got the line I copied?
<lifeless> jdong: no, we don't support that at the moment, sorry.
<Peng> lifeless: Well yeah. But do we care if it fails on IronPython?
<seb128> dato: http://paste.ubuntu.com/4788/
<seb128> dato: where?
<lifeless> Peng: but why do you want to remove the try:except:
<dato> --line              Log format with one line per revision
<dato> --long              Detailed log format
<dato> --short             Moderately short log format
 * dato shakes his head.
<seb128> so --log-format=--line?
<seb128> tha's weird syntax and help description
<elmo> seb128: no, --line or --log-format=line
<dato> --log-format=line or --line
<lifeless> seb128: --line, or --log-format=line
<elmo> it's spectactulary poor help UI
<seb128> ok
<seb128> jockey is using a =gnu
<seb128> has that being deprecated or is pitti getting that somewhere else?
 * dato would have never introduced --line, and always forced --log=line
<seb128> I'm trying to be nice and update bzr rather than doing apt-get source, change, upload
<seb128> but bzr is not nice to me there ;-)
<dato> seb128: gnu probably is a plugin
<dato> s/probably//, even
<lifeless> http://bazaar-vcs.org/BzrPlugins
<lifeless> gnulog on there
<visit0r> is there a way for sending commit emails for the remote branch changes without installing the commit mail plugin to every client?
<seb128> ok, I'll just do apt-get source, update, upload
<seb128> and explain to pitti tomorrow why I don't like packages maintained in bzr ;-)
<seb128> thanks guys
<lifeless> seb128: he should document his practices more :)
<lifeless> seb128: I'm not sure why you need gnulog to update the tree though
<seb128> we should just have one common interface to change packages
<seb128> because he doesn't maintain a ChangeLog but generates one when doing an upload
<seb128> and he's using this gnu format when doing that apparently
<lifeless> seb128: indeed. But we don't - even with 'regular' trees there is much variation
<lifeless> visit0r: yes, there is a script that checks the branch and sends mail
<dato> visit0r: http://launchpad.net/bzr-hookless-email
<dato> visit0r: you'd run that on the server as a daemon, or from cron
<visit0r> sounds exactly what we need, thanks. did you get that wortkt?
<dato> visit0r: wortkt->working?
<dato> visit0r: anyway I use it regularly, and know that several other people do as well.
<visit0r> yep a collegue of mine, we are transforming from svn to bzr and trying to get things together
<dato> visit0r: ping me if you get any trouble with the script
<visit0r> dato: we will, thanks a lot
 * dato bbl
<visit0r> (wortkt is a nick)
<schierbeck> wow, bzr-avahi kicks ass!
<jelmer> hey Daniel
<schierbeck> hi jelmer :)
<lifeless> spiv: ping
<poolie> good morning
<mwhudson> hi poolie
<poolie> hi
<mwhudson> poolie: can you make bzrtools 1.2 debs?
<poolie> that's the first thing for me for today
<mwhudson> cool :)
<spiv> lifeless: pong
<lifeless> spiv: ping-pong on the patch again :)
<spiv> lifeless: ping-pong-punged
<schierbeck> hi jamesh, nice work on bzr-avahi!
<schierbeck> just tried it out
<jamesh> schierbeck: thanks
<schierbeck> jamesh: is it possible to have a server running, serving only explicitly advertised branches?
<schierbeck> other than having --directory point to somewhere empty
<jamesh> schierbeck: I don't think so (although I haven't dug into the bzr server code that much)
<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
<schierbeck> of course, i could just write a script, but it would be cool
<jamesh> schierbeck: it might be possible with a custom transport that collates a bunch of branches and limits access to others
<schierbeck> yup
<jamesh> schierbeck: you can also run multiple servers if you want to restrict what you are sharing too
<jamesh> schierbeck: passing --port=0 to "bzr serve" will pick a random port to listen on
<schierbeck> i guess so
<schierbeck> right now i'm trying using "bzr serve --directory=/dev/null"
<jamesh> what would you expect that to do?
<schierbeck> and then just manually advertising the branches i want to share
<speakman> hi ppl!
<jamesh> schierbeck: to advertise the branch, you need to both turn on advertising with "bzr advertise" and run a server that covers the branch
<schierbeck> jamesh: yeah, just found out. that's a bitch.
 * speakman wants to make a "init-repo" WITH tree, but even with --tree there's no working tree at the remote place.
<schierbeck> i was hoping for an opt-in model
<bob2> schierbeck: "no working tree" after push?
<schierbeck> huh?
<bob2> er, speakman
<schierbeck> :)
<lifeless> schierbeck: we don't ever create trees remotely
<lifeless> schierbeck: trees are filesystem objects
<schierbeck> hey!
<schierbeck> stop it!
<lifeless> oh.
<schierbeck> you guys want speakman
<lifeless> yup sorry
<schierbeck> hehe, np :)
<speakman> no working tree after push...
<speakman> :)
<lifeless> s/schierback/speakman/gy
<speakman> ;)
<schierbeck> jamesh: i guess running multiple servers is the solution, then
<speakman> I need a tree
<awilkins> so open a shell on the server and do bzr update
<schierbeck> and with avahi, you don't need to communicate the port number, so it's not that much harder
<lifeless> schierbeck: server hooks should tell anything listening about each server
<speakman> the server havn't got either python nor bzr...
<awilkins> You can't make a tree from a push, because you can't depend on which push method has been used.
<jamesh> schierbeck: bzr-avahi should handle non-default ports for the server just fine, so running multiple servers should work okay
<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
<jamesh> schierbeck: although it might get confused if you share the same branch twice
<schierbeck> cool
<jamesh> due to naming conflicts
<bob2> speakman: maybe rsync'ing everything but .bzr would be an ok workaround?
<schierbeck> yeah, but all my branches are neatly organized, so it should be fine
<jamesh> likely one will serve the branch as "foo" and the other as "foo #2"
<speakman> bob2: no, it has to go with each commit.. :/
<schierbeck> jamesh: ohh, you mean aliases
<schierbeck> yeah, i'm currently namespacing them
<bob2> speakman: rsync from a post-commit hook ;)
<speakman> why can't I just have a working tree at remote?
<jamesh> schierbeck: no.  I mean mDNS name conflict resolution
<schierbeck> like "bzr-gtk-trunk"
<schierbeck> jamesh: is that the name you provide with --name?
<jamesh> schierbeck: if you run two servers that share the same branch, they can't both share it under the same name
<jamesh> schierbeck: yes.
<schierbeck> then we're on the same page
<schierbeck> s/alias/name/g
<speakman> why is there a argument "--no-tree" when I even CANT have a tree? :D
<jamesh> schierbeck: if there is a name conflict, the server automatically renames the branch
<awilkins> speakman: You can have a tree, you just don't get trees from pushing
<schierbeck> jamesh: i just got a lot of branches named "trunk", so namespacing is required
<speakman> awilkins: ok, not by commit either then?
<awilkins> speakman: It's not implemented because it's so much less efficient than having bzr update the tree from the packs
<schierbeck> jamesh: what characters are illegal in such a name?
<awilkins> speakman: You have to havea tree to commit....
<jamesh> schierbeck: not sure.
<schierbeck> i'll just run a few through, see if they work
<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.
<Peng> push-and-update plugin?
<Peng> Oh, if bzr isn't on the server, never mind.
<awilkins> push-and-update requires bzr on the server
<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.
<Peng> Yeah. I just came into the conversation and didn't know that part.
 * Peng wanders off.
<speakman> is there a better way to do that?
<awilkins> speakman: Without bzr on the server, file transfer is just as effcient anyway ; plus you won't have to transfer the repository
<schierbeck> jamesh: colon works just fine, cool. now i can name the branch "bzr-gtk:trunk"
<speakman> awilkins: but we WANT our repo on the server since we're using it as a bzr repor too! :)
<jamesh> schierbeck: file bugs if you find problems
<schierbeck> sure
<awilkins> speakman: You won't get the best performance without bzr on the server anyway ; bzr or bzr+ssh is the best speed.
<awilkins> speakman: And you won't be getting a tree on the server from the repo without bzr
<speakman> i see...
<speakman> the server is running freebsd I'm a Linux guy.. :/
<awilkins> speakman: File transfer, as said, is just as effcicient as implementing exactly the same thing in bzr.
<speakman> awilkins: hm, 66% is using Windows, so it won't be an easy task to automate...
<speakman> i will consider insatlling bzr on the server though...
<awilkins> speakman: I'd probably rig the tree-transfer from a single machine to which you push
<awilkins> speakman: And write a script that did the push, followed by a ssh remote  call to the rsync script
<speakman> maybe a make a cronjob to a "bzr update" on each 5 min or so :)
<lifeless> awilkins: that script exists; its called 'bzr-push-and-update plugin'
<jdong> are obsolete-packs safe to delete?
<speakman> anyone know how to install it on freebsd?
<lifeless> jdong: bzr will do so itself
<jdong> lifeless: really?
<lifeless> jdong: yes
<lifeless> jdong: the directory must exist
<jdong> lifeless: during what operation?
<lifeless> jdong: during commit/pull/merge/push
<bob2> the operation /after/ theey become obsolete, right?
<jdong> lifeless: I just committed and obsolete-packs still contains 4.6MB of data?
<jdong> bzr 1.2, on bound branch, if that makes any difference
<lifeless> jdong: thats fine; it will get gc'd automatically. It doesn't make push or pull slower.
<lifeless> bob2: when we do latency-management packing, we clean obsolete-packs before we put newly obsoleted packs into it.
<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?
<jdong> (some bad little boy is guilty of borderline-exceeding his quota :D)
<lifeless> jdong: you can manually trim if you need to; bzr will (rarely) use up to twice the repository size.
<lifeless> jdong: one of those standard time vs space tradeoffs :)
<jdong> lifeless: understood, and I agree with the decision :)
<jdong> it's at 20% of the repository size currently, but 20% is significant on this particular storage location :)
<jdong> and I can't say enough how much I'm enjoying bzr's performance these days
<lifeless> jdong: right, so what I'm saying is that you need enough working space for it to peak at 100%
<lifeless> actually in  theory it could peak at 200% additional, when you consider pending uploads.
<lifeless> but I think thats extremely difficult to trigger.
<jdong> does the garbage collect also take care of stale uploaded packs or is that more of my job? :)
<lifeless> no; theres no safe way to that automatically unfortunately; ctrl-C will cleanup stale uploads that that process created.
<jdong> right, I think most of my stale issues have come out of broken dumb-protocol pushes
<jdong> over a lossy network
<lifeless> yeah network lossage sucks
<lifeless> problem is that a new bzr invocation can't tell that its not a concurrent push
<lifeless> if you know that no bzr's are pushing, you can clean up that dir safely.
<jdong> right, I'll just do it manually, since it's really one of those odd rare cases
<jdong> I just wanted to make sure those two locations were safe to poke by hand ;-)
#bzr 2008-02-20
<igc> morning
<db-keen> the user guide describes two methods of starting a repo, one with init and one with init-repo and a nested branch. How should I choose which one to use?
<lifeless> init creates a branch
<lifeless> init-repo creates a shared repo which may contain branches
<lifeless> branches do not need a shared repo, they will have their own if no shared one is available
<lifeless> just start with init and get used to bzr, worry about shared repositories once you are familiar with the tool
<jdong> db-keen: the advantage of shared repos is that multiple branches can share a common storage of their history, which saves local disk space and lowers the cost of retrieving another related branch over a slow network connection
<jdong> but as lifeless said, first familiarize yourself with the operation of bzr without repos, then repos will be an easy tool to learn
<db-keen> I don't see a move command, how do you move a file?
<jelmer> bzr mv
<db-keen> nevermind, I found it
<andresj> hello! how can I install bzr-1.2 in ubuntu gutsy? I added the ppa repository and `apt-get update`, and tried to install it, but there is a conflict... bzrtools needs <bzr-1.2
<tchan> bzrtools-1.2.0 works just fine with bzr-1.2
<db-keen> bzrtools 1.2.0 isn't in the ppa repository
<andresj> tchan: bzrtools--oh db-keen already said it :)
<poolie> andresj, it'll be up soon
<andresj> when was bzr-1.2 released?
<poolie> last friday
<andresj> I see :)
<db-keen> I've got this: bzr: ERROR: Generic bzr smart protocol error: <Fault 8002: 'error'>
<db-keen> however it looks like the operation (push) succeeded
<jml> db-keen: that's from pushing to Launchpad, right?
<jml> db-keen: how did you invoke bzr to get that message?
<db-keen> bzr push bzr+ssh://db-keen@bazaar.launchpad.net/~db-keen/rush/site
<andresj> I created a repository with '--no-trees' and created a branch in the same place. Then, from the repository, run `bzr commit . main` to have a place to do the development. Then I created a file and added it, and tried to commit it. But it throws a traceback and an error... "bzrlib.errors.NoSuchRevision: KnitPackRevisionStore(VersionedFileStore('file:///.../.bzr/repository/')) has no revision ...@....com-20080220032150-zkhw0oui4mdlelzb"
<andresj> (I replaced some parts with ... to not reveal personal details :))
<andresj> mm... fixed in 1.2 :)
<abentley> andresj: Basically until bzrtools 1.2 gets uploaded, you have to choose between bzr 1.2 and bzrtools.
<dle> Hi.  I'm wondering if anyone knows why the version of bzr distributed with Ubuntu 7.04 (Feisty) is stuck way back at 0.15.0?
<dle> I do know of the ppa rep., btw.
<beuno> dle, because packages don't get updated on final versions
<beuno> just security updates
<lamont> dle: because feisty hasn't accepted uploads since it released, would be my first guess
<abentley> Additionally, feisty is out of date, and not an LTS release.
<andresj> And because gutsy is the stable ubuntu now
<dle> Mm, good points.
<abentley> So backports are unlikely.
<dle> I notice that ppa has a nice fresh bzr for fesity but not bzr-svn.
<beuno> dle, and, of course, you have ppa's, so it's probably not worj the extra work
<beuno> s/worj/worth
<beuno> agh, it's late
<beuno> poolie, you wouldn't happen to be around, would you?  I was about to mail the list about the "bazaar" package in hardy, and what the chances where that is was bzr == bazaar instead of baz == bazaar
<beuno> it's past feature freeze now, but maybe we can still push the change it considering it's LTS. Many people come into the channel wondering why "bazaar" isn't what they expect
<lifeless> beuno: we need to patch bazaar to recommend bzr
<lamont> beuno: well, if people quit spelling it 'bazaar'.... :-)
<lifeless> beuno: as a transition; there was a thread on debian-devel a while back about this.
<lifeless> beuno: ideally the entire set of transitions is this:
<dle> beuno: Just a few m. ago, I installed bazaar first, before figuring out that it was not bzr.
<lifeless> step 1) 'bazaar' source package stops producing 'bazaar' binary, instead produces 'baz' binary. New 'bazaar-meta' source package produces 'bazaar' binary, which depends on both baz and bzr packages
<lifeless> step 2) - a release later - the 'bazaar' binary stops depending on 'baz', and starts recommending various additional useful plugins.
<beuno> lifeless, and what are the chances that that transition and start for hardy?  I expect Debian to take a bit longer, but considering this is going to be an LTS...
<lifeless> beuno: we can definitely do step 1 immediately
<lifeless> beuno: possibly depending on bzr and recommending baz would be sufficient, and allow 'bazaar' to be in main with the recommended 'baz' in universe.
<db-keen> how do I branch a specific directory from another branch?
<beuno> lifeless, sounds great
<beuno> db-keen, you can't (yet)
<db-keen> that's really killing my enthusiasm
<db-keen> is it planned for the near future?
<lifeless> db-keen: very few (none) of the modern VCS's support this.
<beuno> lifeless, so I can scratch that off my "to-bug" list, or do you want me to file a bug for it?
<lifeless> db-keen: in fact we do support it via a two-step process already; but I'd like to understand what you want it for
<lifeless> beuno: I'd like you to do it :)
 * beuno waits for ubotu to brag about the bug report
<db-keen> lifeless: In this particular instance, I was trying to branch just the ruby bindings to a program written in C. I don't care about the C source files, and I'm not going to compile them myself, I only want to modify the ruby side of the bindings
<db-keen> why checkout the whole thing?
<lifeless> db-keen: generally we'd say that if you want to do that the ruby bindings should be a separate tree
<lifeless> db-keen: there are a variety of reasons for this, but at the heart of it we generate a single transaction for each commit at the top of the tree
<lifeless> db-keen: being able to work on only a subset of the files is a desired feature; but in terms of network traffic and work-during-commit - neither of those will change at all.
 * beuno is off to bed, g'night all
<ubotu> New bug: #193576 in bzr ""bazaar" package should point to bzr instead of baz" [Undecided,New] https://launchpad.net/bugs/193576
<db-keen> how do I undo bzr add?
<db-keen> (I haven't committed yet)
<spiv> db-keen: bzr rm --keep
<lifeless> poolie: Thats a full day for me, two merge/review requests sent in, 1 branch merged. Stacking moving along well. Tchau.
<poolie> lifeless, quick call about this first?
<lifeless> sure
<jml> does paramiko's log go to .bzr.log?
<poolie> jml, no, we need a patch to do that
 * jml uses the One True Patch instead
<jml> +        import pdb; pdb.set_trace()
<poolie> "pp
<poolie> in vim
<poolie> is it really necessary for bzrtools to refuse to run with newer bzrsL
<abentley> poolie: I can't predict what will happen to bzrlib from release to release.
<abentley> During the 1.5 release cycle, the requirements for locking changed between different release candidates.
<abentley> bzr 1.2 had two API breaks.  How can I predict whether they would have affected bzrtools?
<poolie> i think that should be handled by having the new bzr release declare that it breaks bzrtools
<poolie> i'm not a debian packaging expert, but i think that would be a better match
<abentley> Wouldn't the result be the same?  You still wouldn't be able to install bzr without removing bzrtools.
<poolie> it gets you away from making predictions
<poolie> you just declare the breakage when it happens
<poolie> so there are 3 main cases
<poolie> 1- both
<poolie> 1- both of them are uploaded about the same time; an upgrade gets you both of them
<poolie> 2- there's a lag before getting bzrtools released and packaged, but the old one still works
<poolie> 3- there's a lag but the old one is broken
<poolie> declaring that it will not work with later versions disallows 2
<poolie> i'm talking btw about the debian-level rules
<poolie> or that's what i'm looking at now
<poolie> i guess you also have a check in bzrtools itself?
<abentley> Yes, there are checks in bzrtools itself.
<poolie> btw good point about bug priority vs ordering
<abentley> Thanks.  I do see your point about case 2.
<abentley> I guess my one hesitation about that approach is that it doesn't work in cases where the add-on is not packaged by the same team.
<abentley> But if you're willing to test the one-older version of bzrtools with bzr to make sure that it's not broken, we can try it that way.
<poolie> well
<poolie> i might ask a packaging expert about it firsnt
<abentley> Sure.  We'll also want to disable the automatic version warnings for the packaged version.
<abentley> poolie: Did you have any further thoughts about moving BB to Canonical hardware?
<poolie> if bzrtools will give a warning, then the package should probably warn you too
<poolie> so, moving it to the DC will probably have a lot of setup cost
<abentley> poolie: If we test that the old bzrtools isn't broken, I think it's reasonable not to warn.  But it's up to you.
<poolie> because IS is not really oriented towards running ad hoc apps
<poolie> i did have another idea, which was to put it on a vhost somewhere
<poolie> do you still think it's a good idea/worth spending time on?
<abentley> I think it could reduce the connectivity problems and make the home page load faster, but probably wouldn't address the "aaron just broke it" and "aaron didn't know it was broken" issues.
<poolie> right
<poolie> so, what fraction of outages do you think each one is?
<abentley> In terms of duration, I think "didn't know it was broken" is maybe half of it, with connectivity being another third.
<abentley> I break it the most often, but for the shortest length of time.
<poolie> so it probably would be worth the trouble to move it?
<jamesh> blame turbogears
<abentley> I think so, but it's close.
<abentley> jamesh: Someone mentioned I should talk to you about the lp: transport, but I don't remember why.
<abentley> I've been thinking it makes sense to make it into a straight-up directory service rather than a transport.
<jamesh> abentley: that sounds like something lifeless would say
<abentley> jamesh: Yes, I think it was him.
<Peng> Doesn't bazaar-vcs.org have very restricted access to the server, and don't you guys have problems getting attention from the sysadmins?
<jamesh> abentley: and I agree.  The main reason we converted it to a transport was to delay the branch resolution til after get_transport()
<jamesh> i.e. when the branch is used
<abentley> Oh, good I asked, then.  Why do we need to delay the branch resolution 'till then?
<jamesh> abentley: because get_transport() should not block on network access
<jamesh> (so I was told)
<poolie> Peng, it's fairly tightly controlled
<jamesh> abentley: e.g. get_transport('http://example.com/') shouldn't cause a DNS lookup on example.com or attempt to connect to that server
<abentley> jamesh: I think we need to revisit that rule, because doing the lookup immediately would reduce the pain of that indirection.
<jamesh> and there was apparently a bunch of code that expects get_transport() to be cheap
<abentley> Well, I should get some sleep, but let's talk about this again.
<jamesh> okay
<jamesh> I should be online roughly 2 hours after the other .au guys :)
<thekorn> good morning, I've got a problem, I'm using bzr on two different versions of ubuntu (hardy and gutsy)
<thekorn> since yesterday's update of bzr in hardy I cannot acces my bzr branches in gutsy anymore
<thekorn> it seems the branch format changed
<thekorn> is there any way to fix this
<poolie> thekorn, the default format for new branches changed
<poolie> we shouldn't be automatically updating any existing branches
<poolie> you can control it with parameters to init, init-repo, etc
<poolie> you probably want --knits
<poolie> hth
<thekorn> poolie: but automattically changing the branch format is a little bit harsh IMHO
<poolie> that's my point, we have not
<thekorn> without aksing the user
<thekorn> ok
<poolie> i have to go now, if you have other questions and no one can answer here, please mail bazaar@lists.ubuntu.com
<poolie> night
<thekorn> poolie: ok, thanks
<awilkins> jelmer: I ran that pull all night and it's finally finished....
<awilkins> jelmer: 9250 revisions, pulled 100 at a time. I'm not sure there's a great reduction in size over SVN, this is about 2/3 of a 1.5GB repo and the .bzr tree is 1.3GB
<awilkins> And it's only 9250/13000 revisions
<awilkins> But hey, it all worked, no KeyError exceptions, wahey.
<awilkins> jelmer: Branching it runs the memory use up to 620MB at peak, and a fair chunk of CPU time, but it works too.
 * awilkins waits for the interminable sloth that is the NTFS filesystem to finish
<jelmer> awilkins: ah, great :-)
<jelmer> awilkins: that really sounds like the windows build of python-subversion doesn't actually have that patch applied, btw
<matholio> could bzr be used to manage configuration files ?
<matholio> I have a handful linux boxen which I want to have identical config files.
<mwhudson> uh, do the bzrtools-1.2 debs conflict with bzr-1.2
<dato> the package in sid doesn't; I'm not sure what the package in PPA was based on.
<awilkins> jelmer: You could be right, I've just downloaded that package and run a binary compare on the one in site-packages and there are some differences.
<awilkins> Peng: I've tried to import bzrlib on IronPython 2 alpha 8 but fallen at the first hurdle, it goes into an infinite loop defining a function in trace.py
<johnny> does anybody maintain a bzr branch that contains many of the existing plugins? or would that be a bad idea/
<matholio> I'm trying to use bzr to manage config files but I'm not sure I have it right.
<matholio> first I init a folder : cd /foo/etc; bzr init
 * bob2 just did "cd /etc ; sudo bzr init ; sudo bzr add ."
<bob2> but then found I didn't actually want to version a lot of them
<matholio> bzrignore
<matholio> bob once you have commited them how to you use them on another system ?
<awilkins> jelmer: I am an idiot ; it's managed 230 revisions using 360MB, which previously would have run it up over 1GB or even popped the stack
<awilkins> jelmer: Note to self ; make a list, check it twice.
<bob2> matholio: you can copy the .bzr dir to another one
<awilkins> jelmer: It's still far from perfect though, 300 revisions has it up over 500MB, something I suspect, is still leaking in htere.
<bob2> awilkins: does bzr-svn pack things after the import?
<awilkins> bob2: Yes, it just packs as it goes like normal bzr
<jelmer> awilkins: That's not necessarily a bzr-svn problem though, may be regular bzr problem given the size of your tree
<awilkins> bob2: I've also branched it ; all revisions are now in a single pack and it's still 1.3GB
<bob2> ah, ok
<awilkins> jelmer: Yes, it could well be ; I'd guess that with CPython being a reference counter they should either find or write some leak detection tools for it :-)
<awilkins> bob2: There are a lot of binaries in there so it may well be the nature of the source material
<awilkins> Visio diagrams in particular
<bob2> ahh
<awilkins> jelmer: I think those patches have made it a lot faster too
<awilkins> bob2: We've only recently moved to an XML format instead of Visio
 * awilkins swears violently because he just deleted his branch by accident instead of the old one that didn't work
 * awilkins looks forward to another multi-hour pull from svn :-(
<awilkins> Ah well, not like I'm really working on it :-)
<awilkins> Woot, I got bzrlib to import on IronPython
<awilkins> Any tips on how to make it run the test quite from a python console?
<arnarl> I'm getting some "ObjectNotLocked: KnitPackRepository(...path...) is not locked" after I upgraded form 1.0 to 1.2
<arnarl> google didn't yield anything interesting
<arnarl> anyone know what could be causing this or point me in a direction where I can find out what it is?
<Peng> awilkins: Cool. How much work did it take?
<fullermd> arnarl: I'd start with plugins.
<arnarl> ok
<Peng> Oh, good point. arnarl: Try with --no-plugins
<Peng> arnarl: .bzr.log may also say something useful.
<arnarl> will do, the problem seems to intermittent as it works after a few retries
<arnarl> but I probably have some outdated plugins
<johnny> how do you folks work with multiple devs on a project who want to use specific sets of plugins?
<abentley> awilkins: what commands are producing this error?
<abentley> sorry, arnarl: what commands are producing this error?
<arnarl> I was trying to run push and push_and_update
<awilkins> Peng: Well, I had to patch a module.
<awilkins> Peng: But the test suite isn't running because of the platform checks
<arnarl> (works without plugins though, so I'm guessing its a problem on my side)
<awilkins> Peng: os.platform == 'cli' on IronPython
<awilkins> Not sure what it would read on IronPython/Mono (if such a thing exists)
<jelmer> I would guess cli as well
<jelmer> since mono is technically cli too
<awilkins> jelmer: That would be my interpretation, which means you have to answer "does Mono on *nix support the platform features that are checked off) like "signal"
<awilkins> Although a first apatch will be to change all == 'win32' to "in ['win32, 'cli'] and run the tests again :-)
 * awilkins goes about getting a branch
<jdong> >>> platform.system()
<jdong> 'cli'
<jdong> my os doesn't contain a platform attribute on ipy
<jdong> whoa cool, you can call all of .NET from ironpython
 * jdong instantiates a System.Windows.Form....
<jdong> grr it doesn't take ctrl+D
<awilkins> Meh, the 'doze console is lame
<awilkins> I always miss ^U
<jdong> raise SystemExit seems to be the only way
<awilkins> ctrl-Z <enter> should work
<jdong> quite a silly way to exit out of a shell
<jdong> awilkins: yeah but Linux captures that
<awilkins> Doh
<jdong> well ctrl+V ctrl+Z enter
<jdong> I guess that would work
<jdong> nope that is captured too
<awilkins> You pythonics would know this : would you expect the answer to "does this class have __getattribute__?" to be true if it didn't have it, but the parentclass did?
 * awilkins has submitted a ticket to the IronPython issue tracker because IronPython generates code that doesn't think so.
<awilkins> Anyone else getting "Expected a boundary" errors?
<grutte_pier> awilkins: to your __getattribute__ question: I would say: yes
<grutte_pier> If B is a class derived from A, then the relation 'B is an A' holds
<awilkins> That would be my interpreation too ; Liskovs substitution principle n'all.
<grutte_pier> however the function hasattr() would work only on an instance of the class, not the class itself i guess
<grutte_pier> correction: it works on the class definition itself as well
<awilkins> grutte_pier: Oh yes, classes are not quite classes in Python, it's more like JScript (as far as I perceive it)
<ubotu> New bug: #193685 in bzr "bzr 1.2.0: MemoryError when file size ~1M" [Undecided,New] https://launchpad.net/bugs/193685
<awilkins> Naah, I don't beleive it, it's been versioning 50MB files for me today.
<Peng> He's on Solaris. Maybe that platform has some really weird problem?
<Peng> Or he has 10 MB of RAM...
<schwuk> I'm using the PPA, but I can't install bzrtools:  bzrtools: Depends: bzr (< 1.2~) but 1.2-1~bazaar2~gutsy1 is to be installed
 * lamont wonders if folks would like his packaging for bzr/bzrtools for dapper/edgy
<schwuk> I'd be happy with bzrtools working for Gutsy (from PPA)
<lamont> schwuk: I don't have upload privs  to the ppa, but I'll find someone to fix0r it.
<schwuk> lamont: you are a gentleman, sir
<jkakar> So, I just committed a revision, tagged it and then uncommitted it, which resulted in the tag being left bound to a revision reported as '?'.  Is this behaviour expected?
<jkakar> Or rather, is this a bug?
<fullermd> I wouldn't think so.
<fullermd> The ? would be because it doesn't have a revno, not being in the current branch ancestry.  Try it with "bzr tags --show-ids", it should show the revid.
<Bloguero__Connor> hi, I prepared a patch (using bzr send -o user1code.patch) and send it to another user. How this user should use that file to merge it into his tree?
<fullermd> Bloguero__Connor: "bzr merge usercode1.patch".  Or maybe 'pull', if that's the intended use.
<Bloguero__Connor> what is the difference beteen merge and pull?
<fullermd> The short answer is "pull is for updating a mirror, merge is for merging in someone else's changes to a branch you're developing on"
<Bloguero__Connor> fullermd, thanks
<luislavena> hi everybody
<luislavena> wondered if some of the bzr-svn guys are around?
<jelmer> luislavena, hi
<luislavena> jelmer: hi there :)
<luislavena> jelmer: is true that svn 1.4.7 will include backported patch to make bzr-svn compatible without big hacking?
<luislavena> since I'm aware of 1.5, but is a real pain get svn env building on windows...
<jelmer> luislavena: No, only 1.5.0 will
<jelmer> 1.4.7 will include a memory leak fix, but misses some other changes
<luislavena> jelmer: so there will be no chance of getting an official build of python bindings until 1.5
<jelmer> luislavena: yes, correct. However, most Linux distributions already include the required changes in their svn 1.4 packages and there are windows builds
<luislavena> I'm asking this since every time I tried get svn build on windows, was a real nightmare...
<luislavena> and the windows builds link against msvcr80, not the same msvcrt python uses...
<jelmer> the one on http://d5190871.u44.websitesource.net/bzr/ ?
<luislavena> oh, is up again!, last time I checked was down!
<luislavena> who did it? I want to send a big thank you... :)
<jelmer> luislavena: Kevin Light is to thank for them :-)
<luislavena> jelmer: Oh, I'm so anxious to test it on windows... enjoyed on linux... now I'll be in heaven!
<luislavena> jelmer: thank you for the data, the website should be updated with this.. or at least give hosting for the file... :)
<jelmer> it's already mentioned on the bzr-svn wiki page
<luislavena> jelmer: great, just checked... but I my mouth is faster than my hands... sorry about that
<luislavena> is bzr-svn compatible with 1.2?
<luislavena> just checking... just to be sure.
<jelmer> maybe
<ubotu> New bug: #193779 in bzr "bzr+ssh on Win32 dies in paramiko with EOFError" [Undecided,New] https://launchpad.net/bugs/193779
<jelmer> I haven't checked yet
<luislavena> jelmer: I'll be your guinea pig then...
<awilkins> luislavena: jelmer: It seems to be compatible
<luislavena> awilkins: thank you for the info :)
<awilkins> It managed pulling 1.3GB of revisions.. and some minor pushes
<awilkins> Since there are no api deltas between 1.1 and 1.2 (according to changelog) then I would expect it to work
<abentley> awilkins: There are two API breaks listed in my copy of NEWS.
<abentley> I doubt either would affect bzr-svn, though.
<jelmer> awilkins: wow, ok. That would be a first, I think :-)
<awilkins> Ah, I see, whoever uploaded the sources didn't relink to the 1.2 changelog
<awilkins> Naughty nuaghty
<jelmer> bzr has steadily broken bzr-svn each release until now :-)
<awilkins> Humph, there isn't even a 1.2 changelog on the same link pattern as 1.1
 * awilkins stops trusting the wiki editor
 * luislavena agree with awilkins
<luislavena> some housekeeping must be done :P
<awilkins> THe memory usage in 1.2 is much better than 1.1, it makes bzr-svn almost usable on large trees :-)
<foom> nobody updated the summary of new wonderful features in 1.2 either.
<jelmer> awilkins: that still surprises me somewhat, none of the entries in NEWS seem related to decreased memory use
 * awilkins isn't knocking it
<luislavena> mm, is bzr branch supposed to work over password protected svn:// repositories?
<awilkins> luislavena: Do a password-required thing with the svn client and cache your auth
<awilkins> luislavena: Or use svn+ssh and ssh-agent
<foom> (or use svn 1.5 I think jelmer said?)
<luislavena> awilkins: already did, but svnserve.conf states "anon-access = none" .. and bzr branch failed
<lifeless> moin
<luislavena> awilkins: needed to change it to read for it to work... and was working with svn ci and others
<lifeless> foom: hi
<lifeless> foom: have you filed a bug ? :)
<awilkins> Hmm, I agree that bit is a bit flaky.... using 1.5 is out for me until it releases, and also the wider ecosphere of svn tools releases.
<foom> lifeless: Nope. But when I retry everything on bzr 1.2 I'll file bugs this time.
<awilkins> 1.5 breaks the WC format again, I can't risk fubaring all my Eclipse plugins given that my current project has so many source control automations
 * awilkins really wants to use bzr
<lifeless> foom: thanks
<lifeless> awilkins: 1.5?
<awilkins> They do a lot of heinous branching and merging
<awilkins> svn 1.5
<lifeless> awilkins: oh, right
<awilkins> Bah, can't branch bzr.dev from launchpad
<awilkins>  Revision {('robertc@robertcollins.net-20070321041435-lyb7a2hxgb1547mj',)} not present
<lifeless> we're correcting that at the moment
 * awilkins is thankful
<awilkins> does 1.2 work?
<lifeless> we had a unreconciled repository floating around. bad booboo
<awilkins> I just want to start trying to patch it up to support IronPython better
<awilkins> Does launchpad support putting branches in a shared repo with the originating projec tyet?
<luislavena> awilkins: tried what you said aboud anon-access and auth for a repo... bzr branch still yell at me...
<luislavena> awilkins: I need to set anon-access = read in svnserve.conf for the repository so bzr can access it... even that authentication is being stored in subversion.
<lifeless> awilkins: oh hmm, bzr.dev should be fine
 * luislavena is using a copy of the server with svnserve (subversion smart server)
<lifeless> awilkins: awilkins can you try branching bzr.dev from http://bazaar-vcs.org/bzr/bzr.dev please.
<awilkins> lifeless: No probs
<luislavena> jelmer: this should be a problem of python bindings or bzr-svn?
* lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! w00t! | http://bazaar-vcs.org/releases/src/bzr-1.2.tar.gz | bazaar-vcs.org/bzr repo under maintenance
<luislavena> bzr branch svn://localhost/repo/trunk repo-trunk output:
<luislavena> bzr: ERROR: Permission denied: ".": Can't get password
<awilkins> lifeless: I was using the lp:bzr link before
<jelmer> luislavena: what version of the bindings and bzr-svn are you using?
<lifeless> awilkins: it worked ok ?
<luislavena> jelmer: the bindings indicatd in the BzrSvn wiki page and the bzr-svn package from there too (0.4.7)
<jelmer> luislavena: this is a windows-specific issue in bzr-svn, which has been fixed in the development branch
<awilkins> lifeless: It's still going
<awilkins> I only have 2MBit/s bandwidth here
<jelmer> luislavena: however, the development branch has some severe performance regressions atm
<luislavena> jelmer: no problem, I can live with the anon-access issue for the time being :)
<luislavena> jelmer: wanted to know before submit a bug report...
<luislavena> don't want to waste your time or any other developers with duplicated bugs.
<awilkins> lifeless: Same error
<awilkins> lifeless: I'm branching inside a --rich-root-pack repo, is that effecting it?
 * awilkins tries outside in a fresh folde
<lifeless> awilkins: that will be causing it to rewrite the data; and I know there are bugs in that rewrite process
<awilkins> Heh, different error in clean folder
<awilkins> bzr: ERROR: Could not install revisions:
<awilkins> pqm@pqm.ubuntu.com-20080220014008-9appc9kw4rjg8v1k
<lifeless> doing bzr branch http://bazaar-vcs.org/bzr/bzr.dev test-bzr
<lifeless> just worked for me
<lifeless> do you have a web proxy?
<lifeless> actually, just try again, we may have raced with each other
<awilkins> There is a transparent proxy here, ISP flavoured
 * awilkins goes
<lifeless> it shouldn't be an issue actually
<lifeless> we've made our primary files cacheable
<awilkins> Looks healthier so far
<awmcclain> Hi all.. I'm transitioning my team from SVN to bazaar. I'm looking to split up our current SVN trunk into a few sub branches in the bzr repo. I'm trying to make branching as painless as possible. Is there a way to export, say, just the last 30 revisions of an SVN directory into a new bzr branch?
<awilkins> lifeless: Branched 3228 revision(s).
<awilkins> lifeless: And trying to branch it into a --rich-root-pack repo produces the robercollins error
<awilkins> lifeless: Trying the same with a pack0.92 repo works fine
<lifeless> awilkins: please file a bug; not sure where the fault lies
<ubotu> New bug: #193804 in bzr "Branching bzr.dev to rich-root-pack causes error" [Undecided,New] https://launchpad.net/bugs/193804
<abentley> awilkins: You realize your changes won't be mergeable if you do them in a --rich-root-pack repository?
 * awilkins is now using pack0.92 because you can't branch to a rich-root-pack anyway
<ubotu> New bug: #193814 in bzr-svn "find_repository on local disk does network traffic" [Undecided,New] https://launchpad.net/bugs/193814
<jelmer> lifeless: Stop reading my mind!
<jelmer> I was five seconds away from committing a fix for that bug when you filed it :-)
<fullermd> He doesn't need to _stop_; he just needs to do a better job of it   :p
<bob2> or read the fix out of your mind, too
<lifeless> jelmer: :)
<lifeless> jelmer: it just makes you look responsive :)
<igc> mornng
* lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! w00t! | http://bazaar-vcs.org/releases/src/bzr-1.2.tar.gz
<boolegue> hello
<boolegue> anybody to answer question ?
<awilkins> No, we're all dead
 * awilkins moulders
<boolegue> do dead answer bzr question ? ^^
<dato> boolegue: just ask your question and stay around for a while
<boolegue> ok
<boolegue> I renamed and moved to a different directory a file that was versioned, now I want to tell bzr about this and used bzr mv oldfile newfile
<boolegue> but it fails
<awmcclain> I'm looking to split up our current SVN trunk into a few sub branches in the bzr repo. I'm trying to make branching as painless as possible. Is there a way to export, say, just the last 30 revisions of an SVN directory into a new bzr branch? (sorry about the repost, my internet died since I asked earlier)
<boolegue> I get something like bzr: ERROR: Could not rename newfile => oldfile is not versioned.
<dato> boolegue: try `bzr mv --after oldfile newfile`
<boolegue> -- after dont 't improve things
<boolegue> same result
<boolegue> but bzr status tells oldfile has removed
<boolegue> as removed
<bob2> did you run "bzr mv --after filename directory/filename"?
<boolegue> I used full relative paths
<bob2> did mv say anything?
<boolegue> something like bzr: ERROR: Could not rename newfile => oldfile is not versioned.
<bob2> does "bzr status" show the file as newly added, in it's new location?
<boolegue> I tried without and with newfile added to bzr, same result
<bob2> oh, is the dir added?
<fullermd> The simple answer is just mv it back to the old location, then bzr mv it to the new.
<fullermd> (that doesn't necessarily do much to answer "why isn't it working as-is, which it should", but it does get you to Point B)
<boolegue> actually, with newfile versioned, I get bzr: ERROR: Could not move olfile => newfile: newfile is already versioned.
<boolegue> by versioned here I mean added
<fullermd> Yeah, you don't want to do that.
<boolegue> I am using version 1.1 on os x 10.5.2
<boolegue> looks like adding the new directory but not its content worked
<boolegue> with bzr add --no-recurse
<bob2> "bzr mkdir" is handy, too
<boolegue> but status shows oldfile as removed, is it normal ?
<bob2> it should only show up in "renamed:"
<boolegue> it doesn't :-/
<boolegue> oldfile is removed and newfile is added, status said
<bob2> fullermd's right, mv it back to it's original location, then "bzr mv oldfile newdir/newfile"
<boolegue> ok but I have actually about 100 files !
<bob2> did their filenames change or just their location?
<boolegue> both
<boolegue> a painfull task without bzr helping
<bob2> well, you'll need to run "bzr mv --after oldfilename dir/newfilename" the same way you ran the original bzr mv
<bob2> hm, maybe vcs-load-dirs would be the way to go
<bob2> or reverting and starting over (all the mvs would at least be in your shell history)
<boolegue> after doesn't change anything
<boolegue> but wait, now even bzr mv isn't working while it was 5 minutes ago after adding the newdir only
<bob2> oh, you need to "bzr rm --keep" hte incorrectly "added" ones first
<boolegue> I don't get it
<boolegue> I did
<boolegue> the new dir and file is reported as unknown
<fullermd> The dir needs to be known.  You can't add a file inside a non-added dir, or move a file into a non-added dir.
<boolegue> that seems intuitive, is --no-recurse the right option ?
<bob2> yes
<boolegue> ok so how about I revert to the old source tree, then bzr mv, then replace the tree with actual tree (newdir/newfile is a modified oldfile)
<boolegue> ?
<johnny> how do you guys handle sharing a set of plugins among a project with multiple users?
<lifeless> poolie: yesterday I said:
<lifeless> 15:51 < lifeless> poolie: Thats a full day for me, two merge/review requests sent in, 1 branch merged. Stacking moving along well. Tchau.
#bzr 2008-02-21
<poolie> launchpad will be down for 3 hours, starting now
<AfC> Three HOURS?
<poolie> well, the window is that long
<poolie> it will probably be less
<lifeless> AfC: there is a large data-migration task being performed
<lifeless> AfC: to improve performance
<AfC> lifeless: no doubt.
<awilkins> arse, launchpad is down
<AfC> lifeless: planning and executing that sort of event is what we specialize in, after all. I'm just surprised to hear that {the window is that long | there is that much uncertainty associated with the event's duration}. That speaks of a number of issues.
<lifeless> AfC: The test environment provides an upper cap; but exact block usage etc on a filesystem drives actual timings, so there is some variation. We also prefer to surprise than disappoint if the duration announced is wrong.
<poolie> i think the bottleneck here is technical, at the db level, rather than organizational
<lifeless> poolie: well, I think its arguable either way :).
<AfC> We would generally argue that if a technical bottleneck exists at the db level, that is an architectural failure. But that's a conversation a bit outside the realm of operational circumstances, more in line with "what do we do to prevent this from ever happening again". Which, of course, are the best conversations. But in the mean time,
<AfC> yes, there are both technical and organizational issues.
<beuno> AfC, maybe devs didn't setup the enviroment to such a large scale. It happens everywhere
<AfC> beuno: big time
<AfC> beuno: all though Robert did say "test environment" which speaks of a proper pre-production staging facility.
<AfC> beuno: the problem at that level tends to be that at a certain point it is (business economically) impossible to have a duplicate of the production data store as it is usually too big.
<AfC> beuno: and/or they run production on fast kit, but staging on not-fast kit
<AfC> that sort of thing happens a lot.
<beuno> AfC, generally used for new features rather then scaling testing. It's a bit hard to predict _how_ users will use the application. I don't think it's anything our of the ordinary
<lifeless> to be more precise in this case; we're getting a faster database server.
<AfC> Well, it may not be unusual, but it doesn't change the fact that it's pathetic that so many organizations back themselves into such a corner.
<beuno> there ya' go
<lifeless> there is a lot of data to get fully synchronised across.
<AfC> So the architectural failure here is that the system design did not forecast this operation nor allow for it to happen in such a way that did not require hours of downtime. <10 seconds is the usual standard.
<AfC> (but that requires engineering the system to not have a single point of failure)
<AfC> (hence my observation that that's is an architectural problem)
<lifeless> AfC: it requires rather more than that
<lifeless> no single points of failure is neither necessary nor sufficient for this sort of problem - sorry :)
<beuno> AfC, launchpad devs seem to be generally very skilled, I'm sure they have more than enough reasons to do so
<AfC> lifeless: single point of failure in this case is "a single data base that must be downed to do migrations"
<AfC> the fact that your company is offline right now is more than enough evidence to that point.
<foom> heck, the data warehouse at MIT goes down for 4 hours every sunday night for backups.
<lifeless> abentley: mailed re: branch's having the pointer.
<lifeless> abentley: happy to chat in higher bandwidth if you'd like.
<abentley> Sure.  Skype?
<lifeless> yeah, let me change rooms
<awilkins> Is there a reason the tests don't use osutils for platofrm checks?
<awilkins> (I mean a good one, not "meh, platform == 'win32' is easy to type")
<lifeless> abentley: no
<lifeless> meh
<lifeless> awilkins signed ogg
<eetfunk> Hello all!  Is there a way to convert git to bzr?
<jdong> I think you need linus-proof class 10 armor first....
<lifeless> there is an experimental branch of bzr-git that will do conversions; dunno how good it is. There is also Tailor.
<jdong> lifeless: has tailor gotten better at dealing with distributed vcs branching relationships?
<jdong> last time I used it , it was virtually a "playback one revision, commit it to bzr" deal
<lifeless> jdong: no idea
<jdong> whoa, cool, bzr commit --show does --show-diff
<jdong> does that apply to all options? incomplete ones expand out?
<eetfunk> lifeless: thanks, i'll check it out
<abentley> jdong: Yes.  Standard behavior of the Python optparse library.
<jdong> abentley: very cool didn't know that :)
<abentley> It was basically an accident.  Commands don't do that.
<abentley> i.e. bzr com won't commit.
<elmo> hmm?
<Bloguero__Connor> why I am having this problem?: http://pastebin.com/m57a4a9b8
<elmo> st and di work
<elmo> or are they specific short forms?
<abentley> elmo: yes, only specific aliases work.
<abentley> Bloguero__Connor: It looks like in a previous invocation, you did "bzr send sallycode.patch" and it remembered that location.  You need to specify the target branch to override it.
<jdong> abentley: another case of Python Magic (tm)
<Bloguero__Connor> abentley: Yes, that was what happened, now, How I do that (specify the target branch)?
<lifeless> jdong: we'll probably fix this at some point
<jdong> lifeless: is it really broken? Kinda useful for those long options without a short alias
<abentley> Bloguero__Connor: it is the first argument, so you would do "bzr send -o sally.patch TARGET_BRANCH"
<Bloguero__Connor> ok, gonna try
<lifeless> jdong: yes, its broken.
<Bloguero__Connor> abentley: Target_BRANCH is the branch where I want to sen the patch or it is my branch?
<abentley> It is the branch where you want to send the patch.
<Bloguero__Connor> but I want to create a "merge directive" to by send by email.
<abentley> A merge directive needs to know what data to send.  It does this by determining what's already present in the branch you want the directive to be merged into.
<Bloguero__Connor> I have a branch that is a copy of another code (Harry code). Then I made a change. I commited to my private branch (projectY-fromH). Now I want to send the patch back to the main branch (Harrys one).
<beuno> Bloguero__Connor, bzr push branch_location
<Bloguero__Connor> How the receiving location can accept or reject the change?
<Bloguero__Connor> (hola!)
<Bloguero__Connor> Does Harry have a chance to accept or reject what I push to him?
<Bloguero__Connor> BTW, my user don't have write permission in the other's users filesystem. So the push didn't  work.
<Bloguero__Connor> That is why I want to send him a patch using send
<lifeless> Bloguero__Connor: you can push to a public location of your own | harry can give you access to push to his branch | you can use bzr send
<Bloguero__Connor> ok, will try it now
<Bloguero__Connor> lifeless, YES, I see it now. I was the eclipse, now is backing off and I undesrtand :)
<beuno> Bloguero__Connor, or harry can pull/merge from you
 * beuno is off to bed now
<Bloguero__Connor> beuno: I made the send by using Harry path. To create the .patch file I dont need write access
<Bloguero__Connor> gonna sleep, bye!
<lifeless> woo stacked check passing.
<poolie> lifeless: gentle nudge re the baz packages for this week
<poolie> also, woot
<lifeless> poolie: didn't you see me hand off to beuno yesterday :)
<poolie> i saw you talk to him
<poolie> can he actually do it?
<lifeless> he has as much access as I IIRC
<lifeless> in Debian there is a maintainer lock, noone can do it other than anand unless its rc.
<lifeless> in Ubuntu we need to do stuff in main
<igc> bbiab
<lifeless> poolie: 'bazaar' is another possible venue; and the food there is divine :)
<lifeless> 17:01 < lifeless> poolie: 'bazaar' is another possible venue; and the food there is divine :)
<lifeless> wheee done
<lifeless> poolie: it propogated just fine.
<ubotu> New bug: #193893 in bzr-loom "branching over bzr+ssh does not propogate loom threads" [High,Triaged] https://launchpad.net/bugs/193893
<AfC> What's a loom thread?
<mwhudson_> AfC: install the plugin and 'bzr help loom' is one approach
<mwhudson_> it's a way of maintaining separate threads of development in one branch
<mwhudson_> (roughly speaking)
<AfC> Ah
<AfC> Not a fancy new threading system :)
<g0ph3r> hi folks, i'll have a quick question: i'm using bzr + bzrtools on ubuntu but noticed yesterday that upgrading bzr forced bzrtools to get removed. i'm using the bzr PPA packages for ubuntu gutsy. is this an already known issue? does anybody have any idea if/when this is going to get fixed? thanks a lot in advance!
<g0ph3r> my entry in sources.list is (according to the PPA launchpad info): deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
<g0ph3r> now when i try to reinstall bzrtools (version 1.2.0-1) i get the following complaint: "Depends: bzr (<1.2~) but 1.2-1~bazaar2~gutsy1 is to be installed"
<awmcclain> Anyone alive and familiar with bzr-svn?
<jkakar> lifeless: Congratulations on announcing looms!
<deepjoy> I still cant find any reference to bazaar loom short of installing the plugin
<deepjoy> is there a website?
<poolie> deepjoy, just https://edge.launchpad.net/bzr-loom
<abentley> lifeless: I'm looking at test_combine_last_two_threads in the loom plugin, and I don't understand why it ever passed.
<TFKyle> hmm, wonder how reasonable it'd be to push a statically built web ui whenever you push a branch instead of having dynamic ones, it'd probably use quite a bit of space for branches with lots of history or large branches though
<abentley> TFKyle: it would reduce the flexability too-- many web UIs let you compare any revision to any other revision.
<TankEnMate> Why does bzr use so much RAM?
<visit0r> python produces some overhead
<TankEnMate> I'm doing an initial check out of the ubuntu desktop course, and bzr is using about 400M and hasn't written anything to disk..
<TankEnMate> It's enough to turn people off altogether..
<TankEnMate> If I didn't have to check this stuff out I would have given up long ago..
<TankEnMate> Isn't there a way to clone a repo just by using rsync?
<TankEnMate> At last!! After reaching 500+M it has decided to write out..
<TankEnMate> what a disk storm...
<TankEnMate> is there a way with bzr to clone a repo using rsync?
<TankEnMate> guess not...
<lifeless> abentley: I don't understand why the movement of the fetch is needed, the other stuff is obviously correct
<lifeless> jkakar: thanks!
<lifeless> poolie: I need to add loom to the bzr plugins page too
<johnny> how do folks manage plugins across a group of collaborating developers?
<fredp> hi, what would be the easiest way to know if there are uncommited changes ?  I am currenty using if [ $(bzr status | grep modified) ]; then ...
<fredp> but there may be a better way.
<awilkins> You don't count new files as uncomitted changes?
<fredp> this is just to prevent an automatic commit to apply unexpected changes; and I considered people using bzr add would not forget to bzr commit.
<fredp> but better safe than sorry, I'll also check for ^added
<awilkins> And unknown
<fredp> you're right, and removed, and I'll be set.
<fredp> do you know by chance if it is possible to pipe the commit message to bzr commit ?
<fredp> echo whatever | bzr commit --file=- doesn't work
<TFKyle> fredp: and renamed :)
<awilkins> That was weird, I tried piping it in POwershell and I got trapped in an instance of Vim that was pretending to be a shell.....
<TFKyle> (hmm, and kind changed if bzr st shows that)
<fredp> it would probably be wiser for me to match ^[a-z]+:$ to get everything
<tseliot> hi all, I'm having a problem with my bzr branch on launchpad
<tseliot> whenever I try to push the code to my branch I get this error:
<tseliot> http://pastebin.com/m2196a82d
<tseliot> any ideas?
<luks> you can use "bzr break-lock" if you are sure the lock is wrong (for example caused by a network failure on push)
<sabdfl> hey folks, what's the recommended way to convert baz to bzr?
<sabdfl> i found an ooold baz archive and I think it has revisions that never got properly converted
<jrydberg_> who's maintaing trac-bzr these days?
<tseliot> luks: thanks, I'll try it
<timparkin> Hi, I'm trying to use bzr and subversion but am having problems in that bzr-svn needs bzr 1.1 which I can't get hold of (1.2 seems to be the only one available)
<tseliot> luks: it worked. Thanks again :-)
<timparkin> Is there a 1.2 bzr-svn ? or should I try to find a bzr 1.1
<jelmer> timparkin: there is no 1.2 bzr-svn yet
<timparkin> Hi Jelmer - I guessed at the tarball name and path by changing 1.2 to 1.1 which worked fine... It may be useful to add this path to the bzr download page
<timparkin> and thanks for the response ;-)
<awilkins> timparkin: As far as I can tell bzr-svn 0.47 works fine with 1.2 (better, in fact, due to 1.2 improvements) - you can ignore the version warning, or edit the code that checks it.
<awilkins> But jelmer has the final say, of course :-)
<lifeless> sabdfl: bzr baz-import
<sabdfl> lifeless: how do i re-use history?
<g0ph3r> hi folks, the currently available bzrtools package on PPA for ubuntu gutsy is incompatible with bzr. are there any plans to upgrade bzrtools to a compatible version or to fix the package?
<ubotu> New bug: #193980 in bzr "revert after add destroy my working tree" [Undecided,New] https://launchpad.net/bugs/193980
<abentley> lifeless: bzrlib/test/branch_implementations/test_pull specifically tests that fetch is done before raising DivergedBranches.
 * awilkins has just exclaimed out loud that bzr is "freaking awesome"
<awilkins> Just merged two unrelated (but smae content, essentially) trees for the first tim
<jelmer> awilkins, :-)
<decko> Guys, there's any place to download bzr documentation and tutorials???
<jabr> bazaar-vcs.org
<johnny> lol
<jelmer> igc: hi
<No`> hi all
<No`> dunno if it's possible in bzr, but I'd need somthing like the "externals" in subversion
<LeoNerd> Perhaps explain what those are?
<No`> i.e. a branch inside a branch, that I could sync/pull
<LeoNerd> I imagine most of us here aren't that familiar with SVN
<johnny> it's a branch that links to another branch
<johnny> No`, afaik it is not possible yet
<awilkins> "Nested Trees"
<awilkins> Sort of
<johnny> nested could exist without on repository, but what is the other trees are outside of your control?
<johnny> err with one*
<No`> johnny: ah. too bad. If a project shares "libraries" with others, we could have to manually update them together
<awilkins> True... wasn't there some sort of branch manager thingy hanging around?>
<johnny> my related question, is how do you folks handle plugins within a group of devs on a project?
<johnny> that should be a simple question..
<No`> well it's not "out of my control", but I'd like to automagically have a mirror of a library that could belong to a given rep
<johnny> hmm.. i know monotone had a mirror hook
<No`> anyway. if it's not possible, then it's not possible
<johnny> bzr can prolly do the same thing
<tolbrino> Hey guys. I am new to bazaar and wanted to checkout a existing subversion branch with bazaar. I have successfully installed the bzr-svn plugin. But everytime I try to co from svn I receive a "Not a branch" error message. Is that not a supported use case?
<awilkins> tolbrino: Which protocol are you using to access svn?
<VSpike> I'm looking for a bit of best practice advice.  I've been using bzr on a single machine and getting on pretty well with it.
<tolbrino> awilkins: I'm using http
<VSpike> I'd like to create a main branch on a different machine to enable "Team Collaberation, Distributed Style" as shown in the user guide
<awilkins> Try bzr branch svn+http://my/repo my-local-branch
<tolbrino> awilkins: all right, I check that
<VSpike> On that machine, would I normally create a dir or symlink under root to simplify the sftp URLs?
<tolbrino> awilkins: Now I receive a "Unsupported protocol for url..." error
<VSpike> And then create a user account for everyone that wants to access it, probably under a bzr group?
<VSpike> sftp://something.some.net/home/bzr/main is OK I guess
<VSpike> Just wondering how people normally do it
<dato> something like that, yes
<VSpike> Is there any need to create a separate unix account for each user if bzr has its own concept of who people are?
<dato> VSpike: you normally would call the group "projectname" instead of "bzr", and put "main" under /home/bzr/projectname, eg.
<dato> VSpike: well. sharing a single account by everybody would work too, if you want that. that's just server administration realm, nothing to do with bzr :)
<VSpike> oh yeah, understood :)
<tolbrino> awilkins: The subversion repository I want to access does only support http and https
<VSpike> when you identify yourself to bzr where is that info stored?
<luks> tolbrino: is the svn plugin listed in `bzr plugins`?
<VSpike> in the branch you're working on?
<tolbrino> luks: yes it is
<dato> VSpike: depends
<VSpike> or at a user level on your current system?
<dato> VSpike: you can set it by hand in an env. var, or if you use `bzr whoami John <john@foo.com>`, it'll be stored in a configuration file under ~/.bazaar
<dato> ~/.bazaar/bazaar.conf
<VSpike> but the account/identity that I use to sftp into the repo is irrelevant as far as bzr is concerned?
<VSpike> its only a transport level concern
<dato> correct
<VSpike> Great.  Well a single user would work fine for me then I think
 * dato has to leave now.
<VSpike> If I want to move to a gatekeeper model, i can do that with file permissions, can't i?
<VSpike> dato: thanks for the help
<dato> np
<VSpike> simple make the main trunk read only for regular user(s)
<VSpike> but allow them to create/edit branches
<dato> VSpike: you could change the permissions to not allow writing for the shared account
<dato> yes, what you say too
<VSpike> dato: if I did that, by what means would they submit changes?  just tar the whole lot and email it, for example?
<VSpike> dato: if I did that ^ thing you said
<dato> VSpike: there is bzr send
<VSpike> ohh
<VSpike> right .. will read up on it.  thanks again
<dato> that generates a patch + metadata that you can pull/merge from
<tolbrino> luks: Rechecked the plugins. Seems like cygwin(yes I am running windows) did not load it properly.
<dato> leaving nor for real
<VSpike> :)
<VSpike> bye!
<tolbrino> luks: The plugin is working now. But bazaar shows another error even when I just type "bzr version".
<tolbrino> I guess that is caused by the version bzr which cygwin uses. Version: 1.0.0
<tolbrino> Further upgrading to version 1.2.0 did not help. The error is : "AttributeError: 'module' object has no attribute 'svn_swig_py_cancel_func' in client.py
<tolbrino> Any help?
<luks> are these the patched svn bindings?
<luks> I'd try native bzr and the binaries linked on the website
<tolbrino> ok, I double check that
<tolbrino> Yes, I have installed the patched subversion bindings
<jelmer> tolbrino: that error suggests the python-subversion installation is corrupt
<tolbrino> jelmer: well, maybe the source I have used for cygwin do not fit. I used the ones provided on http://d5190871.u44.websitesource.net/bzr/
<jelmer> tolbrino: I don't think those are meant for use with cygwin, but with the native build of bzr for windows
<tolbrino> ok, are the patched subversion bindings provided somewhere?
<jelmer> the patches are listed on the page you just mentioned
<jelmer> I don't think there are binaries for cygwin available
<mtaylor> bzr: ERROR: The branch format bzr loom format 6 (based on bzr branch format 6)
<mtaylor>  is not supported by loomify.
<mtaylor> um
<mtaylor> huh?
<mtaylor> fog: how do you get this to show in your user: n=fog@debian/developer/fog ?
<fog> mtaylor: it is a cloak.
<fog> mtaylor: you can ask for a cloack if you found the irc netowork or are part of some kind of org
<mtaylor> fog: cool. thanks
 * mtaylor learns new things
<fog> :)
<mtaylor> anybody on with loom zen?
<tbye> Could an OS X 10.5.x user help me to uninstall the .dmg?  I need features in 1.2 and will be installing from the src tar.gz.
<tbye> Is there an uninstall procedure for the OS X dmg's?
<abentley> mtaylor: It looks like your branch is already loomified.
<johnny> tbye, not that i know about
<mtaylor> abentley: so I loomified a branch (trunk) , then branched that branch to a new branch (new-trunk)
<tbye> I'm noticing on the wiki that "a one-touch uninstall" is listed as a missing feature. :-(  I'm looking through the package content to uninstall manually.
<mtaylor> abentley: the new-trunk branch didn't show anything in show-loom
<abentley> mtaylor: branching usually preserves the source format.
<mtaylor> abentley: ok, so did I not get the loom as well because I hadn't done bzr record in the trunk branch?
<abentley> Well, I know about as much about looms as you do.
<abentley> But I would assume branch only copies the traditional branch data, not the thread info.
<jelmer> abentley: So is loom like git-style branching?
<abentley> jelmer: A bit.  The main thing is that it's an ordered list of branches.
<abentley> (each called a thread)
<abentley> But like git, the threads are all associated with a single repository and working tree.
<Yasumoto> Hey guys. I'm trying to install bzr (and bzrtools) but am having some issues with the python2.5 bzrlib. "Please check bzrlib is on your PYTHONPATH."
<Yasumoto> I've been searching on google and trying to figure out how to fix my pythonpath, but I'm not having much luck
<jelmer> abentley: Ah, thanks
<awilkins> Hmmph, I'm getting a "Not enough space" error on some long line diffs
<mtaylor> abentley: so do you know if there's a way to merge/pull or push all of the threads associated with a branch? because merge, etc. each seem to operate on the active thread (other than the first push to create a new branch)
<abentley> mtaylor: No, I don't know that.
<mtaylor> ok.
 * mtaylor is trying to figure out when to use loom and when to use different branches and stuff
<abentley> mtaylor: I think for publishing purposes, looms aren't too hot right now.  Because you can't really ask people to pull or merge from a particular thread.
<mtaylor> abentley: ok... so for now they're mainly good for work on my personal computer
<fullermd> Looms are stored in the branch, so I could branch a loom'd branch [in the same repo] and blow away all the threads except the base?
<jdong> I think there's some confusion looming about... urgh forget it too early in the morning to pun
<abentley> It's always too early in the morning somewhere :-)
<Yasumoto> jdong: brutal, haha
<abentley> fullermd: I think that's not quite right.
<abentley> I think the last_revision for a loomified branch is set according to the *current* thread, not the *base* thread.
<mtaylor> that's what record does, right? set's last_revision?
<mtaylor> so what exactly does that mean... does that set the revision up-to-which to branch if I branch from that branch?
<mtaylor> branch branch branch
<fullermd> Well, what I was thinking (from glancing at the docs) is, the stack of threads is a single stack, so if I want to make a new one on top of the base unrelated to the others, I'd have to make a new branch of the base, and create on top of that, right?
<abentley> mtaylor: No, IIUC, up-thread and down-thread set last_revision, not record.
<mtaylor> so what does record do?
<mtaylor> fullermd: that's how I understand it
<fullermd> It sounded to me like 'record' was sorta a 'meta-tag' on the state of all the threads at the given time.
<mtaylor> yeah - but since I can't actually sync the state of all threads at a given time to somewhere else, I'm confused
 * mtaylor hopes he doesn't sound too negative - he likes the overall concept, just is trying to figure out how to use it
<abentley> mtaylor: I may be wrong that push/merge don't work, since the docs say they do.
<fullermd> I think push/pull are supposed to, though lifeless did file a bug about bzr+ssh not doing so.
<fullermd> (presumably, bzr and bzr+http as well)
<mtaylor> ahh.... so push and pull do the full loom, but merge is the thing that's just getting the currently active thread
<mtaylor> let me try that...
<mtaylor> nope
<mtaylor> push pushes the current thread into the current thread of the other branch
<mtaylor> so I guess there's just a semantic issue of not being able to specify "I'd like to merge the thing this working tree is associated with to/from this other specific thing" and "I'd like to sync this loom to this other loom"
<abentley> fullermd: going back to your "unrelated threads" thing, uncommit and pull --overwrite provide ways to change a branch/thread into something completely unrelated.
<abentley> But having unrelated threads defeats the point of looms.
<abentley> The point being that this is an ordered set of branches, each building on the last.
<fullermd> Yeah, but I don't want to change, I want to have something else.  branch (AIUI) will branch the whole loom, not one thread out of it.
<fullermd> So I'd have to blow away all the threads other than the base in the new copy, if I want to make a new unrelated thread on top of the base.
<abentley> If you have something, and you want something else, how can that happen unless you change something.
<fullermd> I was verifying that all the loom info is located in the branch, so if I do that in a shared repo, it's not going to do anything to my original loom (which I still want to go on with for whatever it's currently doing)
<fullermd> I don't want something else _instead_, I want something else _in addition_.
<abentley> Right, so you create a new thread, and then you change it into what you want.
<fullermd> Yeah, but I want that new thread in a different loom, because it's intended to be a new layer off the base, not depending on other threads in the current loom, nor having any of them depending on it.
<lifeless> moin
<lifeless> fullermd: hi
<abentley> fullermd: huh?
<abentley> If you want the new thread to be in a different loom, you create it in the different loom.
<lifeless> fullermd: the idea is that a loom is a single think working towards a feature X. Do you want this thread to be part of feature X?
 * fullermd doesn't think we're connecting...
<fullermd> The loom is in the branch entirely, right?  Nothing at all to do with the repository?
<abentley> fullermd: yes.
<lifeless> fullermd: the loom is versioned, to allow collaboration
<lifeless> fullermd: the versioning gets stored in the repo, but if you don't record it, then nothing goes into the repo
<fullermd> When I "branch" a loom, I get a new loom that's a copy of the original?  Or do I get one with just the active thread?
<abentley> Oh, I thought the versioned stuff was in the branch, too.
<james_w> hi lifeless, thanks for the loom plugin. I'll try and look at it this weekend.
<lifeless> abentley: well, I didn't want to reinvent the wheel, it just uses a specific file id.
<lifeless> abentley: rather like inventory does.
<lifeless> james_w: hi, cool.
<BasicOSX> Anyone able to get loom working with1.3.0.dev.0? I submitted a bug on it, but thought I'd ask here
<abentley> lifeless: Come over to the Storage dark side.  We have namespaces for you. :-)
<lifeless> BasicOSX: its working for me :), whats happening for you
<lifeless> abentley: yeah well :>
<lifeless> abentley: what I've done as a new namespace would be wrong fwiw.
<BasicOSX> lifeless:  needs to be in plugins/loom
<BasicOSX> I did plugins/bzr_loom
<BasicOSX> :-(
<lifeless> BasicOSX: thats right :)
<abentley> lifeless: I don't know if you saw my response, but moving fetch is required to pass the bzr test suite, which expects fetch to be done before DivergedBranches is raised.
<lifeless> fullermd: when you branch a loom, you get the last recorded loom
<lifeless> abentley: ah!. So, I did merge your patch; but I think we should fix that in the bzr test suite, as its arguably wrong.
<abentley> I make no judgement about whether that expectation is sane.
<abentley> But it even had a comment saying that was intentional.
<lifeless> blink.
<lifeless> I can imagine why, I think we were smoking toenails.
<fullermd> lifeless: So if I branch a loom, blow away all but one of its threads, then create a new thread in it, that will have no ties to the original loom that will affect it?
<lifeless> fullermd: if the loom has been recorded, they will have a common ancestor
<lifeless> and once my aroundtuit of hooking in 3-way logic is done, doing a pull back to the other branch will remove its threads.
<lifeless> fullermd: lets step away from the machinery for a second, and have you tell me what you want to _achieve_
<abentley> lifeless: You are doing source.repository.get_ancestry.  Am I reading this wrong, or is that a network operation?
<fullermd> lifeless: OK.  I have a loom, say based on an upstream thread.  There's a thread on top of that with a change intended to go upstream 'sometime', and a thread on top of that with some local change I want depending on them.
<lifeless> abentley: it is; theres a lot of room for improving looms to use our newer better apis.
<abentley> lifeless: So I'm reasonably sure the test was based on the premise that such checks should be done on the local repository always.
<fullermd> lifeless: I want to make some other change to send upstream, based on the upstream, but TOTALLY unrelated to any of that.  How do I make a new loom based on that upstream thread, with no relation to or effect upon the loom I have (which I intend to keep and keep working on by itself)?
<lifeless> abentley: I think the assertion was about performance and not copying data twice; otoh I thinkmerging $private code to $public branch by mistake should error and -not- have inserted the data.
<fullermd> The obvious way to me is to branch the upstream thread, or failing that, branch the loom and whack those other threads in the new copy.
<lifeless> fullermd: so two things here.
<lifeless> fullermd: I don't expect 'trunk' to be a loom ever.
<lifeless> fullermd: looms are a tool for folk preparing things for merging to trunk.
<lifeless> fullermd: so if you have a loom from someone else, its because they are working on a feature X to go in trunk, and which you want to either use that feature, or collaborate on its development.
<fullermd> I'm assuming that the upstream thread in this loom I'm working on is the only copy of the upstream I have handy.
<lifeless> fullermd: now, if you want to do two things at once: develop a feature Y, not depending on X, and, use a version of the code that combines both X and Y.
<lifeless> fullermd: have I got your use case approximately right ?
<fullermd> Half; I don't want the latter at all, just the former.
<fullermd> Doing it now, I'd have branches A and B based on trunk, and C based on A.
<lifeless> fullermd: so the use case is 'I have a loom containing trunk and feature X of a project; I want to develop a feature Y not related to feature X.' How do I do that ?
<fullermd> Right.
<lifeless> fullermd: I'm not sure where C comes in, if my pithy version is right.
<lifeless> anyhow, heres what I'd do:
<lifeless> bzr init X; bzr nick trunk; bzr loomify; pull -r thread:trunk ../Y; bzr create-thread X; hack hack hack
<lifeless> fullermd: if you map every branch to a thread, looms work best when there is a linear path rather than a graph, because the workflow is a compromise between infinite flexability, and pragmatic use.
<lifeless> fullermd: that means if you have two branches you would not merge, you would keep them in separate looms
<lifeless> fullermd: if you have a branch you'd merge into every feature branch, you'd slot it into every feature loom
<lifeless> fullermd: one thing to think about is that better cherrypicking will make looms much more powerful.
<ubotu> New bug: #194099 in bzr "Unable to load plugin 'bzrloom' " [Undecided,New] https://launchpad.net/bugs/194099
<lifeless> james_w: when you say 'look at', do you mean package? :)
<fullermd> Hm.  Could "branch -rthread:trunk" work?
<lifeless> fullermd: both branch -r thread: and pull -r thread: need some ui care
<lifeless> fullermd: branch -r thread: should indeed give you a regular branch
<lifeless> fullermd: and pull -r thread between two looms should pull a single thread not the entire loom.
<lifeless> I think both of these are in TODO
<fullermd> Reasonable enough.  Thanks.
<lifeless> fullermd: what do you think of looms so far ?
<lifeless> mtaylor: merge is one of the things that is not fully implemented in looms
<lifeless> mtaylor: if you wanted to do the work on it it should be fairly straight forward.
<lifeless> mtaylor: and I'd be delighted to mentor
<lifeless> mtaylor: what merge should do is add the loom being merged to the loom parents, which gives you essentially a merged working tree, for every loom in the stack.
<mtaylor> lifeless: yes... that's the behavior I expected...
<lifeless> mtaylor: then from the bottom up, if a fast-forward is possible on a single thread, do it, otherwise stop on that thread for the user to merge and commit, then go up to the next thread, etc
<lifeless> mtaylor: and going up naturally merges as well, so some ui care is needed (or perhaps getting 3-parent trees is appropriate here).
<lifeless> the loom on disk has all the needed slots to handle this, so no formatting or serialisation stuff is needed.
<lifeless> jelmer: you can use loom to do git style branching - ignore the record and up-thread/down-thread commands. Then just use 'bzr switch' and 'bzr merge -r thread:threadname'
<lifeless> jelmer: but git-style branches are not versioned structures that can be merged and annotated; looms are. I see this as an ok, but natural tension.
<mtaylor> lifeless: what if the merge just did the merge in each thread like you mentioned...
<mtaylor> lifeless: oh, nevermind...
<mtaylor> fingers went faster than head
<lifeless> mtaylor: you are merging two things - the shape of the loom, and the content of each thread :)
<mtaylor> yes
<lifeless> fredp: bzr st || echo 'changes' perhaps ?
<jelmer> lifeless: Not sure I understand what you mean
<jelmer> lifeless: Can't be merged and annotated?
<lifeless> sabdfl: sorry, I was on the way to bed when I answered you; baz-import will create ghost-links appropriately.
<lifeless> sabdfl: if you are within a shared repository, that will reuse history for you
<lifeless> jelmer: the existence of a thread has history
<lifeless> jelmer: so that I can branch you loom for (say) kerberos AD support; remove a thread, record, and when you merge me the removed thread gets removed.
<lifeless> jelmer: but if you revert that thread back and record, subsequent merges from me will not remove the thread.
<jelmer> thanks for the explanation
<jelmer> it's still not entirely clear to me but I guess I should just try it
<lifeless> jelmer: or in packaging, if debian and ubuntu both use a loom to package FOO, there will be an ubuntu thread debian don't want. so when debian merge ubuntu they discard that thread, and when ubuntu merge debian the first time after they revert to keep it.
<lifeless> jelmer: uhm. git's list of branches is static. To combine them is a two-way operation. Looms is versioned, combining is three-way. Is that a better explanation ?
<jelmer> lifeless: ahh
<jelmer> yeah, makes more sense now
<lifeless> so the goal of loom is to build upon this versioned history the ability to collaborate on the list of branches
<lifeless> which only really makes sense if you have some particular thing you are collaborating on - e.g. packaging something, or a feature
<lifeless> I often present loom as 'versioned queues'
<fullermd> lifeless: Oh, my interest and questions are purely academic.  I don't really see anywhere they'd fit my uses.
<jelmer> lifeless: So it's a bit like that mercurial feature people keep asking about?
<jelmer> mq or something?
<lifeless> yes, loom is a superset of mq
<lifeless> and of stacked git
<lifeless> and quilt
<awmcclain> If I have a bzr branch at /foo, and I want add a level to the root directory (to make the branch look like /baz/foo), how would I do that?
<lifeless> awmcclain: mkdir /tmp; mv /foo /tmp/foo; mv /tmp /baz ?
<awmcclain> and then commit that back to the repo?
<lifeless> oh, sorry, if this is al versioned files then:
<jelmer> lifeless: nice
<awmcclain> Exactly
<awmcclain> I want to do this all in the repo
<lifeless> mkdir baz; bzr add baz; bzr mv <list of root paths here> baz; bzr commit
<awmcclain> a ha!@
<awmcclain> ok
<lifeless> awmcclain: I'm worried that you are conflating 'repo' and 'tree'.
<fullermd> Is there some rich-root way of moving the actual rich root?  So potential merges could DTRT?
<awmcclain> lifeless: I'm sure I am, I'm quite new. :)
<lifeless> awmcclain: repositories do not version the list of branches or the shape of the repo.
<awmcclain> Porting from SVN
<fullermd> Something like mtn pivot_root, I guess.
<lifeless> awmcclain: ok, a major difference for you then is that branches are not versioned by the repo. branches record versions of trees.
<beuno> theoretical question: I've got about 200 branches of different size and shapes. About 20 users branching them to their home folders (all on the same server). Would it make sense to have a shared repo on the top level?  Will it decrease performance?  Will file permissions collide among users?
<mtaylor> lifeless: I'm about to go get on a plane, but I'll ping you next week about merges
<lifeless> mtaylor: cool
<lifeless> beuno: I would let different users have their own repo; but it would probably work
<lifeless> got to run for a bit, I will be back in a couple hours
<awmcclain> lifeless: Ah. So I should have said, "I want to change the structure of the tree within my branch"
<beuno> lifeless, that's the current setup. I was just wondering if it was worth having shared repos to save space.  Thanks.
<lifeless> awmcclain: yes; that parsing unambiguously.
<lifeless> grammar bad mine :)
 * lifeless goes
<awmcclain> Ok, so I'm importing my SVN directory "panda" into my shared bzr repo as a new branch. I want the tree to look like panda_src/panda/, though. Do I branch the panda directory into the repo, then check it out, bzr add panda_src; bzr mv panda into panda_src, then bzr commit?
<oly> hi, is there a way to check all my local files with remote ones and repull any that do not match
<oly> both versions say there the same, but some of my files are slightly different
<beuno> oly, bzr pull --overwrite
<thatch> oly: bzr revert?
<oly> okay, will give them a go and see where i end up, cheers :)
<lifeless> awmcclain: two questions; have you considered just pull with bzr-svn ?
<awmcclain> lifeless: That's what I was about to do... you mean pull rather than branch?
<lifeless> awmcclain: secondly, when you say you want the tree to look like that, you realise that means that anyone making a new branch will have 'panda_src/panda' in the branch ?
<awmcclain> lifeless: I guess I'm really confused about the notion of branches and trees then. Right now, my SVN directory structure looks like blah/blah/panda_src/panda blah/blah/panda_src/other_stuff ...  My thought was to split up my projects into branches in my shared repo.
<lifeless> right
<lifeless> so you want a branch where the tree starts from the path 'blah/blah/panda_src/panda
<awmcclain> However, I want my developers to be able to branch "panda_src" becuase the dev environment requires a directory above it.
<lifeless> awmcclain: with respect, I suggest that you ignore that :)
<awmcclain> So: I could either "import" (using bzr-svn) panda_src and lop off the unneeded subdirectoriees
<awmcclain> Or import panda and add a directory
<lifeless> awmcclain: your current repository is structured so that either you have everything under panda_src versioned as one tree, or you have everything under panda_src/panda as one tree
<awmcclain> correct
<rysiek|pl> hi all
<lifeless> awmcclain: so I'd worry about getting your history migrated cleanly. having to have a directory above seems like something very easily documented :)
<rysiek|pl> guys, I am having a serious problem here
<rysiek|pl> here's the crashdum
<rysiek|pl> p
<rysiek|pl> http://www.wklej.org/id/e7bbf75efb
<rysiek|pl> generally it's about "end of file reading from server."
<rysiek|pl> while the server is AOK (it's a bzr+ssh server and worked fine just a minute ago)
<awmcclain> lifeless: So maybe it'd be better to just pull panda_src from svn, then trim off the unneeded branches in bzr?
<rysiek|pl> I need to get this up-and-running ASAP, any ideas what might be the cause?
<lifeless> awmcclain: if you do that you will be carting around the unused directories in your history forever.
<awmcclain> lifeless: exactly. :(
<awmcclain> forrreeeevvvveeeer
<lifeless> awmcclain: which is why I wouldn't; I would just documented that you need to mkdir foo; bzr branch $URL foo/panda
<lifeless> awmcclain: and file a severe bug that this has to be done and shouldn't.:)
<lifeless> rysiek|pl: check your permissions
<lifeless> rysiek|pl: mkdir is failing
<rysiek|pl> humm
<rysiek|pl> perms sez you
<awmcclain> lifeless: Unfortunately that doesn't help me, since makes another step every time I branch... and the whole reason I'm switching is to encourage everyone to branch.
<awmcclain> lifeless: I'm not worried about losing history on this so much
<lifeless> rysiek|pl: also, consider upgrading to bzr 1.2 ;)\
<lifeless> awmcclain: well you can add the directory inside the tree after you've got everything converted
<rysiek|pl> yeah yeah, as soon as it gets into Debian and Ubuntu repos ;)
<lifeless> awmcclain: as previously documented
<lifeless> rysiek|pl: for ubuntu there is a ppa we maintain
<awmcclain> lifeless: Ok, that's what I thought originally. :)
<awmcclain> lifeless: Thank you so much for the help.
<lifeless> no probs
<awmcclain> Any suggestions for the standard distributed workflow? When do you decide to backup your local feature branch?
<rysiek|pl> lifeless: hummm... any hints which file/dir should I check?
<lifeless> awmcclain: I don't back up branches; I publish them ;)
<lifeless> rysiek|pl: .bzr/branch/lock and .bzr/repository/lock
<rysiek|pl> lifeless: I have a script that sets-up proper perms, and I run it everytime I do a bzr ci
<rysiek|pl> ok, checking, thanks
<rysiek|pl> lifeless: on server-side, right?
<lifeless> yes
<awmcclain> lifeless: When do you decide to publish your local feature branches to a central, backed-up location?
<awmcclain> ;)
<lifeless> awmcclain: For many things I use launchpad; generally I push early push often
<awmcclain> Ok. Great! Again, thank you so much. It really helps new users when there's a good community. It's one of the reasons I chose bzr over hg.
<rysiek|pl> lifeless: humm... it's rwxrwxrwx now... and still same thing
<rysiek|pl> hmmm
<rysiek|pl> the lockdirs exist
<rysiek|pl> should I delete them?
<lifeless> rysiek|pl: it may be trying the wrong path
<lifeless> rysiek|pl: no
<lifeless> rysiek|pl: you shouldn't need to be chmodding or touching the inside of .bzr at all
<lifeless> rysiek|pl: perhaps the path you are using is wrong
<rysiek|pl> that would be most strange, as - as I said - few minutes before it worked
<lifeless> rysiek|pl: what url are you pushing to
<rysiek|pl> it got saved in the bzr settings somewhere, so you need to tell me how to check it
<lifeless> 'bzr push' will show it
<rysiek|pl> but won't it push my rev to the server?
<lifeless> what operation is failing
<rysiek|pl> bzr ci
<lifeless> whatever operation is failing is doing it on a url
<lifeless> ok; bzr info then
<lifeless> will say where it is a checkout of
<lifeless> how did you get the checkout - did you do 'bzr checkout' ?
<rysiek|pl> bzr ci the_path
<rysiek|pl> *co
<lifeless> ok
<lifeless> and what was the_path
<rysiek|pl> http://wklej.org/id/a96f92e5a7
<rysiek|pl> there you are
<rysiek|pl> "serwek" is one of the machines on ma LAN
<lifeless> ok.
<rysiek|pl> and there is a corresponding entry in /etc/hosts
<lifeless> and the branc is in /var/bzr ?
<rysiek|pl> nope
<rysiek|pl> /var/bzr/ypdf
<rysiek|pl> I did a bzr up *minutes* before trying to do a ci that failes
<rysiek|pl> lifeless: ^^^
<rysiek|pl> lifeless: and it went AOK
<lifeless> rysiek|pl: thats because its write permission that is failing
<rysiek|pl> ah, right
<lifeless> can you do bzr info -v bzr+ssh://server/var/bzt/ypdf
<rysiek|pl> moment
<rysiek|pl> loading, please wait ;)
<rysiek|pl> lifeless: http://www.wklej.org/id/08520be458
<rysiek|pl> lifeless: and made by root@serwek: http://www.wklej.org/id/8ec0664769
<rysiek|pl> lifeless: any pointers?
<rysiek|pl> lifeless: and how do you know it's related to mkdir? I can't seem to find it in the dump
<lifeless> rysiek|pl: File "/usr/lib/python2.5/site-packages/bzrlib/transport/remote.py", line 213, in mkdir
<rysiek|pl> ah
<lifeless> try doing 'ssh serwek mkdir /var/bzr/ypdf/.bzr/branch/lock/test'
<lifeless> also ssh serwek cat $$HOME/.bzr.log
<lifeless> may give more diagnostics
<rysiek|pl> worked AOK
<lifeless> what filesystem is /var/bzr/pdf on ?
<rysiek|pl> lifeless: wouldn't cat ~/.bzr.log be shorter? ;)
<lifeless> rysiek|pl: you need to expand it on the remote server
<lifeless> rysiek|pl: as the user the bzr serve process is invoked as
<rysiek|pl> ah
<rysiek|pl> you're right
<rysiek|pl> lifeless: .bzr.log
<rysiek|pl> http://www.wklej.org/id/104ee48b3a
<lifeless> thats got no record of commands running
<lifeless> are you sure its the entire thing?
<lifeless> I have to go for a bit; back in < 30
<rysiek|pl> 'kay
<rysiek|pl> yeah, it's the whole thing
<rysiek|pl> in the mean time I'll try to update bzr on the server
<Le-Chuck_ITA> Hi all
<Le-Chuck_ITA> how do I revert a bazaar branch to a given version?
<rysiek|pl> man bzr? :)
<rysiek|pl> bzr revert -r NUMBER
<Le-Chuck_ITA> oh
<Le-Chuck_ITA> this is not the right time to work :)
<luks> revert as in change files as they were in that revision, or make a branch of that revision?
<Le-Chuck_ITA> sorry for dumb question
<Le-Chuck_ITA> revert takes an argument, oh yes ::()
<Le-Chuck_ITA> I just want to get back to rev n xxx
<Le-Chuck_ITA> and I was obviously missing the -r switch
<Le-Chuck_ITA> I am too tired
<Le-Chuck_ITA> thansk
<luks> then you probably want uncommit
<luks> or bzr branch -r X
<rysiek|pl> Le-Chuck_ITA: no prob
<luks> revert will change your working files
<luks> and then you can commit those changes
<Le-Chuck_ITA> yes but I just copied them so I won't care - I need to test if a previous release really did what I remember
<luks> I'd make a new temporary branch then
<Le-Chuck_ITA> yes I did tha
<Le-Chuck_ITA> t
<igc> morning all
<igc> hi jelmer
<Le-Chuck_ITA> igc: where are you ?
<igc> Brisbane, Australia
<jelmer> igc: I was just curious whether the fast-import stuff is faster than bzr-svn's svn-import and if so, how?
<Le-Chuck_ITA> so good morning igc
<igc> morning Le-Chuck_ITA
<lifeless> jelmer: I doubt it will have the right ids ;))
<igc> jelmer: I'm yet to compare to be honest
<jelmer> lifeless: well, I'm mainly interested in stealing ideas from it
<lifeless> igc: whats the interface fast-import exposes? does it capture renames?
<jelmer> igc: Ah, so the bzr side of it doesn't have any specific optimizations?
<igc> jelmer: yes, the bzr side is optimised to my current ability :-)
<igc> I know lifeless and others could go further of course ...
<igc> but there's enough 'tricks' in there already
<igc> jelmer: the code that might be of interest is called revisionloader.py
<igc> that's where most of the time is saved over vanilla bzr importers
<lifeless> igc: what does it do that is different, and is it _correct_ ?
<igc> lifeless: the fast-import stream spec does include renames
<lifeless> igc: and empty directories? symlinks? file copies?
<igc> it caches serialised inventories & skips a check for existence mainly
<lifeless> igc: you've found a new toy; I want to find its edges :))
<igc> oh - there *are* edges
<igc> right now though, my immediate focus is solving the OOo into Bazaar dilemma
<igc> I'm down to 100 commits in around 2 minutes but ...
<lifeless> wow, registering a registered branch is fugly
<lifeless> page long traceback
<igc> that still implies a 12 days conversion
<lifeless> igc: you using packs ?
<igc> yes
<igc> of course
<lifeless> igc: some things
<lifeless> hold a write lock the entire time
<igc> inventory.copy takes 20%
<lifeless> if you can, do a single write group for say 100 commits
<igc> I'm pretty sure I'm holding one write lock as suggested
<igc> by default, it's one write lock for 10000 commits :-)
<lifeless> if you're using commit builder that won't be possible at the moment
<lifeless> one write lock for the entire operation, don't drop it at any point.
<igc> there's a command line param to tune that though
<lifeless> inventory.copy - yeah. use my journalled inventory format (kidding!)
<igc> I'm really looking forward to it after these last 2 weeks on this project
<igc> i.e. the migration project
<igc> lifeless: all the work you did on commit has been essential for making import faster of course
<igc> I'm not quite gaim to skip some of the checks though for data from a foreign source
<igc> s/gaim/game/ :-)
<lifeless> igc: thanks
<ja3> igc: just to be clear, a write group is different than a write lock
<jam> you would hold a write lock for the whole time
<igc> jam: doing that
<ubotu> New bug: #194161 in bzr-loom "up-thread, down-thread and switch are slow" [High,Triaged] https://launchpad.net/bugs/194161
<rysiek|pl> lifeless: update to bzr 1.1 on the server solved the problem
<rysiek|pl> lifeless: I must have gotten some update of bzr on the desktop lately, and that broke desktop<->server communication
<rysiek|pl> lifeless: thanks for your help :)
<eric_programmer> I'm trying to understand the support for nested trees. Some docs on the websites says it is still in development while other docs say it was included in release 0.15rc1.
<eric_programmer> I have an existing branch. I want to import another project as a directory in this existing project.
<eric_programmer> I tried "bzr branch http://other/project other_project"  This worked but it says other_project is unknown when I do bzr status and I cannot add it to make it known. Am I misunderstanding something?
<lifeless> eric_programmer: the disk format is supported; but the ui for it is unpolished
#bzr 2008-02-22
<eric_programmer> lifeless: I am just a user. So when you say unpolished do you mean it is not really supported yet or do you mean it just is a little more pain than it will eventually be?
<lifeless> eric_programmer: I mean lots of rough edges; possible bugs. I wouldn't use it unless you plan on helping finish it off :(
<lifeless> eric_programmer: sorry :(
<eric_programmer> lifeless: No problem. Is there any alternatives. I looked at the config-manager but didn't quite understand how it fit into things. I am coming from SVN + Piston so am looking for somewhat of an equivalent.
<lifeless> I don't know what piston does
<eric_programmer> lifeless: Basically is a add-on for SVN. Works a little like svn:externals but actually puts the source of the vendor code in your own tree. This way you can make changes and track those changes. But then later do a piston update vendor/some_lib and it will pull in the latest from that project merged in with your changes. This way you can make local changes and control when updates come in from vendors.
<lifeless> eric_programmer: config-manager can do that' basically you record all your externals in a flat text file
<eric_programmer> lifeless: OK, I'll have to check that out more carefully then. Sounds like it may be what I am looking for until Bazaar get's full support. Thanks!
<lifeless> eric_programmer: you want the python codebase
<awmcclain> Is it possible to have more than one (non-nested) tree in a branch?
<awmcclain> I'm still trying to wrap my brain around this.
<lifeless> awmcclain: no; a branch is a pointer to a revision-tree
<lifeless> when you commit the pointer is changed
<awmcclain> I see. So when you you run bzr branch inside a shared repo, what happens in terms of "branches" and "trees"
<awmcclain> ?
<awmcclain> is "working-tree" the same as "tree"?
<awmcclain> no, right?
<lifeless> working tree is a tree that can be edited; when referring to whats on disk they are often used interchangably
<lifeless> bzr branch creates a new branch using the revision pointer from another branch; then creates a working tree at the same location with the contents of that revision
<awmcclain> unless invoked in a shared repo with --no-working-trees
<lifeless> right; in that case the second step is skipped
<awmcclain> ah ha! I learned something!
<lifeless> are you new to bzr?
<awmcclain> Yes.
<lifeless> you may find it easier to completely ignore repositories for a while
<lifeless> they are nothing more than a space optimisation
<awmcclain> Well, I'm doing enough nitty-gritty work (between stripping out SVN revisions and writing a plugin to interface with bzr-eclipse deal with our eclipse workflow) that it doesn't really bother me. I just want to make sure I'm understanding the concepts.
<awmcclain> My primary goal is to make branching fast and easy easy easy.
<lifeless> awmcclain: ok :).
<awmcclain> And along the way I need to deal with some architectural issues with the way our VCS was set up.
<Verterok> moin
<awmcclain> If you have a nested branch structure (like in http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch), and you branch the mainline, do you get revisionn histories from everyone's feature branches?
<bob2> outside the repository? no.
<awmcclain> bob2: So if you do bzr branch mainline, you just get the mainline change history, not bob/feature-foo as well
<lifeless> right, branches are separate
<lifeless> this is why I said ignore repositories:) they don't change any semantic behaviour
<awmcclain> lifeless: Ahhhh. Of course. Ok, now it makes sense what you were saying. I was thinking of them in an SVN sense.
<awmcclain> Hierarchy in the filesystem (branch B is in a folder of branch A) is separate than the tree hierarchy
<awmcclain> s/than/from
<awmcclain> Ok. Last question, I swear:
<awmcclain> In http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style, under "backing up" it mentions "You may even wish to bind local task branches to remote ones established on a backup server just for this purpose.". How would that work? bzr branch local-mirror local-feature-branch. bzr <branch create command> remote-branch. bzr bind local-feature-branch remote-branch?
<lifeless> awmcclain: what it means is 'work like you do with svn' - so that the remote server that is backed up has every branch
<lifeless> awmcclain: and when you commit those branches get the commits
<lifeless> awmcclain: I don't think backing up is a reason do to this; workflow and team coherence is a much better reason to do this.
<awmcclain> lifeless: Very good point. The only thing I want to mitigate is the remote possibility that someone's machine goes down with their local feature on it.
<lifeless> awmcclain: then have them make sure its published in some fashion somewhere :)
<awmcclain> lifeless: Is the main reason to have nested branches (or just developer branches published) on the mainline server to facilitate corroboration on feature branches? Because it's easier to just both pull from the central location vs push pulling between devs?
<lifeless> awmcclain: uhm, nested branches is not what you mean I think
<awmcclain> I mean a shared repository structure like: http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
<awmcclain> or even http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar
<lifeless> awmcclain: anyhow, if you have two developers working on a single feature, it can be advantageous to have a single branch they both commit too
<lifeless> I have to go catch a train
<lifeless> awmcclain: man that wiki page is confusing
<awmcclain> Tell em about it. :)
<lifeless> did you try the user guide? it may have something better
<awmcclain> it's the same thing verbatim
<awmcclain> :)
<Odd_Bloke> So, anyone here intending to be at FOSDEM?
<lifeless> igc: ^ see comments re shared repo stuff
<jelmer> Odd_Bloke: yep, I will
<igc> shall do
<jelmer> Odd_Bloke: I'll be wandering around and hopefully be on IRC (if they managed to get the WiFi working this year)
<jelmer> Odd_Bloke: are you speaking / manning a booth?
<lifeless> jelmer: how is wouter?
<jelmer> lifeless: ok but busy with uni last time I spoke to him
<igc> awmcclain: wrt the 'using a backup server', what I meant was something like this ...
<igc> bzr push sftp://our-backup-server/me/work-for-X
<igc> then use bind to bind to it while in the office
<igc> as lifeless said, commits will implicitly go there as well
<awmcclain> igc: our-back-server being different than our-mainline-server?
<igc> when out of the office, unbind and work locally
<igc> it can be - it's up to you
<jelmer> he was actually on the channel a couple of days ago
<igc> if the motivation is "let's not lose work when a laptop disk crashes", then ...
<awmcclain> Exactly
<igc> it doesn't need to be the main repo - it can be anywhere central that's backed up
<awmcclain> also the motivation being "let's make this whole thing as easy as possible"
<awmcclain> =)
<lifeless> igc: I strongly suggest not using 'bind' for 'backup'. Its a) confusing and b) will /conflict/ with folk that use checkouts for workflow.
<igc> well it's one option
<igc> another is being in the habit of doing a regular push to a cental server as well
<lifeless> igc: its an abuse of a workflow feature; as seen above it just confuses people.
<igc> lifeless: yes and no
<lifeless> igc: another is to run a backup tool. Or do push-multi before signing off.
<bob2> clearly you need multi-bind, so you commit to your 17 redundant data centres
<awmcclain> Also, is there any to use http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch over http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar? To me the only real difference is that your mainline trunk is either a parent or sibling... and nested branches don't work in trac-bzr. Is there a performance increase?
<lifeless> bob2: exactly.
<lifeless> awmcclain: I would never arrange branch A under branch B, because when we get real nestd branches working that will cause all sorts of errors.
<bob2> hm, I was being fascetious, but it would be neat to commit to local and remote repository
<awmcclain> lifeless: 'Nuff said.
<igc> keep in mind that some teams are sticking with central VCS solely for the 'we like central backups' all the time side effect
<lifeless> awmcclain: *unless* you know you won't be using tested trees.
<lifeless> igc: in which case, they should just use 'bzr checkout' all the time, which will do the same thing. When offline they use bzr commit --local.
<lifeless> igc: what I'm getting at here is the following:
<lifeless> new users see repository layout as something to get right, because they assume a high cost to change (because svn is bad, mmkay).
<lifeless> and to understand that page they need to know all about repositories, bind, namespaces, difference between branches with trees and without trees.
<lifeless> which is a huge learning curve that new users should not need to know.
<awmcclain> !!!" new users see repository layout as something to get right"
<igc> agreed, but I didn't write that page :-)
<bob2> (and because svn offers some advantages to some layouts (e.g. checkout trunk to get trunk/{project1,project2}))
<awmcclain> i just uttered that not more than 5 minutes ago
<lifeless> bob2: our nested trees will do that correctly when polished.
<igc> my point is that in a central system, commit = checkpoint + publish + backup
<lifeless> awmcclain: you're not the first I've seen having this problem
<lifeless> igc: I'm not blaming you for the page; but you are defending some of the content at least.
<johnny> hmm.. i think even monotone made it easier to understand, as they avoid the trees vs no tree repositories.. since trees are always stored in sqlite, and only working copies make files
<igc> in Bazaar, you have the flexibility to make it mean any one, or two, of those
<igc> lifeless: I did write the bit about pushing to a backup server
<lifeless> igc: I posted to the list a while back that we're making the curve harder than it has to be.
<igc> I'd agree with that ...
<igc> I'm far from finished with the docs fwiw
<lifeless> igc: I think that that page needs to let new users be much more agile; there are multiple answers but we don't have to provide a concordance in the introductory information.
<awmcclain> If I may, as a new user, chime in.... the whole page on distributed workflow is really really great.... except for that one paragraph on backing up the server. (Since that was exactly my worry coming from a central VCS). It just wasn't informative enough.
<awmcclain> (sorry igc)
<igc> feedback is great - thanks
<igc> is it clearer now?
<lifeless> igc: anyhow, I would rather we provide a flowchart 'if you want to achieve X' system for this, rather than a huge list of choices
<awmcclain> On the whole, though, the docs on bazaar have been really great for me to wrap my mind around the big problems... 1 How is DVCS better? 2. How can I adjust our existing workflow to best suite that?
<lifeless> igc: with the first option being 'are you a single user with a small tree' -> no repository, kthxbye
<igc> bbiab
<awmcclain> let me see
<lifeless> igc: I'm heading to Martins now.
<awmcclain> igc: looking at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style. Did you change it?
<igc> lifeless: np - thanks for the ping
<igc> awmcclaim: I wrote it if that's what you mean
<awmcclain> ohhh... is it clearer now, yes, after irc? yes
<awmcclain> i thought you meant that you changed the docs
<igc> No, what I meant was I didn't write the section on NestedTreeLayout
<igc> I wrote a large amount of the rest though
<igc> (and after irc)
<awmcclain> Ah yes. Is "NestedTreeSupport" different than 8.2.2 Nested Style repository layout?
<awmcclain> Overall, i just want to say that the docs were the main reason I chose bzr over hg.
<lifeless> awmcclain: cool
<lifeless> awmcclain: and yes it is different
<awmcclain> Ok, good.
<awmcclain> I don't want to think about it then. :)
<Odd_Bloke> jelmer: Nope, will be a spectator again this year.
<igc> awmcclain: ah yes, I meant Nested Style repo layout (or whatever the really long section like that is called)
<awmcclain> hehh
<igc> awmcclain: and I'm wrapper you like the docs - that's great news
<igc> s/wrapper/wrapped/
<Odd_Bloke> jelmer: Are you manning/speaking?
<jelmer> Odd_Bloke: nope, not this year
<jelmer> Odd_Bloke: Interested in meeting up during FOSDEM? We could get some people involved in Bazaar development together
<jelmer> I know at least LarstiQ is going to be there as well as some users
<Odd_Bloke> jelmer: Yeah, I'd be up for that.
<jelmer> Odd_Bloke: are you going to be on IRC during the weekend?
<jelmer> Hopefully the network is going to be working correctly again this year
<jelmer> anyhow, sleep first
<Odd_Bloke> Night!
 * Odd_Bloke intends to stay up so he doesn't miss his train and then nap liberally.
 * igc food
<awmcclain> Anyone here familiar with bzr-svn?
<Odd_Bloke> awmcclain: A number of people are.  If you have a question, just asking it is the best way to get a response. :)
<poolie> Odd_Bloke, are you coming to London to see us?
<Odd_Bloke> poolie: Yeah, I'd like to.
<awmcclain> Here's a strange thing: I'm getting an error in trac svn: PermissionDenied: Permission denied: "/repos/pandasite/.bzr/branch-format": [Errno 13] Permission denied: u'/repos/pandasite/.bzr/branch-format'
<awmcclain> Even though my /repos/pandasite is world readable
<awmcclain> does it need to be writable as well?
<awmcclain> s/trac svn/trac+bzr/
<lifeless> awmcclain: I don't know why trac+bzr would try to write
<awmcclain> looking at the python it's just trying to "get" using a local bzr transport at file:///repos/pandasite/
<awmcclain> ls -al /repos/pandasite
<awmcclain> total 16
<awmcclain> drwxr-sr-x 4 clownfish dev 4096 Feb 22 02:41 .
<awmcclain> drwxrws--- 6 root      dev 4096 Feb 22 01:37 ..
<awmcclain> drwxr-sr-x 6 clownfish dev 4096 Feb 22 01:36 .bzr
<awmcclain> drwxr-sr-x 9 clownfish dev 4096 Feb 22 02:44 panda
<lifeless> then for whatever reason its failing to read; are the directory above rx for this user ?
<lifeless> drwxrws--- 6 root      dev 4096 Feb 22 01:37 ..
<awmcclain> ahhh!
<awmcclain> the sticky bit!
<awmcclain> sigh
 * awmcclain shudders off into corner
<lifeless> a good way to test these things is to su to the user doing the access
<lifeless> and explore in shell
<lifeless> jml: when are thou arriving?
<lifeless> spiv: ottid
<jml> lifeless: I've pinged poolie confirming if it's ok to leave now. no response yet.
<awmcclain> Can't su as ww-data because i've removed the shell. :)
<awmcclain> www-data that is
<lifeless> jml: I'mm here :)
<awmcclain> So, the instructions on http://bazaar-vcs.org/SharedRepositoryTutorial (set the perms of your repo directory to 02770) don't work for trac+bzr.
<lifeless> jml: he says its ok to come now
<jml> ok.
 * jml tidies up some stuff
<lifeless> awmcclain: su -s /usr/bin/bash www-data
<lifeless> awmcclain: as root; so sudo su -s ...
<spiv> lifeless: "ottid"
<spiv> ?
<lifeless> ditto :)
<spiv> Oh, right
<spiv> I forget to use the xrandr option to flip my screen :P
<poolie> Odd_Bloke: did you tell Claire so?  i don't remember seeing a response from you?
<lifeless> that wouldn't work either :)
<Odd_Bloke> poolie: I haven't responded yet, because I completely forgot to do so.
<lifeless> do now :)
<awmcclain> Oh, so close... now: "No node at revision current%3A"
<spiv> lifeless, poolie: I'll probably head off in about an hour
<poolie> rightyo
<Odd_Bloke> poolie: Who is Claire and how do I tell her so? :p
<poolie> see my mail
<Odd_Bloke> poolie: The only mail I can find (and recall getting) doesn't mention a Claire (http://paste.pocoo.org/show/29283/).
<poolie> do you see my private msg?
<Odd_Bloke> poolie: I don't.
<Odd_Bloke> You would appear not to be identified with NickServ...
<poolie> now?
<kumi> hmm... if I have a path with hundreds of files and folders, and I want to ignore _all but a few_ files, how would I do that in .bzrignore?
<poolie> kumi: probably easiest to ignore everything, then add the ones you want to keep
<poolie> you can add ignored files
<poolie> this is assuming there's no easy expression that will match
<kumi> Oh, that's surprisingly simple
<kumi> let's see
<poolie> we try to be pleasantly simple
<kumi> Worked like a charm, thanks
<awmcclain> Ug. I can't figure this out. I've branched a directory from SVN into a shared repo, but when I point bzr+trac to the repo, I get "no node at current:", and if i point it one level in (to the branch) i get "can't compare datetime.datetime to float"
<ubotu> New bug: #194251 in bzr-dbus "bzr-dbus should not require a separate daemon to broadcast notifications" [Undecided,New] https://launchpad.net/bugs/194251
<jamesh> lifeless: ^^^ the above bug contains my thoughts about how to improve bzr-dbus
<lifeless> jamesh: ok; we should talk about this daemon presence/absence thing; I'm really not sure that we can do without it, and I don't understand why doing without it is a feature
<lifeless> jamesh: specifically getting the mappings right seems to require state to me
<jamesh> lifeless: I don't think that is a problem provided that the servers providing the mappings are able to readvertise themselves on demand
<jamesh> (which I cover in that bug)
<lifeless> jamesh: ah; won't that require event driven servers though?
<jamesh> lifeless: for bzr-avahi, I just run an event loop in a daemon thread
<jamesh> works great
<lifeless> jamesh: ok, I shall read the bug.
<lifeless> jamesh: I still don't get the objection :)
<jamesh> lifeless: other than the daemon being unnecessary and the cause of pretty much all the other bzr-dbus bugs? :)
<lifeless> well, its not being fully utilised today; but besides that - it is the cause of bugs ?
<jamesh> the big improvement is changing things to use signals instead of method calls
<jamesh> with current bzr-dbus, "bzr commit" will needs to send a DBus message to the daemon and wait for a response
<jamesh> by instead sending it as a signal, it need not block on a response
<jamesh> and if you're sending a signal, you may as well send it to everyone who has expressed interest
<lifeless> current bzr-dbus does send a signal
<lifeless> the service is the one that waits
<jamesh> the set_rh hook calls Activity.advertise_branch()  That in turn performs a DBus method call to the broadcast daemon
<jamesh> a method call is two messages (one in each direction)
<lifeless> oh hmmm
<lifeless> so youre right.
<abentley> lifeless: I don't expect "nested-style" layout to interact poorly with nested trees.
<lifeless> abentley: when the user has a tree in the repo I expect it too
<lifeless> abentley: tree-less repos - sure.
<jamesh> a signal is basically a "one way" method call that can optionally be broadcast (as opposed to being sent to a single DBus name)
<lifeless> jamesh: ok; in principle I'm for this, but I want to think around the mapping implications.
<lifeless> jamesh: also, are you volunteering ;)
<jamesh> lifeless: sure, although I may not be timely in sending patches :)
<abentley> lifeless: The plan for nested trees was to allow arbitrary locations to be used.
<lifeless> jamesh: (I do know the difference between signals and calls on dbus :))
<jamesh> lifeless: one of my ulterior motives for running an event loop on "bzr serve" is that I need one for bzr-avahi anyway
<jamesh> lifeless: if bzr-dbus requires effectively no setup and has low overhead with no listeners, I may as well make bzr-avahi depend on it
<lifeless> jamesh: ok; I'm keen to reduce overhead.
<lifeless> tree = bzrlib.workingtree.WorkingTree.open('.')
<lifeless> state = tree.branch.get_loom_state()
<lifeless> tree.branch.remove_thread('string_here')
<lifeless> tree.branch.nick = 'rf'
<awmcclain> Anyone up? Trying to upgrade bazaar on ubuntu... but I can't figure out how to add the entry to my sources.list. It keeps telling me the 1.0.0 i have installed is current
<bob2> https://launchpad.net/~bzr/+archive has the correct sources.list lines
<bob2> maybe you forgot to "sudo apt-get update" or similar?
<awmcclain> oh, man. i'm too tired. I totally misse dthat
<awmcclain> thank you
<bob2> np
<awmcclain> hrm
<awmcclain> it's removing bzr-svn... was that merged into bzrtools?
<bob2> no
<bob2> bzr-svn (maybe) isn't updated to work the latest version of bzr
<awmcclain> :(
<awmcclain> well
<awmcclain> this stinks
<poolie> good night all
<ubotu> New bug: #194274 in bzr-loom "Removing the bottom thread should be possible." [Medium,Triaged] https://launchpad.net/bugs/194274
<poolie> awmcclain: i'll check about bzr-svn, but i have to go now
<poolie> for now i suggest you stay on 1.1
<awmcclain> okee doke
<poolie> awmcclain: i think that bug is the indirect cause of your problem
<awmcclain> 194274?
<ubotu> New bug: #194277 in trac-bzr "Trying to view diffs between revisions on a single file shows revision on ALL files" [Undecided,New] https://launchpad.net/bugs/194277
<igc> night all
<ubotu> New bug: #194282 in trac-bzr "Pointing trac to a shared repository with a single branch yields an error" [Undecided,New] https://launchpad.net/bugs/194282
<lifeless> later all
<awmcclain> night
<awmcclain> well
<awmcclain> this has been a long day. I'm signing off as well. Too bad I couldn't get the trac stuff to wrok. :-\
<awmcclain> thanks lifeless, for all your help
<AnMaster> hm something is odd here: bzr check says "429 revisions", yet bzr up says "Tree is up to date at revision 390.". No I haven't merged anything from anyone, nor branched it.
<AnMaster> any idea? would bzr uncommit cause it? I used it a few times
<dato> yes
<AnMaster> ah
<AnMaster> dato, how do I get rid of those "orphand" revisions?
<dato> at the moment, you only can by branching your current branch to a new branch, and use that one from now on
<dato> b get foo foo.new
<dato> mv foo foo.old
<dato> mv foo.new foo
<dato> :)
<AnMaster> dato, hm I store it in a shared repo (in case I later want to branch), so a bit more complex
<AnMaster> but I see
<dato> oh, it indeed is a bit more hairy in a shared repo
<AnMaster> dato, hariy? hm?
<AnMaster> how would one do in a shared repo then
<dato> but only a bit
<dato> cd ..
<AnMaster> ah right
<dato> b init repo.new
<dato> er
<dato> init-repo
<AnMaster> and then branch each over to new repo right
<dato> b get repo/foo repo.new/foo
<dato> yes
<dato> etc
<AnMaster> hrrm
<AnMaster> dato, would be nice with a command to get rid of such orphand revisions
<dato> unless you committed some really big (or confidential) revisions by mistake
<dato> you normally don't care
<AnMaster> dato, really big indeed
<dato> AnMaster: yes, there's been talk about it for ages
<AnMaster> and saw a typo in commit message. uncommited, recommited
 * AnMaster wonders if bzr uncommit works after bzr sign-my-commits
<quicksilver> I've sometimes wondered about accidental committing of privileged data
<quicksilver> never done it, thank god.
<quicksilver> but it is an interesting issue.
<quicksilver> I guess if the privileged data is in revision N and you do a bzr branch on (N-1) that gives you a clean copy?
<dato> yes
<dato> barring the shared repo issue mentioned above
<AnMaster> I assume it doesn't push orphand revisions
<AnMaster> on bzr push
 * quicksilver nods
<AnMaster> so the data would just be locally
<AnMaster> btw anything interesting new in bzr 1.2?
<jelmer> there is the bzr remove-revisions plugin
<jelmer> which will removed orphaned revisions
<jelmer> but it's slow as hell, because it can optionally rewrite the whole history of the repository
<dato> jelmer: it seems that pushing to svn from bzr shell leaves the database locked
<alfborg1> Can anyone tell me about Visual
<alfborg1> Studio integration?
<alfborg1> I find the SOC-project, but nothing about it actually being successful or not.  As in production quality.
<jelmer> dato: I'm not doing anything fancy to the database
<dato> jelmer: well, all I know is that if I `bzr shell`, and push to svn from there, and leave the shell open, I can't push from another terminal.
<dato> not that is something critical, but just I thought you'd like to know.
<dato> (btw the "db is locked" error spits  a traceback)
<alfborg1> Nobody knows about Visual Studio support for bzr?
<radix> is there a known bug about the bzrtools 1.2.0-1ubuntu2 package being broken?
<radix> the postinst is failing for me because none of the .py files that it's looking for are there
<luris> Hi. Getting the following when committing: bzr: ERROR: exceptions.AttributeError: children
<luris> Full traceback: http://dpaste.com/36405/
<MeLanKoLia> WhAlBeRg
<MeLanKoLia> NeRdEsInNnN
<MeLanKoLia> asf
<Lo-lan-do> Hi there
<Lo-lan-do> Can I update a lightweight checkout of a branch to an older revision?
<beuno> Lo-lan-do, you mean revert it to an older revision?
<Lo-lan-do> Yes
<beuno> Lo-lan-do, bzr revert -r revision_number
<beuno> will revert the tree to the state it was at a specific revision
<beuno> you can also create a new branch from that revision
<Lo-lan-do> Hm.  But I'll have locally modified files then :-/
<beuno> Lo-lan-do, I don't understand what you want very well than. Can you explain a bit more?
<beuno> you have a remote branch, and a local lightweight checkout, right?
<Lo-lan-do> Right.
<Lo-lan-do> And I'd like to change the contents of the files I have locally.  So bzr revert -r foo works.
<Lo-lan-do> But when I do that, bzr status tells me the files are added/modified/deleted/whatever
<beuno> Lo-lan-do, yeap. Then you'll have to commit them, fo course
<Lo-lan-do> I don't want to commit, I just want to navigate the past.
<beuno> Lo-lan-do, then just re-branch at that revision
<beuno> it it's just to look through
<beuno> then just delete ir when you're done
<Lo-lan-do> That sounds a big suboptimal, especially if I want to poke at several past revisions.
<Lo-lan-do> s/big/bit/
<beuno> ah, well, I'm not sure what tool let's you navigate revisions better, but I do think it would be a plugin
<Lo-lan-do> Basically, I've tried the bisect plugin, and I'm trying to go a bit past that.
<Lo-lan-do> See what happens if I poke files around.
<beuno> Lo-lan-do, maybe the list will be more helpful
<exarkun> Did I get this message - `bzr: ERROR: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk/.bzr/branch/>Â´ - because I used `bzr checkoutÂ´ instead of `bzr branchÂ´?
<james_w> exarkun: yes, are you doing a commit?
<exarkun> No, it happened during checkout
<james_w> exarkun: ah, that's a bug.
<james_w> exarkun: you can probably branch and the "bzr bind", or checkout using "bzr+ssh://"
<exarkun> maybe
<exarkun> actually it happened as part of an automated process which is difficult to alter :/
<james_w> exarkun: :/
<jdong> james_w / exarkun : just yesterday I did a light checkout over http and it worked
<jdong> of course not for committing but the checkotu didn't error
<exarkun> hm
<exarkun> lemmie make sure I actually completely understand what's going on...
<james_w> jdong: yeah, it only seems to be some branches that cause it.
<james_w> exarkun: are you using checkout --lightweight?
<exarkun> doesn't look like it.  this is the full command - '/usr/bin/bzr checkout http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk build'
<exarkun> there's a comment in this code about how --lightweight causes a cannot-lock error ;p
<james_w> yeah, that's a heavyweight one.
<james_w> oh dear.
<jdong> lol
<exarkun> oh hm
<jdong> why would you do an entire heavyweight checkout for a  build though?
<exarkun> maybe this is using an old version of bzr
<jdong> (my tests were with bzr 1.1 or 1.2, forgot which)
<exarkun> this host seems to have bzr 0.8.2
<exarkun> maybe I will upgrade it
<fullermd> Holy crap.
<jdong> a tiny bit outdated
<exarkun> ah, cool, that fixed it
 * james_w cheers for progress
<james_w> we finally know that we have improved on 0.8.2
<exarkun> :P
<fullermd> True.  I haven't even considered the question since, like, 0.9   :p
<distatica> Hey folks, when I try to add a directory with bzr add, it says "Ignored 27 file(s) if you wish to add some of these files, please add them by name" is there any way to override that so I don't have to manually go through and find those files?
<distatica> not that I'm even sure where this listing of 27 files would be.
<fullermd> 'bzr ignored'
<distatica> oh sweet, it's just ignoring vim's extra files. thank you.
<fullermd> We try to only ignore ignorable things   :)
<distatica> I wasn't sure, but that's good, vim swap files annoy me. (especially on windows with "show hidden files" true.
<distatica> glad they're not in my repo now too.
<ubotu> New bug: #194450 in bzr "commit doesn't supports wildcards in windows" [Undecided,New] https://launchpad.net/bugs/194450
<EdwinGrubbs> hello, I have some questions concerning looms
<championdusk> anyone know of a good WORKING guide to getting bzr + the svn plugin working on leopard?
<awmcclain> championdusk: I just got it working on ubuntu yesterday, and I'm installing on leopard today... what's going on?
<james_w> EdwinGrubbs: please ask your question.
<james_w> the developer isn't around at the moment, but I have seen a few people trying to use it.
<EdwinGrubbs> james_w: I don't see what effect "bzr record" has for looms
<eric_programmer> I have a question I recently asked on the bzr-svn plugin project but thought I might also ask it here in hopes of getting an answer. Rather than repeating everything I figure I will just point a link to my previous question: https://answers.launchpad.net/bzr-svn/+question/25353
<james_w> eric_programmer: so you don't have any trunk/ branches/ tags/ type organisation on that repo?
<james_w> EdwinGrubbs: have you read about it in README?
<james_w> EdwinGrubbs: also there is a mention in HOWTO
<EdwinGrubbs> james_w: I read the description in the README and HOWTO, but it doesn't seem to be necessary to use record, since it appears that the changes are available to be pulled after doing a commit.
<awmcclain> EdwinGrubbs: Try removing the svn branching schema file from your ~/.bazaar directory
<eric_programmer> james_w: No my repository. Just trying to use the code. Yes it looks like for the most part each project just has one main line of development. There is a branches and tags but they are effectively not used in a normal style and we can ignore them for the most part.
<eric_programmer> james_w: s/No/Not/
<EdwinGrubbs> james_w: I also cannot figure out where the comment passed into "record" is viewable.
<james_w> EdwinGrubbs: so it seems that there is another "branch" that records activity in the .bzr/loom dir or wherever, and the record is actually commit in that branch. I don't know what effect that will have though.
<awmcclain> oops, sent that to the wrong person
<awmcclain> eric_programmer: Try removing the svn branching schema file from your ~/.bazaar directory
<abentley> EdwinGrubbs: It will make all your threads be updated properly, not just the active thread.  It will cause any threads you have deleted to be deleted in the other, add any threads you have added, etc.
<eric_programmer> The entire file or just the entry for that repository?
<EdwinGrubbs> abentley: thanks
<eric_programmer> awmcckain: I have already tried just that entry and no luck. Let me try the entire file just in case. :)
<awmcclain> eric_programmer: I'd try for just that entry first. I had the same problem yesterday; removing the file fixed it, (but i only had one svn repository)
<eric_programmer> awmcclain: Same deal when removing the entire file:
<eric_programmer> eric@sleek:~$ rm .bazaar/subversion.conf
<eric_programmer> eric@sleek:~$ rm -rf .bazaar/svn-cache/
<eric_programmer> eric@sleek:~$ bzr branch http://svn.viney.net.nz/things/rails/plugins/acts_as_modified
<eric_programmer> Initialising Subversion metadata cache in /home/eric/.bazaar/svn-cache/20afb1e0-9c0e-0410-9884-91ed27886737/cache-v3
<eric_programmer> bzr: ERROR: trunk/rails_plugins/acts_as_modified/README is not a valid Subversion branch path in the current
<eric_programmer> branching scheme. See 'bzr help svn-branching schemes' for details.
<awmcclain> hrm
<awmcclain> :(
<awmcclain> did you try backing up your svn-cache directory and removing it?
<awmcclain> oh
<awmcclain> yes
<awmcclain> you did
<awmcclain> Does bzr-svn not work with bzr 1.2.0?
<james_w> eric_programmer: have you read 'bzr help svn-branching schemes'?
<james_w> eric_programmer: it suggests that "none" should be what you want, but also that it should be autodetected.
<eric_programmer> james_w: Yes and I have tried editing the schemes but no luck (by the way that is a typo, it should be svn-branching-schemes). Even when I set it to none it doesn't work because it seems to reset it when I try to create the branch again. I think I may know what happened though. It looks like around revision 295 the developer renamed trunk/rails_plugins to rails/plugins. So basically his scheme changed confusing bzr. So when it tires 
<awmcclain> eric_programmer: If that IS the case, you COULD do something super convoluted like make an svnadmin dump 296:N (where N is the head revision), svnadmin load that into a local svn repo, then branch from there
<eric_programmer> The only problem with that is I then cannot track changes from the upstream vendor repository. Basically I want to be able to occasionally "pull" to get the latest source to merge in with my copy.
<awmcclain> Mmm.
<james_w> eric_programmer: typo fix sent to jelmer, thanks.
<james_w> eric_programmer: ah, that's probably the problem then.
<theuiguy> If I want to call multiple bzr commands in a plugin, how can I avoid multiple password prompts (due to the need to authenticate the remote server)?
<theuiguy> Is there some way to hold on to the transport so it doesn't have to re-auth each time? I'm using SFTP in this case
<james_w> theuiguy: there's a way to reuse transports which should avoid that.
<james_w> theuiguy: possible_transports=list in the arguments to a method.
<theuiguy> james_w: do you know if I can use that with the cmds directly?
<theuiguy> specifically I'm trying to do branch, pull, and push...
<james_w> theuiguy: you are actually calling cmd.run()?
<theuiguy> yes
<awmcclain> I'm confused... does the smart server exist or not exist?
<james_w> awmcclain: it exists, but only if you don't look directly at it.
<awmcclain> james_w: Ah. The watched pot never boils, eh?
<james_w> sorry, I mean yes, it exists, bzr+ssh:// is one of them.
<james_w> theuiguy: that is generally not that popular, but it can be convenient. If you don't need all the cases that the commands handle then it is probably as easy to actually work on the objects.
<james_w> theuiguy: that would then give you access to these facilities.
<awmcclain> eric_programmer: What version of bzr are you running?
<james_w> unfortunately some of the commands have a little too much knowledge in the command class, which you have to reimplement with that approach.
<eric_programmer> awmcclain: Bazaar (bzr) 1.0.0
<theuiguy> james_w: That's what I was going to ask. I'm (sadly) trying to learn how to hack python while updating a plugin for bzr
<theuiguy> james_w: Sadly in that it would probably be easy if I knew more python...
<awmcclain> eric_programmer: You *might* try getting bzr-svn 0.5.0 from his trunk at http://people.samba.org/bzr/jelmer/bzr-svn/trunk
<awmcclain> eric_programmer: Since it's just a python file, it' fairly trivial to install
<theuiguy> james_w: Is there somewhere I can find a mapping between cmds and their objects?
<awmcclain> file(s)
<james_w> theuiguy: well a command usually operates on more than one object, but if you tell me a command I can try and tell you what the essence of this is.
<james_w> theuiguy: is this a plugin that is available, or just something local?
<theuiguy> james_w: It used to be known as ezbzr, but it's no longer available at it's old location
<theuiguy> james_w: eventually we want to put it somewhere, perhaps launchpad?
<eric_programmer> awmcclain: I'll give a newer version a try. Maybe it will work for me
<james_w> theuiguy: launchpad would be ok, there's quite a few plugins there.
<awmcclain> eric_programmer: Good luck. I'm stuck in bzr-svn troubles myself. :)
<james_w> theuiguy: I've heard of it, but never tried it, what does it provide over bzr itself?
<theuiguy> james_w: good deal.
<theuiguy> james_w: ezbzr has three major commands, foreach which does executes a command for every revision with an option to use just the latest
<theuiguy> james_w: diffstatus which is a trivial thing that combines both diff and status into one command
<awmcclain> Can anyone here help me with https://bugs.launchpad.net/trac-bzr/+bug/194282?
<ubotu> Launchpad bug 194282 in trac-bzr "Pointing trac to a shared repository with a single branch yields an error" [Undecided,New]
<james_w> ah, so it's not providing a wrapper on the bzr interface, but extra commands. I though it maybe provided a more "easy" UI.
<theuiguy> james_w:  and the one that's causing problems is release, which tries to cleanly release to another branch without polluting it
<james_w> what do you mean by release?
<theuiguy> james_w: no, just more commands
<theuiguy> james_w: in our environment we're using bzr to manage code on multiple servers (production, dev, testing, etc.)
<theuiguy> james_w:  Release helps us update the code on other servers while not overwriting other people's changes
<foom> eric_programmer: you can probably do what you want with bzr svn-branching-scheme but it's not documented anywhere afaik
<theuiguy> james_w: essentially it creates a temp branch from target server, merges your code changes, lets you conditionally commit them, and then push
<james_w> eric_programmer: one idea might be bzr branch -r last_revision_before_move
<james_w> then change the branching scheme and pull.
<foom> eric_programmer: just put two lines in:  trunk/rails_plugins and rails/plugins
<foom> then it will know both those as branches and should work
<eric_programmer> foom: It's funny you mentioned that. I had just put this in as a list using the --set option and am giving a try now... hopefully it will work. I know my lack of knowledge on Subversion schemas is what is preventing me from working.
<theuiguy> james_w: does that make sense?
<james_w> theuiguy: hmm, sounds like using the objects might be a little work, but it's hard to tell.
<foom> what prevented me from understanding is that the ability to list branches directly is apparently undocumented. :)
<theuiguy> james_w: I know that one of the things the plugin does is a local branch and then a pull with overwrite from the remote server
<james_w> awmcclain: are you using Aaron's multi branch version of trac-bzr?
<eric_programmer> foom: Well after I read what documentation does exist and read the source code I think I am finally understanding schemas a bit. The imports seems much slower this time but as long as it works I am happy. Hopefully I will know soon.
<james_w> theuiguy: the branch that you are currently in?
<theuiguy> james_w: I'm guessing this was for speed... but this was written for bzr 0.15 or so... so this may be unnecessary now
<theuiguy> james_w: yes
<james_w> theuiguy: it's probably still worth doing
<awmcclain> james_w: I'm using the bmonty-devel branch for trac 0.11 support
<james_w> awmcclain: then that can only serve a single branch I think.
<awmcclain> Though I HAVE the multi-branch branched out as well
<theuiguy> james_w: I'm wondering whether there's any better/faster way to construct the temp branch from the target server.
<awmcclain> Ah ha!
<james_w> http://cmcsforge.epfl.ch:6789/cgi-bin/dwww/usr/share/doc/trac-bzr/README
<james_w> awmcclain: ^
<james_w> theuiguy: well the local copy is probably quicker to branch.
<james_w> tree = WorkingTree.open_containing('.')[0]
<james_w> branch = tree.branch
<awmcclain> james_w: There's no multi-repository support yet, right?
<james_w> branch.sprout(tempdir)
<james_w> new_branch = Branch.open(tempdir)
<theuiguy> james_w: does that replace this: builtins.cmd_branch().run(from_location=branch_base, to_location=localcache)
<james_w> or perhaps sprout returns the new branch object, I can't remember.
<james_w> theuiguy: pretty much I think, this is all just guess programming though, so the exact methods will need to be checked.
<theuiguy> james_w: gotcha
<theuiguy> james_w:  what's the branch.sprout(tempdir) do? I haven't seen that method.
<james_w> but you probably want to create a tree rather than branch, and I don't know if you use tree.sprout() or branch.sprout() has an argument.
<james_w> theuiguy: also look for accelerator_tree or something like that, as you have a local tree it can use that to make building the temp one quicker.
<james_w> awmcclain: I think Aaron's branch does
<awmcclain> james_w: !!
<james_w> theuiguy: Then you need to get the server transport so you can reuse it. I can't remember the transport API though.
<awmcclain> Silly that his branch isn't on launchpad
<theuiguy> james_w: ok. Once I have a tree, how could I do a pull overwrite... I'm guessing that's where it needs a transport.
<james_w> theuiguy: but the pull --overwrite is easy, tree.pull(othertree, overwrite=True) or something.
<theuiguy> cool
<james_w> You can pass in possible_transports as well I assume.
<awmcclain> james_w: Hrm. Same problem. "No node at current"
<awmcclain> I wonder if it has to do with the way in which i set up the repository? And made the brach from bzr-svn?
<james_w> theuiguy: I'm just guessing at all of this, but you should be able to work it out from the command in bzrlib/builtins.py
<james_w> theuiguy: though if you are still learning python there might be a lot going on in there to distract you. However it usually boils down to
<james_w> 20-50 lines of setup and checking
<theuiguy> james_w: I think I'm getting it. Thanks for the pointers.
<james_w> call method to do the work, with obvious parameters.
<eric_programmer> james_w, foom and awmcclain: You guys rock. I was able to finally get it working. The secret sauce was to do "bzr svn-branching-scheme http://svn.viney.net.nz/things/ --set". Then when my editor popped up put in "rails/plugins/*" and "trunk/rails_plugins/*" as separate lines. After that everything worked great. Thanks for your help guys.
<james_w> theuiguy: no problem.
<james_w> awmcclain: did you read the link I posted? You have to set some extra config options.
<james_w> eric_programmer: wow, I can't believe it worked, congratulations.
<james_w> I should never have doubted jelmer.
<theuiguy> james_w: I'll have to look at this over the weekend, but it seems like it should similar.
<theuiguy> james_w: er... should be similar to using the cmds directly.
<awmcclain> james_w: Ah. Yes. It's the same README as in the branch. I've set repository_dir
<awmcclain> And all the rest of the configuration
<james_w> theuiguy: yeah, I've done similar things to this, and just poking around in the bzrlib code normally make things clear soon enough, ask again if you need some more pointers.
<awmcclain> I wonder if it's because the "directory containing the branches" IS a repository.
<theuiguy> james_w: do you know of any code that uses multiple commands while sharing the transport? I was looking for some sample code somewhere.
<theuiguy> james_w: might some of the test code do this?
<fullermd> I doubt it.  The test suit either calls functions directly, or exec's out bzr.
<james_w> theuiguy: that's another good place to look. The sharing of transports should be tested somehow, but I don't know if it will look like what you want.
<fullermd> I don't think anything calls command frontends except the commands in bzr proper.
<fullermd> The cmd_'s aren't really made to be called by other code, I don't think.
<james_w> theuiguy: the transport sharing should be easy for you I expect, just pass a list containing the transport you have to every method that accepts it.
<theuiguy> fullermd: it's pretty convenient when you're just grouping some commands
<james_w> awilkins: I don't think that should have an effect.
<fullermd> theuiguy: Well, I do that with my shell   :)
<theuiguy> unfortunately, some bzr internals change made it so the cmds now prompt for password each time
<theuiguy> Since this worked in some earlier versions (admittedly pre-1.0) of bzr
<theuiguy> james_w: thanks again, I really appreciate the pointers. Hopefully you'll see the plugin more publicly available sometime soon.
<awmcclain> Is there a way to apt-get bzr version 1.1 somewhere?
<radix> awmcclain: you mean, as opposed to bzr 1.2?
<awmcclain> radix: Exactly.
<radix> awmcclain: I think the PPA archive keeps the old .debs around, but you'd have to download them manually
<radix> I think?
<awmcclain> radix: Any idea where they might live? I can't find them anywhere. :(
<radix> awmcclain: hmm. guess not.
<radix> I assumed it would be at http://ppa.launchpad.net/bzr/ubuntu/pool/main/b/bzr/ , but it's not.
<awmcclain> Ah well. What a bother that bzr-svn doesn't work with 1.2 yet
<foom> if you were using debian you could use snapshot.debian.net
<foom> dunno about ubuntu
<robey> is there a working version of the bzr-git plugin?
<robey> (bzr-git trunk appears to be broken against bzr 1.2)
#bzr 2008-02-23
<james_w> awmcclain: you mean the packaged version?
<james_w> awmcclain: you could also try your /var/cache/apt
<awmcclain> james_w: i went from 1.0 to 1.2
<james_w> ah, that wont work then.
<awmcclain> james_w: I figured out some of the problem... seems like bzr-trac balks when used with a shared repo without working trees
<james_w> awmcclain: ah, well caught.
<awmcclain> ooh.. yesh
<awmcclain> I'm getting bzr: ERROR: Repository KnitPackRepository('file:///shrepo/.bzr/repository/') is not compatible with repository SvnRepository('svn://localhost')
<awmcclain> when i try to branch an svn directory into a shared repo with trees
<fullermd> awmcclain: bzr-svn needs rick-root-packs format.
<awmcclain> fullermd: Not sure I really understand. Is that an option i need to specify in bzr init-repo?
<fullermd> Yah.
<fullermd> --format=rich-root-packs
<fullermd> Or maybe it's pack singular.  I'd have to check the help...
<awmcclain> For bzr-svn?
<awmcclain> or bzr init-repo
<fullermd> For the init-repo
<awmcclain> Is there a better (more native) way to convert from svn to bzr? I'm doing a one-way port
<fullermd> There are one or two other converters around, but I think bzr-svn is the canonical one.
<fullermd> I think the only other way that's gotten any work lately is whatever that thing is that igc's working on, and that's probably not near as production-ready.
<awmcclain> Won't specifying a different file format hurt performance?
<fullermd> Hurt performance relative to it not working at all?   ;)
<awmcclain> Once i get the repo into bzr, can i convert from rick-root-packs to knit?
<fullermd> No (you wouldn't want to go knit anyway; you'd want to go pack; but rich roots are a trapdoor)
<awmcclain> Is there wiki page somewhere about all this?
<fullermd> There's probably something in the bzr-svn docs about it, but I've never look at 'em.
<awmcclain> So, bottom line is, if i'm converting a repo from svn, i'm stuck with an older file format.
<fullermd> It's not older.
<fullermd> In a sense, it's newer.
<awmcclain> oh wait, i'm so confused.
<awmcclain> The state-of-the-art is using packs, right?
<fullermd> Correct.
<fullermd> rich-root-pack is a variant of pack-0.92 that supports rich roots (much like rich-root is a variant of knits that supports rich roots)
<awmcclain> But using bzr init-repo doesn't default to that? And bzr-svn is expeciting it.
<awmcclain> Ah.
<awmcclain> rich-root-pack is a superset of pack?
<fullermd> Yah.
<awmcclain> Ahhhh.
<awmcclain> Is there a performance difference?
<fullermd> Well, I would assume there has to be one, since it does more.  But that diff is almost certainly unmeasurable.
<awmcclain> That's the magic word!
<fullermd> It may miss some optimizations that exist in the straight format; I'm not sure how much of the code is shared.
<fullermd> But I don't think it would be a large difference, if it's a meaningful one at all.
<tgunr> Thought I would try out bzr on macosx, on 1st attempt to use it with the whoami command I get Unable to load plugin 'qbzr'
<tgunr> :)
<johnny> hmm..so.. do you guys talk about the bzrarchives proposal thingy here?
<beuno> tgunr, so you installed the qbzr plugin and it's failing for some reason
<beuno> you should remove it
<beuno> and try again
<beuno> Verterok, ^  :p
<tgunr> just delete that folder?
<tgunr> or plist or something?
<Verterok> tgunr: the 10.4 installer?
<tgunr> 10.5
<Verterok> beuno: thanks :)
<Verterok> tgunr: I don't have 10.5, but in 10.4 it's installed inside python site-packages
<tgunr> CC
<awmcclain> In a shared repository (with trees), is there anything different between mkdir foo; bzr add foo; bzr commit and bzr branch bar (where bar is an empty directory)?
<Verterok> tgunr: I think it should be in: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
 * fullermd blinks.
<fullermd> awmcclain: Either you're confused, or you confused me   :)
<awmcclain> fullermd: I think both. :)
<awmcclain> fullermd: Basically, is adding a directory using bzr the same as branching?
<awmcclain> fullermd: I ask because I need to fiddle with my directory structure in my shared repository
<fullermd> You can't "add a directory" in a repository.
<fullermd> The concept has no meaning in bzr terms.
<awmcclain> Using bzr add?
<fullermd> Maybe you're thinking svnish?
<awmcclain> Maybe i'm garbling the advice that lifeless gave me yesterday
<fullermd> (Or maybe you mean 'branch' when you're saying 'repository', but branch'ing inside a branch doesn't make sense either)
<awmcclain> I creating my shared respository
<awmcclain> Well, there is that whole "nested branch layout" under http://bazaar-vcs.org/SharedRepositoryLayouts. ;)
<awmcclain> I want my repo to look like: repo/trunk/src  repo/bobby/featureX/src repo/sally/featureY/src
<awmcclain> "repo" in the sense of "shared repository"
<awmcclain> The problem is that in my current SVN tree, I only have /src
<awmcclain> So.
<fullermd> I think you're mixing too many things around...
<awmcclain> ??
<fullermd> For one thing, 'add' is a command that deals with a working tree.  A working tree is only related to a branch; it doesn't have anything to do with repositories.
<fullermd> It may be simpler to forget wholesale about the shared repo, at least mentally, for starters.
<fullermd> The existence (or non-) of the repo doesn't change anything, relative to just having standalone branches.  It just saves space/time.
<awmcclain> Ok.
<awmcclain> So.
<awmcclain> I should do bzr branch svn://src
<awmcclain> which will give me a /src branch + working directory, correct?
<awmcclain> I need to change my tree to look like /trunk/src
<robey> since ppl are talking again: any word on bzr-git?
<awmcclain> robey: just that bzr-svn is broken for 1.2 too.
 * robey howls with pain
<fullermd> robey: I believe somebody (lifeless?) looked at it recently, but I'm not aware of any real movement.
<fullermd> (where 'recently' is the past month or three)
<robey> i tried various branches from the launchpad project page for bzr-git, and they all failed in exactly the same way
<robey> it sucks cuz i really dont want to use git, but some stuff here is stored in git repos
<fullermd> I don't think bzr-git is sufficiently present at its best to be useful for doing real work.  So it being broken doesn't necessarily lose you much   :)
<awmcclain> fullermd: I'm just trying to set up my mainline server so that we can share feature branches, and I want to do it in such a way that encourages branching.
<awmcclain> I guess another question would be: How would you change the root directory of a branch?
<fullermd> You mean the "move everything from / into /foo" thing?
<robey> if it was good enough to make a bzr branch from a git one, that would've probably been enough
<fullermd> I don't think it was ever that good.
<robey> oh well, ok... thanks
<awmcclain> if i have a branch /foo, i want to "reroot" it at /bar/foo
<fullermd> awmcclain: Theoretically, with rich roots, one could pivot the root dir.  But there's no UI or other support for doing so.  So the real choice is pretty much as above; make a dir, and bzr mv everything into it.
<awmcclain> fullermd: Exactly what I want to do.
<fullermd> See, that phrasing is unclear, which makes it tough to answer.
<awmcclain> My use of "reroot"
<awmcclain> ?
<fullermd> It could be read as "move the branch from /foo to /bar/foo", or it could be read as "move the contents of the branch which is located at /foo into the bar/ subdirectory inside the branch"
<awmcclain> Ah. Sorry. #1
<fullermd> (or alternately phrased; you could be talking about moving the _branch_, or you could be talking about moving stuff around _in the branch_.
<fullermd> If you want to move the branch, you just mv it.
<awmcclain> hrm
<awmcclain> because it's a directory?
<fullermd> Or tar, or zip, or whatever other random mechanism you use for moving filesystem trees around.
<awmcclain> ah
<awmcclain> but
<fullermd> Yah.  If it's a standalone branch, everything it needs is inside itself, so you can throw it around however you like.
<fullermd> (if it's in a shared repo, a little more care is needed, since it doesn't have the repo included, but that's another matter)
<awmcclain> Well, it's a branch inside a shared repo.
<awmcclain> =)
<awmcclain> but
<awmcclain> ideally, i want to be able to say
<fullermd> If it's in a shared repo, as long as it stays under the repo, mv is still what you want.
<awmcclain> ok
<awmcclain> so
<awmcclain> i could do
<awmcclain> bzr-init --trees repo; mkdir repo/trunk; bzr branch SOURCE_URL repo/trunk/src
<awmcclain> and then from the client, bzr branch repo/trunk?
<fullermd> No.
<awmcclain> OK. That's what I want to do.
<fullermd> You can only branch a branch, which in this case would be "repo/trunk/src".  "repo/trunk" is nothing.
<fullermd> (also, "bzr init-repo", not "bzr-init", but that's details)
<awmcclain> (Sloppy typing sorry)
<fullermd> 'src' is a bad name for a branch.  You probably want 'repo/trunk' to be the branch.
<awmcclain> Exactly!
<awmcclain> that's the problem
<fullermd> Either that, or you want to have 'src' be a directory inside the branch.
<fullermd> (possibly the only thing in the root of the branch)
<awmcclain> The problem is that right now, i have many project in my svn /trunk directory
<awmcclain> so, in order for me to split things up
<awmcclain> i can only do bzr branch svn://.../trunk/sub_proj
<fullermd> Mmm.  Let's assume proj1, proj2, and proj3.
<awmcclain> But, in bzr, i want to make /trunk/sub_proj the branch
<fullermd> And we'll ignore the presence (or absence) of a share repo for the moment.
<awmcclain> well (/trunk)
<awmcclain> ok
<awmcclain> great
<fullermd> You can arrange stuff two ways (an infinite number, of course, but 2 main ones)
<fullermd> One is
<fullermd> /proj1/trunk, /proj2/trunk, /proj3/trunk
<fullermd> The other is /trunk/proj1, /trunk/proj2, /trunk/proj3
<awmcclain> So, I want to have my bzr projects set up like choice A
<awmcclain> But my SVN is set up like choice B
<fullermd> In the former, other branches of each project would be under /projX, in the latter you'd have either /branchs/RANDOM, or /branches/proj1/RANDOM, /branched/proj2/RANDOM, etc.
<fullermd> OK, that's no problem at all, since branches are independent.
<fullermd> You'll bzr branch svn://... once for each project, and you'll end up with N bzr branches, one for each project.
<fullermd> Then you can arrange them however you like.
<fullermd> In svn, you're kinda stuck with them laid out however you did them initially.
<fullermd> With bzr, you can rearrange at will, because there's nothing quite like a svn repo; there's no higher level thing they're all explicitly pieces of.
<awmcclain> SVN looks like this: /pandasite/trunk/panda /pandasite/trunk/artwork pandasite/trunk/notify
<awmcclain> I want bzr to look like:
<awmcclain> ...
<awmcclain>  /pandasite/trunk/panda
<awmcclain>  /artwork/trunk
<awmcclain>  notify/trunk
<awmcclain> */notify/trunk
<fullermd> Was that first meant to be /panda/trunk?
<awmcclain> So, unfortunately, I can't branch the /pandasite/trunk into bzr, because that will give me two other projects
<awmcclain> no
<awmcclain> We could call it /pandasite/trunk/src /pandasite/trunk/artwork
<awmcclain> I have some "nested" directories in SVN that I want to fix when I move to bzr
<fullermd> OK, well, let's forget about that, because it twists my brain into probably somewhat irrelevant side paths, and stick with the other two   :)
<awmcclain> That's the tricky one, though. :)
<awmcclain> Im done witht eh other two
<awmcclain> :)
<fullermd> Well, crud.
<awmcclain> Just say you're given a branch that is /src
<awmcclain> And you need to convert to a branch that is /trunk with a subdirectory /src
<fullermd> I think you're confusing me because you're mixing up the branch, and what's in the branch, which doesn't happen in bzr.
<fullermd> The branch is /src.  It could as well be /, or /foo/bar/mybranch, or whatever?
<fullermd> So what you really want to do is "move the files/dirs in the root of the branch into a subdir".  I keep feeling like you mean more than that, because the solution to that seems so simple.
<awmcclain> Yes!
<awmcclain> That's what I want to do!
<fullermd> Well, you want to make a dir in the branch, and move everything into it.  You do that by making a dir in the branch (technically, your working copy of the branch), and moving everything into it   :)
<awmcclain> using bzr mv
<fullermd> Right.
<awmcclain> do i need to bzr add the dir?
<awmcclain> first?
<fullermd> I don't think you can actually 'bzr mv *' like you can with straight 'mv', since I dunno if it'll notice you trying to move a dir into itself and DTRT, but...
<fullermd> Yah.
<awmcclain> i was confused because I was equating "the directory at the root of the tree" with the definiation of the branch
<awmcclain> Does that make sense?
<fullermd> Ah.  Yeah, that could be a source of confusion.
<awmcclain> pehw
<fullermd> There's a sharp line between "working on your project" (in which you essentially chroot into the root of the branch), and manipulating the branch from the outside.
<awmcclain> right
<fullermd> (in which case the branch is opaque)
<awmcclain> and "working on your project" == "working within your working-tree"
<fullermd> cd $BRANCH ; mkdir src ; bzr mv [A-Za-rt-z]* src ; {manually bzr mv s* files or dotfiles} ; bzr ci -m 'Move a bunch of crap'
<fullermd> Right; your day to day "getting stuff done"
<awmcclain> Ah ha!
<fullermd> (whoops, I missed the 'bzr add src' before the mv)
 * fullermd pours more coffee.
<awmcclain> Ok. Would another approach be to create a new branch (call it trunk)
<awmcclain> then somehow move the contents of $BRANCH2 into $TRUNK?
<awmcclain> (without creating nested branches)
<fullermd> Well, you could 'bzr branch src trunk' and do the work in trunk/ instead of src/ if you like.  No real reason to, though.
<fullermd> Or just 'mv src trunk' (not 'bzr mv', since you're not working in a bzr tree).
<awmcclain> but mv src trunk would create nested branches, right?
<awmcclain> you have branch trunk
<awmcclain> then branch src inside trunk
<fullermd> I meant with 'trunk' not existing; just renaming the directory.
<fullermd> Branches aren't "called something"; they're just "located somewhere", so changing the "name" is just mv'ing the branch.
<awmcclain> right
<awmcclain> So it wouldn't make senses to somehow move the working tree from branch src into a src directory in branch trunk
<awmcclain> $SRC/*  ---> $TRUNK/src
<fullermd> Not really.  Either way you have to move $BRANCH/* into $BRANCH/src/*.  It's just a question of whether you 'rename' the branch before or after, which affects nothing.
<awmcclain> Oh, just to be clear, I'm talking about moving working trees from two _separate_ branches, but I'm guessing you can't do that
<fullermd> Well, you can merge the trees, then mv all the new files before commit.
<awmcclain> ok, let me just dive into this
<awmcclain> If I do all this branch work outside my shared repository, can I just push my branch into my shared repo?
<fullermd> Sure.
<awmcclain> Can I just cp it in?
<fullermd> Well, yes and no.
<fullermd> You *can*.  But it'll still be a standalone branch, just one located inside a repo.
<awmcclain> no, because it defaultst he purpsoe of the shared repo
<awmcclain> defeats
<awmcclain> :)
<awmcclain> ok
<fullermd> You should consider too at what level you want the repo; whether all this goes in one, or you want one for each project.
<awmcclain> right
<fullermd> Right   :)
<awmcclain> it's going to be
<awmcclain>  /repo (plain directory with a misleading name)
<awmcclain>  /artwork (branch)
<awmcclain>  /pandasite (shared repo)
<awmcclain>  /pandasite/trunk (branch)
<awmcclain>  /pandasite/andrew (dev branch)
<awmcclain> etc
<awmcclain> eeep
<awmcclain>  everything from /artwork down lives in /repo
 * fullermd nods.
<awmcclain> (/repo/artwork/) etc
<awmcclain> ok
<fullermd> Don't need to handle multiple branches of artwork?
<awmcclain> Nope
<fullermd> What about notify?  Where does that fit?
<awmcclain>  /repo/notify (shared repo)
<awmcclain>  /repo/notify/trunk
<awmcclain> So, the same thing needs to happen for that
<awmcclain> oh, no
<awmcclain> i'll just do
<awmcclain> cd repo; bzr init-repo --trees --rich-root-pack notify; cd notify; bzr branch svn://pandasite/trunk/notify trunk
<awmcclain> btw, thank you for taking the time to walk through this with me. As I've said before, the community and the docs are why I'm switching my team to bzr rather than hg.
<fullermd> Sounds like something remarkably like a plan to me.
<awmcclain> Ok, last thing... in order to push into the shared repo, I'll have to serve it on localhost, right?
<fullermd> Well, on localhost, I'd just 'branch' instead of 'push'.  Comes out to the same thing, though.
<awmcclain> So, say my directory-fiddled branch ends up at ~/good-branch
<awmcclain> i can just say, bzr branch ~/good-branch /repos/pandasite/good-branch
<awmcclain> oh of course
<awmcclain> yes
<fullermd> Yep.
<fullermd> cd ~/good-branch ; bzr push /repos/pandasite/good-branch/ is _almost_ the same.  Either would work.  I'd just reflexively use 'branch'.
<awmcclain> Ok. Great!
<etteyafed> anyone know about a bzr plugin for netbeans?
<Peng> Ouch.
<jml> zoinks!
<jml> $ bzr branch bzr+ssh://myserver/home/jml/a/branch
<jml> bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request 'bzr request 2'\n"
<jml> that's not a fun error message
<awmcclain> Ug. One MORE error.
<awmcclain> I can't checkout my branch from my mainline! Repository KnitPackRepository('file:///Users/andrew/clownfish/panda-mirror/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://bamboo.fluther.com/repos/pandasite/.bzr/)
<awmcclain> I inited my remote shared repo with --format=rich-root-pack so that I could import SVN branches into it.
<bob2> you'll need to do the same for your local repository
<awmcclain> ah... I have to init a local repository in order to do a checkout from a shared repo?
<bob2> what command gave you that error?
<awmcclain> bzr checkout bzr+ssh://bamboo.fluther.com/repos/pandasite/trunk panda-mirror
<awmcclain> I get no error if i do a branch
<bob2> is clownfish or panda-mirror a repository root?
<awmcclain> no
<bob2> er, clownfish, that is
<awmcclain> it is not
<awmcclain> it is a vanillay directory
<bob2> (and no, you don't need to init a local repository to do a checkout from a shared repo)
<awmcclain> hrm
<awmcclain> i don't get it then
 * bob2 tries a bzr+ssh checkout of a rich-root-pack branch
<bob2> hah, same error
<awmcclain> !!
<awmcclain> booo
<awmcclain> Is there any way to convert to KnitPack?
<awmcclain> I have no need to communicate to SVN anymore... I just needed to port over from SVN
<bob2> [09:55] <mwhudson> there's a bug where initial branches over bzr+ssh always create local branches in the default format
<bob2> awmcclain: if you use sftp instead of bzr+ssh, it should work
<awmcclain> Aren't there weirdnesses with using sftp? Like losing some meta information or something?
<awmcclain> Or... is there a way to convert rich-root-pack to knitpack?
<bob2> awmcclain: the other workaround from http://irclogs.ubuntu.com/2007/12/13/%23launchpad.html is to use sftp for the first revision (-r1), then bzr up
<bob2> I don't know of any weirdness from using sftp, aside from it maybe being slower
<awmcclain> ug
<awmcclain> what does bzr up do?
<bob2> if it's on a lan, it shouldn't matter
<awmcclain> it's not
<awmcclain> and speed is important
<bob2> ah
<awmcclain> hrm
<bob2> (bzr up would update you from rev1 to the current rev)
<awmcclain> and in order to branch from SVN you _have_ to use rich-root-pack, right?
<awmcclain> Right...makes sense
<bob2> or rich-root, but the bug is that "co" always picks the current bzr default format, instead of the remote format
<bob2> there is another confusing workaround
<bob2> if you make a rich-root-pack repository on your local machine, then checkout into that, then it uses rich-root-pack for the check and thus works over bzr+ssh
<bob2> thus making my intiial comment about not havbign to init a local repository quite wrong
<awmcclain> And there's no command to remake the entire file repository, right?
<bob2> hm?
<awmcclain> bzr convert-file-format crappy-rich-root-format nice-knit-pack-format?
<awmcclain> just guess on the syntax. ;)
<awmcclain> s/guess/guessing
<bob2> well, branches from svn require rich-root support, so no
<awmcclain> right, but if i dont' need svn support anymore, can i convert them?
<bob2> well, branches that didn't come from svn can be branched into a knit or pack repository
<bob2> not sure if you mean "if I don't need to use branches that came from svn anymore" or "if I don't need my branches from svn to interact with svn anymore"
<awmcclain> choice B
<bob2> not afaik, but I know little about bzr-svn
<awmcclain> sigh
<awmcclain> ok
<awmcclain> i'll try the workaround. thank you for your help!
<awmcclain> bob2: still here?
<awmcclain> Is there a better way of switching the source of my checkout from sftp:// to bzr+ssh:// than editing the branch.conf manually?
<bob2> awmcclain: bzr switch bzr+ssh://...
<awmcclain> great
<awmcclain> that's from inside the checkout, right?
<bob2> yes
<rysiek|pl> guys, where does bzr keep revno in branch/repo?
<luks_> nowhere, they are calculated
<bob2> ("bzr revno" will figure it out)
<rysiek|pl> hmmm... ok, so what files should I watch (say, with inotify) to get a heads-up when a revno changes?
<rysiek|pl> bob2: yeah, I know, but I am trying to run something automagically when a revno changes
<luks_> .bzr/branch/last-revision might work if you want only a single branch
<bob2> surely a commit hook would be less hacky?
<luks_> bob2: not if it's on a server and you want something like push hook
<rysiek|pl> precisely
<rysiek|pl> luks_: I don't have anything named "last-revision" in there
<luks_> revision-history for old branches
<luks_> but you should upgrade them :)
<rysiek|pl> $ find ./ -iname last* -> ./checkout/last-revision
<emilis_info> Can bzr checkout sourceforge svn on Ubuntu Gutsy? Fails on my machine.
<luks_> oh, a checkout
<rysiek|pl> emilis_info: bzr != svn
<emilis_info> rysiek|pl, I know
<bob2> rysiek|pl: bzr-svn!
<emilis_info> I use the plugin
<luks_> you said branch/repo, so I though you mean a branch
<emilis_info> :)
<rysiek|pl> ah
<luks_> *thought
<rysiek|pl> luks_: ell, it is a branch
<rysiek|pl> *well
<luks_> ls .bzr/branch
<emilis_info>  bzr selftest svn gives some output but ends in error: bzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko
<rysiek|pl> luks_: yup. revision-history is her
<rysiek|pl> e
<bob2> emilis_info: you can install python-paramik to fix that
<bob2> emilis_info: but can't imagine how that would affect svn support
<luks_> yep, upgrading it would be a good idea, unless you have a reason to use the old format
<rysiek|pl> nope, just did a bzr upgrade (to 1.1) so it might be a good idea
<emilis_info> bob2, I'll try now, thanks
<rysiek|pl> hope it won't mess my 2000+ revisions branch... ;)
<rysiek|pl> luks_: so, how can I upgrade a branch
<rysiek|pl> aah
<ubotu> New bug: #194675 in bzr "encoding problem with `bzr merge --preview | less`" [Undecided,New] https://launchpad.net/bugs/194675
<rysiek|pl> bzr upgrade
 * rysiek|pl is blind
<emilis_info> doh... got it working finally... seems I had to use https://...sourceforge.net/... instead of svn+https://...
<hsn_> why are .bzr directories hidden on windows? this is confusing
<bob2> because they're hiddon on unix
<hsn_> but most programs in unix stills shows them, on windows practicaly nothing shows them
<AfC> Do we ever use UDP in our bzr:// communications?
<ubotu> New bug: #194716 in bzr "bzr pull should support --local" [Undecided,New] https://launchpad.net/bugs/194716
<VSpike> I'm trying to do a bzr push by sftp on a lan and the command just goes away and does not return
<VSpike> How can I figure out what the problem is?
<VSpike> I know I can ssh from one machine to the other succesfully, although it does normally require a password
<Odd_Bloke> jelmer: Hey, you around ATM?
<echo-are`> hello
<echo-are`> was the format of the bzr.dev head updated again?
<echo-are`> pulling remotely really takes long time again now
<echo-are`> thanks
<bob2> are you pulling into a rich root or knit repository?
<echo-are`> how to see that?  sorry i'm a newbie
<bob2> what command are you running, and where?
<echo-are`> i'm running bzr pull
<echo-are`> in the top level directory of my local version of bzr.dev
<bob2> and that's just a branch you made, and not in a repository?
<hsn_> is there simple way to convert checkout to lightweight checkout?
<echo-are`> bob2: yes
<bob2> hsn_: bzr reconfigure --lightweight-checkout should do it
 * echo-are` thinks he should not delay reading the bzr manual by other things now
<bob2> afaik the format hasn't changed in a couple of months, and the only other thing I could suggest is that pulling packs into other format repositories is slow
<hsn_> bob2: thanks, it worked
<echo-are`> bob2: ok.  i recall that on nov 2007 the format was changed, and i did update my local format.  so perhaps this is because of the poor network i have.  thank you
<Odd_Bloke> echo-are`: Does the output of 'bzr info' include 'pack' anywhere?
<bob2> echo-are`: you can compare the output of "bzr info" and "bzr info http://bazaar-vcs.org/bzr/bzr.dev/"
<echo-are`> Odd_Bloke: yes, it says "format: pack-0.92"
<Odd_Bloke> echo-are`: In that case it's likely to be network.
<echo-are`> bob2: Odd_Bloke: thanks.  i'll read the bzr manual right now :)
<echo-are`> bob2: when you mentioned "a repository", did you mean creating a repository with 'bzr init-repo' and executing 'bzr branch' etc in that repository?  thanks
<bob2> yes, if you did that with a different repository format to that of bzr.dev, it could cause a slowdown
<echo-are`> bob2: thanks :)
<awilkins> Is there any way to get bzr diff to just emit a list of paths that changed?
<awilkins> Bah, never mind, I think bzr status is what I want
<james_w> I'm trying to checkout a branch from launchpad using the smart server and Repository.get_parent_map() is taking a huge amount of time.
<awilkins> Ok, next question, whats the easiest way to determine the common base revision of two given revisions?
<james_w> awilkins: "bzr find-merge-base" can do it for two branches.
<awilkins> Would the algorithm there be something like "read back until they share a mainline revision id, then check all the merges to see which contiguos revisions they have in common"?
 * awilkins is more and more wishing he could use bzr instead of svn for this project....
<awilkins> Maybe I'll just try and use bzr-svn for it.
<james_w> awilkins: I'm not sure what the algorithm is to be honest.
<awilkins> Well, I was just trying to work it out, but I'm glad there's an implementation already
<awilkins> IF I can't figure it out I'll have to do i9t for SVN (or integrate bzr-svn.... looking better and better....)
<awilkins> If only the Eclipse plugins  for bzr were more mature./
<db-keen> I have two bzr branches in a directory, can I just init-repo in that directory, or do I have to do something special?
<awilkins> db-keen: init-repo another directory, and branch those two branches into it
<db-keen> then delete the original and rename the new one to the old one?
<awilkins> That should work
<db-keen> thanks, I'll do that
<awilkins> mylyn
<awilkins> oops
<Verterok> awilkins: I'm working on making bzr-eclipse better :)
<awilkins> Verterok: Oh, much appreciated :-)
<Verterok> awilkins: what are the key features you need in it?
<Verterok> maaybe
<awilkins> Verterok: Difficult to say, I'm working on a project for rather-non-technical users
<Verterok> maybe I can push those first :)
<awilkins> I'll communicate with you as I go ... I'd quite like the bzr / Java binding that underlies it too.
<Verterok> I just merged a improved 'new project wizard' (going to release it soon)
<awilkins> I thought the use of Jepp was prefereable to the "eats xml-output" approach, but that was mostly because xml-ouput was clashing with something at the time
<awilkins> Verterok: I might have a look at the wizard, I need a branch creation wizard that I can subclass to add functionality to mny users.
<Verterok> awilkins: great, I'm currently working in the bindings, updating to 1.x syntax and implementing switch, merge and reconfigure
<awilkins> ATM my project plan says "Subversion", but given their heavy and scary merge requirements I might persuade them otherwise
<Verterok> awilkins: jepp is quite dificult to distribute, and Jython guys are targeting 2.5 :-D
<awilkins> One downside being that the issue tracker I've settled on so far is integrated to a Subversion plugin
 * awilkins has no problems with Python 2.5, even though bzr officially targets 2.4
<awilkins> The issue tracker is a file based one, it shares little XML files around using a SVN repo
<Verterok> awilkins: jython only supports 2.3 syntax, with 2.5 we can use bzrlib from jython :) (I already have jython integrated in eclipse)
<awilkins> I keep finding myself wanting a Mylyn tracker like that instead
<Verterok> awilkins: did you look at bugs-everywhere? it's a similiar approach, but integrated with bzr
<awilkins> Oooo.
<awilkins> Can it do hook functions on workflow transitions?
<Verterok> awilkins: sorry Â¿hook functions?
<awilkins> I used a few brain cycles thinking about branched issue management the other day, merge the "issue fixed" along with the issues :-)
<awilkins> Yeah, things like "before I allow the issue to make this transision, check this function returns "true"
<ltsampros> hello ppl
<awilkins> Set field automatically, automatically commit + push on state transition, etc.
<Verterok> i think, that can be done from a bzr hook and  bit of python glue
<Verterok> awilkins: here is it: http://www.panoramicfeedback.com/opensource/index.html
<awilkins> I was thinking the same mysself..... is it integrated with Eclipse?
 * awilkins looks
<Verterok> awilkins: I think is not
<awilkins> But does it use dinky little XML files?
<awilkins> I could always write some integration, if it's easier than breaking my current appraoch (which really hasn't had too much work donwe to it)
<Verterok> awilkins: I think it uses plain text files
<awilkins> Well, that's fine too
<ltsampros> sorry for interrupting guys (i'm a very new user) , but let's say there is a repository like http://code.bitlbee.org/jelmer/win32/
<Verterok> Hi ltsampros
<ltsampros> according to the website, i'm told to create a local copy of the bitlbee-win32 branch using  bzr branch http://code.bitlbee.org/jelmer/win32 bitlbee-win32
<ltsampros> which works of course
<Verterok> awilkins: I'm sure abentley can help you with bug-everywhere integration with bazaar workflows
<Verterok> ltsampros: yep
<ltsampros> but let's say i want to get a list of all published branches in that repository. is there a way to do so. a half hour googling didn't reveal anything
<Verterok> ltsampros: http://code.bitlbee.org/jelmer/win32 is one branch, not a repo in the svn/cvs-way
<awilkins> If the web server lets you list the directory that'll workj :-)
<ltsampros> i see. thanks for the info
<Verterok> ltsampros: launchpad can help with that :) https://code.launchpad.net/bitlbee
<ltsampros> thanks for that too.
<ltsampros> integration with launchpad seems nice
<awilkins> Integration with launchpad will be veen incer when the source opens :-)
<ubotu> New bug: #194789 in bzr "Branches with symlinks can't be exported on Windows" [Undecided,New] https://launchpad.net/bugs/194789
<jelmer> Odd_Bloke: hi!
<jelmer> Odd_Bloke: still there?
<jelmer> Odd_Bloke: Im in the debian room atm
<Odd_Bloke> jelmer: Cool.
<Odd_Bloke> I attempted to get to that talk, but was too late to fit in. :p
 * jelmer is trying to get out atm, but I'm in the far back
<jelmer> LarstiQ: ping
<seba__> hi
<seba__> i try to run bzr fast-import
<seba__> and get http://pastie.caboo.se/156320
<seba__> any idea ?
<seba__> python version prolly
<Verterok> seba__: it seems that fast-import is using python-2.5 syntax
<Odd_Bloke> seba__: Yeah, that's syntax that changed between 2.4 and 2.5.
<seba__> yeah saw that
<seba__> http://www.python.org/doc/2.5/ref/try.html
<seba__> got this now:
<seba__> $ bzr fast-import /del/dvcs-test/hg
<seba__> bzr: ERROR: [Errno 21] Is a directory
<Odd_Bloke> seba__: I believe that 'fast-import' is designed to import from a specific format.
<seba__> I want to import from hg
<Odd_Bloke> To be able to import an hg branch, there needs to be Mercurial support for exporting to that format.
<seba__> thing is i didn't really understand what is this front-end
<seba__> ah ok
<seba__> front-end | bzr fast-import -
<seba__> I have to replace front-end by the one I chose
<hsn_> can i upgrade remote repo to packs?
<awilkins> Only via bzr+ssh, methinks
<Odd_Bloke> jelmer: I'm in the hacking room in the main building, BTW.
<seba__> it seems as if it's mission impossible to hg -> bzr
<Odd_Bloke> seba__: Yeah, unless you go via something that they both have decent conversion tools for.
<Odd_Bloke> jelmer: I'm being kicked out of the hacking room, so probably won't be on IRC for a while.
<Verterok> seba__: maybe bzr-hg? http://bazaar-vcs.org/BzrForeignBranches/Mercurial
<seba__> Verterok, I tried this one
<seba__> it's slow as hell
<awmcclain> If you have a local mirror branch with local feature branches, wouldn't it theoretically make branching faster to put them all in a local shared repository?
<Verterok> seba__: the last option I'm aware is tailor, but never used it
 * Verterok lunch, bbl
<seba__> Verterok, in fact i didn't try bzr-hg but http://bazaar.launchpad.net/~luks/+junk/bzr-hgimport
<seba__> which was the slow one
<seba__> but bzr-hg only allow mirroring
<seba__> not direct export <-> import
<seba__> and concerning tailor it was ~as slow as bzr-hgimport
<johnny> slow is a problem?
<johnny> it'll finish and you won't have to do it again?
<seba__> yeah sure
<seba__> i agree
<seba__> but you know ppl are impatient :)
<johnny> calling it mission impossible is a big overstatement then
<johnny> unless it fails..
<seba__> hg -> git was ~5h while hg -> bzr with bzr-hgimport would be 37h and with fast-import fails
<johnny> git is surely faster
<seba__> and 37h when it doesn't fail in the middle for unknown reason...
<johnny> git makes more compromises tho in design
<seba__> like ?
<johnny> compare monotone to git and you'll see
<seba__> it's already hard job comparing hg, git, bzr
<bob2> awmcclain: yes branching within a repository might be faster than not
 * awmcclain tests
<johnny> hg is out of the running for me, mainly due to the fact i think bzr will getmore use than hg
<johnny> and go farther, mostly due to launchpad if nothing else
<johnny> and git is still too cryptic to use
<johnny> especially for vcs n00bs
<seba__> hehe
<johnny> so for me, it is monotone vs bzr
<seba__> fact is apart of Canonical partners bzr wasn't chosen by any big name so far...
<johnny> that's a big enough name, especially since launchpad mirrors so many repositories
<seba__> and monotone isn't as popular as the 3 others
<johnny> but the design is amazing
<awmcclain> seba__: I've used hg and bzr. I ended up choosing bzr for our team because a) the centralized features made sense for our webapp 2) the docs are much better IMHO 3) the eclipse plugin is _much_ better (and we're a partial eclipse shop
<johnny> seba__, you do know git got it's best ideas from monotone right?
<seba__> what prevented you from having a central peer with hg ?
<seba__> johnny, i do think it just got its ideas from BitKeeper instead...
<johnny> no
<johnny> i'm sure they got some of the ideas
<johnny> but if you go back and read, you'll see that if mtn would have been faster at the time
<seba__> lol
<johnny> we might not even know what a "git" is
<seba__> sure man
<awmcclain> seba__: There aren't as many features to faciliate centralized workflows (i.e. checkouts to force lockstep development).
<seba__> but that's the game...
<johnny> seba__, i was using bitkeeper around the time
<johnny> so i know about that whole situation, we had to switch too
<johnny> we were #3 on the bitkeeper list
<johnny> right behind the linux kernel and mysql
<seba__> bzr lost many battle because of its crappy performance of the beginning
<seba__> it's hard going back after such
<johnny> when we chose, we didn't have a git to choose from :) and bzr barely exited
<johnny> existed*
<awmcclain> Yup. I still think hg is a tad faster... but if you follow a workflow where you have local mirrors (which i think bzr does a better job promoting), then it's not really an issue
<johnny> oh..and when git did start.. there was definitely no win32 support
<awmcclain> Woah! Big peedup!
<awmcclain> *speedup!
<awmcclain> Average time branching without a shared repo... ~20sec
<awmcclain> Average time branching with a shared repo... ~3 sec
<awmcclain> Plus, using a shared repo I can get around that rich-root-pack bug!
 * awmcclain cheers
<awmcclain> One question about http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar
<awmcclain> Are the developer names just folders in the repository? With branches inside them?
<abentley> awmcclain: yes
<ubotu> New bug: #177683 in trac-bzr "All revisions and changesets starts with a comma sign" [Low,Triaged] https://launchpad.net/bugs/177683
<ubotu> New bug: #194831 in trac-bzr "Non-urlsafe characters are escaped in branch names" [Undecided,New] https://launchpad.net/bugs/194831
<db-keen> I'm having trouble pulling an svn repo to branch into a repository
<db-keen> bzr: ERROR: Repository KnitPackRepository('file:///[...]/.bzr/repository/') is not compatible with repository SvnRepository('http://[some_site]')
<db-keen> it works fine if I branch outside the repository
<db-keen> can I just bzr branch $SVNREPO $BRANCH;mv $BRANCH $LOCAL_BZR_REPO/
<james_w> db-keen: yes, bzr-svn requires something called 'rich-roots'. The default format does not support them.
<james_w> You can either create a "rich-root-pack" repository (bzr init-repo --rich-root-pack) for working with bzr-svn, or force bzr-svn to not use that repository, by using the workaround you suggest.
<james_w> *providing that $BRANCH is not inside another shared repository*
<db-keen> is there some reason I wouldn't use rich-roots?
<db-keen> Can I convert an existing repo to use rich roots?
<james_w> db-keen: they are a watershed conversion, so once you switch to it all branches of that code you interact with must use it also.
<james_w> This is fine for bzr-svn based stuff, but for existing bzr projects it is harder.
<james_w> For new bzr projects then I suggest you use it.
<db-keen> why is it harder?
<db-keen> is it compatible with Launchpad?
<db-keen> if I should use it for new projects and it works with svn when other formats don't, why isn't it the default?
<james_w> yes, it is.
<james_w> I'm not sure what the exact reason is really, but we want to transition soon.
<james_w> one reason is that "bzr init-repo" would do the wrong thing to branch an existing project.
<db-keen> I'm still not sure what you meant by "for existing bzr projects it is harder"
<awmcclain> db-keen: I *just* ran into this today
<awmcclain> Also note that as of 1.2.0, if' your client is using bzr+ssh:// you have to do a work around to check out SVN-based bzr branches as well.
<awmcclain> Since the "smart server" transports create branches on the local machine in the default format, not the remote format
<db-keen> what exactly do you mean svn-based?
<db-keen> I'm still running bzr 1.1.0
<awmcclain> bzr branches that you import from SVN. I set up our machines to have a mainline on a central server (and I ported over our codebase from SVN), so when i made my shared repo i had to init with --format=rich-root-pack.
<awmcclain> (in order to prevent that error that you're talking about)
<awmcclain> Then, on my dev box, when I went to bzr co bzr+ssh://mainline local-mirror, it gives another error
<awmcclain> If you're not using a "smart" transport (bzr+ssh://, bzr://), you don't have to worry about that second bug.
<awmcclain> db-keen: Is the repository you're branching into on your local machine or a remote one?
<db-keen> awmcclain: I'm trying to branch an svn repo on a remote machine into a bzr repo on the local machine
<awmcclain> And you already have other, non-svn branches in your repo?
<db-keen> yes
<awmcclain> :(
<db-keen> I've been working with bzr without using repositories
<db-keen> I'm still entirely sure what the advantage is, but people make it sound like a good idea for some reason...
<db-keen> still *not* entirely sure
<awmcclain> Are your existing branches the same codebase as the svn branch?
<db-keen> they're related, I'm trying to merge code from another project (the svn) into my existing bzr project
<awmcclain> Here's what I would do...
<johnny> i'm still trying to merge my understanding of what i'm used to working with. with bzr..
<johnny> thus i have trouble with understanding the repository thing too
<awmcclain> Here's how I think of bzr shared repositories
<awmcclain> (as someone who just spent the last 3 days moving from SVN to bzr)
<johnny> well moving from svn to anything would be an improvement (except cvs)
<johnny> i avoided svn from the start.. so i dont'really have experience with that
<awmcclain> Normally, when you make a self-contained branch, you have ALL of your version history in that branch, along with your working tree-- the "checkout" of that branch (to use SVN terms)
<awmcclain> meaning, the entire log is tucked away inside that directory
<johnny> the entire change graph
<awmcclain> shared repositorities are basically special folders that hold the common histories of the branches inside them
<awmcclain> johnny: ye
<awmcclain> s
<johnny> aha..
<db-keen> awmcclain: that seems like what I'm trying to do
<johnny> see.. i'm used to working with monotone, where that already happens by default
<awmcclain> For example:
<johnny> as long as you put your code in the same db
<awmcclain> I have a mainline server
<awmcclain> And I have a mirror on my local machine, and from that mirror i'll be making lots of little feature branches
<awmcclain> Without a shared repository (on my local machine), each time i branch i copy the ENTIRE history
<awmcclain> (the entire graph)
<awmcclain> but, if my mirror and all my branches are in a repository
<awmcclain> when I branch, I'm copying over (i think) just my working tree
<awmcclain> difference of 20 secs to branch vs 3 sec to branch
<awmcclain> plus less disk space
<db-keen> awmcclain: I keep all my projects in a single directory (~/Projects), should I just turn that directory into a repo?
<johnny> hmm. why do i feel that bzr is more complicated ..
<johnny> db-keen, not if they are unrelated it seems
<awmcclain> exactly
<johnny> ~/projects/foo/ would be one
<db-keen> they are unrelated, but at the same time, I just might share code between them
<johnny> ~/projects/bar would be another
<awmcclain> because you only really get a benefit of a shared repository when you have a signifcant common history
<johnny> then how are they related?
<johnny> db-keen, use case?
<awmcclain> db-keen: I'd say, if you're just cherry picking some change between them, don't worry about putting them all in a shared repo
<db-keen> that's what I thought, I just had to ask
<awmcclain> db-keen: Are projects/foo and projects/bar two different branches or two different projects?
<johnny> i meant projects when i used it as an example
<db-keen> the way I have it right now, subdirs of ~/projects are mostly branches, but I've been converting the larger ones into repos with nested branches
<awmcclain> db-keen: Can you give an example of the one of your repos?
<awmcclain> s/the//
<johnny> you should go with ~/projects/random for random unassociated branches
<johnny> or something
<johnny> and then ~/projects/projectfoo for repos
<johnny> for all branches of projectfood
<johnny> err foo*
<lifeless> johnny: unrelated projects work fine in a reop
<lifeless> johnny: repos are _just_ storage optimisation.
<johnny> either way... the actual shared ones can go together
<johnny> or should
<db-keen> I have to go, but thanks for your help
<awmcclain> welcome
<db-keen> I might be back later...
<awmcclain> What's the bzr command to show me what files have changed in a branch?
<luks> bzr st?
<awmcclain> That's not recursive, though, right?
<luks> it is
<luks> it displays files for the whole branch by default
<awmcclain> ok
<awmcclain> Sorry, i was looking in the wrong branch. You're totally right. :)
<awilkins> The bit about bzr I find more complicated is the multiple repo formats, and the no-fixed-central-point thing.
<johnny> the no fixed central point is at least par for the course among all the systems :)
<johnny> except svn and cvs that is
<johnny> the multiple repo formats is certainly an annoyance in bzr atm
<awilkins> And a lack of mature integrated GUI tools... I'm too used to being able to r-click on a file and get a diff in my favourite diff tool
<johnny> something to deal with at some point
<johnny> once again.. par for the course :)
<johnny> there are some tortoise type things iirc
<johnny> for other systems
<awilkins> Handling win32 file locking semantics is another thing
<johnny> does any system handle that well?
<johnny> it's been awhile since i've used anything on windows
<awilkins> TortoiseSVN is of course very good at it :-)
<johnny> nasty windows
<awilkins> swings/roundabouts
<johnny> i'm glad i only have to make small glances at worry about support with
<awilkins> In some ways, I don't really trust the whole laxy unlinking thing
<johnny> with windows*
<johnny> windows file locking sucks.. i'm so glad i don't have to worry about..
<Peng> The one good thing about the multiple formats is that at least it's handled pretty smoothly.
 * awilkins could name several bugs that contradict that theory
<Peng> "pretty". :P
<johnny> i bet they relate to svn crap :)
<awilkins> Translating between pack-092 and rich-root-pack are the ones I've bumped into :-)
<Peng> Ah, yeah.
<Peng> Incompatible formats seem to be the main rough spot at the moment. :\
<lifeless> awilkins: you can use a fixed central location i fyou want, by using 'checkout and commit' rather than 'branch and push'
#bzr 2008-02-24
<james_w> lifeless: looms look pretty cool to me, thanks again.
<james_w> lifeless: any direction you want to point me in to do a bit of hacking to start to understand the mechanics?
<james_w> I think the only difference with what I was looking at was the order of the parents in the merge commits that result from up-thread.
<james_w> and obviously that you have a working implementation :)
<cjb> Hi!  Is there a way for a repository to specify its submit_to address, such that `bzr send` could send mail to a default address for a pulled repository?
<Verterok>   
<baijum> The "HistoryOfBazaar" wiki page says: "In early 2008, Bazaar became GNU Bazaar when release 1.2 was accepted as part of the GNU project." is there any news or more details available ?
<abentley> baijum: Not yet.  I was expecting some kind of announcement, but it's just kind of leaked out gradually.
<abentley> cjb: Not yet.
<Peng> Wait, so that's true?
 * bob2 watches bzr climb up to 1gb of ram to check out ikarus.dev
<bob2> with a healthy 3MB of data in the branch so far
<Peng> So, what's the point of being a GNU project? Canonical can provide all of the hardware bzr needs, and I doubt they'd want to give up any control over the project...
<Basic> marketing
<Peng> Advertising?
<Peng> Heh.
<NichardRixon> homestarrunner.com cool website
<Basic> heh
<Peng> So, the big thing for shareware in the 1990s was to be get a Download.com badge, and now FOSS projects are going to go after GNU badges?
<Basic> my local repo is messed up, is there a way, other then do do a bzr pull of upstream to just suck down all of upstream and overwrite and conflicts in my local repo?
<Peng> Basic: Conflicts? Like, you've committed things in the branch, or your repo is corrupt?
<Basic> like I forgot to commit stuff in local (desktop), hacked code in my laptop, pushed the changes from laptop to upstream, now want local/desktop to be in-sync
<Basic> bzr merge gives me 138 conflicts and I know upstream and laptop are the changes I want to keep
<bob2> now hit 1.5GB, nice
<Peng> Basic: Why can't you bzr pull from upstream?
<Basic> trying
<Peng> Basic: "bzr help pull" says "If you want to forget your local changes and just update your branch to  match the remote one, use pull --overwrite."
<Peng> s/  / /
<Basic> excellent, exactly what I want thanks
<bob2> with giant red flashing lights "you may lose data"
<Peng> Heh, right.
<Peng> Basic: You can use "bzr missing" to see if you have anything important in your version of the branch.
<Peng> Oogh, why do I feel sick?
<Peng> jelmer: I'm being lazy and not doing research here, but the BzrPlugins page lists bzr-svn as beta. Is it still?
<lifeless> bob2: 'bzr heads' can recover commits, at leat until a gc.
<lifeless> 16:33  * bob2 watches bzr climb up to 1gb of ram to check out ikarus.dev
<lifeless> woops, didn't mean to paste :|
<Peng> lifeless: By gc you mean the revisions being removed from the repo? Does that ever happen automatically?
<lifeless> Peng: not presently
<Peng> Right.
<Peng> Ok, I'm going to go take that nap I meant to take an hour ago. Bye. :)
<jeremyb> Peng: it's at 0.4.x iirc
<jeremyb> Peng: i need to try it...
<jeremyb> Peng: recently saw a bug fixed where it made a remote svn repo unusable by *anyone* on commit fwiw
<jeremyb> (not all commits)
 * jeremyb needs to sleep as well
<bob2> lifeless: ah, neato
<Odd_Bloke> jelmer: I'm in the Debian room ATM.
<jelmer> Odd_Bloke: ping
<Odd_Bloke> jelmer: Pong.
<jelmer> Odd_Bloke: still wandering around on FOSDEM?
<Odd_Bloke> jelmer: Yeah, in the Debian room ATM.
<jelmer> Odd_Bloke: ah, cool
<jelmer> me too
<jelmer> LarstiQ is the guy behind the big camera btw
<Odd_Bloke> Yeah, I ran in to him last night.
<Odd_Bloke> His hair was less blue at that juncture.
<Odd_Bloke> jelmer: I'm kinda opposite the door, wearing a red T-shirt using a Thinkpad.
<Odd_Bloke> A T60, if that helps narrow it down. :p
<johnf> is there anyone about that understands the smart server code? I'm trying to fix a bug in it
<Odd_Bloke> johnf: Asking your question makes it more likely that people will respond. :)
<johnf> Odd_Bloke: ok let me go paste some stuff somewhere
<jelmer> Odd_Bloke: ah, I think I know who you are then :-)
 * jelmer is sitting close to the door with a Thinkpad X60 and wearing a black debian sweater
<johnf> http://pastie.caboo.se/156526. Basically a change was made which meant bzr+https stopped working. I've fixed that but now it looks like _remote_is_at_least_1_2 needs to be set somewhere.
<johnf> I think just setting it to true like is done in bzrlib/smart/client.py is correct but I'm not sure of the right place to do it
<johnf> the transport/http/_urllib doesn't feel like it would be the right place to do it
<jelmer> johnf: you may want to bring this up on the list
<jelmer> I don't think there are any smart server ackers about
<johnf> that was my next move :)
<jelmer> *hackers
<james_w> johnf: one moment
<james_w> johnf: I thought this came up on the list the other day, but I can't find it now.
<james_w> johnf: are you using latest bzr.dev?
<johnf> james_w: opps too late. Just emailed the list with some potential fixes. Stupidly didn't check archives. I'm testing with latest bzr.dev
<james_w> johnf: no loss, I just thought there was a tentative patch you could apply, but as I can't find it a mail to the list is best.
<johnf> james_w: The patch I just email works. First part I know is right. Second part does the job but I'm not sure that its appropriate. As I learned while debugging it today there is a lot of codebase involved in getting the smart server to do stuff!
<james_w> johnf: I can't confirm I'm afraid, but you should get a response either way tomorrow.
<hsn_> someone with sf.net shell acount with installed bzr here? I need bzr path
<ubotu> New bug: #195133 in bzr-loom "Please notify when a thread becomes empty" [Undecided,New] https://launchpad.net/bugs/195133
<ubotu> New bug: #195134 in bzr-loom "Lots of up-threads are tiring" [Undecided,New] https://launchpad.net/bugs/195134
<Janzert> does "bzr tag blah" tag the most recent revision committed or get applied to the next commit?
<dato> Janzert: the most recent committed revision
<Janzert> thanks
<shagbag> Can anyone help me with bazaar.launchpad.net?    I'm trying to checkout some code but it's taking AGES to connect and then it gives me the error: bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known')
<awmcclain> Hey all... can someone enlighten me why, when I try to push my changes back to my mainline, I get bzr: ERROR: No push location known or specified.
<jdong> awmcclain: it doesn't know where to push?
<awmcclain> jdong: How does that get set? I can pull fine
<jdong> awmcclain: the first push has to have an explicit destination. Afterwards bzr will remember that destination. Also see push --remember
<awmcclain> jdong: I see. So, the first time you have to specify.
<jdong> awmcclain: right.
<jdong> awmcclain: hte last paragraph in bzr help push explains it better than I can :)
<awmcclain> jdong: Got it.
<jdong> awmcclain: also, bzr info can show you the various remembered locations, if you forgot or need something to copy-paste from
<awmcclain> jdong: Is there an easy way to convert a branch into a checkout w/o overwriting the files I've changed?
<jdong> awmcclain: bzr bind
<awmcclain> Done.
<awmcclain> greart
<jdong> awmcclain: any differences you've made will show up as a merge when you first bzr up
<awmcclain> hrm
<lifeless> shagbag: sounds like a dns error at your location
<lifeless> shagbag: what does 'host bazaar.launchpad.net' say ?
<lifeless> hi poolie
<poolie> good morning lifeless
<james_w> morning lifeless
<james_w> morning poolie
<james_w> lifeless: I might be being silly, but can you confirm that setting tree.branch.nick doesn't change the thread you are on?
<james_w> I'm looking at test_up_thread_preserves_changes in blackbox.py
<lifeless> james_w: it changes the pointer at the current thread
<lifeless> james_w: in the TODO there is a note that this should be replaced by it renaming the current thread.
<james_w> lifeless: thanks.
<lifeless> james_w: most of TODO can be made bugs now
<lifeless> james_w: for hopefully obvious reasons, using malone was a little tricky before the release.
<james_w> lifeless: of course.
<james_w> lifeless: you abandoned the rename to warps?
<igc> morning all
<lifeless> james_w: mixed minds
<lifeless> I think the accuracy of warp and weft reference will be beyond most folk;
<lifeless> that is not actually helpful
<lifeless> but most everyone knows what a thread is in fabric terms
<lifeless> OTOH warp and weft are a more detailed analogy with richer (and useful) implications
<lifeless> poolie: today I am doing ui for shallow branches
<igc> poolie: call now?
<james_w> lifeless: I might spend some time sorting out the TODO and moving some stuff to Malone then.
<james_w> patch sent anyway, that's all for tonight.
<lifeless> that would be good
<lifeless> thanks!
<james_w> the code looks very clean from what I have seen, and the documentation is great as well, so thank you.
<james_w> The only thing I am not that clear on is "record", but it seems that is a temporary solution according to the TODO.
<lamont> I wonder if there's already a bug in the system about bzr not tracking file permissions
<lamont> (git does)
<james_w> lamont: git doesn't
<james_w> lamont: which permissions would you like tracking?
<lamont> git diff 8e16fa6ff4f1bd3e42febd166f3e1074c6f87bdb..7fca3ff2f2ab0774d4a92c2bd40bfc7c4d596e4c
<lamont> diff --git a/cron.d/cache-git-status b/cron.d/cache-git-status
<lamont> old mode 100755
<lamont> new mode 100644
<lamont> james_w: I beg to differ.
<lamont> although just tracking the last 12 bits would be plenty.
<lifeless> lamont: git doesn't track full modes; it just cheats for what it appears to record
<lifeless> lamont: see git-fastexport's stream format for instance
<lamont> while bzr just plain ignores mode
<lifeless> bzr tracks exec
<james_w> lamont: that just means executable, which bzr tracks as well.
<lamont> ah, just not rw?
<lifeless> anyhow, for sysadmins see the discussion I'm having with elmo & co about a plugin
<james_w> lamont: make it 750 and try again.
<lamont> james_w: hrm.. thanks
<lifeless> lamont: score one for git...not :>
<james_w> lamont: no problem. You can see etckeeper for some wrappers and stuff around git(?, maybe others) that tracks full (?) permissions for versioning /etc
<fullermd> It's easy to make it 750; you just have to change your umask   ;)
<james_w> lamont: but in general it is a headache to track them, so most systems don't.
<lamont> right
<lifeless> james_w: the canonical sysadmins would love a etckeeper for bzr; I have a spec
<james_w> lifeless: you mean a plugin, rather than using etckeeper?
<lifeless> yes
<james_w> I doubt etckeeper is VCS specific, but a plugin may make for a better experience.
<jelmer> lifeless: I have the implementation
<jelmer> lifeless: see http://gitweb.samba.org/
<james_w> right, that really is all from me. Thanks all, and good night.
<jelmer> however, it hsn't been merged yet because bzr doesn't have a start-commit hook
<jelmer> so it's not totally functional, which is why it hasn't been merged yet
<lifeless> jelmer: could you be more specific; thats just a web page list
<lifeless> jelmer: also, I'm talking about not using etckeeper but doing a plugin
<jelmer> there's only one etckeeper repo there :-)
<jelmer> http://gitweb.samba.org/?p=jelmer/etckeeper.git;a=summary
<jelmer> it basically boils down to being a plugin since it requires a plugin that calls out to etckeeper
<lifeless> is it just me or that web ui ugly?
<jelmer> of git web?
<jelmer> I like it better than loggerhead
<lifeless> loggerhead is ugly too
<lifeless> in differnet ways
<lifeless> none of the web uis I've seen for vcs introspection feel nice
<jelmer> yeah, there aren't any really good ones yet
<mwhudson> if anyone can come up with a nice design for loggerhead, i'm permanently volunteered to do the coding to make it happen, btw
<ubotu> New bug: #195245 in bzr-loom "'record' is too generic a name, and is possibly a conflict with another plugin" [Medium,In progress] https://launchpad.net/bugs/195245
<lifeless> mwhudson: I think its basically too static and too slow
<lifeless> mwhudson: the visuals aren't the issue, the coarseness of the interface is.
<mwhudson> lifeless: 'too static' ?
<lifeless> mwhudson: I'd like fast drill-downs, pivots between files/history/annotations
<lifeless> google maps for the vcs data
<mwhudson> oh right yes
<lifeless> now theres an idea; if we built maps tiles from a  branch we could literally point maps at it
<mwhudson> well, i see the point but don't really have a clue how this would work well
<mwhudson> (even out of a browser, truth be told: 'bzr viz' is pretty nice, but not completely there)
<awilkins> Is there a plugin which will allow you to commit selectively by deleting lines from your commit log "line below" section?
<lifeless> I believe so
<lifeless> selective commit I think its called
<awilkins> Could also use gcommit I suppose, but not as vimtastic :-)
<lifeless> jelmer: so when should I expect a patc to review for a commit start python hook ?
<jelmer> lifeless: when I find the time :-(
<jelmer> lifeless: My time for bzr is somewhat limited at the moment and the time I do have I spend on the plugins I'm maintainer for
<lifeless> you're coming next week ?
#bzr 2009-02-16
<lifeless> wow I love this plugin shit man
<lifeless> someone just added a plugin to do regex based mass renaming
<chx> oooh
<chx> so if i created a repository without rich roots (--1.9 ) then i cant change it now?
<lifeless> chx: you can upgrade to a rich roots flavour if you need to, but unless you have a specific need to don't.
<lifeless> we'll make a big noise and give instructions etc to everyone when we're ready to make rich roots the default
<chx> lifeless: ok.
<lifeless> spiv: ping
<edcrypt_> lifeless: this someone is me (the multi-renaming plugin) :)
<lifeless> edcrypt_: cool!
<mwhudson> argh
<mwhudson> getting BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x21bb410> has delta references to items not in its repository: ... pusing to launchpad
<mwhudson> do i need to reconcile the branch?
<chx> lifeless: if you would take time to read http://drupal.org/node/289117 and offer your view on some of the relevant points, i'd be delighted. I wanted Drupal on bzr for long and now David Strauss is partner in crime :) and also bzr got a tortoise -like Windows interface and also it became a lot faster so we are getting there
<edcrypt_> lifeless: its my first plugin, I hope its not the code is not too horrible
<lifeless> chx: I have a hectic day today, so I can't make any promises, but I'll see what I can do
<chx> I could find no documetnation of that Windows integration since it became integrated into bzr -- or the http://bazaar-vcs.org/TortoiseBzr page is still relevant despite it's shipped with bzr  since 1.6?
<mwhudson> oh god that "Brief article on benchmarks of Python repository with leading 	DVCSen" thread is so long
<lifeless> mwhudson: short story long analysis
 * mwhudson hits r and moves on
<rysiek|pl> ah, well
 * rysiek|pl 'll finish removing cruft tomorrow
<rysiek|pl> thanks a lot for your help, guys
<rysiek|pl> cu
<lifeless> ciao
<lamby> jelmer: I was wondering whether you could remove me from the Uploaders in bzr-gtk? Alas I haven't run bzr since I last played with that package in May '08.
<jelmer> lamby, sure, np
<lamby> I would do it myself but my non-DD alioth account (with the right perms) is gone.
<lamby> Was pleasure working with you, hopefully we'll cross paths (both technically and personally) soon.
<lamby> Take care and good night.
<jfroy> mwhudson: where is that thread you spoke of? Sounds interesting
 * igc back from doctors
<lifeless> jfroy: last week, about 40% of the traffic on bazaar@
<jfroy> lifeless: thanks!
<jfroy> Just read the PDF, and although it's very slim on experimental procedures, the data is a little bit harsh on bzr >.>
<jfroy> (now reading the mailing list thread)
<jml> uhh
<lifeless> huu
<jml> I'm starting to get a *lot* of email about ~launchpad-pqm/bzr/dev
<lifeless> I shall return shortly, getting bottled caffeine and other essentials
<jml> oh wait, that's *our* branch of bzr.
<jfroy> *phew* that was a long thread.
 * igc picks up kids
<gotgenes> I tried to do a Daggy Fix per http://monotone.ca/wiki/DaggyFixes/, which is linked off of http://bazaar-vcs.org/CherryPick, but it did not work at all like I expected. I must be missing something.
<gotgenes> I introduced a bug at revision 77 of the trunk, which is now at 90-something.
<gotgenes> I made a branch from revision 77, fixed the bug, and committed to the branch.
<gotgenes> Then I attempted a merge from the bugfix branch to the trunk. It resulted in a conflict because of all the revisions in the trunk since revision 77.
<lifeless> gotgenes: this is one of the big flaws with daggyfixes
<gotgenes> lifeless: shoot
<gotgenes> So I didn't necessarily do it wrong, right?
<gotgenes> Was I supposed to select a revision range from the bugfix branch instead? Does that still cause the cherry-picking problem?
<lifeless> gotgenes: you haven't cherry picked at all
<gotgenes> lifeless: right, I was trying to avoid cherry-picking
<lifeless> gotgenes: daggy fixes doesn't rely on cherry picks, but it leads to conflicts where the code has been changed since the bug was introduced
<gotgenes> since it says "it creates intransitive branches"
<lifeless> well
<gotgenes> er, ancestors
<lifeless> I don't do daggy fixes, I think they rarely work well in code that is being looked after, so I'm not really well positioned to tell you how to make it work
<gotgenes> lifeless: How do you merge in bugfixes to multiple releases, then?
<lifeless> I cherrypick
<lifeless> if we introduce a bug in say 1.6
<lifeless> and fix it during the 1.11 cycle
<lifeless> we generally don't merge it to multiple releases at all
<lifeless> but if we need to, we'd cherry picked it from the 1.11 branch
<lifeless> with one release a month, there is a massive cost to cherrypicking every bugfix across multiple releases
<lifeless> because there are lots of releases :)
<gotgenes> Yeah.
<gotgenes> I can see that.
<gotgenes> What about "cherry picking" the other way, as a forward port?
<lifeless> if we released every six months it would be different
<lifeless> so, cherry picking forward is daggy fixes
<gotgenes> Is it?
<lifeless> just starting sometime after the bug rather than 'right on'
<gotgenes> so technically branches after it should have all necessary ancestors, correct?
<lifeless> yeah, you would not need to cherry pick to go from 1.10 to 1.11, its a simple merge
<lifeless> but the issues are the same: code that has been maintained will have skewed, as you experienced
<gotgenes> yeah, I made a lot of edits on this file between revision 77 and now
<lifeless> yup
<gotgenes> but the lines I patched--they've been the same since
<lifeless> gotgenes: well, you could try --weave-merge and see if that behaves better for you
<gotgenes> so the revision 77-78 patch in the bugfix branch is what I need to put in my release branches
<gotgenes> lifeless: that's a good idea
<lifeless> I'm starting to think we need to revisit using patience diff
<gotgenes> what's a patience diff?
 * gotgenes should google it
<lifeless> its a clever diff algorithim thought up by the codeville authors
<lifeless> but it depends very heavily on ordering of unique lines
<lifeless> and I'm starting to think its too easy to break it badly
<gotgenes> so in my case, at commit 91, a lot of lines are unique to that commit compared to 77, so that throws off the algorithm?
<lifeless> gotgenes: uhm, I don't know it well enough to boil it down to a straight forward yes or no
<lifeless> but I can point you at the code :)
<gotgenes> So I did --weave and it didn't complain, says the file friendfeed.py was modified, but bzr diff friendfeed.py doesn't actually reveal what changed, and bzr status doesn't list the file as modified, but lists it in "pending merges"
<lifeless> gotgenes: *blink* if this is open source please file a bug
<lifeless> thats clearly bogus
<gotgenes> lifeless: My project is definitely open source
<lifeless> cool
<gotgenes> https://code.launchpad.net/~chris.lasher/friendfeed-pyapi/0.1.0/+merges
<gotgenes> That's what I'm trying to do at the moment.
<gotgenes> blarg, how do you back out of a merge?
 * igc back
<gotgenes> ah, mark conflicts as resolved first, then revert
<stub> Is there a plugin somewhere that implements upgrade-repo ? Or is standard practice to throw together a shell script to upgrade the repo and all its branches?
<lifeless> gotgenes: 'bzr revert' should just work
<lifeless> gotgenes: don't do 'bzr revert .' because that doesn't back out the merge
<gotgenes> lifeless: ah, that's the trick
<gotgenes> I was using '.'
<lifeless> why?
<gotgenes> um
<gotgenes> habit?
<lifeless> yeah, but from where?
<gotgenes> svn maybe?
<lifeless> no bzr commands need '.' :P
<gotgenes> silly me
<lifeless> 'bzr revert .' says 'revert only the subtree, no metadata'
<gotgenes> so explicit, too
<gotgenes> lesson learned
<gotgenes> Thanks for your patience.
<lifeless> my pleasure
<gotgenes> I do really enjoy bzr
<gotgenes> the Launchpad integration's a thing of delight for me, too.
<lifeless> excellent
<gotgenes> A couple of us in the BioPython project are trying to push it to bzr.
<gotgenes> There's the classic batting-around of the big 3 at the moment.
<lifeless> oh, I'm sure there is :)
<ronny> lifeless: is there any way to merge only a subtree of the full trr within a repo, it would be helpfull for stuff like wiki's where the granularity tends to be page-based, not tree based
<lifeless> ronny: bzr merge branch/subtree && bzr commit
<lifeless> ok, I'm done for the day; ciao
<ronny> hm
<ronny> now i have to figure an api for that
<vila> hi all
<thumper> hi vila
<thumper> vila: what are you up to today?
<vila> hi thumper
<vila> cleaning my plate of minor issues and fixing tests in brisbane-core, need any help on something ?
<ronny> are there any docs on the structure of brisbane-core?
<vila> ronny: that's a pretty vague question :-/ I don't think there are any high-level easy to grasp doc by itself... There have been many discussions on the mailing list, many  intermediate result reports but I'm not sure you will call that doc
<ronny> sad
<thumper> help
<thumper> bzr: ERROR: The dirstate file (DirState(u'/home/tim/src/lp/rocketfuel-devel/.bzr/checkout/dirstate')) appears to be corrupt:
<thumper> just from a measly Ctrl-C
<thumper> can I fix it?
<thumper> or shall I just blow the checkout away and get another one?
 * thumper re-checkingout
<vila> thumper: better blow the checkout away I'm afraid :-/ We should really have some command to re-create a dirstate from scratch though
<vila> thumper: if it's not too late may be filing a bug and attach the dirstate file, there may be some simple fix to avoid most common causes (no matter how rare they are, and they appear to be very rare to the best of my knowledge)
<thumper> vila: I kept a copy of the checkout
<thumper> vila: so I could file something later
<thumper> vila: but I'm chasing an issue right now
<vila> thumper: fair enough, I make no promises either but we have to start somewhere (and I fully understand 'chasing an issue right now' :-)
<thumper> :)
<vila> thumper: just for curiosity, was the ctrl-C misplaced or caused by a fear about not being able to reverse the command effect ?
<lifeless> thumper: ctrl-C is odd, because we write to a different file, then rename
<lifeless> *I thought*
 * thumper shrugs
 * igc1 dinner
<ronny> how does bzr store tags?
<Peng_> What do you mean?
<ronny> Peng_: how does it store tags for a revision
<ronny> oh, i just found the store
<ronny> hmm
<ronny> jelmer: any reason why tags are storend like [<len>:<name><len>:<rev>]*
<Peng_> Are they bencoded?
<ronny> the numbers are ascii text
<Peng_> Yeah, it looks like .bzr/branch/tags is bencoded. I never noticed that before.
<ronny> lifeless: if i merge a subdir of a branch it stops being able to merge the rest later
<Youssef> Hello all
<Youssef> or good morning for belgian people
<Youssef> i have a question!
<Youssef> who can help me?
<ronny> lifeless: odd, now it works again
<Lo-lan-do> Youssef: Nobody until you've asked.
<Youssef> :)
<Youssef> soo
<Youssef> so
<Youssef> i would like to lock a file woth bazaar like we do in subversion
<Youssef> is it possible first?
<Youssef> "with" bazaar sorry
<Youssef> not woth
<Peng_> Youssef: No.
<mvo> hm, I have a update-manager branch (not-automatic) that bzr 1.6.1 merges happily into the "main"  branch. but 1.9 (and 1.11) from jaunty say "Nothing to do". did something n the (default) merge algo change?
<mvo> ("not-automatic" is the name of the branch)
<ronny> lifeless: how does bzr manage metadata about subdir merges? im taking a look at bzr vis, but there it looks like a normal revision
<Youssef> Peng!
<Youssef> what it's not possible to lock in bazaar?
<ronny> Youssef: hu?
<Lo-lan-do> How could you lock in a DVCS?
<alex_morelli> hi all
<alex_morelli> how do I move a branch from a shared repo to another?
<Lo-lan-do> alex_morelli: Branch from one to the other, then remove it from the original one?
<alex_morelli> Lo-lan-do: What makes me hesitate is that I have two shared repos without trees and I would like to move (or copy) a branch from the first to the second
<Peng_> alex_morelli: So?
<Lo-lan-do> "bzr branch", also known as "bzr clone", is exactly a branch copy, whether for shared repos or not.
<alex_morelli> I tried to do this:
<alex_morelli> bzr init-repo --no-trees /opt/new-repo
<alex_morelli> cd /opt/new-repo
<alex_morelli> bzr branch /<other-repo>/project
<alex_morelli> now, do I feel like the complete idiot.... I was checking out, not branching
<alex_morelli> thanks everybody...
<Peng_> At least it was easy to solve. :)
<Peng_> Explaining problems often helps you figure them out.
<beuno> we should enforce lag
<Lo-lan-do> bzr status enforces a 1-second lag on me already.
 * awilkins wonders where the win32 builds of 1.12 are
 * Lo-lan-do wonders where the lenny backports of 1.12 are
<Lo-lan-do> ;-)
<awilkins> Bah, at least you can build it easily enough on Lenny
<awilkins> Building it on win32 is a female dog
<Youssef> guys please
<Youssef> noone respond me
<Youssef> is it possible to do a lock to a fille with bazaar?
<Lo-lan-do> Yes we did.
<stub> He wants to lock a file in his branch or repository, not every branch or repository.
<stub> I don't think it is possible to do that in bzr like in svn (not that I've ever done it in svn). There are better ways of working with a DVCS.
<ronny> Youssef: why do you need that lock
<Youssef> becoz my want it
<Youssef> heheh dunno why
<Youssef> mayber sick!? dunno.
<Youssef> maybe
<Youssef> :p
<stub> Locks are useful for files that can't be merged sanely. You want to flag that you are the person messing with it, and nobody should touch it until you have committed.
<stub> I don't think this can be done sanely with bzr or any DVCS.
<ronny> jelmer: ping?
<markh> awilkins: things like that are always subjective - I find building bzr on Windows quite simple these days :)
<ronny> hmm
<ronny> is there any reason why bzr branch in a repo wont create a workdir, even if the branch thats getting branched has one?
<Odd_Bloke> ronny: If the repository was created with --no-trees.
<ronny> ah, i see
<ronny> cna that be reconfigured?
<Odd_Bloke> ronny: Yes, but not using a bzr command AFAIK.
<ronny> rm .bzr/repository/no-working-trees ?
<Odd_Bloke> I think the code looks for a .bzr/repository/no-working-trees in the... yes.
<Odd_Bloke> :)
<ronny> hmm
<ronny> anyone awae how bzr tracks partial merges?
<ronny> unforutnately there isnt a tool to view the history of specific trees so its tricky to figure
<ronny> oh dammit
<ronny> actually partial merges can produce merge conflicts later
<ronny> lifeless: its kinda useless if it doesnt fix conflicts
<ronny> its just no fun having to fix conflicts twice
<fullermd> It doesn't.
<fullermd> Cherrypicks aren't tracked, whether they're of disconnected sections of history, or of partial bits of the tree.
<ronny> sad
<ronny> then its useless for me
<fullermd> No different from any other major tree-oriented system.
<fullermd> You can't record "I've merged this revision", since you haven't; you've only taken some changes from it.
<fullermd> It probably works in svn, since it's not tree-oriented.
<fullermd> You could do a full merge, and then revert everything but that subdir.  That would record it.
<fullermd> But of course, since you recorded that you've merged those revs, you'll never get changes to the other files in the future.  And probably set up some ugly conflicts there later.
<ronny> cant it be recorded at least for the tree
<ronny> else its just generating merge conflicts and pretty useless
<fullermd> But what could you record?
<ronny> no idea, doesnt each tree have a parent?
<fullermd> Merges are recorded by tieing revisions into the ancestry.
<fullermd> They're not recorded by saying "Oh, I got change X to file Y from over here".
<fullermd> The tracking happens by merge later saying "Oh, I've already got this revision, so I don't need to look at it again".
<ronny> cant it do that with trees, too?
<fullermd> By having a non-tree-oriented system, like svn.  Or by inventing a whole new layer of metadata, which would be a rich field for bugs, and probably very touchy.
<fullermd> I mean, anything _can_ be done.
<fullermd> But it's far more likely that some solution will be created for tracking the cherrypicking of revisions, long before cherrypicking of PARTS of revisions.
<fullermd> And that's an ugly enough problem in itself.
<ronny> hmm
<fullermd> (actually, I'm not even sure it svn can record merges of parts of revisions and DTRT.)
<fullermd> But I would guess it does, or at least can relatively easily.
<fullermd> As well as it DTRT with anything, of course  ;)
<awilkins> markh: Yes, it's getting the environment up that's the nasty bit :-) it's very easy after that
<verterok> vila: I'm back home, dmg for 10.4 is comming ;)
<vila> verterok: great !
<verterok> vila: oh, Hi :)
<LeoNerd> Anyone have a nice bash trick on how to ignore .bzr directory for tab complete?
 * fullermd points at the manpage and the first match for /dot
<fullermd> And then smack yourself (or whoever you stole your rc file from) for setting the option in the first place   :p
<CBro2007_> hi I am new to BZR
<CBro2007_> any users here?
<CBro2007_> just had a few questions about it
<CBro2007_> I have just created some files under revision control
<CBro2007_> now I was wondering how I can "checkout" revisions from the past?
<CBro2007_> like an undo feature?
<Odd_Bloke> CBro2007_: Look at 'bzr revert'.
<CBro2007_> ok
<weigon> revert, uncommit or just branch to a older revision
<Odd_Bloke> CBro2007_: Or possibly uncommit, depending on whether you want to revert content or commits.
<CBro2007_> I am super new... just looked at it 5 mins ago
<CBro2007_> and just trying to see if it will work for me
<CBro2007_> so now that I have created a repository.... this will keep the history of the project?
<CBro2007_> is that what I should have in my .bzr directory?
<LeoNerd> fullermd: I already have dotglob off
<LeoNerd> fullermd: this means that .bzr isn't listed if I do   echo *
<LeoNerd> That doesn't affect the tab complete;  complete 0-f
<LeoNerd> -f
<asabil> CBro2007_: bzr init hello && cd hello && touch hello-world && bzr add hello-world && bzr commit -m "Initial import"
<asabil> that's the complete sequence for a really quick start
<CBro2007_> I have done all that
<CBro2007_> but one step at a time
<asabil> yep, then that's all what you really need to start hacking
<CBro2007_> I am just trying to understand what my WORKING copy is and if I screw something up how I can revert back to a good copy?
<asabil> bzr revert -r -1
<asabil> to return to the previous commit
<asabil> (sort of)
<ronny> hmm
<ronny> still no support for update -r ?
<asabil> I also suggest installing bzr-gtk or qbzr to view the history
<asabil> ronny: https://bugs.launchpad.net/bzr/+bug/45719
<ubottu> Ubuntu bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress]
<ronny> ah, nice
<asabil> CBro2007_: another better solution imho is to use bzr branch
<asabil> bzr branch -r 1234 trunk old-trunk
<ronny> oh, not so nice, seems kinda dead
<ronny> asabil: branch sucks in various cases when going back in history
<asabil> personally I prefer this approach, since I tend to maintain multiple "builds"
<asabil> but different people have different workflows
<stefanlsd> Anyone seen this before - bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'  (doing an bzr status)
<jelmer> stefanlsd, out of date bzr-loom I think
<fullermd> LeoNerd: Well, I dunno.  I don't use bash (actually, had to think for a second to figure out which boxes even had it installed)
<fullermd> LeoNerd: A little more /-ery finds match-hidden-files though.
<LeoNerd> Oooh
<fullermd> (though the description doesn't make a damn bit of sense.)
<stefanlsd> jelmer: thanks. thats prob it. will update it from the ppa
<jelmer> stefanlsd, afaik bzr-loom isn't in the ppa
<LeoNerd> Excellent. That has it
<LeoNerd> Thanks.
 * fullermd just assumes the option name makes more sense than the alleged explanation  ;p
<LeoNerd> Now all I have to do is work out how to have it ignore 'CVS' :)
<fullermd> Oh, that's what "rm" is for  ;)
<quicksilver> grah!
<quicksilver> I can never find loggerhead's "real" home page
<quicksilver> https://launchpad.net/loggerhead
<quicksilver> ^^ is that the right one?
 * fullermd didn't know our patches were tracked by Brigitte Bardot.
<fullermd> No wonder bzr is so awesome...
<vila> fullermd: :)
<vila> quicksilver: 'bzr lp-open lp:loggerhead' goes straight to the trunk branch, from there you can click the Overview tab :)
<quicksilver> ;)
<quicksilver> vila: google search for 'loggerhead bzr' fails
<quicksilver> which is a bit odd.
<vila> quicksilver: file a bug against google :)
<Odd_Bloke> Sounds more like a Launchpad SEO problem. :)
<vila> speaking of google and bzr, does anyone know hw to add search engines python, I added some (for modules, documentation, mailing list and bugs) but I can't remember where I found them :-/
<vila> gee, s/garbage/how to add search engines for python/
<vila> add search engines to *Firefox*, looks like I really don't want to help people who can answer :)
<CBro2007_> guys I just created the "initial import"
<CBro2007_> I want to be able to create a fresh copy of my project so I can start adding new features to it
<CBro2007_> how do I do this in Bazaar?
<CBro2007_> should I be making the changes to my working copy now?
<CBro2007_> or do I create a new branch from my initial import?
<CBro2007_> just trying to understand how I can structure this
<CBro2007_> anyone got any suggestions?
<Lo-lan-do> You can work in the same place, or create another branch.
<awilkins> bzr init-repo /home/me/my-new-repo --no-trees ; bzr push ~/my-new-repo/my-project/trunk --create-prefix ; bzr push ~/my-new-repo/my-project/feature-1 ; bzr bind ~/my-new-repo/my-project/feature-1
<evarlast> i think I may have had a file once in the history of my bzr branch. I would like to find the said file. does bzr have a find command?  bzr find -r 1.. FileName*.c ?
<fullermd> log -v | grep?
<evarlast> ah, duh.  thanksyou.
<Youssef> thanks all
<Youssef> i have to go bye
<Youssef> ++
<jelmer> verterok, ping
<vila> spiv_: go back to sleep :)
<vila> jam: ping
<vila> jam: in bbc, do we intend to keep development3 or can I delete it ?
<jam> vila: I'm deleting it as part of my --development5 patch
<jam> so I wouldn't delete it *just* yet
<jam> further, I'm technically on holiday today...
<vila> jam: oh sorry
<jam> its fine
<jam> I'm  building the 1.12 installers
<jam> and doing other work
<jam> and certainly, lurking on IRC :)
<vila> True holiday :)
 * vila notes to never go in vacations with jam :-P
<jam> well, I do take real vacations
<jam> but only when my wife is *also* on vacation
<jam> today is a federal holiday
<jam> so it is a Canonical holiday
<jam> but it isn't a holiday all businesses recognize
<vila> haaa, that kind of holiday :)
<jam> so I'm mostly using it as a day to play with stuff
<jam> like finally setting up the new Ubuntu based server w/ 1TB RAID1 drives
<vila> SSD ?
<jam> (as opposed to my old FC3/4 server)
<jam> well, new as in 3+ years old
<jam> but better than my 10-year old server I have now
<jam> :)
<jam> the hard-drives are new
<vila> good enough :)
<jam> It seems that Ubuntu install disks don't like to do software raid by default
<jam> it seems that the "server" version might be a bit better
<jam> but instead you can use the live cd
<jam> to configure everything manually
<jam> and then install
<jam> but it took 2 different guids
<jam> because one didn't explain the simple "you should have used -server" fact
<jam> and the other assumed you didn't, but was setting up raid 10 rather than just raid 1
<Mez> what does
<Mez> Value "bzr+ssh://io/home/bzr/mf/lib/branches/foo/" is masked by "bzr+ssh://io/home/bzr/mf/lib/branches/foo" from locations.conf
<Mez> mean?
<jam> Mez: you have a value in ~/.bazaar/locations.conf
<jam> and a value in .bzr/branch/branch.conf
<jam> the value in locations.conf "wins"
<jam> but may not be what you actually want
<jam> most likely you did "XXX --remember"
<Mez> this is a new branch though
<jam> Mez: then I would guess you have a recursive policy set in locations.conf
<jelmer> Mez, perhaps an older branch existed on the same location?
<Mez> new repo.
<Mez> Maybe it's being bound automatically on first push ?
<verterok> jelmer: pong
<jelmer> verterok, does the main bzr dmg include bzr-svn these days?
<Mez> hwo cna I check if a branch is bound?
<jam> Mez: bzr info
<santagada> who does the macosx installer?
<Mez> that doesnt metnion anything to do with bound branches
<verterok> jelmer: no, the main issue to solve is how to include two builds of bzr-svn in the same dmg and check which one to use (for svn 1.4 and 1.5)
<Mez> basically, I want to be able to automatically set a bind location, like I can with a push location
<verterok> jelmer: as OSX 10.4 don't have any subversion, so any version could be installed :/
<santagada> the one for 10.5 was not updated, maybe I could generate it if it not contrived
<Mez> but it doesnt seem that it wants to work
<verterok> santagada: I build the OS X 10.4 dmg
<verterok> santagada: phanatic builds the 10.5 one
<santagada> but I use svn 1.5... so this could be a problem
<jam> Mez: you should see something like: "checkout of branch: bzr+ssh://..." if it is a bound branch
<santagada> verterok: there isn't a way to support both svn versions automatically at runtime?
<jam> vila: I have to say, setting up much of anything on a 1TB disk takes a while.
<jam> Even at a nice 70MB/s, it still takes 4Hours for software raid to sync the partitions
<vila> jam: ? You mean formatting it ? Or any install ?
<jam> well, raid syncing
<jam> Even if I did the hardware-raid option
<verterok> santagada: that is a question to jelmer, but I think the problem is compiling/linking of the bindings
<jam> it wants to sync the drives
<jam> which is a bitwise copy of everything
<verterok> santagada: I think the 10.5 installer already provides bzr-svn
<vila> ohhh, that I have no experience with :-) I'm going the SSD and full-backups-when-it-s-time route :)
<jelmer> verterok, it's not possible to ship the required svn libs?
<jam> vila: yeah, this is a server with some hard-to-get-back data
<jam> so I like to have a bit of RAID
<jam> I'd like to do full backups
<jam> but w/ 300GB it gets difficult
<verterok> santagada: as I don't have the sources, I'm starting to work on a 10.5 installer based on the 10.4 one
<verterok> jelmer: don't really know, what libs should be shipped?
<santagada> verterok: I have svn 1.5 from fink, and I have the bindings only for python-2.4 on fink also...
<jelmer> verterok, the ones installed by svn, or rather, the ones that subvertpy links against
<vila> jam: I can understand the hard-to-get-back data... not :-) I have 1,5TB available for compressed backups ran at night, some crossed fingers and most of the important bits under bzr and as such mirrored here and there :)
<verterok> santagada: as far I know subvertpy can't be linked against the fink svn and used with other svn
<verterok> santagada: other users might have the macports one or the Collabnet
<verterok> version
<verterok> jelmer: sadly I didn't looked subvertpy yet, the last time I worked on this subject, the binding was bundled with bzr-svn. I might take a look to it again :)
<jelmer> verterok, ah, ok
<santagada> verterok: so bundling the svn client is the only answer right?
<verterok> jelmer: now that you mentioned this, if there is a way to compile the deps as static libs and link subretpy to that I think it should be fairly easy to bundle bzr-svn
<verterok> santagada: yes, or build an installer for each possible svn installation :/
<verterok> jelmer, santagada: or compile  subvertpy during the install (but that might be even more difficult)
<jelmer> verterok, building against a static libsvn should be doable
<santagada> verterok: needing to have xcode just to use bazaar is not optimal...
<vila> verterok: not to mention requiring a C compiler :)
<phinze> so CruiseControl.rb (the CI server we would probably use) only supports Subversion
<phinze> it's possible for me to use bzr-svn to publish our trunk and project branches as svn urls for the CI server, no?
<jelmer> phinze: you'll have to push them into svn manually, but yes
<verterok> vila, santagada: sure, was just a crazy idea, thinking that most people using a vcs are developer :p
<verterok> :)
<vila> python, perl, java, etc are some languages that doesn't require a *C* compiler :-P
<verterok> jelmer: ok, I'll try to build it that way
<verterok> vila: yeap, having a 1GB monster (xcode) to use bzr is overkill
<jelmer> phinze, bzr svn-serve is not mature enough yet
<phinze> jelmer: so not really a viable solution currently for automatic continuous integration
<vila> jam: is your default working PC 64 bits or 32 bits ?
<jelmer> phinze, well, you can push using a cron-job or something like that
<jam> vila: 32
<vila> that explains the warning I encounter then I presume: /home/vila/src/bzr/experimental/brisbane-core/bzrlib/chk_map.py:78: DeprecationWarning: 'i' format requires -2147483648 <= number <= 2147483647
<jam> perhaps
<jam> could you get a backtrace for it?
<vila> Using L solve the problem but I still find it strange that zlib.crc32(bit) can return such values... Oh wait it returns an unsigned. That still doesn't explain you never saw that warning...
<jam> Considering where I'm seeing it:
<jam> struct.pack('>i', zlib.crc32(bit)
<jam> right
<vila> That's the right line
<jam> if it was returning an unsigned int
<jam> then I would have expected to use ">I"
<jam> it is returning a *signed* int on 32-bit python
<jam> since it is just an "int"
<jam> PyInt
<jam> which is a 32-bit signed int on 32-bit platforms
<jam> AIUI
<vila> crc32 should returns a 32bits int so to be compatible you should use a long
<vila> the question is is it signed or not
<jam> on 32-bit I'm sure it is signed
<jam> >>> zlib.crc32('aocehu')
<jam> -2083739398
<jam> vila: what do *you* get ?
<vila> 2211227898 :-)
<vila> boom
<jam> (The issue on Python is that a 32-bit unsigned int has to be held in a PyLong)
<jam> vila: that is very unfortunate... :(
<vila> jam: don't worry, better understand that *now* :)
<vila> eerk, more hits while grepping crc32 than I hoped :-/
<jam> vila: what do you get for this: >>> zlib.adler32('\xff'*20)
<jam> -784198675
<vila> 3510768621
<jam> vila: and you aren't doing anything fancy with your python, right?
<vila> apart from running it on a 64bits processor, I don't think so
<jam> IIRC we explicitly switched from adler32 to crc32 at some point in the past
<jam> I thought because crc32 was supposed to be more stable across platforms, etc
<jam> (we use it in the dirstate file)
<jam> vila: see http://bugs.python.org/issue4903
<vila> I just checked dirstate.py and tune_gzip.py and AKAICS whe use them after some U32 conversions
<jam> .. Guido prefers to keep Python 2.x always having signed values for the  scattered crc functions.
<jam> vila: output_lines.append('crc32: %s\n' % (zlib.crc32(inventory_text),))
<jam> I don't see a U32 conversion there
<jam> do you?
<vila> argh, missed that oen
<vila> So, accessing a dirstate file from a 32 bits *and* a 64 bits hosts should blow up half of the time ?
<verterok> jelmer: I'm building svn-1.5 with --enable-all-static atm, I'll let you know how it's going in a while (my oldish G4 needs some time to compile it)
<jelmer> verterok, cool!
<vila> Poor jam, that was too much :)
<jelmer> :-)
<Tak> argh, how do I get the status of one file using bzrlib?
<vila> jam, come back ! It looks like that crc isn't used after all :)
<fullermd> ISO9001 requires we have a CRC.  It doesn't require that it be used   :p
<vila> That how I understand IS9001 too :-)
<vila> The pity is that most of QA guys *think* that way though :-/
<vila> "I broke the code !!", "No problem, as long as you *document* it !" :-(
<fullermd> Works for Microsoft.
<ronny> lifeless: would there be any reasonable way to take partial merges into account when merging again?
<rocky> jelmer: hey, is there a bzr-svn release for bzr 1.12 yet or a branch?
<jelmer> rocky, the 0.5 branch
<rocky> kk
<jelmer> rocky, 0.5.0 will also work, but is slower
<rocky> jelmer: the 0.5 branch is merely lp:bzr-svn right?
<jelmer> rocky: yeah, lp:bzr-svn is a mirror of the 0.5 branch (between 0 and 8 hours out of date, usually)
<rocky> oh yeah, you host the 0.5 branch yourself right?
<jelmer> rocky, yep
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<ronny> jelmer: sup?
<luke-jr> How do I switch a checkout to another upstream branch?
<mwhudson> bzr switch
<lifeless> ronny: well its a specific case of cherrypicking (in the content dimension)
<lifeless> ronny: so the same things apply as for cherrypicking - yes, we need to when merging take it into consideration
<lifeless> but we don't yet
<rysiek|pl> yellow again
<rysiek|pl> any teflon-underwear-wearing, sharks-with-lasers-defying bzr-replay-helping volounteers of yesterday present and willing to help? :)
 * Lo-lan-do unleashes the sharks
<Lo-lan-do> Go kids go!  Get him!
<rysiek|pl> erm
 * rysiek|pl kindly points out it was he who unleashed sharks - with lasers! - last time he was here
<rysiek|pl> and it *would* sound better a'la Mr Burns:
<rysiek|pl> "Swim, my pretties!"
<mwhudson> vila: ping
<mwhudson> duelling sharks with lasers!!
<rysiek|pl> ops, with lasers?
<Lo-lan-do> Mine have laser swords and ninja powers.  Do you surrender now?
<rysiek|pl> ninjas can't catch you when you're on fire!
 * rysiek|pl takes spills around some gasoline
 * rysiek|pl fires a match
 * RAOF fires up the petrol-powered, ninja zombie steampunk cyborgs.
<rysiek|pl> with lasers?
<rysiek|pl> RAOF: ok, so I branched -r REV_BEFORE_FSCKUP my_branch
<RAOF> Ok.
<rysiek|pl> RAOF: and now I bzr replay -r REV_AFTER_FSCKUP.. my_branch
 * RAOF notes that he hasn't done what you're trying to do before, so will only be able to offer general advice.
<rysiek|pl> hopefully this will give me a nice, clean, cruft-free branch
<rysiek|pl> *but*
<rysiek|pl> it will be bound to the original, crufted branch
<rysiek|pl> so...
<RAOF> What do you mean by "bound"?
<rysiek|pl> oh, wait
<rysiek|pl> checkouts are bound
<rysiek|pl> branches aren't
<rysiek|pl> m'kay
<RAOF> Yes.  Branches are not :)
<rysiek|pl> so, this will give me my nice, cruft free branch
<rysiek|pl> now, it's a "secondary" branch, ie it's my dev branch
<rysiek|pl> so, to make the miracle happen in the upstream "trunk" branch - bzr push?
<RAOF> I believe so.  It might take push --overwrite, because you're doing some history rewriting.
<rysiek|pl> right
<poolie> hello all
<poolie> hello jam
<rysiek|pl> RAOF: hmmm, ok, I have gotten a conflict, resolved it and need to continue
<rysiek|pl> RAOF: bzr rebase-continue tells me there is no rebase pending
<rysiek|pl> RAOF: bzr replay-continue -> no such command
<rysiek|pl> I am stuck
<RAOF> rysiek|pl: And you're now out of my sphere of experience :(
<rysiek|pl> ah, well
<rysiek|pl> google, then
<mwhudson> sounds like a question for jelmer :)
<lifeless> rysiek|pl: now you replay from the point it stopped
<jelmer> ronny: hi
<lifeless> rysiek|pl: a newer bzr-rebase plugin may help, I fixed some bugs recently
<rysiek|pl> lifeless: great, but the revision of the no_cruft branch when started replaying was 2315
<rysiek|pl> lifeless: and the revision I started replaying from was 2320
<rysiek|pl> lifeless: now, as I watched the output I have noticed, that the "Comitted revision <REVNO>" messages tell me about the <REVNO> of the no_cruft branhc at the given moment
<rysiek|pl> lifeless: so orig:2320 becomes no_cruft:2316, etc
<jelmer> rysiek|pl: hi
<jelmer> rysiek|pl: replay doesn't handle conflicts at the moment
<rysiek|pl> lifeless: as I understand, I should take the REVNO that was given in the last "Committed revno..." message, add 4 and start again from <LAST_REVNO+4>?
<lifeless> jelmer: it spuriously conflicts without my patch
<lifeless> jelmer: I dunno if you merged it or not
<jelmer> lifeless: which patch?
 * rysiek|pl brb
<jelmer> the one that had the --rewrite-nick ?
<lifeless> yes amongst other fixes
<jelmer> I didn't merge that one, but I think all your other branches are in
<lifeless> rysiek|pl: rebase may not actually be the right tool on consideration, because we have to flatten all your other branches, so that they don't drag the bad history back in
 * jelmer wonders what happened to Asabil's filter-branch plugiun
<phinze> hmm anybody have a way of appending the a diff to the bottom of $EDITOR when writing the commit message as well as the list of files modified?
<lifeless> poolie: ping
<lifeless> phinze: 'commit --show-diff'
<poolie> phinze: commit --show-diff
<poolie> lifeless: hi!
<phinze> haha
<phinze> just found it
<poolie> phinze: where did you look for it?
<phinze> thx lifeless, poolie
<phinze> i was just glazing over it in bzr help ci
<phinze> my bad
<rysiek|pl> lifeless: huh? I don't think I understand the problem
<lifeless> poolie: I have my allergy specialise appointment today @ 11:30; I'm pondering popping by your place beforehand, in the gap between transport and appointment. Does that fit for you?
<poolie> sure
<lifeless> rysiek|pl: say you have revisions 1,2,3,4,5, where 2 is bad
<rysiek|pl> aye
<lifeless> rysiek|pl: if 4 is a merge of a branch, made from 3, (so that branch went 3,4,5 of its own and got merges as '4' to the trunk
<rysiek|pl> aye
<lifeless> rysiek|pl: then, if we recreate the merge, and *still reference* the branch, we can follow history back down to 2, which is what we're trying to redact
<lifeless> rysiek|pl: so in theory we need to replay the items of that branch seperately as well, and then its fine, but more simply is to just cherrypick merge '4'
<rysiek|pl> something tells me now will be the conclusion
<rysiek|pl> ah, there we are ;)
<lifeless> 'replay' doesn't quite handle this case IIRC, I'd need to check the code again
<rysiek|pl> hmm
<rysiek|pl> ok, so what I understand from what you're saying is:
<rysiek|pl> when doing a replay, use the first rev ABOVE the last merge into the original branch?
<lifeless> no, I'm saying that replay may not be quite the tool you need, but bear with me a sec
<rysiek|pl> sure
<lifeless> jelmer: at least cherrypick http://bazaar.launchpad.net/~lifeless/bzr-rebase/dev/revision/116 if you won't take the rest
<lifeless> jelmer: it makes the code match the documentation
<phinze> okay so trying to get --show-diff to be default behavior... i need to use aliases, no?  but aliases don't allow spaces in alias name.  so i'm just stuck defining something like alias bzrci="bzr ci --show-diff" ?
<phinze> or is there a better way?
<lifeless> rysiek|pl: ok, try replay - just keep upping the revision to start from in step with any manual fixes you need to make, you can use 'bzr log' to see whether you have the right revno
<lifeless> phinze: bzr can do command aliases, you can alias commit to commit --show-diff
<phinze> ahh aliases *within* bzr... i always thought the reference was to bash aliases
<rysiek|pl> lifeless: so, bzr replay (...), when conflicted fix manually and bzr replay again from where the conflict occured?
<phinze> once again, misreading the docs [/shame]
<lifeless> rysiek|pl: yes
<rysiek|pl> ok
<lifeless> rysiek|pl: once you're done, test by:
<lifeless> 'bzr diff -r branch:../source' - that should show no changes
<lifeless> and
<lifeless> 'bzr branch /tmp/testsize' - then du -sh .bzr/repository
<lifeless> if it has worked, you won't have that 400MB any more
<jelmer> lifeless: any chance you can provide a patch ? :-)
<ronny> jelmer: im wondering, can you guys manage to track partial merges better?
<lifeless> jelmer: I did :P
<lifeless> jelmer: I proposed the branch for merging
<jelmer> lifeless: yeah, but that's got different things bundled together, cherrypicking just some causes conflicts..
<lifeless> jelmer: what does it conflict in ?
<ronny> i hate that merging a subdir of a repo will cause conflicts later :/
<jelmer> lifeless: can't recall, it's been a while since I've tried
<jelmer> ronny: I'm not really familiar with merge algorithms, but from what I hear from those who do cherrypicking is tricky
<lifeless> jelmer: that commit is independent of the other two, I can't see it conflicting on anything other than NEWS, and its trivial
<ronny> hmk
<lifeless> jelmer: much faster really for you to merge and adjust than me to merge you, fix, push, and have you cherrypick the result (which won't apply anyway, because its still my full feature branch)
<rysiek|pl> hmmm
<spiv> lifeless: I figured out why I feel slightly hesistant about putting get_missing_compression_parents on VersionedFiles.
<rysiek|pl> turns out quite a lot of cruft (about 1/2) was there from the beginning
<rysiek|pl> is there a way to make a "lightweight" branch or something like that?
<rysiek|pl> i.e. branch with the history of the last, say, 20-500 revisions?
<rysiek|pl> *20-50
<jelmer> lifeless: Well, you could push a separate branch that provided just the bugfix, no need for me to cherrypick in that case.
<jelmer> lifeless, Anyway, I don't object to doing the cherrypick + conflict resolution, I'll merge next time I work on rebase.
<jelmer> lifeless: Looks like test_blackbox.py conflicts, and some of the tests in test_rebase.py fail
<verterok> jelmer: this static svn build is getting difficult :/. until now I only succesfully builded a ppc-only version :-(
<mwhudson> beuno: hello?
<rysiek|pl> lifeless, RAOF, jelmer: I've got a fourth conflict in the same file, an the size of the no_cruft branch is 3x what was the size of the crufted branch
<rysiek|pl> this does not bode well, I think I'll live it be
<jelmer> verterok, :-( What are the other builds failing on?
<jelmer> vila, ping
<rysiek|pl> anywhoo, thanks for your help
<rysiek|pl> cu all
<lifeless> jelmer: ok, I'll look at that then
<lifeless> jelmer: and get you a specific branch for it
<lifeless> rysiek|pl: :( sorry
<lifeless> I wish we had a polished-better-answer
<rysiek|pl> lifeless: nothing to be sorry about, really
<lifeless> spiv: so, I'm so close I can taste it
<rysiek|pl> thanks a lot for your help, anyway
<rysiek|pl> learned a lot about bzr during this
#bzr 2009-02-17
<jelmer> lifeless: Thanks
<jelmer> lifeless, hopefully I'll be able to find some time next month to transform bzr-rebase into bzr-rewrite
<verterok> jelmer: I'm trying to build a universal (ppc & i386) static svn in order to ship it with bzr-svn
<verterok> jelmer: I'm failing to build it as universal, but I think it's a matter of configure it with the right flags, atm I'm trying to build apr as universal, as it seems the svn iself works ok
<lifeless> spiv: success:
<lifeless>         raw_record_map = self.vf._get_record_map_unparsed(keys, allow_missing=True)
<lifeless>         record_map = self.vf._raw_map_to_record_map(raw_record_map)
<lifeless> spiv: if we serialise raw_record_map, a dict of simple types, we can resume this function on the other side .
<lifeless> spiv: 'yay'
<lifeless> -> appointment
<spiv> lifeless: :)
<eferraiuolo> I'm wondering what the best way is to do SVN style keyword substitution is in bzr?
<eferraiuolo> I would like to replace $Date$ and $Rev$ in my files in a certain project (repo/branch)
<spiv> eferraiuolo: there was a thread about that on the mailing list recently
<spiv> I think igc is looking at writing code to do that?
<spiv> igc: ^
<eferraiuolo> oh alright; so I shouldn't expect it to be baked into bzr right now then?
<RAOF> You can get the same sort of effect semi-automatically, ish.
<RAOF> eferraiuolo: 'bzr help version-info' will give you something a (very) little bit like what you want.
<eferraiuolo> So do you put things like {date} in your source code then run the command?
<igc> eferraiuolo: see https://launchpad.net/bzr-keywords
<igc> eferraiuolo: the main sticking point is that bzr.dev doesn't supporting content filtering yet - a patch is up for review for that
<eferraiuolo> not sure I totally get the workflow with bzr version-info
<RAOF> eferraiuolo: What you'd have to do is stick {date} in your source code, and then filter it through sed with the output of version-info (urgh).
<RAOF> gnome-do uses version-info in the buildsystem, to define a nice, complete version string with revno and branch nick and such.  It works well for that.
<spiv> eferraiuolo: a cleaner way to use version-info tends to be to have a command to use it to generate a single, small source code file with the values in it.  e.g. a header file for C with a #define.
<spiv> eferraiuolo: and then have the rest of your project reference that file, and have your makefile regenerate it when appropriate.
<eferraiuolo> yeah, although I'm looking at doing this in a JavaScript file
<spiv> Ah.  That does sound awkward :)
<eferraiuolo> :-) It's mainly to help people keep track of what revision my small JS file is in so they know if the one they are using is old or not
<eferraiuolo> so I just wanted it in the comment block at the top of the file
 * spiv nods
 * igc lunch
<jml> what's the default merge algorithm these days?
<poolie> jml, i think it's lca
<jml> I just had an interesting conflict experience where I removed a large chunk of code in one branch, and the branch I merged in had removed adjacent but independent large chunks of code.
<jml> reading the herringbones was a little tricky at first. the solution (under a weave merge) was just to delete everything inside conflict markers
<mwhudson> i think the default is still merge3 actually
<mwhudson> as i've done bzr remerge --show-base and not had it complain at me
<baxissimo> how do you sever the connection between bzr-svn checkout brach from svn?  I want to switch to "mirroring" setupd.
<RAOF> baxissimo: I'd guess that you'd do that with 'bzr unbind', assuming bzr-svn works as I'd expect.
<baxissimo> RAOF: "convert the current checkout into a regular branch"  -- That sounds like that should do it!
<baxissimo> What kind of non-regular branches are there?
<baxissimo> Just checkouts and branches?  Is that the distinction?
<RAOF> Pretty much, yes.
<baxissimo> And big difference with a checkout is that bzr ci actually pushes to the remote repo automatically?
<baxissimo> (Looking into bzr after a while using hg...)
<lifeless> baxissimo: yes, checkouts behave like svn checkouts, branches behave like, well, branches
<baxissimo> Hmm, "bzr bind" on the bzr-svn tree says "No location supplied and no previous location known"
<lifeless> baxissimo: you can supply a url
<lifeless> baxissimo: this is the one oddity - you can turn a brnach into a checkout by doing 'bzr bind URL'
<lifeless> )
<lifeless> :)
<baxissimo> What I mean is that RAOF said bzr-svn was like a checkout, but unlike a checkout "bzr bind" doesn't report the currently bound location (the SVN tree).
<RAOF> bzr-svn, in my experience, basically makes bzr treat svn URLs the equivalent of bzr branches.  So you can 'bzr checkout svn://wherever', and get a checkout, or you can 'bzr branch svn://wherever' to get a branch.
<baxissimo> Anyway, what I really wanted to know was how to determine if a given source tree is a branch or checkout.
<RAOF> 'bzr info' will probably get you that.
<baxissimo> I thought "bzr bind" with no arg would give that, but maybe not.
<baxissimo> Beautiful.  Thanks.  Ok, and "bzr bind" apparently will rebind to the previously bound location.  "bzr unbind && bzr bind" seems to get me back where I started.
<igc> lifeless: see line 145 in http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/annotate/head%3A/scripts/script_common.py
<igc> lifeless: also log -v takes days/hours for large repos so I don't include a benchmark for it yet. I will soon
<lifeless> igc: is that a 'tree only' answer?
<baxissimo> I had one more newbie question -- hg folks recommend NOT setting up repos SVN style with lots of separate projects all together under one common top directory. How about bzr?
<baxissimo> I think with Hg the problem is that there's no way to check out just a single directory of a repository, so you end up having to pull everything in just to get that one dir.
<baxissimo> Is Bzr the same in that respect?
<bob2> bzr doesn't conflate branches and repositories
<bob2> also repositories are just storage optimisations for bzr
<bob2> so "no"
<baxissimo> So can "bzr branch" make a branch of just a particular directory of a remote repository?
<bob2> sure
<bob2> with bzr, repository = box of branches sharing a common revision store
<baxissimo> Ok, but I want the offline check-in goodness, too.
<bob2> the only downside is that operations modifying revision data will lock the whole repository (I think)
<bob2> that is unrelated
<baxissimo> Ok.
<baxissimo> So what would be the command to get a branch of just the bar directory of the foo repository?
<igc> lifeless: yes
<bob2> bzr branch bar/foo
<bob2> foo foo/bar, obviously
<bob2> holy crap
<bob2> bzr branch foo/bar
<baxissimo> bob2: that tells me ERROR: Not a branch: "........foo/bar"
<bob2> are you sure you're clear on what a branch is?
<baxissimo> bob2: but just   "bzr branch foo" works.
<bob2> you can't "branch" a subdirectory of a branch
<baxissimo> bob2: not entirely sure what it means in bzr-o world, no.
<bob2> then foo is a branch, not a repository
<baxissimo> bob2: Ah, ok.  So they're different with bzr.  I sort of see what you mean about bzr not conflating the two concepts.
<bob2> bar is just a subdirectory in a branch, and you can't checkout (or branch) just that bit (no dvcs I've heard of can)
<baxissimo> Ok.
<baxissimo> You can do it with SVN, so SVN repos tend to have lots of only loosely related stuff in them.  Like 'baxissimo-repo".
<bob2> if hg works differently, it is pretty unique among version control systems
<bob2> svn is just a versioned filesystem
<bob2> it doesn't really have branches
<rexbron> james_w: So, profiles did not make the cut outstanding merges on bzr-bd? Do you still see it as nessicary and/or useful?
<bob2> except by convention
<baxissimo> No hg can't do it, svn can.
<baxissimo> Those are the two vcs's I know best.  So I wanted to know what about bzr.
<bob2> I was refering to hg's idea of a "repository"
<baxissimo> I'm about to convert a big svn repo to bzr, and I want to know if I should try to split it up into separate bzr repos ... er "branches" I guess I mean.
<lifeless> bob2: hg doesn't work differently
<lifeless> baxissimo: 'bzr-svn' can split it up into different branches for you
<lifeless> baxissimo: in fact,it tries quite hard to guess correctly. The easiest way to find out is 'bzr branch svn://foo/bar'
<bob2> lifeless: ah
<baxissimo> lifeless: easiest way to find out what?  What it actually did?   I used TortoiseBzr to make the svn->bzr checkout.  It looks like it put everything in one big branch.
<baxissimo> By that I mean there's only one .bzr file at the top.
<lifeless> baxissimo: if you did a checkout, then yes. As a special case though, bzr-svn considers a checkout of a whole svn repo different to checking out one branch within a svn repo
<lifeless> baxissimo: so did you checkout the root of your svn repo, or a subdir?
<baxissimo> I checked out the root.
<baxissimo> So I should do dir-by-dir checkouts instead?
<lifeless> baxissimo: yes
<lifeless> baxissimo: also, there is a command 'bzr svn-import' that will convert the entire repo for you in one hit
<lifeless> I doubt that tortoise exposes that, but you might like to give it a go
<lifeless> jelmer: that special case ^ seems to confuse people regularly, can we make it more inaccessible or something, so it only works when its really the right thing to do?
<jelmer> lifeless, it's not a special case
<jelmer> lifeless, at the moment bzr-svn will warn if it thinks you should not be checking out the root
<baxissimo> lifeless: Looks like it does not expose it.  So svn-import will split things up automatically?
<jelmer> baxissimo, did you see such a warning?
<baxissimo> lifeless: or do I need --standalone?
<jelmer> baxissimo, yeah, it will split up automatically, no need for --standalone
<baxissimo> jelmer: ugh, ok here goes another 3 hr checkout/conversion process
<jelmer> baxissimo, what bzr-svn are you running? Newer versions should be significantly faster
<jelmer> baxissimo, also, did you see a warning about checking out the repository root when you ran "bzr checkout" originally?
<baxissimo> 1.11 seems to be the newest installer version for windows
<baxissimo> No saw no warnings, but maybe tbzr just didn't pass them along?
<jelmer> baxissimo, ah, that could indeed be what's happening
<baxissimo> I have to pull 1116 revs from france to tokyo, so it may not be bzr's fault here :-)
<jelmer> I think the 1.11 installer still has an older bzr-svn, but still one that does have the warning
<baxissimo> Anyway, it is time for lunch over here, so I'll just let svn-import chew, while I go do some chewing of my own.
<baxissimo> Thanks for the help jelmer, bob2, lifeless and RAOF.
<lifeless> jelmer: will you see a warning from the gui?
<jelmer> lifeless, I don't know what tortoisebzr/qbzr do, bzr-svn just calls trace.warning
<lifeless> jelmer: I suspect nothing :)
<jelmer> I suspect you suspect right
<lifeless> jelmer: if its not on bzrlib.ui.ui_factory, I'd expect everything to disappear
<jelmer> lifeless, so, the alternative is to just flat out refuse checkouts from the root if that doesn't match the layout (as set by the user or guessed)
<jelmer> lifeless, I'm divided as to what is the right thing to do here
<jelmer> some users seem to actually *want* to check out the root, but the current behaviour also allows others to shoot themselves in the foot
<lifeless> jelmer: I agree its difficult
<lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
<poolie> is it just me or does 1.12rc1 not give progress bars on windows?
<ronny> jelmer: sup?
<ronny> jelmer: after my exams i'll tackle compiling python down to c a bit using annotations + inference, i hope i'll be able to apply that to dulwich
<lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
<poolie> lifeless: i hope you haven't been doing that since lunchtime?
<lifeless> poolie: oh no,
<lifeless> poolie: you d/c'd when I went to tell you before
<lifeless> 15:55 < lifeless> poolie: I have made a minor edit, I'm not sure i'm finished, but there is plenty there
<lifeless> 15:56 -!- poolie [n=mbp@ppp112-44.static.internode.on.net] has quit [Read error: 60 (Operation timed out)]
<lifeless> poolie: I have just sent in a [MERGE] for byte-encoding for record streams
<lifeless> poolie: which means that tomorrow spiv and I will be glueing the various bits together, we should have a wart-free push working to stacked branches, without the ucky upcast to full texts used previously
<ronny> lifeless: why are tags bencoded?
<lifeless> poolie: however, I'm well past 'done time' :) so sayonara, and chat to you tomorrow
<lifeless> ronny: I don't know
<ronny> lifeless: also, are there things like signed tags? (git has those as objects)
<lifeless> ronny: sorry, I need to head off, hopefully someoneelse can chat :)
<lifeless> ciao
<ronny> cu
<vila> hi all
<CBro2007> hi guys I am just checking out bzr and I am a newbie...
<CBro2007> I have gone ahead and done the steps to reach my "initial import" and now I am wondering how I can proceed by keeping a good working copy and working on another copy that I will add features to?
<CBro2007> Any suggestions as to how I should be doing this?
<Peng_> You should read the documentation.
<CBro2007> Peng: I am
<CBro2007> its a bit convoluted
<CBro2007> I am used to CVS and then SVN's trunk/branch model
<CBro2007> just wondering how I can achieve the same using bzr
<keithcu> Hi;
<keithcu> I have a basic BZR question. Can I ask it here?
<CBro2007> after the initial import do I just start working on the "working copy"?
<CBro2007> or should I create a different "dev" branch and work on that ... then merge the branch to the main branch?
<CBro2007> Peng: any suggestions?
<keithcu> I peng: it seems like you are trying to do something similar to me. You should have two branches
<keithcu> One that is the main one, and then your personal one where you do your work.
<keithcu> (Or maybe two branches, if they are totally different areas that you are working)
<keithcu> Then, when you are satisfied with something, you push it to the main one.
<keithcu> I guess that is for CBro2007, sorry.
<CBro2007> keithcu: yes
<keithcu> That is what I am trying to setup. Unfortunately, the docs I see don't give such clear help in the context of launchpad
<CBro2007> keithcu: my understanding is that maybe I don't need to start a NEW branch and I can just use the working dir
<Peng_> Some people like to use the main branch for simple things, and separate branches for mroe complicated stuff.
<CBro2007> aha
<CBro2007> that is the concept
<keithcu> Yes, if it is just you, you can party in one branch
<CBro2007> so when I reach a major milestone I commit my changes to the MAIN branch (or trunk)
<CBro2007> and then I should in theory be able to start up a new branch yeah?
<CBro2007> I have done the initial import... now how do I create a new branch from this?
<Peng_> CBro2007: "bzr branch"
<CBro2007> bzr: ERROR: command 'branch' requires argument FROM_LOCATION
<CBro2007> how do I view a list of my branches?
<Peng_> CBro2007: "bzr branch path/to/your/branch some_new_path"
<CBro2007> it tells me how I can branch from a PUBLISHED branch
 * Peng_ points to the documentation
<Peng_> CBro2007: You can branch from any branch.
<CBro2007> so how do I branch a copy from my Original Import?
<CBro2007> and when do I "publish" a branch? Is this done so other people on the project can COPY this branch and work on it?
<Peng_> CBro2007: Yes.
<CBro2007> k
<keithcu> I have a question: I have setup two branches: https://code.launchpad.net/openracing
<keithcu> My keithcu work branch is fine, but now I'm trying to push these changes to trunk.
<CBro2007> ok managed to create a new branch from my existing initial import
<keithcu> I don't know how to do that.
<keithcu> I tried bzr init, bzr merge ../work, bzr push lp:openracing, but that didn't work
<CBro2007> you want to know how to branch from the initial import?
<CBro2007> ?
<Peng_> keithcu: 1.) What's the point of merging into an empty branch? Heck, you can use pull then, 2.) You need commit after merging
<Peng_> keithcu: Did you want "bzr branch"?
<CBro2007> keithcu: is that what you wanted?
<keithcu> I just wanted to push my changes to trunk. I have my work directory branch and that is it!
<Peng_> keithcu: "bzr push", then?
<CBro2007> Peng_: How do I look at a list of branches ?
<keithcu> Okay, so I go to my work directory, and when I type: bzr push lp:openracing
<CBro2007> keithcu: if you have done the initial import and want to create a branch off that initial import --> "bzr branch . something.dev"
<keithcu> it tells me that the target directory already exists, but does not have a valid .bzr file
<Peng_> CBro2007: Unlike git, there's only one branch per directory, so you can just use ls...
<Peng_> CBro2007: The bzrtools plugin adds a "bzr branches" command if you really want it.
<CBro2007> so u saying that I cannot have more than one branch in this directory?
<Peng_> CBro2007: You cannot. Fortunately, most file systems support having multiple directories. :P
<CBro2007> mmm
<keithcu> I haven't done any import. I just have my work branch and I'm trying to setup a connection to setup a connection to trunk and pull to it, but I don't know how to do that.
<keithcu> and push to it
<CBro2007> so if I navigate to my .dev branch... that would be the files that I should be working on?
<Peng_> CBro2007: Sure? You might want to use multiple branches, or you might not.
<CBro2007> Peng_: At the moment I just want to test out the simple case where I can branch a new dev copy ... work on it.. be able to revert changes if I screw up, commit to a branch and then finally merge it to my main branch
<Peng_> Okay.
<CBro2007> so let me get this right
<CBro2007> I just created a branch called "something.dev"
<CBro2007> I navigate to that directory and work on the copy there
<Peng_> You can do that.
<CBro2007> and then I should be able to issue commands like "bzr status" etc in that dir
<CBro2007> Peng_: what other way is there?
<keithcu> There are 1 million ways to work with bzr
<CBro2007> how do I start to work on the branch I just created and only be constrained to this branch?
<CBro2007> thats the problem! :)
<CBro2007> I just need one... not a million..
<CBro2007> maybe the solo case for now
<keithcu> How many people are you working wiht?
<CBro2007> two more
<CBro2007> so the trunk branch model would suffice
<keithcu> Okay, so you create your work branch (and they create their work branch)
<CBro2007> Once I am comfy with this whole branching stuff I will publish the branch on launchpad for the rest (atleast that is the plan)
<keithcu> And then when any of you are satisfied, you push your changes to the trunk branch
<CBro2007> yep!
<CBro2007> or they send their changes to me first and I commit it to the main trunk
<keithcu> Yes, that is doable too.
<keithcu> My problem is that I don't know how to setup the trunk branch
<keithcu> I have one:
<Peng_> CBro2007: Send how? Patch files?
<CBro2007> isn't there a way they can do a "bzr send" or something
<CBro2007> or maybe they can send me their branch
<CBro2007> and I can merge it from my end
<CBro2007> possible?
<Peng_> CBro2007: "bzr help send" :D
<CBro2007> you love pointing out the documentation don't ya?
<CBro2007> you might as well give us some pointers mate! :)
<Peng_> The people who wrote the documentation are better writers than me. :P
<keithcu> Well, how do you setup the trunk branch?
<keithcu> I set one up: https://code.launchpad.net/~openracing/openracing/main
<keithcu> but I can't push to it.
<Peng_> keithcu: Honestly, I'm not sure. Try "bzr push --use-existing-dir"
<Peng_> CBro2007: You can use "bzr send -o foo.patch" to create a patch-like file that also preserves the history, then "bzr merge path/to/foo.patch" in another branch.
<Peng_> CBro2007: "bzr send" can also help you send an email with the file attached; see the edocs.
<Peng_> Err, docs*
<keithcu> Okay, I'm trying that and overriding the warning.
<keithcu> It seemed to work...
<keithcu> that seemed to kill my work branch! grr
<keithcu> oh well, I'll figure it out another time.
<CBro2007> I am sure they could have made it easier :)
<CBro2007> wish someone wrote a cool GUI tool that fronted all this backend stuff
<keithcu> I just wish there were docs specifically walking through the basic launchpad setup.
<poolie> keithcu: you want something like
<keithcu> I've read all I can find, but it wasn't enough. Some of it was clearly written before it was integrated into launchpad
<poolie> bzr push bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main
<keithcu> I was doing bzr push lp:openracing
<CBro2007> poolie: so i just created a new branch.... does this mean I can navigate to this branch and start modifying the contents?
<keithcu> CBro2007: yes
<CBro2007> poolie: would this mean that I am contraining the changes to this branch only?
<CBro2007> keithcu: ok
<CBro2007> keithcu: do you have to publish your changes?
<keithcu> CBro2007, it works better when you have a basic question to ask rather than a long series of them
<CBro2007> yeah thanks :)
<Peng_> keithcu: Oh, did you ever run "bzr launchpad-login your_username"?
<CBro2007> bazaar does raise a LOT OF QUESTIONS
<poolie> we have lots of answers too
<keithcu> yep
<keithcu> I think I've hosed my stuff. It shows 2 branches, but only makes one visible, etc.
<Peng_> Though not all of the answers match up to the questions. ;D
<keithcu> I'll start over and try that longer syntax for bzr push
<Peng_> keithcu: What? Two branches where? Launchpad?
<poolie> slow down
<poolie> where/
<keithcu> yes, launchpad.
<poolie> on which page?
<keithcu> I'll come back another time. I'll fiddle around more. I just want to understand a very simple question:
<Peng_> Eh.
<keithcu> I've got my work branch all setup, and I'm trying to setup / push to the trunk branch
<poolie> ok
<keithcu> I used bzr push lp:openracing, but maybe I should try bzr push bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main
<keithcu> It sort of seems like they are the same but maybe not
<keithcu> I deleted my trunk branch which was in launchpad and I'll try it again.
<Peng_> keithcu: lp:openracing is just a shortcut. If bzr+ssh://bazaar.launchpad.net/~openracing/openracing/main is the openracing project's default branch, it'llpoint to it.
<keithcu> Yes, that is what I thought.
<poolie> ok
<poolie> what i suggest you do is
<poolie> delete that branch on launchpad
<poolie> push to the ssh url
<poolie> then link it as the main branch for the product through the web ui
<CBro2007> guys I am testing by committing changes to a branch.. basic stuff. Now how do I revert to previous revisions in the branch?
<CBro2007> bzr revert?
<keithcu> Okay, poolie, I wil try that.
<keithcu> jeez, cBro2007, sit down with the documentation and experiment.
<keithcu> Poolie, that worked. I think I created the branch in launchpad first and that messed things up or something
<poolie> CBro2007: check out http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<keithcu> Poolie: my mistake was that I registered a hosted branch before I created it.
<keithcu> And when I do that, I can't push to it, or something.
<poolie> thumper, jml ^^
<poolie> it should work
<poolie> it is kind of a confusing situation
<jml> poolie: we are aware of it and have decided on a course of action :)
<poolie> oh yeah
<jml> poolie: but neither of us will do anything about it tonight.
<poolie> (:
<poolie> you're going to remove the option to create them?
<jml> basically, yeah.
<jml> there's an open bug.-
<keithcu> okay, so that was my problem?
<poolie> thought so
<jml> keithcu: in the meantime, bzr push --use-existing-dir, IIRC
<keithcu> Okay, I tried that but thought something went wrong. But I think that might have worked.
 * igc dinner
<keithcu> But now it works and everything looks good: https://code.launchpad.net/openracing?field.lifecycle=ALL
<keithcu> Thanks!!!!!!!!!!!!!!!!!!!!!!!
<keithcu> I spent an hour on that simple thing...
<Peng_> Well, congrats on getting it working. :)
<keithcu> yep, feels good.
<keithcu> okay, thanks again, I understand the "suggested" workflow. Bye
<poolie> sorry for the confusion
<keithcu> no problem. But I do suggest to focus your documentation on the launchpad workflow as many bzr people will be using launchpad
<keithcu> Well, I'm off to code. Thanks for your help...
<CBro2007> whats the difference between doing a "revert" and an "uncommit"?
<CBro2007> Just want to know the consequences of doing that
<Peng_> CBro2007: Revert is about the working tree, Uncommit is about the branch history.
<CBro2007> ok
<CBro2007> so revert will not get rid of any of the committed branches yeah?
<Peng_> CBro2007: Right.
<CBro2007> k
<Kamping_Kaiser> i've rm'ed a few files. how can i remove them from my bzr repo? bzr is refusing to ci/rm the files because they dont exist.
<Lo-lan-do> Just commit?
<Peng_> Kamping_Kaiser: For better or for worse, "bzr commit" automatically removes missing files.
<Kamping_Kaiser> Peng, ah, ok. i'll ignore a few things then commit the missing files. cheers.
<Lo-lan-do> If you have other changes, you could also shelve them, then commit the removals, then unshelve.
<Kamping_Kaiser> i have a dozen files i want ignored (which bzr isnt ignoring), and these 5 pngs. I could ... i wonder . brb.
 * rockstar loves the new progress bar.
<Kamping_Kaiser> still doesnt ignore if the files are added. oh well.
<fullermd> Well, that's because ignore is a filter on nadd  :p
<Kamping_Kaiser> on what?
<fullermd> nadd.  It's sorta like add.  The 'n' is silent.
<Kamping_Kaiser> it must be bzrs fault, i can't *possibly* be at fault :P
 * Kamping_Kaiser wishes ;s
<Kamping_Kaiser> commitng the dir the images were in seems to be doing the trick. probably what Lo-lan-do was trying to tell me 15 min ago *heh*
<Lo-lan-do> Not really, I was suggesting a full commit; but you're right, I should remember about the possibility of committing a single dir, I often forget about it.
<Kamping_Kaiser> thanks for the pointers - think i'm getting ignore sussed too. (remove --keep is handy too)
 * fullermd has rm aliased to --keep, and dark memories of the day when it was changed   :p
<james_w> rexbron: they just weren't merged yesterday, I still plan to review them
<gioele> hello
<gioele> is there a way to run a command when bzr commit is run but *before* the actual commit? I'd like to modify a file on every commit, before and save the modified file with in the same commit
<Lo-lan-do> gioele: There's probably a hook for that.
<SteveA> lifeless: ping
<jelmer> gioele, look for the start-commit hook
<gioele> Lo-lan-do, jelmer: thank you. I'll use those. Actually my hope was to just write a line in a conf file and have my script run on every commit, but those python hooks are nice enough
<CBro2007> guys if I have setup the shared repository structure as shown in the user guide, I was wondering whether I have to copy my files to the "trunk" dir and then do a bzr add?
<CBro2007> do I have to do a "bzr init" in the project dir?
<CBro2007> ?
<CBro2007> can someone help?
<CBro2007> project1/          # A repository for project1
<CBro2007>  +- trunk/         # The mainline of development of project1
<CBro2007>  +- branches/      # A container directory
<CBro2007>      +- foo/       # Branch for developing feature foo of project1
<CBro2007>        ...
<CBro2007> I use this model
<CBro2007> should I then have to get into the "trunk" directory and do a "bzr init"?
<CBro2007> before I can add files to this dir?
<asabil> CBro2007: how did you create the trunk/ directory ?
<CBro2007> manually
<CBro2007> I created the repository with init-repo
<asabil> then yes, you will need to cd trunk && bzr init .
<CBro2007> and then went into that dir to add in the structure I wanted
<CBro2007> then copy my files into trunk and bzr add , then initial import -commit yeah?
<asabil> yep exactly
<CBro2007> And then I need to fork out like a seperate branch from this trunk
<CBro2007> like a fresh copy to start adding features on
<CBro2007> Can I just go :  bzr branch /proj1/trunk /proj1/branches/foo
<CBro2007> ?
<CBro2007> asabil: would that work? or do I have to PUBLISH my branch first?
<asabil> CBro2007: that works perfectly
<asabil> (that's the workflow I use myself)
<CBro2007> which one? the first one?
<CBro2007> so I can branch out first and then publish my branch later so others can collaborate?
<CBro2007> it says the target directory already exists
<CBro2007> maybe I should get rid of the branch
<asabil> CBro2007: yes, you don't need to create the directories yourself
<asabil> bzr branch will do it
<CBro2007> yep done all that
<CBro2007> worked out real good... also managed to PUBLISH my branches
<AfC> Is there a reason you keep saying "publish" in all capitals?
<crisb> hiya, i'm getting a MemoryError when I try to commit a move of some directories  (containing arround 700 files) into another directory - http://paste.pocoo.org/show/104281/
<crisb> this is on AIX...
<fullermd> AfC: It's an acronym for Putative Unsubstantiated Brilliant Lunch In Some House.
<crisb> seems to be in patiencediff
<msmits> could some please help me out with some bzr-svn issues?
<msmits> s/some/someone/
<jelmer> msmits, hi
<msmits> jelmer> hi, is it supposed to work with Python 2.4?
<jelmer> msmits: 0.5.0 doesn't work with python2.4 at the moment
<msmits> jelmer: what version would you recommend for Python 2.4?
<jelmer> msmits, I would recommend upgrading to Python2.5..
<msmits> (I've run into the defaultdict requirement)
<msmits> that's not an option, work environment dictates python 2.4 (I guess I could install 2 versions but would rather avoid that)
<jelmer> the 0.4.x series work with python2.4
<jelmer> however, a lot of bugs (>40) in the 0.4.x series of bzr-svn are fixed in 0.5.0, and the 0.4.x, and performance is also worse in 0.4.x than in 0.5.x
<msmits> jelmer: I've also tried 0.4.17 and have run into a fairly serious problem
<msmits> hang on while i get the logs
<msmits> jelmer: http://pastebin.com/m48b4b358
<jelmer> msmits, that's a known bug, fixed in 0.5
<msmits> jelmer: no easy way to backport the fix to the 0.4 series?
<jelmer> msmits: That particular bug might be fairly easy to backport
<msmits> hmmm, maybe i should just install python 2.5 next to python 2.4...
<jelmer> no guarantee you won't run into more older bugs
<msmits> can you point me at the fix, in case i decide to backport it?
<jelmer> bug 329284
<ubottu> Launchpad bug 329284 in bzr-svn "dpush can't handle merges" [Undecided,Fix released] https://launchpad.net/bugs/329284
<msmits> jelmer: thanks very much for your help, that's awesome
<jelmer> msmits, alternatively, it should be possible to provide replacement implementations of defaultdict and deque in bzr-svn 0.5.0
<msmits> jelmer: yep, i've got substitute versions lying around
<msmits> jelmer: I can think of other reasons to have Python 2.5 installed so I might try that approach first
<vila> crisb: worth filing a bug
<jelmer> msmits, I would be more than happy to accept patches that make bzr-svn use substitutes when running under python < 2.5
<vila> crisb: did you get less traumatic response times since last week-end ?
<jelmer> msmits, ok
<msmits> jelmer: ok, if that's the case you might get some patches from me soon
<crisb> vila: I have fixed it now, its an AIX malloc funny - returns NULL if malloc(0)... :)
<crisb> i will file it though with patch
<vila> wow, that kind of bug makes me think about the worst I encountered: memcpy copying 655[56] bytes when asked to copy 0 or 1 bytes... did wonders for C variables in the stack...
<vila> s/655[56]/65536-[01]
<crisb> its running slightly faster now, but selftest is still incredibly slow
<ronny> oO
<ronny> its ok of malloc(0) returns NULL
<crisb> ronny: not according to the patiencediff extension ;)
<ronny> ah
<ronny> manpages say it may return 0 or a unique value that works with free
<crisb> indeed
<crisb> one patiencediff test is still failing unique_lcs - error return without exception set when doing unique_lcs('', '')
<fullermd> Er?  malloc(0) is painting outside the lines.  Demons are allowed to fly out of your nose.
<fullermd> The only requirement is that the return value work with free(), which NULL does everywhere but freakin' dmalloc.
<fullermd> (well, maybe that's fixed by now, it's been a couple years since last I fired it up)
<Odd_Bloke> "If  size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()." suggests that it's not painting outside the lines.
<fullermd> It's painting outside the lines in that it's implementation-defined.
<fullermd> "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
<Odd_Bloke> Oh, yeah, there's a spec. :p
<fullermd> (C99 7.20.3)
<crisb> my fix is just to fail if we return NULL from malloc and the size is not 0
<crisb> rather than just when we return NULL
<luks> the proper fix would be to not even try to allocate 0 bytes, because diff of empty documents can be easily special-cased :)
<vila> fullermd: ha ! At least the spec matches my mental model (which includes never calling free with NULL, but that's just healthy paranoia :-)
<vila> luks: nag the patiencediff C extension author ;-)
<ronny> whats the name of that new repo format again?
<luks> vila: he is too lazy :)
<vila> luks: :)
<vila> ronny: split-inventories nick-name brisbane-code or bbc for short
<vila> ronny: split-inventories nick-name brisbane-coRe or bbc for short
<crisb> luks - is that you? ;)
<luks> yes
<crisb> any idea about test_unique_lcs failing with "error return without exception set" on 2 empty sets?
<crisb> Traceback (most recent call last):
<crisb>   File "/opt/freeware/lib/python2.6/site-packages/bzrlib/tests/test_diff.py", line 782, in test_unique_lcs
<crisb>     self.assertEquals(unique_lcs('', ''), [])
<crisb> SystemError: error return without exception set
<luks> crisb: it's the memory error problem, but masked
<luks> crisb: I think that was fixed in recent versions of bzr, what version are you using?
<crisb> 1.12
<crisb> all new stuff ;)
<luks> hm
<luks> is this your changed version?
<luks> yeah, the testing function don't set exceptions as well
<crisb> yes, my changed version.  works fine on my linux
<luks> well, the code currently expects malloc(0) to return a valid pointer
<luks> you could fix the SystemError by setting MemoryError
<luks> but to fix the functionality it needs to avoid allocating 0 bytes
<crisb> got it - all tests passed now :)
<crisb> cheers luks
<vila> crisb: all tests for the whole test suite or just patiencediff ?
<igc> jam: any eta on the development5 formats?
<igc> jam: also, I'd like to pick just one initially and focus my testing & tuning on it
<igc> jam: do you have a leaning wrt hash16 vs hash255?
<fullermd> Why's one a power of 2, and the other isn't?
<crisb> vila: patiencediff :) theres a hang on one of the tests (around 98)
<vila> fullermd: the other *is* a power of 2, but minus one :) The reason being that one char can't be used in the hash key  and is replaced by another (already used, hence 256 -1)
<vila> crisb: ghaa 98 means nothing to me :-) try 'bzr selftest -v'
<igc> jam: also, I'm getting a DeprecationWarning when trying to upgrade to development4-hash255: chk_map.py line 78: "i" format expects a number within a given range
<igc> jam: is that serious?
<vila> igc: are you using a 64bits host ?
<igc> vila: yes
<igc> anyhow, it's past my bedtime
<igc> night all
<vila> igc: if your branches are used on a 64bits host only you should be safe, I noticed the problem yesterday and is talking about it with jam
<vila> igc: cu
<igc> thanks vila. If you could ask jam for me about the Qs above when he's offline, that would be great
<vila> He's connected, so I think he will read them, I'll remind them if not
<jam> igc, vila: hey
<vila> jam: hi :-)
<jam> igc: --dev5 will probably be sent for review today
<jam> as for -16 versus -255...
<jam> my earlier work suggested 16
<jam> however the groupcompress work (so far) is favoring 255
<jam> igc, vila: as for the deprecation warning, I'm pretty sure we could safely do "crc = zlib.crc32()&0x7FFFFFFF" if we want to avoid it
<jam> we don't need *all* the bits
<jam> have a good night igc, if I haven't missed you yet
<crisb> vila: blackbox.test_check.ChrootedCheckTests.test_check_missing_branch
<vila> crisb: doesn't ring a belll. Make sure you didn't left some breakpoint somewhere since that's a blackbox test, outputs are redirected
<Odd_Bloke> Where can I see the bzr PQM?
<beuno> Odd_Bloke, pqm.bazaar-vcs.org
<Odd_Bloke> I'm getting a 503 from there.
<vila> jam: that sounds perfectly right for 32bits, bu will truncate the value on 64bits which sounds wrong
<jam> vila: there are only 32 bits either way
<jam> I'm just chopping off the 32nd one
<jam> so you are left with 31
<jam> which is always the same signed or unsigned
<vila> which is wrong for unsigned values
<jam> nope
<jam> try it
<vila> 0xFFFFFFFF is valid
<jam> vila: I'm *intentionally* chopping off the 32nd bit, by using 0x7FF...
<vila> That's the wrong part, I have dirstate files with values > 2^31
<jam> do you have any with values > 2^32 ?
<vila> :-)
<jam> the *point* is that we universally sacrifice one bit
<jam> for platform uniformity
<jam> (it won't work for dirstate being compatible with dirstate)
<jam> but we don't have to worry about chk_map compatibility *yet*
<vila> But going with struct.pack('>L' instead of struct.pack('>i', just works everywhere without sacrifying anything including having a valid crc
<vila> and regarding dirstate, we don't use (anymore ?) the crc anyway so that may not be such a big deal
<jam> vila: "l == i" for all platforms (IIRC)
<jam> you could use "Q" but we don't have 64 bits of actual data
<vila> Oh my, I sure hope not !
<jam> long == int
<jam> long long != int
<vila> long == 32bits
<vila> int == 32bits or 64bits
<jam> except for maybe 16-bit platforms
<jam> vila: I haven't seen a platform yet where "int == 64 bits"
<luks> isn
<luks> er
<jam> I could be wrong, but I'm pretty sure long should always be >= int
<luks> isn't it the other way around, long == 64, int == 32?
<jam> luks: "long long == 64 bits"
<jam> I think there were 16-bit platforms
<luks> yeah, I know
<jam> where long == 32 bits ,and int == 16 bits
<jelmer> vila, any idea why every apache process start by bzr-lts would disappear?
<jam> jelmer: the subvertpy 0.6.2 release is just win32 changes, right? (I noticed you didn't upload 0.6.2 to the ppa)
<jelmer> jam, yeah
<jelmer> vila, I don't get much more than: [Tue Feb 17 16:09:24 2009] [alert] Child 27932 returned a Fatal error... Apache is exiting!
<vila> jelmer: not from the top of my head, but there is a log file
<jelmer> vila, that comes from the log file, it's basically the only thing in there
 * fullermd blinks.
<fullermd> Long is required to be >= int...
<vila> jelmer: have you checked the conf with apache2 -t ?
<fullermd> And there are/were plenty of 16 bit platforms.  I'm perfectly willing to say "who cares" in 2009 though.  Heck, I was willing in 1999...
<jelmer> vila, yep, that's fine
<vila> jelmer: hmm, did you load all the required modules ? Did you try running as root ?
<vila> jelmer: running as root is bad and may create files you won't be able to modify afterward caveat testor
<vila> jelmer: did you set LogLevel debug ?
<jelmer> vila, I'm running as root since /usr/sbin is not in my standard PATH
<jelmer> vila, even "bzr lts-start apache2" doesn't work
<vila> jelmer: ha, progress :)
<vila> You *have* apache2 aren't you ? :-)
<jelmer> yes :-)
<jelmer> vila, the system one starts fine
<vila> did the local_test_server/work/apache2 directory got created ?
<vila> with data, etc, var inside ?
<jelmer> yeah
<jelmer> the pid file also gets created but the process dies
<vila> jelmer: and the pid file is deleted ?
<jelmer> vila, yeah, I've deleted the pid file (otherwise it won't start)
<vila> hmm, so something is wrong inside apache regarding workers spawns, what OS are you using ? I think the Ubuntu apache2 may come linked with some modules that you may miss and need to load explicitly
<jelmer> I'm running Debian
<jelmer> it does actually start, it just aborts right after
<vila> what does 'apache2 -l' say
<jelmer> If I add syntax errors, it neatly aborts on the commandline
<vila> It's  core.c, mod_log_config.c, mod_logio.c, worker.c, http_core.c and mod_so.c here
<jelmer> same here
<vila> Ghaa, what machine were you using when you contributed apache2-svn ?
<jelmer> vila, much older installation
<vila> jelmer: can't you spot an obvious mistake between local-test-server/apache2.conf and /etc/apache2.conf ?
<vila> jelmer: or add /sbin in your path (I can't remember if apache2 can be run as root or need a dedicated user)
<vila> jam: I just realized you meant to apply the work-around to _search_key_255, not dirstate, I'm fine with the former, the later still needs discussion I think or should I just file a bug ?
<jelmer> vila, it seems to silently exit if there's no group set
<jelmer> and no user
<jam> vila: we can file a bug, and yes it was mostly just about _search_key_255
<jam> Though there may be tests that need updating
<jam> the other possibility is to do:
<jam> if platform == 64bit && val > 2^31: val = val - 2^32
<jam> or something to that efffect
<vila> jam: we need something that works if the disk format is used from both 32bits and 64bits so the &0x7FFFFFFF sounds better for that
<ronny> lifeless: are there any plans to store things like tags in the history store instead of unversioned files?
<ronny> (not as normal revs/commits tho)
<vila> jelmer: sorry, I missed your last comment, where are you at ?
<jelmer> vila, apache silently exits if there's no user set
<vila> jelmer: apache2 can't be run as root ?
<jelmer> at least not the Debian sid package
<vila> jelmer: so you tried adding /sbin to your path a running as normal user ?
<vila> jelmer: so you tried adding /sbin to your path and running as normal user ?
<jelmer> vila, yeah, and that's working
<vila> jelmer: haaa, real progress now :) Good.
<Kobaz> bzr: ERROR: This tree contains left-over files from a failed operation.
<Kobaz> how do i fix that
<Kobaz>     Please examine /usr/local/library/.bzr/checkout/limbo to see if it contains any files you wish to
<Kobaz> i have no files in there
<jelmer> vila: lp:~jelmer/+junk/bzr-lts-krb5
<vila> Kobaz: I think you cut the part where it says: "and delete it when you are done"
<fullermd> bzr: It's krb5!
<vila> jelmer: errors.NotBranch, still pushing ?
<Kobaz> yeah
<jelmer> vila, whoops, sorry, yeah
<vila> jelmer: ok, got ot no
<jelmer> vila, it's done now
<Kobaz> i delete it
<Kobaz> and then it complains about another dir
<vila> err got it now :)
<Kobaz> and then i delete the other dir, and then it complains about a lock
<Kobaz> and then i remove the lock, and then it complains about limbo
<Kobaz> endless loop
 * jelmer hands fullermd a ticket granting ticket
<Kobaz> hmm
<Kobaz> i did bzr shelve -all
<fullermd> Sorry, I can't use that.  My branch isn't rich-ticket.
<Kobaz> and that did it
<Kobaz> i couldn't shelve an individual file, otherwise i would get into the limbo loop
<vila> jelmer: great, you're nearly there, you need to update test_server.get_permutations though
<Odd_Bloke> Kobaz: What version of bzr are you using?
<Kobaz> .10
<vila> And a final 'bzr selftest -s bt.test_http krb5' passing will be the reward :)
<Kobaz> i'll try and reproduce the problem
<vila> jelmer: and some bzr-add krb5.keytab may be missing too ? Or it is private ?
<jelmer> vila: it's pointless without a KDC
<vila> jelmer: ok, just say so in comments in the apache2.conf file then with any hints you feel relevant (a copy/paste from your mail for example)
<vila> jelmer: and thanks for the instant feedback :-)
<jelmer> vila: Hmm, I'm not getting the tests to show up
<vila> try --list for a start
<vila> if they don't show up with --list, the feature may have say the server is not available, check that's it's started
<Odd_Bloke> Kobaz: There have been a few fixes to shelve recently, you might want to update to .12.
<jelmer> vila, ok, that passes now
<jelmer> vila, pushing new bzr-lts
<vila> jelmer: yeah !
<jelmer> vila, it's pushed (lp:~jelmer/+junk/bzr-lts-krb5 again)
<vila> jelmer: if you needed to declare a new user and/or run some additional commands there will make a nice addition to the comments :-)
<jelmer> Ran 12 tests in 4.178s
<jelmer> I've added a note about the keytab file
<vila> jelmer: yeah, that's generally slow
<jelmer> now I need to teach Subversion about Kerberos, and that'll be trickier :-/
<jelmer> vila: thanks for the help getting bzr-lts updated
<vila> jelmer: thanks for updating it :-) Now you just have to add a new one that does svn *and* kerberos and you'll have a nice test server for implementing the svn part :-)
<jelmer> vila, how do you plan on implementing bug 256612 ? It seems somewhat related to the mandatory username thing I came across
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612
 * jelmer updates bug 256612
<ubottu> Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612
<vila> I think there are several steps, 1) raise ConnectionError instead of 401, 2) Prompt for users or something like that, 3) delegate to auth handlers the decision about requiring user
<vila> jelmer: I have to run, I'll be back later
<jelmer> vila, ok
<sender> hi all. please advice, what to do after a "bzr merge -r0..-1" from branch without common ancestry. Remove all the '.moved' items and add the new items, or rename?
<ollie> i guess this question must of been asked many times but i am having the parmiko error: Unable to import paramiko (required for sftp support): No module named paramiko. System is Ubuntu 8.04.1 Bazaar (bzr) 1.3. Any ideas?
<ollie> was trying to do a bzr co sftp://blah
<ollie> zr: ERROR: Unsupported protocol for url
<santagada> ollie: install paramiko... it is probably a package in ubuntu
<santagada> maybe it is from the MOTU repositories
<ollie> santagada: i did apt-get source python-paramiko
<ollie> dpkg-source: applying ./paramiko_1.6.4-1.1.diff.gz
<santagada> ollie: why get the source?
<ollie> it is just what apt-get did
<Tak> is there a way to directly get a branch from a workingtree?
<Tak> err, the workingtree's branch instance
<santagada> ollie: try apt-get install python-paramiko next time :D
<ollie> ah yeah odd
<ollie> i see what you mean not sure why i would of done that
<santagada> apt-get source installs the source code
<santagada> apt-get install install a package
<ollie> yep not sure why i typed it
<evarlast> can anyone point me to how I can help get the windows installer onto the http://bazaar-vcs.org/Download page?
<crisb> seems like on AIX a fair few tests involving http server hang - how can I find out more about where the tests are hanging?
<crisb> using the debugger it seems like one thread is stuck in sock_dealloc and one in fd_select (i guess this is the server?)
<fullermd> Some sorta *lock in close() sounds like?
<crisb> yeah, im pretty sure i've had this before porting to AIX ;-)
<crisb> its bringing back memories
<fullermd> I find that alcohol helps with that.
 * fullermd fails to clarify whether the alcohol is introduced into one's self or the machine...
<hughesw> question to the room. Say I wanted to wipe out all revprops set by bzr-svn on a repository, how would I go about doing so? My repository has a bunch of ghosts in it and it's still causing bzr-svn to crash on branch.
<hughesw> would svn pd with all of the bzr: props I see with a pl do it?
<jelmer> hughesw, uhm, how did you get into that situation in the first place?
<hughesw> jelmer: I'm not sure honestly.
<jelmer> hughesw, and what doesn't work exactly?
<hughesw> starting around bzr 0.4.10 and the version of bzr-svn that shipped with it, it seems to have stopped pushing up revisions from local branches, so now when I do a checkout, a pull, etc fresh from the svn repo
<hughesw> I can't branch the checkout or anything as it just dies
<jelmer> hughesw, how does it die?
<jelmer> what error?
<hughesw> hold, writing it out so I can upload it
<jelmer> JAM!
<Lo-lan-do> Too late...
<Lo-lan-do> jelmer: Any news on git-serve, by the way?
<jelmer> Lo-lan-do, hi
<jelmer> Lo-lan-do, bzr dpush works (but that wasn't what you were asking..)
<jelmer> Lo-lan-do, John mainly works on bzr git-serve, I'm focusing on performance at the moment
<Lo-lan-do> Cool.
 * Lo-lan-do would really like to get rid of that SVN we keep as a pivot between bzr and git
<jelmer> Lo-lan-do, roundtripping bzr revisions in git is still quite some time away though
<Lo-lan-do> I thought the bzr-receive-pack and bzr-upload-pack was supposed to work for that... did I misunderstand something?
<jelmer> Lo-lan-do, that's roundtripping git into bzr
<jelmer> which is much simpler, since bzr has transitive history and things like revision properties
<Lo-lan-do> If that works and we can use bzr as the pivot, then I'm *quite* happy :-)
<Lo-lan-do> The one git user can access the bzr repo through that "gateway", the rest of us can do bzr, and everyone wins.
<Jc2k> Lo-lan-do: i havent had time to poke git-serve lately, so i dont know if its got bit rot
<Jc2k> (so need to figure out a sane way to test it..)
<jam> morning igc, you're up early
<jam> igc: dev5 has been submitted to the list
<igc> jam: saw that - thanks
<jam> it should actually cause a slight amount of 'bloat' to the repos
<jam> maybe 1-2%
<jam> as we don't actually have delta compression enabled
<jam> and it adds about 2bytes per record
<jam> by the way, igc, I was really happy to see usertest runs on the different formats
<jam> I was benchmarking size
<jam> but speed is also an important factor
<jam> and certainly I didn't expect "bzr branch" to be 2x faster with -255 versus -16
<jam> which is why I have both formats in there
<jam> I'm pretty positive we don't want plain "--development5", though I think lifeless is less sure
<igc> jam: the revno for the mysql branch I used was 2677
<igc> I'm pulling mysql now and I'll build and use an updated archive
<jam> which branch?
<jam> (they have a lot :)
<igc> mysql-server
<jam> lp:mysql?
<igc> yes
<igc> (I think that's it)
<jam> well, it is "lp:mysql-server" which is the 5.1 branch
<jam> good enough
<jam> it is just nice to know which
<jam> as I mentioned, you may want to hack in the little change for "bzr upgrade"
<igc> jam: shall do
<jam> I'm not sure if it safe for the other commands, but I've used it here for "bzr branch" quite a bit
<jam> (using branch to convert, rather than 'upgrade')
<igc> jam: any thoughts on the time required to upgrade from dev5 to dev5h16?
<igc> will it be just as slow as btree->dev5?
<jam> it should be faster
<jam> because the delta logic from the source is faster
<igc> likewise, will upgrading from dev5h16 -> dev5h255 be slow or quikc?
<jam> dev5 => dev5h16 should be ~the same as dev5h16 => dev5h255
<jam> I have some other updates in my 'hack' branch which I should put together for review
<igc> jam: what do those hacks do?
<jam> it changes the copy logic to use a 'more-optimal' ordering
<jam> igc: http://bzr.arbash-meinel.com/branches/bzr/brisbane/hack
<jam> if you want to check it out
<jam> it was where I was exploring the various hashes, etc
<igc> jam: would it be better for me to benchmakr that than brisbane-core?
<jam> igc: I would be curious to see what results you get from that, but I don't think it is strictly better than brisbane-core
<jam> It does stuff like knit-delta compression
<jam> hash-16
<jam> 'get_record_stream' ordering, etc
<jam> It was just my "play with this and get ideas" branch
<jam> so I'm slowly getting things out of it, and properly tested into brisbane-core
<igc> jam: ok, I'll probably stick with brisbane-core then
<jam> well, I *would* like to see how much my knit-delta helps these repos (at least for size) and how much it hurts (for copying/extracting performance)
<fullermd> Does anybody else find it irritating how the wiki no longer gives you a handy link to your userpage?
<jam> fullermd: that was actually intentional, because people were creating non-useful userpages
<jam> you are one of the *few* exceptions
<mwhudson> beuno: bzr upload bzr+ssh:/// seems not to work
<mwhudson> is that expected?
<fullermd> Well, shucks.  Can't we just lay on a few LART's instead of making me type it in?
<beuno> mwhudson, well, there's not upload smart server, so yes
<mwhudson> is just a transport though?
<mwhudson> ah well, i guess i'll fight with it some other day
<mwhudson> (fwiw, the error is bzr: ERROR: Invalid url supplied to transport: "diff.html")
<beuno> yeah, but vila discriminates it for some reason
<beuno> and I have not had any incentive to understand why yet
<mwhudson> fair enough :)
<vila> mwhudson: If you have ssh access you'd better run 'bzr update' locally...
<jam> fullermd: after about the 10th LART we decided to make it harder for people to do it by default
<jam> you can always bookmark your own page :)
<mwhudson> vila: i guess i could use push-and-update indeed
<beuno> mwhudson, you have ssh and not sftp?
<chx> i did google but can only find sporadic remakrs that 'it wont be hard to do' from years ago -- so is it possible to somehow check out from a bzr branch with an svn client?
<vila> beuno: it's not that I discriminate, if the transport support the required operations it should just work, if it doesn't it may be a bug or that bzr doesn't implement some needed VFS command
<mwhudson> beuno: nah, i have sftp
<beuno> vila, I know, I know  :)
<mwhudson> i just tried bzr+ssh first
<vila> mwhudson: if you want to update a working tree with a colocated branch, push-and-update is better suited
<vila> bzr-upload is not meant to replace bzr update, it's meant to allow building a remote working tree when the remote branch doesn't exist
<jam> chx: I thought Jelmer implemented something along those lines, but I don't know that he completed it
<lifeless> SteveA: pong
<chx> jelmer: that would be VERY interesting to me.
<jam> chx: are you talking something like bug 127768 ?
<ubottu> Launchpad bug 127768 in bzr-svn "bzr svnserve" [Wishlist,In progress] https://launchpad.net/bugs/127768
<jam> I'll note that jelmer at least implemented it a bit here: https://lists.ubuntu.com/archives/bazaar-commits/2008-October/010639.html
<chx> jam: yes , i even found that issue but as you can see the last comment is from 2007.
<jam> and with 'bzr-svn' installed, there *is* a "bzr svn-serve" command available
<poolie> hello
<chx> davidstrauss: ping
<jelmer> chx, So, bzr svn-serve does some things properly at the moment; checkout and log are among them
<jelmer> the main missing things are update and commit
<davidstrauss> chx: pong
<infinit_> does anyone know how to setup Bazaar plugin on eclipse? I get the error that it needs the xmlrpc plugin. I've downloaded the plugin and add it in eclipse but it gives more errors when I do that. Any solution?
<jelmer> infinit_, you need to add it in bzr
<infinit_> how?
<jelmer> copy it in ~/.bazaar/plugins/xmloutput
<jelmer> I think it's documented on the xmloutput wiki page
<ronny> hmm, wouldnt it make more sense if they used dbus?
<infinit_> I did that but still there are errors
<infinit_> usage: bzr [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
<infinit_>    or: bzr --help [cmd1 cmd2 ...]
<infinit_>    or: bzr --help-commands
<infinit_>    or: bzr cmd --help
<infinit_> error: invalid command 'xmlversion'
<infinit_> this is the error
<jam> jelmer: well, 'bzr svn-serve' is currently broken in a few ways, mostly just forgetting to import functions that it calls
<jelmer> ronny, for communication between IDE's and the VCS?
<ronny> yeah
<lifeless> ronny: its eclipse; xmlrpc is more portable for it than dbus; think win32
<jelmer> jam, ah
<jam> and using "port" without converting it to an integer
<jam> etc
<jelmer> jam, untested code is broken code :-)
<jam> I'm trying it here
<jam> and "svn co svn://localhost/ test" does seem to try to do something
<jam> but doesn't get very far
<jam> it seems to be hung
<ronny> lifeless: last time i took a look at xmlrpc it was a damn ugly mess tho
<ronny> dbus is a lot more nice
<ronny> and it actually works on win32
<ronny> at least deluge uses it
<lifeless> ronny: also dbus isn't particularly good at 'call a command', its better at 'get a service'
<ronny> lifeless: objects + methods, sound perfectly fine to me
<lifeless> ronny: xmlrpc is dead trivial, if you close your eyes and ignore the xml :)
<ronny> the only thing thats nasty with dbus is generators, as they would need a callback
<lifeless> anyhow, I'm not the author of bzr-eclipse, so don't really hold an opinion :)
<ronny> lifeless: dbus more featurefull, efficient and not a fscking ugly mess ^^
<ronny> well, i generaly prefer background threads tho
 * ronny writes the vcs integration of pida
<lifeless> ronny: cool
<nitind> .part
<ronny> lifeless: 0.6 will have native support for bzr workingtrees - and somewhere in betwen 0.6 and 0.7 i will add branch management
<ronny> the fun part in that is that _every_ vcs play its own little __fscked__ up game about branch management
<lifeless> oh yeah, we're all different
<lifeless> sometimes usefully, sometimes less so
<lifeless> bzr's not ideal
<ronny> bascially everyone does it wrong
<ronny> by default
<fullermd> Hey, where would Edison be if he didn't try all the wrong filaments?   :p
<ronny> fullermd: branch management has a much larger social component that light bulbs
<ronny> so by default one can do it only wrong
<ronny> lifeless: btw, what would you change about bzr's branch management?
<fullermd> A Gandhian answer may be appropriate...
<ronny> i kinda belive that for every vcs the correct answer should be *everything*
<CardinalFang> Ugh.  How do I track down what causes IllegalUseOfScopeReplacer exceptions?
<CardinalFang> dev guide says, """It also is incorrect to assign ImportReplacer objects to other variables. Because the replacer only knows about the original name, it is unable to replace other variables. The ImportReplacer class will raise an IllegalUseOfScopeReplacer exception if it can figure out that this happened. But it requires accessing a member more than once from the new variable, so some bugs are not detected right away."""
<CardinalFang> I don't even see anything lazily imported around my code.
<jam> lifeless: I think I worked out why "pack" is failing for GC repos
<jam> at least one item
<jam> is that packer assumes it knows the format of the "value" index
<jam> sorry "value in an index"
<jam>             for key, value in items:
<jam>                 # ---- KnitGraphIndex.get_position
<jam>                 bits = value[1:].split(' ')
<jam> unfortunately, that is only true for non gc values
<jam> which start with a "EOL" marker
<lifeless> ronny: It's very nice that we have url's per branch, and that we don't particularly couple branch to repo, so you can have several projects and just organise the branches like you do directories
<lifeless> ronny: I *love* that
<jam> lifeless: anyway, from what I can tell, we need a custom Packer to handle it properly.
<ronny> lifeless: i only like it if i want it, else i dont
<ronny> lifeless: however collated branches might fix that for me
<lifeless> ronny: however, we have some scaling issues related to that (expensive to query 'branches') and it would be nice to allow 'getting started' to give more than one branch
<jam> CardinalFang: doing "from bzrlib.XXX import foo" where 'foo' is a lazy import in *that* module will cause the problem
<jam> I would double check your imports
<lifeless> jam: I am sure it used to work, or something
<jam> lifeless: well if you left a space for EOL (which was always empty) it might work
<lifeless> jam: anyow yes thats one of the root causes, repo assuming it knows the format
<ronny> bbl, gota sleep early today
<lifeless> jam: no, we want to recompress in gc pack, at least some fo the time
<jam> ah, and it seems packer writes out the index based on its assumptions as well
<jam> so it would be broken anyway
<jam> (Packer assumes it understands index_memo, which it obviously doesn't )
<jam> anyway, it is non-trivial to fix Packer
<jam> so perhaps we should just change GCRepository to do record_streams and live with that
<lifeless> as a first cut setting up a VF with just a writable index and selecting into it would at least let full conversions work
<jelmer> lifeless, pqm is down :-(
<jelmer> lifeless: (well, the web page gives a 503
<CardinalFang> jam, found it.  Thanks.
<lifeless> spm: ^
<CardinalFang> Strange that it suddenly stopped working.  Schroedinbugs are cool.
<jfroy|work> jelmer: holy **** 0.5.1 is fast, good job!
<jfroy|work> I am, quite honestly, shocked at the snappy :)
<jelmer> jfroy|work, thanks :-)
<jelmer> it should be significantly faster yet after some of my patches for bzr.dev land
<CardinalFang> Sorry to butt in, but what is that, jfroy|work?
<jfroy|work> CardinalFang: hum?
<CardinalFang> "0.5.1 is fast"
<CardinalFang> Svn plugin?
<Jc2k> CardinalFang: Yes
<jfroy|work> yeah
<jfroy|work> bzr-svn
<jfroy|work> jelmer: pulling a 216070 rev repository right now
<jfroy|work> (which was migrated from CVS, actually)3
<jfroy|work> it's building the cache right now, and unfortunately it doesn't report revisions/sec
<jfroy|work> (which would be interesting as a benchmark)
<lifeless> abentley: is bb dead?
<lifeless> spiv: you're popping over here yeah?
<abentley> lifeless: restarted.
<lifeless> abentley: thanks
<lifeless> abentley: It would be nice to allow the same tree to be nested multiple times; I know thats not trivial but perhaps worth thinking about, if you're hoping to get the format out in advance of the support
<spiv> lifeless: yeah.
<lifeless> spiv: I sent in my branch, so I'm all set to pair
<abentley> lifeless: To me, the cost/benefit ratio isn't nearly good enough.
<lifeless> spiv: until you get here I think I'm going to setup a effort test on new-branch-push and start ratcheting
<lifeless> abentley: I'm specifically thinking of the gnome pattern of a common reused library nested at multiple points
<lifeless> abentley: projA/common, projB/common, and projA and projB are nested conceptually in 'release/projA' and 'release/projB'
<lifeless> abentley: but as you say there is a significant cost
<abentley> lifeless: It would basically mean redesigning all our tree operations so they don't use file-ids.
<lifeless> abentley: I'm pretty convinced we need something beyond fileids, have been for a long time; but our plates are all pretty full.
<lifeless> abentley: so I'm entirely happy with this staying in dreamland, I was just noting a 'would be nice' :)
<abentley> lifeless: Well, I do recall that you wanted that.
<spm> lifeless: jelmer: pqm web front end is restored
<jelmer> spm: Thanks!
<lifeless> bbs, fooding
<mtaylor> hey all... bzr on windows breaks for me
<mtaylor> pretty substantially...
<mtaylor> install bzr 1.11 ... do bzr branch lp:libdrizzle
<lifeless> spiv: could you pastebin the blackbox stacked new acceptance test please
<mtaylor> get an error about no such file or directory about some file in .bzr/checkout/limbo/new-12
<lifeless> spiv: I want to use that for ratchetting till we meet up
<lifeless> mtaylor: I'm just popping out for a minute, but that rings some bug bells - do a lp bubg search for bugs with 'limbo', you may find something helpful
<mtaylor> k
<spiv> lifeless: ok
<spiv> lifeless: http://rafb.net/p/CydF0b17.html
<lifeless> mtaylor: any luck?
<mtaylor> lifeless: yup. it's not a bzr bug
<mtaylor> lifeless: it's that you can't create a file called "con.h" on windows
<lifeless> mtaylor: ah yes, that will be difficult
<lifeless> it would be nice to give a better error
<chx> omg even after all these years, windows still can't name a file con.foo?
<lifeless> mtaylor: if you care to file a bug with the error you got, and why[con.h] + the actual backtrace, we can look at improving the reporting
<mtaylor> lifeless: hrm... that'll require more touching of the windows computer...
<lifeless> mtaylor: just think of it as payment for the lovely linux box you use mostly
<chx> http://blogs.msdn.com/oldnewthing/archive/2003/10/22/55388.aspx#55399
 * chx chuckles
<lifeless> spiv: a *little* more context please :)
<lifeless> spiv: setup_smart_call_log etc - just the whole hunk or something :)
<enigma42> apt keeps complaining about not the debs from the PPA not being signed.
<enigma42> Is there a key for the PPA that I somehow missed?
<enigma42> Or are the packages just unsigned by design?
<lifeless> enigma42: I don't think the ppa keys are fully live yet
<enigma42> OK.
<lifeless> enigma42: they are currently unsigned, that is a ppa bug and its getting fixed
<enigma42> I'll just keep ignoring the messages then.
<enigma42> :-)
<enigma42> Thanks for the help. :-)
<Peng_> I thought they were live for bzr's PPA though.
<Peng_> Maybe not the beta PPA?
<enigma42> specifically, I'm using: https://launchpad.net/~bzr/+archive/ppa
<enigma42> And: deb http://ppa.launchpad.net/bzr/ppa/ubuntu hardy main
<Peng_> Eh. https://edge.launchpad.net/~bzr/+archive/ppa lists the key.
<Peng_> Anyway, lifeless is probably right. It's a new feature, so maybe it's not fully live yet.
<spiv> lifeless: that was the whole hunk :P
<lifeless> spiv: can you do from the thread below?
<lifeless> like both acceptance threads
<lifeless> or something
<lifeless> +        self._setup_smart_call_log() is definitely new
<lifeless> and knowing the line number I can put it in the same spot :)
<spiv> Yeah, just a sec
<spiv> http://rafb.net/p/ObfhP236.html
<nevans> Peng_, enigma42: try out "sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com   37B19B80"
<spiv> lifeless: ^
<chx> wow
<chx> never knew apt-key adv before
<lifeless> spiv: thanks
<chx> that's a useful trick
<nevans> or 8C6C1EFD for the non-beta PPA
<nevans> chx: it doesn't seem to be documented on the manpage.  odd.  I wonder where I learned it?  :)
<jfroy|work> jelmer: checkout that large svn repository is painful
<enigma42> nevans: Even the 37B19B80 part?
<enigma42> What's that?
<jfroy|work> 216071, Python's at 1.26 GB of real memory while doing "determining revisions to fetch"
<nevans> enigma42: 37B19B80 for bzr-beta
<jfroy|work> *216071 revisions
<enigma42> Hm...looks like "apt-key adv" is a secret command for those in the know....
<nevans> enigma42: 8C6C1EFD for the non-beta PPA
<enigma42> OK...let me get both.
<enigma42> nevans: Thanks!
<chx> just the other day i googled for this and it's certainly gpg import-export and piping everywhere in google
<chx> nevans: by lurking in the darkest channels on irc where such things are passed along in secrecy? ;) ?
<nevans> chx: I think it must have been on some launchpad help page or something webby like that.  :)
<enigma42> I almost feel like I need to put on a brown cloak before typing in that "apt-key adv" command...
<nevans> but ever since then, I just use "^Rapt-key" to recall the last time I did it, then edit the command line for the new key  (^R in bash, another cool tip to send around in dark IRC channels)
<nevans> I wonder what "adv" stands for, anyway?  "advanced-dark-magic"?  :)
<enigma42> I know...I'm addicted to "^R", but it seems that almost no one I run into has used it before...
<lifeless> thanks spiv
<enigma42> nevans: LOL!
<LeoNerd> I prefer the non-default stuff I have bound to my pageup
<LeoNerd> "\e[5~": history-search-backward
#bzr 2009-02-18
<fullermd> bash?  People still use that?  :p
<Odd_Bloke> *BSD?  People still use that? ;)
 * fullermd is single-handedly keeping it from dying.
<lifeless> keyboards?
<fullermd> "The keyboard.  How quaint."
<Odd_Bloke> (People still use those?)
<lifeless> does anyone know what irc nick marius uses?
<lifeless> 99 round trips to push a new trivial branch
<abentley> lifeless: amanic
<lifeless> abentley: thanks
<fullermd> Take one down, pass it around...
<lifeless> fullermd: yeah looking at that :)
<lifeless> vila: ping
<Odd_Bloke> Next format: 'bottlesofbeer-core'
<AfC> fullermd, Odd_Bloke: :)
<lifeless> this is weird
<lifeless> pqm hates my branch, but the failing test passes locally ><
<poolie> lifeless: which test?
<lifeless> branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-v2)
<lifeless> branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-default) passes
<lifeless> which adds to the oddity
<spm> lifeless: oops. let me just remove the "fail-lifeless'-branches-spuriously" config option from bzr pqm.... :-P
<lifeless> spm: pqm runs make check yes?
<spm> lifeless: yup (verified)
<lifeless> python 2.4?
<spm> Python 2.4.3
<spm> in the chroot as in
<lifeless> thanks
<thumper> I have a repository object that is on my local filesystem
<thumper> and I want to pull in some revisions from a remote branch
<thumper> without creating a branch locally
<thumper> how do I do this?
<Odd_Bloke> thumper: Shared repositories are purely a storage mechanism.
<Odd_Bloke> Which is to say: there isn't a way.
<thumper> Odd_Bloke: well, abentley told me there was a way :)
<Odd_Bloke> But branching into the shared repo and then deleting the branch should have the desired effect.
<thumper> Odd_Bloke: and I think jamesh has done the before
<Odd_Bloke> Actually, 'bzr pull -r revid:... <REMOTE LOCATION>' might do it.
<jamesh> repository.fetch() perhaps?
<Odd_Bloke> And it's certainly possible in bzrlib.
<Odd_Bloke> (Which it now occurs to me you might have been talking about. >.<)
<thumper> jamesh: ta
<thumper> ah
<thumper> ha
<thumper> y'know what
<thumper> this code is written already
 * thumper smacks himself
<baxissimo> Howdy, I'm having trouble deciding how to convert my svn repo... where to draw the branch lines, basically.
<jamesh> thumper: the code I did for that bzr-gnomeserver plugin?
<thumper> jamesh: no, it came from a gobby session I had with abentley
<jamesh> thumper: ah.  I think I did something like this in that gnomeserver plugin to make sure a repository contained all the revisions from another repository without creating a branch.
<thumper> jamesh: yeah, I remember you writing it
<thumper> jamesh: I'm working on my version of your old pending reviews
<thumper> script
<jamesh> making it launchpadlib aware?
<thumper> yep
<thumper> I have all the launchpadlib bits in place now
<thumper> or will have very shortly
<jamesh> cool.  are you allowed to make that code public yet?
<baxissimo> I've got top-level dirs in SVN like  app/ and lib1/ lib2/.  The libs are used by app/ but also could be used without app/
<thumper> jamesh: it will be public as soon as it is written
<baxissimo> Best to put all three in one repo? or three separate repos?
<thumper> jamesh: users will be able to run it locally
<thumper> hmm.. Branch.open doesn't like lp: style urls
<thumper> load plugins maybe?
<thumper> yep, that did it
<baxissimo> Any advice?
<lifeless> baxissimo: 'bzr svn-import SVN-REPO-ROOT BZR-REPO-ROOT'
<baxissimo> lifeless: q isn't what command to use but whether it's better in general to have three .bzrs for three related but independent things, or one .bzr containing all three.
<lifeless> baxissimo: I don't think there is a general answer to the question
<baxissimo> I frequently make changes to the libs same time as the app, so like being able to have all changes committed with one commit.
<baxissimo> But I'd also like to be able to branch just a lib or just the app.
<baxissimo> Is it the case I have to pick one or the other of those capabilities?
<lifeless> yes
<lifeless> (sorry)
<baxissimo> Ok.  No, that's helpful.  Now I can stop looking for how to get both at once.  :-)
<baxissimo> Any chance of "bzr externals" at some point a la svn externals?
<baxissimo> I.e. have multiple branched locations collected in a single directory tree so that one update/commit/pull will hit all the locations.
<bob2> I think you mean "branch" not "repository" btw :)
<lifeless> baxissimo: not yet, but there is some hope we'll get something soon
<bob2> you can do that with the repo-push or multi-pull plugins
<baxissimo> bob2: grr.  Ok what do I call the stuff that's in a .bzr dir?
<baxissimo> bob2: That actually contains all the history
<lifeless> baxissimo: .bzr/repository is a repository
<lifeless> baxissimo: .bzr/branch is a branch :)
<bob2> it might be simpler to just forget about repositories entirely
<lifeless> baxissimo: a .bzr can have either or both of these things (and more besides, like working trees [.bzr/checkout], search indices [.bzr/bzr-search], etc)
<baxissimo> bob2: ok.  I mostly meant "a place where all the history actually lives" as opposed to one of those lightweight or stacked branches that doesn't actually contain any history.
<lifeless> baxissimo: that is indeed a repository
<baxissimo> bob2: I'll check out those repo-push and multi-pull plugins.
<lifeless> they don't give you commit coherency
<lifeless> which was one of the things you asked for
<baxissimo> lifeless:  so what do you call the .bzr dir that can have all of that?
<lifeless> baxissimo: a .bzr dir
<lifeless> (literally, in the code its 'BzrDir')
<baxissimo> lifeless: .bzr dir.  Ok.  I'll see if I can remember that one at least.  :-)
<lifeless> baxissimo: you can't 'push' or 'checkout' or 'clone' or run nearly any UI commands just on a '.bzr' dir though - you generally have to have a branch [.bzr/branch] to run any UI commands
<lifeless> baxissimo: bzr is very focus on branch level operations
<baxissimo> lifeless: ok I was focusing on the .bzr dirs since they seem to be the easiest way to see if the files I have are all part of one branch or come from separate branches.
<lifeless> baxissimo: 'info' and 'branches' are two commands you might like
<baxissimo> lifeless: ok, but I can see right from Explorer if there's a .bzr or not without typing any commands.  :-)
<AfC> Should we still be using curl or is it time to stop building with that?
<baxissimo> lifeless: what did you mean by "no commit consistency" -- that I'll have to issue commit once for each branch even with those plugins?
<lifeless> baxissimo: exactly
<lifeless> AfC: ask vila on the list - he knows all https :)
<baxissimo> lifeless: so they make it so pulling/updating can be done with one command?
<lifeless> yes
<AfC> lifeless: um, oh, right. I was using bzr:// so I guess curl doesn't come into it.
<AfC> lifeless: I was a bit surprised to see it sitting for 40 seconds at 0/7805 while it downloaded something huge and then over about 3 seconds cycled through all the integers up to 7805 and moved onto the next thing that it sat at 0/ for a while.
<AfC> lifeless: I naively wondered if the to-curl-or-not-to-curl thing was to blame.
<lifeless> AfC: what release?
<AfC> 1.12
<AfC> lifeless: ^
<lifeless> AfC: and were you seeing network download counters?
<AfC> no
<AfC> lifeless: come to think of it, having seen a download counter in a pull was why I tried the raw branch
<AfC> lifeless: wanting to see what it said. Let me try again.
<lifeless> thats odd, I was sure there was a patch to do network counters for bzr*://
<baxissimo> Does bzrtools work on Windows?  The lack of a .zip is usually a bad sign.
 * AfC notes that there seems to be an awful lot getting packed onto that progress line. I wonder if a standard 80 char wide terminal isn't wide enough
<AfC> Nope
<baxissimo> Doh, [/me smacks forehead] looks like bzrtools are installed by default with the Windows installer.
<AfC> that's not a problem
<AfC> lifeless: I'd have to guess that the download counter only works over http transport.
<AfC> And indeed 80 columns is NOT wide enough. Yetch.
<AfC> lifeless: yeah. It's http only (in 1.12, anyway)
<thumper> AttributeError: 'RemoteBranch' object has no attribute 'supports_rich_root'
<thumper> poos
<lifeless> thumper: branches don't affect rich root support
<lifeless> thumper: what are you doing?
<spiv> There's a patch for hpss download counters, but I didn't get time to decide how it should interact with vila's socket-wrapping approach for the HTTP ones.
<baxissimo> lifeless,bob2: ok, seems like repo-push isn't what I want.  I don't want to "push all branches to another [single] location", I'd want to push all branches to their different respective locations.
<spiv> So I decided against rushing it into 1.12 late in the release cycle.
<baxissimo> But multi-pull looks good.  Thx for the pointer.
<bob2> baxissimo: that's what repo-push does
<baxissimo> bob2: the command description makes it sound like it only works with 1 destination location.
<lifeless> thumper: jml: mwhudson: lp:foo through proxies - http://docs.python.org/library/xmlrpclib.html#example-of-client-usage
<bob2> baxissimo: yes...
<lifeless> jamesh just dug that up
<bob2> baxissimo: /local/foo/liba -> /remote/whatever/liba, /local/foo/libb -> /remote/whatever/libb
<bob2> ideally, at least, it was broken last time I tried it
<baxissimo> bob2: ok, so you couldn't have  a --> /remote/whatever/a  b --> /somewhere/else/something/b then?
<thumper> lifeless: repository.fetch from a branch
<lifeless> thumper: b = Branch.open('remote')
<lifeless> refs = b.get_last_revision_info()[0] + b.tags.get_tags_dict().values()
<lifeless> for ref in refs: target.fetch(b.repository, ref)
 * thumper tries
<lifeless> or something ~= to that
<thumper> AttributeError: 'RemoteBranch' object has no attribute 'get_last_revision_info'
<thumper> last_revision()?
<lifeless> last_revision_info(), or sure, last_revision()
<thumper> does bzr tag it's revisions in lp:bzr?
<thumper> 'cause I'm not seeing any using Branch.open('lp:bzr').get_tag_dict()
<thumper> insert a .tags in there too
<lifeless> thumper: there is something weird with pqm, they don't propogate through the merge process
<lifeless> thumper: in the general case, tags for releases aren't in trunk anyhow
<lifeless> thumper: anyhow, see that link above?
<lifeless> there is a bug/limitation in the bzr-lp plugin which it allows fixing
<thumper> which one?
<thumper> the docs.python.org one?
<lifeless> yes
<lifeless> thumper: bug 330823 - its a dup of a much older one
<ubottu> Launchpad bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New] https://launchpad.net/bugs/330823
<thumper> base = graph.find_unique_lca(rev1, rev2)
<thumper> why does this raise ObjectNotLocked?
<lifeless> thumper: because your backing repository isn't locked
<thumper> lifeless: and I lock and unlock how?
<lifeless> we used to autolock but had too many cases of 'its slow because its continually refreshing the object list'
<lifeless> tree|branch|repository.lock_read(), unlock()
 * igc heads off for lunch & medical stuff
<lifeless> thumper: why do you need that though?
<thumper> lifeless: ;-) you'll see
<thumper> bzrlib.errors.NoCommonAncestor: Revisions have no common ancestor:
<thumper> I don't believe it
<thumper> how can I manually confirm?
<thumper> I think it is lying to me
<jml> lifeless: I wonder if 2.4 supports that: http://www.python.org/doc/2.4.4/lib/module-xmlrpclib.html
<lifeless> jml: if it doesn't, we could version-check
<jml> lifeless: anyway, I *think* I knew about that already :)
<thumper> abentley: ping
 * thumper calculates time zones
 * thumper thinks abentley may still be up
<lifeless> thumper: you can traverse the graph by hand, but its not lying to you
<thumper> lifeless: the graph is obviously not complete
<thumper> lifeless: as the revisions are related
<bob2> baxissimo: you can, but afaik repo-push nor multi-pull will do it for you
<lifeless> thumper: or something; but without some details on what you're doing I can't comment sensibly
<thumper> lifeless: I have a repo with no branches but a bunch of revisions
<thumper> lifeless: which I have populated with repository.fetch yadda yadda
<bob2> baxissimo: in practice 'for dir in *(/); (cd $dir ; bzr pus) ; done' may suffice
<thumper> lifeless: I'm trying to generate preview diffs without using working trees
<thumper> lifeless: abentley tried to give me an outline
<thumper> lifeless: and we're close
<thumper> lifeless: I've got it so I get the repository populated with the revisions
<thumper> lifeless: but I need to work out the lca to pass into the 3 trees merger
<thumper> lifeless: or preview tree thingy
<thumper> lifeless: I'm at the stage of trying to find the lca
<lifeless> thumper: and why are you sure the revisions are related?
<thumper> lifeless: because I branched one from the other
<thumper> lifeless: one is lp:pqm
<thumper> lifeless: and the other is one of my pqm branches
<thumper> lifeless: so I'm pretty sure they are related
<lifeless> well
<lifeless> make sure you're using the right key type
<lifeless> if graph is repository.get_graph(), its a simple string otherwise its a key tuple
<thumper> rev1, rev2 = repo.get_revisions(['my-revid', 'trunk-reviid']) # not real revids
<thumper> I used repository.get_graph()
<thumper> base = graph.find_unique_lca(rev1, rev2)
<lifeless> secondly, you don't need a shared repo for this sort of thing if you have recent repositories you can just add a temporary fallback repo during the calculation
<thumper> lifeless: lets just say I have a local copy of all the revisions
<lifeless> sure, just letting you know :P
<thumper> so why does the graph not think they are related?
<spiv> We really should improve the "here's a traceback, please file a bzr bug" message to peek at the traceback to see if a plugin is obviously involved, and if so blame the plugin rather than bzr...
<jml> lifeless: can you please take a look at https://bugs.launchpad.net/bugs/330823
<ubottu> Ubuntu bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New]
<abentley> thumper: You rang?
<lifeless> jml: in what sense
<thumper> abentley: yes, I'm having mad issues
<abentley> thumper: lol
<thumper> abentley: I have my local repo with revisions now
<thumper> abentley: but the graph doesn't seem to think that the two revs are related
<lifeless> jml: oh its a more complex report than I knew
<abentley> thumper: Well, it's possible they're not...
<thumper> abentley: the branches that they are from are related
<abentley> How are you creating them?
<thumper> abentley: pulled from real branches
<abentley> thumper: Can you run bzr find-merge-base against them?
<lifeless> thumper: oh
<lifeless> thumper: don't pass in revision objects
<lifeless> thumper: pass in revision ids
<thumper> grr
<lifeless> nearly everything works in terms of identifiers
<lifeless> full revision objects are expensive when not needed
<thumper> the docstring says revision not revision_id
<thumper> so I assumed revision objects
<lifeless> fair enough
<abentley> thumper: Sorry, I'm a bit sloppy with that distinction.
<thumper> hah
<thumper> have a base now
 * thumper attempts to generate a preview diff
<kkubasik> hey, anyone know if/when a osx 10.5 installer will be available for 1.12
<thumper> abentley: where does the preview tree code live?
<mwhudson> kkubasik: i saw some swearing in here about bzr-svn on os x, so hopefully soon
<kkubasik> slash, I'm totally willing to build it if anyone can point me to how the 1.11 package was built
<abentley> thumper: In transform.py, but you won't use it directly.
<kkubasik> mwhudson: thanks!
<thumper> abentley: so given base_id, rev1_id, and rev_2 id
<thumper> abentley: and a repo
<thumper> abentley: what do I do to generate the treeless diff?
<abentley> thumper: Instantiate a Merge3merger
<thumper> found in?
<thumper> merge?
<abentley> thumper: merge.py
<mwhudson> thumper: have you seen http://pastebin.ubuntu.com/119504/ ?
<mwhudson> (from my lpreview hackery(
<jam> kkubasik: there is already one uploaded last I checked
<abentley> thumper: You'll need to get RevisionTrees for all the revisions first.
<thumper> abentley: a Merge3Merger wants working trees
<mwhudson> me has a shiny loggerhead branch he wants everyone to try!
<jam> ah, only a 10.4 one here: https://edge.launchpad.net/bzr/1.12/1.12
<jam> not sure why
<mwhudson> lp:~mwhudson/loggerhead/unified-by-default-sbs-by-ajax
<abentley> thumper: Yeah, but you can get away with just revisiontrees.
<jam> or if it matters
<thumper> abentley: RevisionTrees are created how?
<thumper> mwhudson: I have no real trees
<abentley> thumper: Repository.revision_tree
<jam> thumper: repository.revision_trees([revision_id1, revision_id2])
<mwhudson> thumper: neither does that code
<kkubasik> jam:at  https://launchpad.net/bzr/+download ?
<mwhudson> branch.basis_tree() == branch.repository.revision_tree(branch.last_revision())
<kkubasik> I can't find one....
<abentley> thumper: Make sure you pass in do_merge=False.
<thumper> mwhudson: I don't have a branch
<mwhudson> thumper: but you have a repository and a revision tree
<jam> kkubasik: On the page you linked, I see: Bazaar-1.12-OSX10.4-universal.dmg
<mwhudson> thumper: but you have a repository and a revision id
<mwhudson> (rather)
<jam> but you're right that I don't see a 10.5 one
<jml> lifeless: thanks
<kkubasik> jam: yeah, i need OSX10.5
<thumper> hmm
<thumper> KeyError: 'pop(): dictionary is empty'
<thumper> line 1694, in _iter_inventory_xmls
<thumper>     chunks = text_chunks.pop(key)
<thumper> that is attempting repo.revision_trees
<baxissimo> Why doesn't this work?:  bzr svn-import --trees http://svn.dsource.org/projects/multiarray/trunk/multiarray/dflat
<abentley> thumper: that's odd-- it should just fail if it can't find the right inventories.
<thumper> :(
<abentley> thumper: Did you pass revision_ids in as a list?
<thumper> yes
<thumper> base_tree, rev1_tree, rev2_tree = repo.revision_trees(base, rev1, rev2)
<thumper> hang on
<thumper> wrong line
<abentley> thumper: That should be  repo.revision_trees([base, rev1, rev2])
<thumper> base_tree, rev1_tree, rev2_tree = repo.revision_trees([base, rev1, rev2])
<thumper> I tried the first after the second
<thumper> but it failed with wrong number of args
<thumper> base, rev1 and rev2 are all revision ids
<abentley> thumper: Can you put a pdb in _iter_inventory_xmls where it's looping through records?
 * thumper wonders which bzrlib he's using
<thumper> abentley: I'm in the interactive interpreter right now
<thumper> so I should just be able to invoke pdb
<thumper> and set a break point right?
<abentley> thumper: Could be.  I always do it the hard way :-)
<thumper> ok
<thumper> abentley: do you want to skype?
<abentley> thumper: sure.
<spiv> baxissimo: file a bug on bzr-svn
<baxissimo> spiv: is making a repo with init-repo first a requirement?
<spiv> baxissimo: not
<spiv> "no", rather
<baxissimo> spiv: Ok.   I'll file a bug.
<spiv> baxissimo: cool.  jelmer's pretty good at fixing them :)
<jblount> Can someone tell me why I get this response from launchpad-login ? http://dpaste.com/121983/
<spiv> jblount: hmm, because of a bug with progress bars
<lifeless> its not being ifnished()
<baxissimo> spiv: submitted https://bugs.launchpad.net/bzr/+bug/330832
<ubottu> Ubuntu bug 330832 in bzr "svn-import doesn't import anything" [Undecided,New]
<spiv> jblount: I don't think that bug has been reported yet
 * jblount heads off to LP
<lifeless> or possibly its reporting when there isn't a progress bar?
<jblount> lifeless: I could take a video if you like, but it does go into "progress bar mode" briefly and then report the paste.
<jblount> fwif http://etc.joshuablount.com/bzr-launchpad-login-weirdness.ogv
<lifeless> jblount: heh
<lifeless> you have far too much bandwidth
<Peng_> Are those progress bar warnings disabled in release builds?
<lifeless> Peng_: not yet
<jblount> lifeless: :)
<Peng_> ...That's unfortunate.
<jamesh> perhaps using "script" might produce a more australia-friendly recording
<jamesh> actually, that is a fairly small ogv
<jblount> 49KB
<poolie> jblount: is that perfectly reproducible?
<poolie> and thanks for the video, i think that's the first time i've seen one used in a bug report
<baxissimo> If I have branches foo/ and bar/ how can I reorganize that so bar is under foo -- like foo/bar?
<baxissimo> merge keeps telling me they have no common ancestor.
<baxissimo> oh... bzr merge -r0..-1 is the magic I'm looking for.
<baxissimo> Dang, I merged into the wrong place.  Is there an undo?
<poolie> baxissimo: bzr revert
<poolie> baxissimo: probably you want to just make a checkout of bar under foo
<baxissimo> foo/ already has foo/baz and foo/bif as part of the same branch though.
<baxissimo> poolie: bzr revert ... very nice.
<baxissimo> So ... think about it more actually maybe what I'd rather do is break baz and bif into their own branches.  They are all pretty independent.
<lifeless> baxissimo: there is a merge-into plugin too
<baxissimo> lifeless: that sounds like what I'm after.  But I guess it pretty much just does a merge 0..-1.
<vila> hi all
<poolie> hi vila!
<davidstrauss> Is there an efficient way to unmerge a branch?
<baxissimo> davidstrauss: bzr revert I think
<davidstrauss> baxissimo: I mean one that's long committed.
<poolie> davidstrauss: you can uncommit
<davidstrauss> The merge is about 20 commits down.
<baxissimo> Can I somehow change a repo to --no-trees after it's already created?
<jfroy> baxissimo: right now not through bzr
<jfroy> however, you can simply touch .bzr/repository/no-working-trees
<davidstrauss> jfroy: What about http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree
<jfroy> that operates on a branch
<davidstrauss> Or do you mean shared storage
<davidstrauss> oh
<jfroy> I think baxissimo was asking about the --no-trees option for repositories
<baxissimo> I have a shared repo that I just filled up with a bunch of different branches.
<davidstrauss> Well "repository" can mean many things in Bazaar.
<jfroy> No :p
<jfroy> A repository is what gets made by init-repo :p
<baxissimo> Now I'm thinking I'd like to convert all those branches to --no-trees style.
<davidstrauss> jfroy: No. "A branch consists of the state of a project, including all of its history. All branches have a repository associated..."
<jfroy> baxissimo: touching that file will turn on the no trees option on the repo.
<davidstrauss> jfroy: And not all branches use shared storage.
<jfroy> You'll need to remove-tree on any existing branch however
<baxissimo> jfroy: remove-tree before or after touching the file?
<jfroy> davidstrauss: don't actually consider that relevant. Branches may have internal storage of their deltas or use external storage e.g. a repository
<davidstrauss> jfroy: The fact that there's a command "init-repo" doesn't change that all revision storage, branch-local or not, are called "repositories."
<jfroy> Saying that "branches may contain a repository" just confuses things.
<jfroy> IMO
<jfroy> But, I suppose, "shared storage" is more accurate.
<davidstrauss> jfroy: Well, then the docs need updating, because the quote I pulled was from them.
<jfroy> I'm aware of that.
<davidstrauss> "All branches have a repository associated"
<davidstrauss> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree
<jfroy> But the confusion about bzr shared repositories is well known...
<baxissimo> bzr terminology is definitely confusing.
<jfroy> Which is rather unfortunate.
<jfroy> baxissimo: it isn't, once you have clearly separate things
<davidstrauss> And "shared storage" doesn't mean it's a repository in the collaborative "main line" sense, either.
<jfroy> It's shared by many branches.
<davidstrauss> I use shared storage on my laptop to avoid pulling revisions twice for my own dev branches
<jfroy> And yes, again, the terminology isn't as clear as it could be.
<jfroy> But the concepts are, however.
<davidstrauss> jfroy: Also: "Repositories in Bazaar are where committed information is stored."
<davidstrauss> jfroy: That is true of non-shared storage, as well.
<jfroy> I ind that quote, again, unfortunate.
<jfroy> *find
<jfroy> It's unnecessarily confusing.
<davidstrauss> And: "By default just running 'bzr init' will create a repository"
<jfroy> Repositories are such an unimportant, technicality of bzr.
<jfroy> The core concept is that of a branch.
<davidstrauss> Agreed
<jfroy> init creates a branch
<jfroy> repository has clearly defined semantics by virtue of other, past VCS
<davidstrauss> All I'm doing is quoting the docs
<jfroy> I know
<baxissimo> I think it would help if the words were more often coupled with their concrete implementation
<jfroy> :|
<baxissimo> Like a repository is generally implemented as a .bzr/repository directory containing the data.
<davidstrauss> And saying I'm justified for not assuming removing a tree from a repository means from shared storage ;-)
<baxissimo> That helps demystify the terms I think.
<davidstrauss> Bazaar should stop using the term repository entirely, I think
<jfroy> I agree
<jfroy> well a tree is its own thing
<davidstrauss> Yes
<baxissimo> And instead .... "revision store" or something liek that.
<jfroy> a "bazaar", so to speak
<baxissimo> What would you call it instead?
<davidstrauss> jfroy: Just saying that "How do I remove (a) tree(s) from a repository?" is an ambiguous question with current terminology.
<jfroy> *rimshot*
<jfroy> It is, unfortunately.
<davidstrauss> Unless you have a shared mainline. Then it's a cathedral. ;-)
<baxissimo> :-)
<luks> I think it's just wrong, repositories can't have working trees :)
<jfroy> And they don't!
<jfroy> branches do
<jfroy> but the repository no-tree option affects branches pushed to the repository
<jfroy> it's a pragmatic option
<luks> that's a configuration option
<jfroy> that lives in a poorly defined semantic space
<luks> not a tree
<luks> I personally think the term repository makes perfect sense
<davidstrauss> I'd rather have Bazaar kill shared storage and merely use a shared revision cache. I don't care about disk space. I care about performance.
<jfroy> I meant the option is there because it provides a solution for storage of remote branches on a server that don't need working trees.
<jfroy> No, I think shared storage is great.
<davidstrauss> And disk space can be saved pretty effectively with stacked branches, anyway
<jfroy> It's a powerful tool to optimize your branch storage.
<jfroy> However, I agree there needs to be an automatic *cache* fallback.
<davidstrauss> Shared storage is inherently flawed because of the impossibility of safe garbage collection.
<jfroy> The use case of "branch remote branch, branch local branch" needs to be addressed perfectly with 2 branch commands at optimum speed, no matter the user configuration.
<AfC> jfroy: I think what davidstrauss is trying to say is that if there was a global (per user, whatever) revision store then no one would need to ever think about setting up the structure where a shared repository can work.
<luks> you have the same problem with stacked branches
<jfroy> It's a do-or-die use case IMO.
<AfC> And since most people screw that up the first time, and changing to it later is also a pain in the ass, I tend to support the notion.
<davidstrauss> AfC: Correct, at least for the sake of performance.
<luks> unless you store list of branches in the repository, it's impossible to do gc
<jfroy> That's an interesting point.
<asabil> I also agree with davidstrauss
<davidstrauss> But I think that revision store should be a cache, not canonical storage.
<davidstrauss> I should be able to safely delete or gc it.
<AfC> davidstrauss: well, if you mean performance as in "not setting things up in such a way that causes you do duplicate network I/O" then sure.
<AfC> davidstrauss: But otherwise, if anything, such a hypothetical global one shot revision store would slow things down by the mere fact of having [way] more revisions in it that need indexing and searching through than a given individual project would have.
<luks> ehm, where would it store revisions then?
<davidstrauss> luks: locally with the branch
<davidstrauss> luks: the cache would be to save network I/O
<luks> davidstrauss: what's the point of revision store then?
<jfroy> shared revision storage saves a ton of time for local branching as well, however
<davidstrauss> revisions have globally universal IDs, a local cache of the last X MB of revisions I pulled would do wonders for my frequent branching of drupal
<AfC> davidstrauss: all that said, if you go ahead and `bzr init-repo ~` you'll have your global revision store.
<luks> davidstrauss: so if you have 5 branches of the same project, instead of having them stored once, you have stored them 6 times?
<jfroy> disks may be orders of magnitude faster than network, but they're still slow
<luks> that's insane, IMO
<davidstrauss> AfC: http://fourkitchens.com/blog/2009/02/09/no-brainer-shared-branch-storage-your-workstation
<jfroy> local branching within a shared repository is nearly instantaneous, as it should be
<AfC> davidstrauss: and given that you have enough knowledge to be having this conversation, why on earth have you not just used a shared repository at .. or wherever as the developers of Bazaar want you to do?
<davidstrauss> luks: The idea that the shared storage accumulates cruft that I can't clean up bothers me.
<jfroy> it may be worthwhile to have bzr gc
<davidstrauss> AfC: That's exactly what the guide I linked (that I also wrote) describes
<davidstrauss> AfC: And I do that
<AfC> davidstrauss: fine. So what's the problem?
<luks> davidstrauss: more than duplicating the data all over the disk?
<asabil> what about some kind of automatic branch stacking ?
<davidstrauss> AfC: It's clunky
<davidstrauss> I think branch stacking is the real answer, combined with multi-level caching.
<asabil> local automatic branch stacking ?
<jfroy> I'd say that it's additional mental load that users of the other DVCS don't have to deal with
<luks> I don't like branch stacking at all
<asabil> suppose that I branch http://foo.bar/baz into ~/mybranches/baz
<davidstrauss> Branch stacking is bad now because it's not horizon-based.
<luks> I want to have the full history right there where I'm working
<davidstrauss> You should have a certain amount of history
<asabil> and then try to branch again from the same location, it can try to stack it on the branch in ~/mybranches/baz
<davidstrauss> asabil: Yes, but you're still thinking from the perspective of a user who knows Bazaar internals.
<asabil> davidstrauss: how so ?
<davidstrauss> asabil: You know that you can branch locally and stack off that for efficiency.
<asabil> davidstrauss: no, that can be automatic
<davidstrauss> asabil: To search for a local branch to stack off of?
<asabil> the cache can keep a (remote branch => local branch)
<asabil> and stack based on that information
<davidstrauss> asabil: That's basically what I mean.
<asabil> or not even stack, just copy the revisions from the local branch
<davidstrauss> Now, I'm always thinking from the perspective of Drupal developers. We want to branch cheaply, have a bit of local history, and not have to think too hard about it.
<asabil> davidstrauss: I see your point
<davidstrauss> And almost everyone will branch from the master server.
<davidstrauss> Only advanced users would think to branch locally and re-branch from that or use shared storage.
<luks> I don't see how running bzr init-repo _once_ is a problem
<davidstrauss> Once merged, we typically delete the local branch.
<davidstrauss> luks: It continues to grow, and you can't gc it.
<davidstrauss> luks: Nor is there an obvious method for gc'ing it that we could implement.
<luks> davidstrauss: I uncommit or develop dead-end branches very rarely
<luks> so I don't find that a problem
<asabil> luks: the current approach used by bzr, is to *just work* by sacrificing the performance
<asabil> the proposed approach is the *just work* by sacrificing the disk space usage
<jfroy> well, you could do a breath-first traversal of the fs starting at the root of the shared repository, build a set of live branches, then delete any changeset no longer required by the set of branches you found.
<jfroy> But that may be a time consuming process.
<davidstrauss> jfroy: And incorrect.
<davidstrauss> jfroy: You can move a branch using shared storage to a non-child location from the shared storage.
<luks> asabil: using any tool without reading at least it's basic documenation is wrong, IMO
<jfroy> you would destroy that branch
<davidstrauss> jfroy: Yes, and that's unacceptable for safe gc.
<jfroy> you need to push it outside the scope of the shared repository, at which point it has a complete history
<luks> asabil: if the user can't find out that running bzr init-repo is an important step, there is a bug in the documentation
<davidstrauss> When you have a community as large as Drupal's, we can depend on most users not reading the docs.
<luks> davidstrauss: ehm, you can?
<jfroy> which means any branch not under the root of the shared repository can effectively be considered "no stored in this repository", which would let you find dead-ends in the histories, e.g. deleted branches,
<luks> davidstrauss: if you move the branch, it will be broken
<asabil> luks: I'd say it is a bug in the human behavior :p
<jfroy> luks: I disagree there
<jfroy> the *less* mental load you *force* on your user, the better
<davidstrauss> luks: Don't branches using shared storage refer to their shared storage with an absolute path?
<jfroy> bzr is worse than hg and git in that respect, period.
<asabil> luks: do you read the documentation of the appliances you buy ?
<luks> davidstrauss: no
<luks> davidstrauss: they just traverse directorties until they find a repository
<davidstrauss> luks: when you create them
<davidstrauss> luks: but what if you move them later?
<luks> davidstrauss: outside of the repository, using mv? you have a problem
<jfroy> they break if you move them above the shared repo
<jfroy> IIRC anywhere under the shared repo is fine
<luks> asabil: yes, I do
<asabil> :)
<luks> not all of it
<luks> but the "how to start" parts
<jfroy> luks: you are far more diligent than most people then :p
<luks> well,Â it takes longer to figure it out myself than to read it
<jfroy> I'd also like to remind one of the strongest argument of bzr over its competition is ease of use (particular w/r to git)
<luks> bzr by default works just fine
<jfroy> The need to know about, understand and setup share repositories, even once, takes away from that.
<davidstrauss> Interesting. They do fail if you move them, despite claiming to refer to the shared storage using an abs. path on creation.
<luks> if it's too slow, it's because the usert didn't read the docs
<jfroy> luks: but unacceptably slowly
<jfroy> that answer is arrogant, to some extent
<luks> jfroy: at that point the user will be forced to read the docuemntation
<luks> you can't use svn/hg/git/csv without setting up a repository
<luks> you *can* do that with bzr
<davidstrauss> luks: You can git init in place.
<davidstrauss> luks: The difference is that git inherently uses shared branch storage because of its branching model.
<luks> davidstrauss: that sets up a shared repository as well
<thumper> jfroy: the core devs are looking into making the first impressions better
<jfroy> thumper: I'm certain they are
<thumper> jfroy: which does include better stories around shared repos and inital working
<davidstrauss> luks: There's no such thing as non-shared git branch storage AFAIK
<luks> davidstrauss: right, neither there is for subversion, for example
<davidstrauss> correct
<jfroy> thumper: I don't care what the solution is. I care about the use case. "Branch from a remote branch, then branch locally is way slower under Bazaar if you don't care / know about shared repositories."
<jfroy> That use case should be as simply as "bzr branch http://... foo; bzr branch foo bar"
<jfroy> Nothing less.
<jfroy> *Nothing more.
<davidstrauss> A cache would solve that.
<jfroy> *as simple
<jfroy> davidstrauss: or implicitly initializing a shared repository in the parent when checking out a remote branch
<thumper> jfroy: I understand
<davidstrauss> Especially if the answer I'm getting for the flaws in shared storage is that disk space doesn't matter if it makes life easier.
<luks> jfroy: in the parent directory?
<jfroy> I think there is a place for discussion on the how, but now the need to do something.
<luks> oh
<asabil> davidstrauss: the best would be to write a plugin that does what you want
<jfroy> I dislike plug-ins.
<asabil> and hopefully it will become part of the core
<davidstrauss> This ought to be in core.
<jfroy> It's yet more stuff to worry about to get going.
<thumper> jfroy: well, bzr loves them :-|
<davidstrauss> Some things should be plugins.
<jfroy> plug-ins are fantastic to expand on the program and integrate bzr
<asabil> davidstrauss: yes, but it would be a very good proof of concept
<thumper> I agree that the core story needs to be better
<jfroy> But there's so much good stuff in them that you basically need bzr distros at this point.
<thumper> as do almost all the core devs
<davidstrauss> The fundamental code to pull revisions quickly should not be a plugin.
<thumper> if you have a really strong opinion, let kfogel know
<asabil> davidstrauss: I agree ! but you have to start somewhere
<thumper> hi emmajane
<luks> I think having this would come at the price of making bzr less flexible
<asabil> davidstrauss: discussions don't lead to anything
<emmajane> thumper, morning :)
<davidstrauss> asabil: Understood. We have a similar philosophy in Drupal. Try it out in contrib, and we might migrate it to core.
<asabil> davidstrauss: then apply that philosophy to bzr :p
<davidstrauss> luks: How would a ~/.bzrcache or something cost flexibility?
<jfroy> luks: I'm not certain about that. bzr could establish a heuristic for branch history storage that maintains its flexibility.
<asabil> davidstrauss: bzr-svn already uses a cache, you can take a look at it
<luks> davidstrauss: it forces you to certain workflows
<davidstrauss> luks: I'm not suggesting removing shared storage, at least right now.
<luks> the cache would take a lot of space, and it wouldn't be possible to have it on every machine
<davidstrauss> luks: The cache would be used when you're not using shared storage.
<luks> there are e.g. deployment machines, where you would explictly not want it
<davidstrauss> luks: And there could be an option to not use one, possibly on the user level.
<asabil> wait wait
<asabil> davidstrauss: are you talking about a revision cache ?
<luks> well, this seems just wrong to me
<jfroy> I agree with david on those principles.
<jfroy> it is, after all, only an extension of the current mechanism.
<davidstrauss> asabil: Yes, one bzr can check before pulling from a remote server.
<jfroy> Where bzr will search for shared storage, and if that search fail store history in the branch itself.
<asabil> davidstrauss: I would rather create a remote -> local uri mapping cache
<davidstrauss> asabil: So, the result of not using shared storage would be wasted disk but not much lost performance.
<jfroy> A cache would only introduce an additional step in that process.
<jfroy> *with the caveat that by definition a cache can be deleted safely at any time*
<davidstrauss> jfroy: Which is very good.
<jfroy> And that, I think, is the biggest problem of a per-user cache.
<jfroy> No, it's a very difficult design problem w/r to bzr.
<asabil> davidstrauss: that way you don't need to store the revisions in the cache
<luks> jfroy: I can already see users downloading hundrets of bzr data, just to see how the code looks like, then deleting it
<jfroy> it essentially means history duplication and atomicity nightmares.
<luks> jfroy: what will happen with the cache?
<davidstrauss> jfroy: How could you have atomicity nightmares? Revisions are keyed with globally unique IDs.
<luks> er, +megabytes
<davidstrauss> jfroy: It's a cache designers dream.
<jfroy> Implicitly, if the cache can be deleted, you need to store revisions elsewhere as well, don't you?
<davidstrauss> designer's*
<jfroy> Hence, 2 FS operations.
<davidstrauss> jfroy: Yes, but the cost of the FS operations is trivial compared to Internet I/O.
<jfroy> granted, if the operation on the cache fails, then the cache will simply be missing data, which by design is not an issue
<jfroy> I disagree to some extent with that.
<jfroy> Disk operations are costly in time and energy.
<luks> davidstrauss: this going in circles, if the FS operation is cheap, why not use standalone repositories?
<jfroy> Less so than network, but they are.
<davidstrauss> luks: Because you end up downloading all revisions over and over again.
<lifeless> also, note that we're looking at shrinking the size of repos by nearly an order of magnitude
<luks> davidstrauss: no, you end up copying the data from your disk
<davidstrauss> luks: Are we talking with or without caching?
<lifeless> I've been down the cache route before with 'arch', and I think its a sign of a different problem if you need one
<jfroy> For example, if I'm using a laptop on battery to do some hacking on the move, I would want all software on my computer to do as little IO of any kind as possible.
<luks> davidstrauss: assuming this is about "bzr branch http://.. foo; bzr branch foo bar"
<luks> davidstrauss: without
<jfroy> So I'm certainly not ready to call disk IO "cheap".
<davidstrauss> luks: No, it's about repeatedly branching from a remote URL.
<davidstrauss> luks: Which is the common case for large projects with many contributors.
<lifeless> davidstrauss: is it because shared repos are too hard to setup? / not default?
<jfroy> davidstrauss: mmm this suggests 2 problems, possibly
<lifeless> davidstrauss: if so thats under discussion at the moment anyway
<jfroy> perhaps we could have a remote branch cache
<luks> davidstrauss: well, you lost me there. I think think that case needs special handling at all
<jfroy> used only on protocols that are known to be "remote"
<luks> if the developer is branching from the URL multiple times, they should know about shared repositores
<jfroy> then we can worry about fast local branching as a separate concern, to be addressed perhaps in tandem with this remote branch cache.
<davidstrauss> lifeless: I'm trying to think about what would happen if Drupal moved to bzr.
<davidstrauss> lifeless: The common case for developers would be to branch from a remote URL. We cannot expect most users to create shared storage.
<davidstrauss> lifeless: How can we make that fast?
<luks> davidstrauss: branching from CSV requires you to re-download the data as well, is it that different?
<luks> CVS
<davidstrauss> luks: CVS checkouts are lightweight.
<davidstrauss> luks: And you can do lightweight checkouts with bzr, but that defeats the point of DVCS.
<lifeless> davidstrauss: well, the first thing that can make it fast is to download less; branch --stacked [currently slow due to a bug in the memory/IO tradeoff algorithm, in line for a fix in the next couple of weeks I suspect]
<lifeless>  will download only enough to reconstruct the tree locally; thats about the same as a cvs / svn initial checkout
<davidstrauss> lifeless: True, but is there a way to branch --stacked and download a little history (but not nearly all)?
<lifeless> davidstrauss: yes, --stacked could [should in fact for the branch case] do that
<davidstrauss> One of the boons of DVCS is being able to work effectively offline.
<lifeless> note that --stacked doesn't work offline
<davidstrauss> lifeless: indeed
<davidstrauss> If would be great to have the horizon stuff implemented
<lifeless> secondly, as I note, we have a new repo format which in some trials is 1/7th the size of current repositories
<davidstrauss> wow, congrats :-)
<jfroy> lifeless: is that the new compression stuff I've seen people talk about?
<lifeless> and performs equivalently for log/commit/annotate
<davidstrauss> stacking with horizons could plausibly work offline for recent history
<lifeless> jfroy: yes, the groupcompress plugin [*not* ready for end users]
<jfroy> I believe in eating your own dogfood :p
<lifeless> davidstrauss: indeed, but I'd rather talk about things that are nearly-complete rather than 'talked about but noone working on'
<davidstrauss> Something just bugs me about the idea of offline-usable branches continuously growing larger, no matter how well we compress the data.
<jfroy> It's incredibly painful (distasteful, you could say), but it's a great motivation to file bugs / fix bugs.
<lifeless> jfroy: oh sure, but groupcompress is being revised - its like working on zlib, you dogfood but you don't keep your tars in it, until you freeze the format :)
<jfroy> lifeless: oh we do that all the time, and it leads to pain :p
<lifeless> davidstrauss: I think its reasonable for repeat contributors to run some command to get a local working area
<davidstrauss> fair enough
<lifeless> davidstrauss: now, I definitely think we need a better, default, story in core
<jfroy> I vote for bzr getem'branch http://...
<davidstrauss> lifeless: What exactly do you mean by "story"?
<lifeless> but its easy enough to have a plugin that makes a local shared repo and does a branch into it
<jfroy> davidstrauss: use case, I believe
<lifeless> davidstrauss: user story,  top level 'this is how it works'
<davidstrauss> ah
<lifeless> one path through a use case, if you like
<davidstrauss> lifeless: I've been drafting some on my blog from a Drupal perspective.
<lifeless> [no conditionals]
<jfroy> indeed, a plugin could even replace "branch" and add logic to it to always enforce a shared repository, for example.
<lifeless> davidstrauss: e.g. bzr drupal-setup c:\src\drupal 6
<davidstrauss> I don't think we can expect our normal contributors to install plugins.
<jfroy> lifeless: incidentally, I've been convincing myself that bzr needs a command to install plug-in as well as a plug-in index
<davidstrauss> btw, I was elected today to the Drupal Association, and I'm discussion VCS tools with the rest of the infrastructure team now.
<jfroy> (or plug-in index mechanism, which would allow for internal plug-ins)
<davidstrauss> discussing*
<lifeless> jfroy: yes, there is a hook in bzr to discover plugins when a user runs a missing command, and this could install. We've put that there with the intent that people can do this
<jfroy> I had no idea that was in place.
<davidstrauss> I think it should download random code from the web and run it with no verification.
<jfroy> But, a "bzr install-plugin foo" would be great
<davidstrauss> But only on the Windows client.
<lifeless> jfroy: see doc/developers/plugin-api.txt for the declaritive data that lets my plugin-info plugin tell you the metadata
<lifeless> jfroy: most of the bits are there just needs a little glue
<jfroy> innnnnteresting
<lifeless> jfroy: the reason its a hook and not a run-random-code is because on e.g. Ubuntu you should really call into apt to install a plugin, because thats validated, signed code etc
<lifeless> rather than random bits off the net
<jfroy> ah yes, that's quite true
<lifeless> davidstrauss: http://drupal.org/node/147789 talks about a bunch of tools to setup
<jfroy> it is unfortunately useless to Mac OS X and Windows developers
<AfC> I've got to admit that I just (socially-) engineered around this whole issue by making it *very* clear to people wanting to checkout our project that they have to go through the steps to create a shared repository. Having done that, they never duplicate the network traffic again.
<jfroy> AfC: yes, that works quite well, having experience with it
<jfroy> I wrote steps to start using bzr with my project at Apple
<AfC> It's a bit of a pain to force that at the beginning, but it's now down to "Follow those instructions, and things will work great". "Yeah, but I did...". "No. Delete that, and try again. Follow these instructions..."
<lifeless> davidstrauss: I don't see that downloading a tiny .exe and running it on windows would be hard; you expect your contributors to know SQL and a long list of other tools
<jfroy> Which includes each and every command to run, copy-pastable to a terminal
<jfroy> it really is about the only reliable solution to get everyone a sane working environment
<lifeless> davidstrauss: but! like I say, I think bzr's core does need to improve
<davidstrauss> lifeless: I have a hard enough time betting devs to download Bazaar itself: http://fourkitchens.com/blog/2009/02/17/developer-preview-materialized-views
<lifeless> OTOH does tortoise-bzr give an easy clicky clicky to do stuff?
<AfC> Part of what makes it "hard" is that they are following instructions that seem really arcane. But since it's so entirely worth it, I've done my best to front load the issue.
<davidstrauss> "Oh, and for those of us who don't have bzr, how do we get this magical code? :-)"
<davidstrauss> "And a tarball would indeed be much appreciated :)"
<lifeless> davidstrauss: do you have a loggerhead instance? (or are your branches registered with launchpad?)
<davidstrauss> These are serious core devs from Drupal.
<davidstrauss> lifeless: http://vcs.fourkitchens.com/
<davidstrauss> lifeless: We host everything
<jfroy> urg, loggerhead
<jfroy> *the pain*
<jfroy> it's dandy for your own branch on your own machine with a local apache
<davidstrauss> It would be great if loggerhead allowed tarball downloads (via bzr export) from branches.
<jfroy> it doesn't work on a central sharing server with 1000s of users
<jfroy> that well
<jfroy> (each with their own set of branches)
<lifeless> davidstrauss: its meant to
<beuno> davidstrauss, that's a branch for LH which does that. Still needs some cleanups, but it's landing is immanent
<gioele> hello
<lifeless> I patched bzr's core to support that
<lifeless> beuno: JFDI
<lifeless> beuno: otherwise your core cleanups will make that branch bitrot, not good.
<davidstrauss> beuno: what's that branch?
<beuno> lifeless, it needs an option to disable it, or many users will hunt me down and kill me
<lifeless> beuno: why?
<beuno> lifeless, server resources?
<lifeless> beuno: and we know them all, can't be that hard)
<davidstrauss> it ought to cache the exports
<lifeless> beuno: compared to the cost of running loggerhead in the first place, I don't think anyone will notice
<beuno> davidstrauss, https://code.edge.launchpad.net/~danigm/loggerhead/loggerhead/+merge/3266
<gioele> BzrFastExport keeps saying to me: "Fixing recursive rename for ./dir/foo.bar".
<gioele> Is there a way to fix these recursive renames once for all?
<beuno> lifeless, exporting mysql-server qoul problably not be the best thing in the world for LPs sedrvers
<lifeless> beuno: didn't we add this like june last year?
<lifeless> beuno: it should be totally fine, for folk that are hosting branches of mysql-server
<beuno> we did, I never got to it   :(
<beuno> so someone in the community did
<lifeless> beuno: don't let the perfect be the enemy of the good
<poolie> hi beuno
<lifeless> beuno: I'd be more worried about robots following the links
<beuno> ok, let's make a deal. I'll tweak that branch and land it with the config option before Sunday  :)
<davidstrauss> I have a real problem with getting deeply involved with all open source tools I use. :-/
<beuno> hiya poolie
<davidstrauss> Bazaar is not proving to be an exception.
<davidstrauss> :-P
<lifeless> beuno: than about having an option to turn it off completely.
<lifeless> davidstrauss: I love users like you :)
<davidstrauss> I'd contribute more, but I barely know Python
<beuno> lifeless, we already have a way to specify a robots.txt, so that's a little bit less of a problem
<lifeless> beuno: in which case, what user has asked to have this unmerged feature configurable ?
<beuno> lifeless, the reviewer of that branch, rockstar
<beuno> and myself  :)
<davidstrauss> It sounds like a nice "poor man's" release builder
<beuno> we have enough performance issues at it is, so if we're going to add this, I'd like to make it optional
<beuno> on by default
<beuno> but optional
<lifeless> beuno: well he says its a concern
<beuno> not very hard, just need to plug in a config option to bazaar.conf
<beuno> lifeless, he's also across the table from me, and it's a blockable concern
<beuno> etierh way, I'll make that fix myself by sunday, or erge as is
<beuno> sound good?
<lifeless> beuno: I'm happy with that, in this specific case.
<beuno> *either
<beuno> good, I'll take it
<lifeless> but I really would like to point out that folk hosting big branches have big resources ;)
<lifeless> and they are more likely to want the feature (capability >> no capability) than not
<beuno> I know at leasy one big hosting facility that doesn't fall in line with that  ;)
<davidstrauss> Speaking as a Drupal.org infrastructure guy, I think we should be able to turn it off.
<lifeless> in terms of performance, actually measuring it should show its pretty fast FWIW. Its actually basically what bzr downloads trigger
<lifeless> davidstrauss: ok, well thats fair enough then :) I was just objecting against strawmen objections.
<lifeless> <- unwell today, so extra ornery
<davidstrauss> lifeless: Understood, but big projects create their own tarballs for users to download.
<davidstrauss> lifeless: And we do things like synching them to CDNs.
<lifeless> davidstrauss: sure. As far as caching exported tarballs from loggerhead; I think that would be a useful (configurable by giving it a place to put em) feature
<beuno> yeah, just cache them with the revid as their name (but serve them with a saner name)
<davidstrauss> I'm less concerned about caching if you can just turn it off.
<lifeless> I will note that by default bzr should simply be fast enough to do it on the fly
<davidstrauss> lifeless: Even gzipping the data would be a horrible server load for a project like MySQL.
<Lo-lan-do> How about uncompressed tarballs then?
<lifeless> gzip is pretty cheap, as long as you don't use pythons GZipFile
<lifeless> which sets -9 :P
<jelmer> bandwidth can also be a problem
<jelmer> that's one of the reasons we've got this option turned off on git.samba.org
<lifeless> jelmer: people downloading tarballs they don't need?
<lifeless> jelmer: or robots?
<jelmer> lifeless: robots, and people downloading tarballs from cronjobs
<Mez> are bzr up and bzr update meant to do different things? cause they just did
<jelmer> lifeless: maybe caused by the fact they don't know how to do keep a checkout with git, but still :-P
<lifeless> Mez: due to an unfortunate thinko, 'bzr up' is an alias for 'bzr up-thread'
<lifeless> Mez: it will be getting fixed
<lifeless> jelmer: yes well, don't get me started on *that* topic :)
<Mez> lifeless... that's internal? because it seems neither bzr up or bzr update will restore a working copy
<lifeless> Mez: what do you mean 'restore a working copy'
<davidstrauss> Mez: You restore working copies with revert.
<davidstrauss> Mez: If you mean like "svn up" does
<Mez> lifeliess
<davidstrauss> Mez: Just be careful
<Mez> lifeless: no, the .bzr folder is there, but there is no working tree... we need the files from the tree
<davidstrauss> Mez: That's bzr checkout
<davidstrauss> Mez: or you can export the branch to elsewhere
<Mez> davidstrauss: bzr revert seems to work
<lifeless> Mez: 'bzr checkout .' is likely what you want. Note that if you the .bzr dir is on a remote server, you may be better of looking at either loggerhead (web history viewer) or 'bzr-upload'
 * Mez shrugs
<lifeless> poolie: I was unwell all day today
<Mez> it's from a checkout where people cocked up :D
<lifeless> poolie: this is advance warning, if I feel == or worse tomorrow, I'll be calling in sick, well not calling in precisely :)
<davidstrauss> lifeless: Where do you work?
<lifeless> davidstrauss: @ canonical
<davidstrauss> lifeless: I mean physically
<lifeless> Oh, like most canonical folk, from home. I live in Sydney
<davidstrauss> ah
<poolie> lifeless: hope you feel better soon
<lifeless> poolie: so do I :)
<AfC> lifeless: I'm not sure I really believe them, but it's supposed to actually be sunny tomorrow. Maybe that'll help.
<lifeless> AfC: I'm reasonably sure its not drectly weather related, but who knows
<lifeless> throat closed up, raw-feeling, feverish, snuffly
<AfC> They even have a name for it where I grew up. "Seasonal Disaffective Disorder" or some such. Also known as "holy cow I need to get the hell away from the bleak misery of winter and go sit on a beach somewhere."
<Lo-lan-do> Grog!
<AfC> (so I did :))
<lifeless> AfC: :)
<poolie> Affective
<poolie> SAD
<AfC> ah
<AfC> I knew something didn't sound right there.
<lifeless> jml: btw, I acked your subunit review with a full reply branch changes etc
<davidstrauss> lifeless: I'm headed to bed. Hope you feel better tomorrow. :-)
<lifeless> jml: if you can ack-me-back I'd love that
<lifeless> davidstrauss: gnight, thanks
<Lo-lan-do> (Kerosene, propylene glycol, rum, scumm, axle grease, battery acid, pepperoni.  Grog.  It's good for you.)
<lifeless> Lo-lan-do: VM?
<Lo-lan-do> Er, yeah.  That was sort of a quote from Monkey Island, a game I mostly play in scummvm :-)
<lifeless> ok, halt()
<lifeless> night all
<ronny> moin
<beuno> g'night lifeless
<ronny> yo
<ronny> is there a way to sign tags in bzr?
<luks> ronny: no, tags are just simple name -> revision_id map in bzr
<james_w> would it be reasonable to have a hook so that plugins can set revision properties at commit time?
<james_w> or is that already possible?
<gioele> james_w: start_commit can do everything (while pre_commit cannot touch some things). Is that the hook you're looking for?
<ronny> jelmer: ping?
<ronny> jelmer: is there any need to keep dulwich compatible to old pythons?
<Peng_> ronny: How old is old?
<james_w> a simple one like commit_message_template would be nice
<james_w> but pre_commit might work
<ronny> Peng_: <2.5, preferable <2.6
<james_w> nope, it would need a new hook
<jelmer> ronny: My aim was to be compatible with 2.4 and up
<jelmer> ronny: Since that means being able to use generators
<jelmer> ronny: is there anything in particular that breaks 2.4 at the moment?
<ronny> jelmer: with breaks 2.4 and annotations break 2.5
<jelmer> ronny: hmm, where is dulwich using either?
<jelmer> ronny: I'm running 2.5 at home, so it shouldn't require any 2.6 features yet :-)
<ronny> jelmer: i started to hack simple tools that compile python code down to c
<ronny> works best with annotated code cause inference is hell
<Peng_> I should do research before asking this, but anyway: Isn't Git libifying itself? Why rewrite it in Python instead of writing bindings for that?
<jelmer> ronny: no cython/pyrex ?
<jelmer> Peng_: there is something, but it's not ready for prime time yet
<ronny> jelmer: it wont be possible to give those sane backends for jython/ironpython
<ronny> jelmer: and they wont run out of the box
<jelmer> Peng_: also, the git formats, etc. are pretty simple
<jelmer> Peng_: and writing them in Python means they'll work on Windows OOTB
<Peng_> jelmer: Okay. Thanks for the answer. :)
<ronny> jelmer: well, annotations help, and annotation decorators would suck as they would add complexity for detection
<jelmer> ronny: I wouldn't mind depending on annotations at some point, but preferably not before Python2.6 is available somehow in the main linux distro's
<ronny> ok
<ronny> gmm
<ronny> kinda sad it doesnt go into the next ubuntu
<ronny> i think fedora already has it
<jelmer> Debian unstable/testing will have it soon as well
<jelmer> I wasn't aware yet it wasn't going into Jaunty :-/
<luks> it does have it, but not as the default
<luks> or am I reading http://packages.ubuntu.com/jaunty/python2.6 wrong?
<ronny> jelmer: oh, im not sure, i just asumed cause its not yet there
<jelmer> luks: ah, that must've been added recently
<luks> same situation happened when 2.5 was released, 2.4 was the default for a long time
<ronny> very recent i think
<luks> 13 Feb 2009, according to the changelog
<igc> night all
<james_w> night igc
<vila> igc: night
<vila> jam: ping
<jam> morning vi
<jam> vila:
<vila> jam: I'm not your editor :)
<vila> I'm even your reviewer today :)
<jam> morning vila's emacs
<jam> anyway, I didn't mean to derail your question. What's up ?
<vila> jam: 'bzr gblame bzrlib/tree.py 985' and scrollback a little
<vila> jam: until the previous elif, choking isn't it ?
<vila> That's the cause of the bt.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified failure in bbc because the indentation has been fixed in bbc
<vila> And the commit comment for the patch that introduced that test proves that the author had some doubts :)
<vila> bzr gblame bzrlib/tests/test_merge.py 2636 &
<vila> AIUI, the wrong indentation predates your test, so I'm not sure about how to fix. Obviously tree.py must be fixed like in bbc, but what about the test ? subtrees semantics are unclear for me and fixing *that* will be time-consuming and again put me off bbc :-/
<jam> vila: the "elif from_kind == 'tree_reference'" looks like it should be lined up with the other elifs
<vila> jam: yes, it's done in bbc
<vila> jam: that's why the above test fails there and not in trunk
<vila> jam: at the time you wrote the test I think the bug was there in trunk and you didn't realize it (but given your commit comment, were not satisfied either :)
<jam> vila: so just change the test to expect "True"
<jam> ('sub-tree-root', True, ..)
<vila> hehe, you didn't try to run it don't you :-)
<vila> it fails in the wt.revert()
<vila> well it didn't fail, it errors I should have said
<vila> with: ImmortalPendingDeletion: Unable to delete transform temporary directory /tmp/testbzr-x7bubL.tmp/bzrlib.tests.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified/work/tree/.bzr/checkout/pending-deletion.  Please examine /tmp/testbzr-x7bubL.tmp/bzrlib.tests.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified/work/tree/.bzr/checkout/pending-deletion to see if it contains any
<vila>  files you wish to keep, and delete it when you are done.
<vila> And from there it's really unclear to decide where the bug is, is is in the test because you used some operation that is guarded somewhere else when tree references are present or are there other bugs that were hidden by the wrong indentation in iter_changes...
<vila> That's the question I pinged you for :) Well, the first past at least: do you see something wrong in that test ?
<vila> s/past/part/
<vila> Otherwise I think I'll just follow up to Larstiq and abentley
<Lo-lan-do> Immortal pending deletion?  What's that, rm -f /dev/duncan-mcleod?
<awilkins> That would be UniqueImmortalPendingDeletion (there can be only one!)
<Lo-lan-do> There *should* be only one, but see what happens when you define your constraints when the database is already populated?
<jam> Lo-lan-do: the .bzr/checkout/pending-deletion is supposed to be cleaned up
<jam> if it is still around it "didn't die"
<jam> which means the previous command failed in some bad way
<jam> vila: my guess is that other code that handles subtrees is broken
<jam> vila: and changing False => True, and changing the indentation causes the test to *pass* (on bzr.dev) here
<jam> So I would say... fix it in bzr.dev, get that submitted
<jam> and then we'll try to figure out why it breaks in bbc
<jam> vila: btw, any feedback on my --dev5 patch?
<jam> I'm willing to just merge it to bbc
<jam> but it would be nice to have someone look at it first
<vila> jam: there is another reason for why it fails in bbc, I'm on it
<vila> jam: czj:approve
<jam> czj?
<vila> czj is sexier than bb (younger at least :)
<jam> vila: anyway, for a fix like this, I'd rather see it happen in bzr.dev, before we do it in brisbane-core
<jam> anything that can be cleanly split out is something that ends up under constant PQM monitoring :)
<vila> jam: agreed, that's why I tried to reproduce it in bzr.dev as soon as I realized the root cause (but until now I was parallel pbd stepping and didn't realize it didn't fail in the same way)
<jam> and less to review when bbc lands
<vila> jam: understood
<jam> glad to see you working on bbc test suite, though :)
<vila> jam: by the way, if you merge from bbc, be aware that we both fix some failing tests in different ways, that should conflict in an obvious way
<jam> k
<vila> jam: it appears that my setup is still incomplete, my commits on bbc didn't get posted to bzr-commits (they were trivial enough to be push and I thought you got feedback by the ML hence my lack of "noise" about them)
<vila> jam: err, it errors out in bzr.dev here >-/
<jam> it seems my fix isn't complete yet anyway...
<jam> I forgot to actually change the inventory serialization, and only changed the chk_map serialization...
<jam> fixing
<jam> (I'm glad I double checked that, though for a different reason)
 * mvo thinks the new progress bar is sweet
<jam> mvo: I agree it is quite a bit better than the old one
<vila> mvo: did you said some days ago or was it someone else ?
<mvo> I just upgraded my bzr, I see it for the first time (and it seems to be more accurate as well)
<vila> mvo: far more accurate yes, did you see the IO rate for some operations ?
<mvo> yes!
<mvo> I need to do some big commits now so that it actually stays a bit longer :)
<vila> mvo: it's not complete yet, only some protocols are implemented so far so don't be surprised
<mvo> thanks vila
<vila> mvo: that's a team thing, I deserve only a little part :-)
 * mvo hugs the team and vila
<vila> jam: can you confirm you made the test pass with bzr.dev@4017 ?
<jam> vila: this change: http://paste.ubuntu.com/119711/
<jam> applied to bzr.dev 4011
<jam> I'll upgrade now
<vila> wth
<jam> you know what... I may have run the wrong one
<jam> (wrong bzr)
<vila> I sure hope so (kind of :/
<jam> yeah, it fails 2x now
<jam> once in giving the wrong result
<jam> a second time in giving Immortal...
<jam> vila: shall I leave it to you? Or do you need me to work on it?
<vila> jam: I think I'll bring the issue on the ML instead to leave it to the ones working on subtrees
<vila> They ought to run into it anyway at some point so it should help them
<jam> vila, just to check, if you run "bzr selftest -s X -s Y" it runs the X tests before the Y ones, right?
<vila> jam: it doesn't care about the order at all :-) The execution order is.... roughly the loading order
<vila> if you switch them and use --list you can confirm that
<vila> and --list will give you the running order too
<jam> dang
<jam> oh well, it is probably alphabetical
<jam> since that is how we list things
<vila> it can change at each '.' depending on how the module load its tests
<vila> parametrized tests can also come in vastly different orders
<jam> sure, but I'm just doing bt.XXX
<jam> anyway, it doesn't really matter
<jam> I just have about 500 tests I run for chk branches
<vila> At that level, yes alphabetical
<jam> and it is nice to know that if it fails in Y I don't have to run X tests agaig
<jam> again
<Tak> what am I doing wrong here? http://paste2.org/p/149615
<jam> it looks like you have a Branch objects whose "self.base" is None
<jam> is it, perhaps, a bzr-svn branch?
<SiCuTDeUx_> Hi!
<SiCuTDeUx_> how can i install the webdav plugin for bazaar?
<jam> SiCuTDeUx_: "mkdir -p ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr co lp:bzr-webdav webdav"
<SiCuTDeUx_> that's ala?
<SiCuTDeUx_> *all?
<jam> SiCuTDeUx_: generally
<jam> I won't absolutely guarantee it, but that is a general way to install plugins
<jelmer> vila: btw, did I mention I packaged bzr-webdav for Ubuntu?
<jelmer> jam: bzr-svn should set self.base properly
<vila> jelmer: wow, no, thanks. Did you do that for debian too or is it ubuntu only ? Do you have public branch for that ?
<jelmer> vila: it's for Ubuntu only at the moment, but it'll go into Debian as well
<SiCuTDeUx_> jelmer, ?
<jelmer> vila: James reviewed and advocated bzr-webdav last night, so it should end up in Jaunty
<SiCuTDeUx_> jelmer, where can i find it?
<jelmer> vila: there should be a packaging branch here: http://bzr.debian.org/pkg-bazaar/bzr-webdav/ubuntu
<SiCuTDeUx_> i use 8.10
<vila> James as in james_w ? :-)
<SiCuTDeUx_> it is empty jelmer
<jelmer> SiCuTDeUx_: I'll upload a new package to my PPA
<jelmer> SiCuTDeUx_: it's a bzr packaging branch
<SiCuTDeUx_> jelmer, nice
<jelmer> vila: there very same
<vila> jelmer: your ppa contains webdav_1.6.0, there was an update for bzr1.12 and the plugin version is now 1.12 too to reflect that
<vila> The revno for webdav is 62
<jelmer> vila: I haven't uploaded a recent version to PPA yet
<jelmer> vila: only to REVU, am preparing to re-upload to PPA
<vila> jelmer: no problem, I was mentioning just in case
<emmajane> vila, thanks :)
<vila> emmajane: *I* thank you :)
<emmajane> vila, I thought it might make sense to link to that document from the plugin page/
<emmajane> ?
<vila> emmajane: oops, forgot that one :) I printed your mail and read it in bed yesterday and then forgot that part :)
<jelmer> vila: any chance you can tag releases in bzr-webdav? That makes my live as packager a bit easier
<emmajane> vila, *chuckle* I'm not sure it was quite worthy of bed time reading.
<jelmer> james_w: is there any harm in me uploading a version of bzr-webdav to REVU that merges a new upstream ?
<vila> jelmer: there are several things I'd like to discuss about packaging branches, I'll try to mail about it
<jelmer> james_w: or will I automatically lose the advocation
<jelmer> james_w: ?
<james_w> you will, but I can re-review
<vila> emmajane: hehe, but there, I knew I could read it peacefully :)
<emmajane> vila, hehe
<vila> james_w, jelmer : the change is really minor FWIW
<emmajane> vila, Ultimately I think it would be nice to extend all of the plugins to have a little bit more information; and also for the workflows to have an "in five minutes" tied to each. I'm slowly working my way through the ones that I know.
<jelmer> james_w: ok, I'll reupload in that case - thanks
<emmajane> vila, also: I'm talking about the plugin for my Bazaar presentation at SCaLE this weekend. I only talk about it briefly so I wanted to have the documentation available for people who wanted to give it a try.
<james_w> jelmer: unfortunately I may not be able to re-review in time though, sorry
<james_w> perhaps you are better seeking advocation on #ubuntu-motu now, and then I will sponsor an upload once it is in
<jelmer> james_w: ok
<jelmer> james_w: will do
<vila> emmajane: http://bazaar-vcs.org/BzrPlugins updated, feel free to change it and good luck for your talk !
<emmajane> Thanks!! :)
 * emmajane heads out.
<emmajane> thanks again, vila  for looking through the tutorial!
<Tak> jelmer: I'm trying out yet another md-bzr backend
 * vila hugs his little daughter cause she needs love just right now and he just got some to share :)
<jelmer> Tak: other than bzr-xmloutput?
 * jelmer hopes the new monodevelop enters sid soon..
<Tak> yeah, I'm using bzrlib via pinvokes into libpython
<Tak> jam: oh, belated response to your response: no, it's a branch from lp
<Tak> I can get the push location successfully, but not the submit branch or the parent branch
<jam> vila: so the reason *not* to use 0xFFFFFFFF is because it casts up to PyLong
<jam> which are pretty slow
<jam> and we call the function a lot
 * vila feels depressed 
<vila> :-)
<jam> for now, I'll leave your fix, because I don't feel like worrying about it until we have to
<jam> but I figured I'd point that out
<vila> ha good
<jam> In reality, I think if performance there becomes an issue, we'll just write an extension
<vila> jam: We'll end up coding that in C at one point anyway
<jam> because struct.pack is + '\x00'.join is never that good
<vila> lol, heard the echo on the wire ?
<jam> I just type faster :)
<jam> however, it *would* be reasonable to do that for dirstate
<jam> since it is not a performance critical section of code
<jam> feel free to submit a patch to bzr.dev
<jam> ):
<jam> :)
<jelmer> vila: does it seem reasonable to just have each AbstractAuthHandler provide a variable that says whether it needs a username?
<jam> vila: inv_as_lines has now landed. --dev5 is now the only new format.
<jelmer> SiCuTDeUx_: looks like the new version is now available in PPA
<vila> jelmer: sounds reasonable without seeing the code, if you propose it *hacking* the code, that should be good :)
<jelmer> SiCuTDeUx_: you'll need bzr 1.12
<jelmer> vila: Don't worry, there'll be a patch for you to review soon ;-)
<vila> jam: ok
<awilkins> Anyone using Homeplug?
<emile> We just started our migration from svn to bzr by using svn2bzr.py. Our repo in svn was 22MB, in bzr it is 382MB. Is there some kind of housekeeping I'm supposed to run? I can't imagine bzr needing a 15-fold of the disk space.
<Odd_Bloke> emile: Try 'bzr pack'.
<jam> emile: did you have a lot of binary files in your svn repo? (bzr's delta for binaries isn't as efficient as svn's)
<jam> though 22 => 382 seems a bit extreme, regardless
<Lo-lan-do> Maybe svn2bzr.py didn't use a shared repo?
<jam> oh, and bzr-svn is generally preferred to svn2bzr, just as a heads up
<jam> Lo-lan-do: certainly could be
<emile> Odd_Bloke: I tried "bzr pack /path/to/repo", no change in size
<emile> jam: I'll try bzr-svn. There were some bins, but it isn't the bulk of the repo
<awilkins> emile: How messy is your SVN repo?
<emile> Lo-lan-do: I don't understand?
<emile> awilkins: messy in what regard?
<awilkins> emile: Project layout, esp. history of project layout
<emile> awilkins: nope, one branch, two tags, and the bulk of the work on trunk. There's just 50 or so revisions in the svn repo.
<awilkins> emile: Ok, sounds tidy compared to my 14k revisions and 1.5GB of repo
<awilkins> Most of that is alas, PNGs and DOC files
<emile> awilkins: Ah, make that 108 revs. Anyhow, shouldn't be significant at these numbers I reckon. We're just starting out this project on vcs.
<emile> jam: I thought bzr-svn was a like connection of sorts? We're looking to abandon svn.
<jam> emile: it is still the best converter
<jam> highest fidelity, etc
<jam> and the most actively developed, probably also the fastest
<emile> jam: "highest fidelity" in what regard? Should I be expecting loss?
<jam> emile: the big issue is with tracking what a branch is, and when they occurred, etc.
<jam> the actual content probably never differs
<jam> but the revision ancestry can be difficult to follow
<jam> again, your repo doesn't sound complex enough to cause problems.
<jam> I'd still recommend bzr-svn
<emile> I see. We can actually discard the one branch. Maybe even the tags.
<jam> emile: I would just try converting again with bzr-svn
<jam> there are certain ways you can convert which might cause bloat, and I'm not sure how bzr2svn does it
<jam> If it is hard to get set up, I can try to talk you through alternative setups for bzr2svn, it just doesn't seem specifically worth it
 * awilkins would also use bzr-svn
<emile> It's a one-time task, so I don't really mind. I'm trying to get bzr-svn set up, I don't have root access so I'm going to have to get bzr-svn installed in my home dir
<awilkins> At least it's *nix, it's a pig to build on Windows
<awilkins> Although there is allegedly a version in the exe-flavoured installer
<emile> jam: ok, bzr-svn has run its setup. Something showed up in /var/www/opt. So what next?
<jam> emile: "bzr svn-import $SOURCE"
<jam> or at least "bzr help svn-import"
<emile> it says "No help can be found". I've set my pythonpath, I can import bzrlib.
<jam> emile: it means you haven't properly installed bzr-svn yet
<jam> how did you "install" it?
<emile> $ ./setup.py install --prefix /var/www/opt
<emile> $ export PYTHONPATH=/var/www/opt/lib/python2.4/site-packages:$PYTHONPATH
<emile> you're correct, the following fails: from bzrlib.plugins import svn
<jam> emile: so I think the easier way to install is:
<jam> cd ~/.bazaar/plugins
<jam> bzr co "bzr
<jam> bzr co "bzr-svn" svn
<jam> cd svn
<jam> python setup.py build_ext -i
<jam> Depending on what "bzr-svn" you are grabbing
<jam> (also, newer versions of bzr-svn also require you to build the "subvertpy" library)
<emile> the bzr co yields "bzr: ERROR: Not a branch: "/home/hnse/.bazaar/plugins/bzr-svn/"."
<jelmer> I think John means "bzr co lp:bzr-svn svn"
<emile> slow, but it's doing something...
<emile> OK, running build_ext, no errors, but "bzr plugins" doesn't list svn
<emile> Logged in and out, now I "bzr plugins" says "Unable to load plugin 'svn' from '/home/hnse/.bazaar/plugins'"
<jelmer> emile: you need the subvertpy python module as well
<emile> what will be easiest? Grabbing an older bzr-svn version, or installing subvertpy (in a non-standard location)
<jam> jelmer: can you just build subvertpy in the bzr-svn directory?
<emile> jam: will check, it's coming in from launchpad now
<jelmer> emile: installing subvertpy somewhere in PYTHONPATH should be easiest
<jelmer> jam: atm it's not possible, bzr-svn no longer modifies sys.path
<emile> drat, it needs apr-config, which is not installed
<jelmer> emile: yeah, it needs the subversion development libraries as well :-/
<jam> jelmer: but doesn't it do "import subvertpy"?
<jam> which means that if it is in the same dir, it should just find it?
<jelmer> emile: you can try an older version of bzr-svn, but it will probably mean downgrading your version of bzr
<jelmer> jam: yeah, but bzr-svn has subpackages
<emile> jelmer: damn. I have no root access to this machine, so I can't downgrade *or* upgrade. I suppose bzr repos are portable? Could I do the migration elsewhere and put the repo back?
<jam> emile: yes, you can convert anywhere
<jam> emile: ok, so basically installing a plugin into your PYTHONPATH doesn't really work, because we don't search PYTHONPATH (though you could add it to BZR_PLUGIN_PATH), installing subvertpy should be on PYTHONPATH
<jam> emile: if you want, you can have one of us do the conversion
<jam> though it means exposing the repo to someone
<emile> jam: appreciate it, but I can't, my manager would freak out
<emile> Oops, gotta run, thanks guys! I'll check back in later
<Tak> jam: ok, in the situation above, b.base is a file:// url
<jam> Tak: that shouldn't really be a problem, then. The issue it is bringing up is that it is trying to work with a path which is None
<jam> which I don't quite understand
<jam> hmm... different base
<jam> just a sec
<jam> Tak: what platform are you on?
<Tak> debian x86
<jam> We seem to have this trap:
<jam> if base is None:
<jam>     base = os.path.expanduser("~")
<jam> What does: python -c "import os; print os.path.expanduser('~')" give you?
<Tak> my homedir
<jam> well, one thing to try
<jam> export BZR_HOME="$HOME"
<jam> Otherwise I don't really understand why we are getting None there
<Tak> same thing with BZR_HOME set
<Tak> it only seems to happen with get_submit_branch and get_public_branch
<Tak> parent and push location seem to be fine
<vila> jam: ping, just fix the same crc32 problem for _search_key_16 (test_search_key_16 fails on 64, succeeds on 32)
<vila> jam: but I now realize that I broke compatibility for dev5, since you should be the only one affected how big a problem is it ?
<jam> vila: hmm.. I would have thought the abs() would have been enough there
<jam> but I guess I understand why not
<jam> actually, you can take out "abs()" if you switch to using 0xFFFF...
<vila> jam: I thought abs() was ok too until the test broke and I realized I was wrong
<vila> jam: that's what I did
<jam> k
<jam> no problems here
<vila> good
<jam> I recreate them all the time :)
<vila> ./bzr selftest -s bt.test_chk_map.TestMap.test_map_splits_with_longer_key
<vila> ERROR: test_chk_map.TestMap.test_map_splits_with_longer_key
<vila>     maximum recursion depth exceeded while getting the str of an object
<vila> jam: rings a bell ?
<vila> jam: it's in a map -> _split -> map -> map chain
<jam> IIRC I added explicit tests for "splitting doesn't cause infinite recursion"
<jam> so there is certainly a different issue here
<jam> well, still an issue, obviously
<jam> but I'd like to understand why
<jam> vila: "bt.test_chk" passes here
<vila> jam: Holy cow ! It breaks here on both 32 and 64 8-)
<jam> well, I haven't updated to the latest bbc
<vila> It was failing before I fixed the crc32
<vila> And bt.test_chk says: FAILED (failures=1, errors=1)
<vila>   File "/net/bigmamac/Volumes/home/vila/src/bzr/experimental/brisbane-core/bzrlib/tests/test_chk_map.py", line 1176, in assertSearchKey16
<vila>     self.assertEqual(expected, chk_map._search_key_16(key))
<vila> AssertionError: not equal:
<vila> a = '738C9ADF'
<vila> b = '8C736521'
<vila> is the other one
<mneptok> jam: got a moment?
<vila> mneptok: nope, I pre-empted it :)
<vila> kidding, no urgency from me :)
<jam> mneptok: what's up?
<mneptok> vila: could i convince you to commit a k: line-able offense? >;)
<mneptok> jam: some "commit --fixes" questions.
<kfogel> hunh
<jam> vila: it passes at revno 3821
 * vila wonders what 'a k: line-able offense' means...
<jam> so something you've done recently broke it
<mneptok> kfogel: ahoy sailor
<kfogel> why do we have http://bazaar-vcs.org/Documentation and a separate "official documentation site" http://doc.bazaar-vcs.org/
<jam> perhaps either your "assert" patch, or your "search_key_16" one.
<mneptok> vila: "something that would get you banned from the network" (so i can then steal jam) ;)
<kfogel> mneptok: doing a draft of a new bzr home page right now, which is leading to lots of questions/cleanups about other pages :-).
<vila> mneptok: Ohhhh Kkkkk
<jam> kfogel: some are wiki documentation, doc.bazaa is built from the source tree
<jam> plus referencing 3rd-party docs/tutorials, etc.
<mneptok> vila: hence my wink
<jam> mneptok: so what are you trying to do with --fixes ?
<kfogel> jam: hmmmm. okay, so the seams of our automation are showing to the user, sounds like :-).
<vila> mneptok: I got the wink but not the joke ;-)
<kfogel> Not necessarily worth cleaning up right now, but worth fixing if we can.
<jam> kfogel: I don't think all documentation should be bundled into the bzr source tree... do you?
<kfogel> jam: huh?  no, never thought that
<mneptok> vila: my humor is like that. obtuse until you "get" it. and then it's just unfunny. ;)
<jam> So I think there is still worth in having a Wiki page that can reference things we haven't bundled
<kfogel> jam: ?
<jam> Whether we should be calling the stuff from source "doc.bazaar..." perhaps
<kfogel> jam: couple of things:
<mneptok> jam: the question was about "commit --fixes" referencing multiple bugs as fixed.
<kfogel> jam: one, the so-called "official documentation site" is really talking about developer and reference documentation, not other kinds of documentation, it sounds like.
<jam> mneptok: '--fixes' is a list option, so I'm pretty sure you can supply it multiple tiems
<jam> times
<kfogel> Since the Users Guide is by far the most needed bit of documentation, than which all others pale in comparison to, a user would naturally expect it to live on the official documentation site.
<jam> bzr commit --fixes lp:1 --fixes lp:2
<jam> etc
<kfogel> jam: sorry, misphrased
<mneptok> jam: right right. i didn't realize it was a list
<mneptok> (that's pretty sweet)
<jam> mneptok: I don't see that the help text really *tells* you it can be supplied multiple times
<kfogel> jam: what I'm getting at is: docs is just docs, users don't care where they came from, but right now it looks to a user like our docs are split across two sites.
<jam> mneptok: so certainly there is a bug report & fix waiting for your name
<mneptok> jam: your hints are as subtle as a flying mallet. :)
<mneptok> and .... on the to-do
<mneptok> thanks
<kfogel> jam: anyway, it will be less important when those globes-on-external-links go away. :-)
<jam> kfogel: so, you're welcome to clean it up as you see fit, but I think non-vetted documentation is still worth having
<jam> and once vetted we can bring it into the bzr source tree
<jam> I don't really care how that is organized
<jam> vila: revno 3822 breaks '-s bt.test_chk' for me
<jam> shame on you :)
<vila> jam: I see that, amazing (I mean the fix is amazingly simple but I'd like to understand it :)
<jam> vila: you changed: "common = prefix[:pos+1]" to "common = prefix[:pos]"
<serg> jam: "bzr help bugs" does say that "Note: As you provide a short name for each tracker, you can specify one or more bugs in one or more trackers at commit time if you wish."
<kfogel> jam: until you said that, I never even knew that in-source-tree vs in-wiki meant vetted vs non-vetted.  I think if a user sees something on a website with "bazaar-vcs.org" in its name, the user will assume it's reasonably vetted.  I don't think anyone but a few developers is even conscious of what docs are in the source tree.
<jam> kfogel: well, I do watch the emails about updates to the wiki
<jam> but it *is* still a wiki
<vila> jam: I thought I have that covered with the tests I added when removing the asserts, I need to find the right test to add :)
<jam> vila: just add direct tests to the "common_prefix" code
<jam> It is a class method anyway
<vila> look at that 3822 diff again ;-)
<kfogel> jam: I understand.  I'm just saying that we don't have a choice about what users regard as "vetted".  If it's on the site, they'll trust it -- they're not tracing the source back to this or that location.  So if we're maintaining these distinctions with the idea that it's meaningful to users, that's probably not working...
<jam> vila: the problem is that you aren't asserting *what* the common prefix is
<vila> jam: I do now :)
<jam> so for "beg" versus "begin" I would guess it is returning "be"
<jam> which wasn't being detected
<jam> vila: so did that fix it?
<jam> and when are you committing that to core :)
<vila> sure
<vila> jam: argh family NMI, I'll commit the fix later tonight :-/
<jam> vila: then I'll fix it now
<jam> since I need a non-broken brisbane-core
<vila> no wait, almost there
<jam> vila: enjoy your family time, though
<jam> (certainly don't postpone family for this, it isn't that hard to fix)
<vila> but the tests are already updated too here
<vila> jam: pushed (and that's why we want full test suite passing everywhere :-)
<Lo-lan-do> Jc2k: I'm interested in helping out with bzr-*-pack, what would be a good way for me to help?
<Jc2k> Lo-lan-do: thats up to you!
<Jc2k> Lo-lan-do: writing test cases would be awesome
<Jc2k> but even reproducable bug reports would be welcome
<jam> vila: of course, in your haste you left in a "import pdb;" but I'll fix that :)
<Lo-lan-do> Jc2k: I'll try using it first then :-)  Is there any doc?
<Jc2k> Lo-lan-do: ooh, docs would be nice too.
<Lo-lan-do> I'll take that as a "no".
<Jc2k> the gist is you install the bzr-git plugin and then set the bzr-*-pack scripts up so git finds them instead of its own git-*-pack.
<Jc2k> then it should *just work*
<Lo-lan-do> A symlink to ~/bin/git-*-pack would do the trick?
<Jc2k> Lo-lan-do: well thats the icky bit, it probably wouldnt - i dont think .bashrc/.profile is respected when doing "ssh host git-program-name"
<Lo-lan-do> I see.  /usr/local/bin it is then.
<montwi> mneptok: hi
<montwi> About --fixes; Can one also use --fixes=lp:444,lp:3333 ?
<montwi> Anyway, better documentation for 'bzr help commit' would be appreciated
<jelmer> montwi: I think you can specify --fixes multiple times
<montwi> works, but a little more cumbersome; Best would be to allow both things
<jam> montwi: well, it is possible that bugfixes have commas in them
<montwi> how can bug fix numbers have commas in them ?
<montwi> aren't the bug numbers just an incremental serie ?
<Lo-lan-do> On LP maybe.
<Lo-lan-do> But there are other bug trackers, you know :-)
<kfogel> Okay, opinions: "screen shots" -- one word or two?
<montwi> then make an option --multi-fixes that supports both
<Odd_Bloke> kfogel: One.
<kfogel> Odd_Bloke: ok, sold
 * fullermd was going to say 'two'...
<fullermd> Especially if you're running multi-head, because then you get "screens shot".
<fullermd> And "screensshot" is a bit too Gollum.
<Tak> it's still one logical screen imo
<jam> Tak: it gets a bit weird if you have different sized monitors, though
<Lo-lan-do> Jc2k: __init__() takes exactly 2 arguments (1 given) / Unable to load plugin 'git' from '/home/roland/.bazaar/plugins'
<Lo-lan-do> Jc2k: Does that ring a bell?
<jelmer> Lo-lan-do: you need a newer bzr
<Lo-lan-do> >> 1.11?
<jelmer> yeah
<Lo-lan-do> Um.  I actually have 1.12-1.
<jelmer> Lo-lan-do: what bzr-git do you have?
<jelmer> you might need a newer bzr-git instead :-)
<Lo-lan-do> Straight out from http://bazaar.launchpad.net/%7Ejohncarr/bzr-git/git-serve/ rev "215: John Carr 2009-01-26 Merge upstream"
 * Lo-lan-do tries from trunk
<jelmer> I suspect John may have to merge trunk
<Jc2k> *nod* havent merged in a bit.
<Lo-lan-do> Ah, better.
<Lo-lan-do> Blah.  It seems I need to install the plugin to /usr/local or something, it doesn't seem to find bzrlib.plugins.git.server otherwise.
<Lo-lan-do> Nope.  Not better.
<Lo-lan-do> Ah, installing to /usr works slightly better -- only to stop later by not finding bzrlib.plugins.git.foreign.
<Lo-lan-do> jelmer, Jc2k: http://pastebin.com/d705b5138
<Lo-lan-do> Also http://pastebin.com/d319f3cde :-(
<jelmer> Lo-lan-do: thanks
<Lo-lan-do> Seomething seems to expect normal bzr revids to start with a particular prefix, which they... don't.
<Lo-lan-do> (The bzrtest is a standalone branch of the simplest "bzr init;date>foo;bzr add;bzr commit -mbar" variety)
<jelmer> Lo-lan-do: yes, it only works with revisions pushed from git afaiu
<jelmer> this is the roundtripping I mentioned yesterday
<Lo-lan-do> Oh damn.  I misunderstood that part then.
<Lo-lan-do> So it's currently only usable as a storage backend for git, with read-only for bzr clients?
 * Lo-lan-do ponders
<jelmer> Jc2k: ^
<Jc2k> *nod*
<Jc2k> in theory you can dpush to it..
<Jc2k> :P
<Lo-lan-do> Any clue what I'd need to do to fix that?
<Lo-lan-do> As far as I understood, git revids are hashes of their contents, so presumably they could be computed on the fly, right?
<Jc2k> Lo-lan-do: so consider git ls-remote
<Jc2k> it just lists the tip sha1s of each branch
<Jc2k> to satisfy this on the fly, we not only need to sha the commit, but the inventory and all of the blobs. and not just for the top commit, but *all* parent commits going back to the origin.
<Lo-lan-do> I get the same error.
<Jc2k> of course you do, its just the easy part of git pull
<Jc2k> just saying, you cant do it on the fly, too expensive. we need to build a lookaside cache of sha to bzr rev id
<Lo-lan-do> I guess all that data could be cached, but yeah, I see the problem.
<jelmer> my branch has the beginnings of a cache
<fullermd> That's good.  If it had the end of the cache, you'd already have run out.
 * Lo-lan-do tries following the code
<Tak> what's the bzrlib equivalent of `bzr branch`? Branch.clone?
<mwhudson> Tak: sprout
<Tak> that'll do WT as well when applicable?
<lifeless> Tak: yes
<Tak> cool, thanks
<lifeless> poolie: I still have some symptoms; I am coding ok at the moment, but I'm going to stay fairly submarine today; if I go downhill I'll let you know
<phinze> okay weird lock issue doing a netcat bounce with bzr+ssh
<phinze> is there any way of checking manually for lock data?
<lifeless> phinze: bzr info
<phinze> blank
<phinze> (no locks)
<phinze> hmm oh the lock is actually on the remote branch
<phinze> lemme go there and do it
<lifeless> bzr info <url> should work
<jelmer> moin lifeless
<phinze> yeah because of the bounce the lock-url looks like chroot-3079972620:///path/to/repo/and/branch/.bzr/branch/lock
<mwhudson> ah that bug
<mwhudson> bzr break-lock :push will work, i think
<lifeless> hi jelmer
<ronny> jelmer: can subvertpy tell me infos about moves in the svn workdir?
<phinze> mwhudson: nice! ty
<jelmer> ronny: only about copies
 * phinze is all about breaking locks
<jelmer> lifeless: wrt bug 330928, what do you expect bzr-svn to do differently?
<ubottu> Launchpad bug 330928 in bzr-svn "1.12 bzr help commands failed" [Undecided,New] https://launchpad.net/bugs/330928
<ronny> jelmer: so i'd have to infer moves via copy + remove?
<jelmer> ronny: yeah, although I wouldn't mind seeing a utility function for inferring moves in subvertpy
<montwi> strange problem with merge
<lifeless> jelmer: I thought I put it in the bug: the absence of a dependency shouldn't cause noise on operations that don't need the plugins functionality
<montwi> I upgrade just my own mysql-maria trees to bzr version 1.9; The original on launchpad is the previous versions
<montwi> now I get a lot of conflicts, even on easy stuff when doing a merge
<montwi> The question:  Can one get different merges than before becasue of version 1.9 ?
<lifeless> jelmer: you don't need subvertpy to have a command object with help text :)
<montwi> I mean with with the 1.9 "A branch and pack based repository that uses btree index"
<lifeless> mwhudson: montwi question, oculd that be related to the fixup script?
<montwi> in some cases, I have a conflict but now .BASE file
<mwhudson> lifeless: i'm not completely sure what you mean by "fixup script" but instinct says "no"
<lifeless> mwhudson: didn't you just forward the output of a script run on all the mysql branches?
<phinze> mwhudson: can't seem to find that bug reported -- should i file one for the lock message to suggest break-lock :push?
<mwhudson> lifeless: oh
<mwhudson> lifeless: yes, i guess that is possible
<mwhudson> phinze: it's certainly reported
<lifeless> montwi: no, the 1.9 formats don't change the data model. However a seperate task has been done recently
<mwhudson> phinze: https://bugs.edge.launchpad.net/bzr/+bug/250451
<ubottu> Ubuntu bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed]
<montwi> lifeless: tell me...
<mneptok> oh dear. Monty meets Robert. i'm pretty sure this day is mentioned in Revelations. :)
<mwhudson> montwi: there was a bug in the initial conversion of mysql to bzr
<lifeless> mneptok: we've met before
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/277537
<ubottu> Ubuntu bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Fix released]
 * montwi waits with high antipation for a simple, elegant solution that doesn't require hours of work on my side
<mneptok> lifeless: oh good!
<mwhudson> we recently ran the script to fix the damage to the repositories hosted on launchpad
<jml> lifeless: yeah, I want to review it over the next couple of days
<lifeless> montwi: I would guess that running the fixup script on your copy of any branches is the right answer, but I wasn't personally involved
<mwhudson> vila: hello!
<mwhudson> i didn't think running this script should have had far-reaching consequences though from what i was told
<montwi> so I should revert the merge, run the script and try the merge again ?
<mwhudson> montwi: are you using --weave merges?
<lifeless> montwi: that is my first inclination, yes. vila: or jam: have more detail on the specific issues
<montwi> no, just bzr merge
<mwhudson> then i _think_ it should be something else, 'cause the fix only affects the per-file graph but the merge3merger doesn't look at that afaik
<lifeless> montwi: I'll poke quickly at this; can you run 'bzr revision-info' in both branches(source and target) for the merge
<lifeless> montwi: I'm just steting up a work area now
<montwi> 2674 monty@askmonty.org-20090218144051-xtg0ki3hbhosiqk7
<lifeless> is it lp:mysql-server to get trunk ?
<montwi> sorry, don't have both trees
<lifeless> montwi: that ok, URL for the second is fine
<lifeless> or url's for both
<kirkland> i just did a 'bzr revert', how do i undo the revert?
<montwi> I am basicly doing a merge with the bzr+ssh://bazaar.launchpad.net/~monty/maria/1.5 and the lp:~mysql/mysql-server/mysql-maria trees
<montwi> So I have a copy of the 1.5 tree here and then I did:
<montwi> bzr merge lp:~mysql/mysql-server/mysql-maria
<lifeless> kirkland: you don't? any files reverted are backed up with ~ pattern suffixes
<mwhudson> kirkland: with a nasty shell script probably; revert leaves the changes in *~#~ files
<kirkland> lifeless: okay
<kirkland> better question
<lifeless> kirkland: if you had a pending merge, you can put that back by just doing the merge again
<kirkland> let's say i'm currently on revision 320
<kirkland> i want to prune only revision 315
<montwi> I just got a lot more conflicts that expected and some have looked strange. Unfortunately I resolved a lot before starting to think something is wrong
<kirkland> and leave everything else untouched
<kirkland> what's the best way to do that?
<lifeless> kirkland: 'bzr merge -r 315..314 .'
<montwi> will check if I can find one file that includes not resolved conflicts that should have been resolved
<kirkland> lifeless: brilliant
<kirkland> lifeless: thanks.
<mwhudson> does bzr do any logging setup at import time?
<lifeless> mwhudson: no
<mwhudson> hm
<lifeless> mwhudson: its hard to undo that sort of thing, due to python.logging.sucking.hard
<lifeless> montwi: nearly up to testing
<jam> mwhudson: you can call 'bzrlib.trace.enable_default_logging()"
<poolie1> hello
<jam> hi poolie1
<poolie1> lifeless: ok, take it easy
<mwhudson> jam: yeah, but...
<mwhudson> let me work out what i'm really complaining about first i guess :)
<jam> lifeless: just found something odd with groupcompress
<montwi> lifeless: thanks
<jam> I put together code to support "negative" offsets
<montwi> found one file that shows the strangeness
<jam> so that rather than giving the bytes since-start, you can give bytes before current endpoint
<montwi> lifeless: mysql-test/extra/rpl_tests/rpl_log.test
<jam> the weird thing is that before zlib, it should save something like 44kB
<jam> but *after* zlib, I actually see an increase in size of ~120kB
<montwi> Here the .OTHER and .THIS files are almost identical but the .BASE file is very differnt from either of the files
<montwi> it's almost as it's from and older version
<mwhudson> montwi: ah, maybe you _should_ be using --weave or --lca to merge
<mwhudson> the overall least common ancestor can end up being surprisingly old
<lifeless> jam: interesting; I presume you figured that that will be smaller to encode?
<lifeless> jam: I expect that its larger because bytes-from-start is probably a repeating pattern
<montwi> Shouldn't one normally get the .BASE from the last merge ?
<jam> lifeless: well it is shorter for raw (uncompressed) bytes
<jam> but you're probably right
<jam> anyway, it was worth exploring
<mwhudson> montwi: nope
<mwhudson> well, maybe normally
<jam> I also notice that for the chk invs, we have a trailing "insert" which is always followed by an insert of the final newline
<lifeless> montwi: ok, I get 128 conflicts, so trivially reproduced :)
<mwhudson> anyway, i'll let robert explain with science rather than guessing
<lifeless> montwi: it goes off the top but:
<jam> lifeless: does it give a "criss-cross" warning?
<lifeless> Warning: criss-cross merge encountered.  See bzr help criss-cross.
<lifeless> jam: :)
<jam> hence use --weave
<lifeless> jam: perhaps that should be down the bottom/also at the bottom ?
<montwi> I have already resolved some conflicts, so can I do bzr remerge on the rest ?
<jam> lifeless: we just need to either auto-switch it on
<jam> or use per-file graphs for merge3
<montwi> bzr remerge --weave ?
<jam> montwi: should work
<montwi> thanks; will try
<lifeless> montwi: I think so; I just repeated the merge with --weave, got 40 conflicts
<montwi> ok, down to 41 conflicts, sounds much better
<lifeless> montwi: and mysql-test/extra/rpl_tests/rpl_log.test is not conflicted
<asabil> is there any way to convert a rich-root repo to non rich root ?
<lifeless> asabil: no
<poolie> jelmer, hi
<lifeless> asabil: not in terms of 'downgrade and merge with folk that hadn't upgraded'
<asabil> lifeless: I want to convert a repo completely
<montwi> lifeless: yes, rpl_log.test is ok
<montwi> why is weave not default ?
<asabil> I am the only owner of the repo and related branches
<lifeless> asabil: if you're already on rich root, it should work fine - just stay with that format
<asabil> lifeless: I am trying to write a filter-branch thingie
<Lo-lan-do> I'll ask the recurring question: when's rich-root becoming default?
<asabil> but when I call Tree.revert
<asabil> I hit a ValueError: Cannot have multiple roots.
<asabil> in rich-root repositories
<montwi> lifeless: any obvious reasons why include/maria.h doesn't have a .BASE file ?
<montwi> it's has an OTHER in THIS file
<lifeless> montwi: I don't think --weave generates .BASE files
<lifeless> I may be wrong
<asabil> lifeless: any idea ?
<lifeless> asabil: a bug in your code I suspect
<asabil> lifeless: that's definitely the case, but is there any doc that would help me understanding the issue
<asabil> why the code works with non rich root ? and doesn't with rich root ?
<lifeless> montwi: in fact, maria.h isn't conflicted for me at all
<montwi> strange. I had a conflict
<montwi> trivial conflict to resolve, but still strange that we get different answers
<lifeless> montwi: you remerged after doing some edits
<montwi> but I didn't commit
<montwi> so shouldn't remerge have used the original (kind of reverted) file ?
<lifeless> I'm not 100% sure if it looks at your edits or not
<montwi> just noticed I am using bzr 1.10; Will update to bzr 1.12 at once
<lifeless> its not a command I use much
<lifeless> I used 1.11 in this test
<montwi> lifeless: no problem, the issue is resolved for that file. will see if same things happesn for files I didn't touch before
<lifeless> mtaylor: when are you upgrading your main repos to 1.9 :)
<mtaylor> lifeless: when you say "my main repos" ... are you referring to MySQL
<lifeless> mtaylor: and drizzle, unless its already 1.9
<mtaylor> lifeless: drizzle is on 1.6 ... I just haven't gotten around to 1.9 upgrade yet
<mtaylor> lifeless: I'm pinging chad about 1.9 for mysql
<emile> jam: hi again. I tried a conversion (bzr svn-import subversion bazaar) on another system, and this time the bzr repo was actually smaller than the original svn repo. How can I confirm everything went OK? If I cd into the created directory and do "bzr log", I get: bzr: ERROR: Not a branch: "/home/emile/PW/bazaar/.bzr/branch/"
<jam> emile: the repo isn't a branch. there should be subdirectories which *are* branches, though
<jam> bazaar/trunk
<jam> for example
<emile> Hey ho, and so there is! It's even kept the commit logs! The tags subdir isn't present, however. Not a major biggie, but if it can be preserved...
<jam> emile: "bzr tags -d bazaar/trunk"
<jam> I believe we convert tags as real "tags" and not as directorise
<jam> directories/branches
<emile> awseome. Time for me to start digging through the docs, as you can see I'll have a few svn-isms to shake loose ;)
<montwi> lifeless: did you get a conflict with mysql-test/mysql-test-run.pl
<montwi> this didn't have a .BASE for me either
<lifeless> montwi: not sure, I removed the test area already :(
<lifeless> jam: does --weave output .BASE ?
<montwi> ok, looks like I don't have any .BASE files
<montwi> not good as it makes life harder
<mwhudson> lifeless: i don't think --weave even really has a sane concept of base
<mwhudson> it's not a three way merge
<montwi> merge done, now running test. will push in the morning if test suite goes trough
<montwi> sorry, wrong channel ...
<asabil> does anyone see the problem with this code: http://bazaar.launchpad.net/~asabil/%2Bjunk/bzr-filter-branch/annotate/head%3A/__init__.py ?
<asabil> I get the following traceback: http://pastebin.ca/1341535
#bzr 2009-02-19
<Kobaz> whoops
<Kobaz> i broke bze
<Kobaz> bzr
<Kobaz> http://pastebin.com/m3850ffa2
<spiv> Kobaz: you upgraded bzr, but have an old bzrtools shelf
<spiv> Kobaz: you can use "bzr shelve1"/"bzr unshelve1" to keep using the bzrtools shelf, IIRC.
<Kobaz> oh
<Kobaz> should probably be a warning for that or something
<Kobaz> ii  bzr                                  1.10-1~bazaar1~intrepid1            easy to use distributed version control syst
<Kobaz> ii  bzrtools                             1.10-1~bazaar1~intrepid1            Collection of tools for bzr
<Kobaz> both are the same version
<spiv> Right; what happened was that bzr shelve became part of the core, rather than provided only by a plugin.
<Kobaz> k
<spiv> But the implementation in the core is new and improved compared to the bzrtools one :)
<Kobaz> k
<Kobaz> so how would i use the new one?
<spiv> "bzr shelve", in theory.
<Kobaz> hmm
<Kobaz> but that is what croaked
<spiv> I'm not sure why it's breaking for you, there seems to be a broken shelve file there.
<spiv> My guess is it's a bzrtools shelf, but that's just a guess.
<spiv> I could easily be wrong about that...
<spiv> Please file a bug.  At a minimum it shouldn't give a traceback just because of a damaged file.
<Kobaz> k
<Odd_Bloke> There already exists a bug for that.
<Odd_Bloke> Bug 303569.
<ubottu> Launchpad bug 303569 in bzr "shelving a patch with no new line at end of file fails" [Undecided,Confirmed] https://launchpad.net/bugs/303569
<Odd_Bloke> Kobaz: ^
<lifeless> spiv: ping
<IsoSchiz> Hi, I was wondering if someone could help. I am attempting to create a bzr repository from an svn one. I'm running Intrepid (bzr 1.6.1-1, bzr-svn 0.4.13-2) and used the following command: "bzr svn-import --all --scheme=trunk --prefix=endets/ svn+ssh://<hostname>/var/repository endets". It seems to work initially (build a cache, then 'Importing branches with prefix /endets/', which takes a while), but it appears to stop abruptly a
<lifeless> IsoSchiz: your coment cuts off at 'abruptly a'
<IsoSchiz> Darn it. :-) Ok, after that it goes:
<lifeless> rather ironic I thought
<IsoSchiz> but it appears to stop abruptly and gives the following error when I try to co or branch from it: 'bzr: ERROR: Not a branch: "/home/martin/bzr/endets/.bzr/branch/".' What's gone wrong? :-)
<IsoSchiz> Yes, it is rather..
<lifeless> IsoSchiz: svn-import creates a set of branches
<lifeless> so run 'bzr branches endets' and you should get the relative url of the branches it made
<spiv> lifeless: pong
<IsoSchiz> That gives no output at all...
<lifeless> spiv: I want to chat [irc] briefly about a refactoring
<lifeless> IsoSchiz: so, it sounds like it may have errored/failed - what return code did it give? Is there anything in ~/.bzr.log
<spiv> lifeless: btw, I discovered https://edge.launchpad.net/compiz-colorfilter.  I wonder if it could be used for non-colour-blind people to simulate e.g. red-green blindness?
<IsoSchiz> The svn-import command ends with: 202.125  return code 0 - I haven't checked that's actually the return code though.
<spiv> lifeless: fire away
<lifeless> spiv: ok, so I'm going to tackle the stuff we discussed just-in-time, working on the round trips for that blackbox test
<lifeless> spiv: format.intialize_on_transport() is the code called to make a .bzr dir
<lifeless> spiv: MetaDirFormat is the concrete class used
<lifeless> spiv: so I'm thinking in MDF' initialize_on_transport can do a check to see if there is a remote capable transport
<lifeless> now the question
<lifeless> at this point I could create a RemoteBzrDirFormat and pass on the format details to it
<lifeless> and then call that new instance's initialize_on_transport
<lifeless> or I could do something different
<lifeless> making a RemoteBDF seems appropriate to me
<Odd_Bloke> Should the Windows installers work on 64-bit Windows?
<spiv> Hmm.  So asking a MDF to initialize_on_transport might actually give you a Remote thing instead?
<spiv> That feels a bit weird, but I don't know of anything that would actually break.
<lifeless> spiv: ok
<lifeless> spiv: do you know of a good place to put a test that this happens?
<IsoSchiz> lifeless: Re-ran the import: it returns 0. The log file claims it returns 0, and looks fine otherwise (though I am unsure what to expect). bzr branches gives no output, but returns 0 too.
<lifeless> IsoSchiz: are there any subdirs in the output?
<spiv> Hmm.  I suppose you could put that test in test_remote.  Although I'd probably expect to find it in a test_bzrdir_format module -- if we had one ;)
<IsoSchiz> lifeless: Only the .bzr, which contains branch-format, branch-lock/, README, repository/ and svn-import-revision
<lifeless> spiv: we have that
<lifeless> IsoSchiz: sounds like its not finding any branches to import
<spiv> Well there's TestBzrDirFormat in test_bzrdir, yeah
<lifeless> IsoSchiz: have you tried the simpler 'bzr svn-impoprt svn+ssh://<hostname>/var/repository outputdir'
<spiv> I'd probably lean towards adding it there, I think.
<IsoSchiz> lifeless: I am just trying that now :-)
<IsoSchiz> lifeless: slightly more exciting: bzr branches now prints a blank line. :-)
<IsoSchiz> lifeless: I don't quite understand why it would find *no* branches. Surely at least the trunk would become a branch (even if it doesn't correctly identify the copies in the 'branches' directory as actual branches)?
<lifeless> IsoSchiz: you might like to try bzr-svn 0.5 which has lots of improvements, you need a newer bzr at the same time too
<IsoSchiz> lifeless: Is there a PPA containing these for Intrepid? Or do I need to install manually?
<lifeless> IsoSchiz: yes
<lifeless> IsoSchiz: http://bazaar-vcs.org/Download
<baxissimo> Q about this tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/centralized_workflow.html
<baxissimo> It says create a new branch by first doing "bzr init  REMOTE/newbranch" then "bzr checkout REMOTE/newbranch" locally.
<baxissimo> Seems like it's also legit to do "bzr init LOCAL/newbranch" and later "bzr branch LOCAL/newbranch REMOTE/newbrach"
<bob2> yes
<baxissimo> Sound ok?
<bob2> + bzr bind REMOTE/newbranch
<baxissimo> bob2: Ok, yeh, bind if you want automatic pushes.
<bob2> if you don't do bind, they do NOT do the same thing
<baxissimo> bob2: ok.  I see.
<bob2> but both are reasonable ways to use it
<baxissimo> bob2: and if you don't bind, then "bzr send" will do the equvalent of "hg push"
<baxissimo> bob2: ?   (if you know hg at all...)
<bob2> no idea what hg push does
<bob2> bzr send will generate a bundle (ie patch with metadata) and dump it in a file or open your email client
<baxissimo> It send revisions in the local branch that aren't in the remote branch to the remote branch.
<bob2> bzr push will push changes back to the remote branch
<baxissimo> Ohh.. ok yeh that's the equiv of "hg push"
<baxissimo> bzr send is I guess analogous to "hg bundle", though sounds like it does a bit more.
<baxissimo> hg bundle just doesn't have the --mail-to option.
<baxissimo> bob2: thanks!
<lifeless> spiv: I'm moving the smart call log to TestCaseWithMemoryTranspirt
<IsoSchiz> lifeless: newer versions don't work either. :-( Without the --prefix arg, 'bzr branches' produces blank line; with --prefix gives the error: bzr: ERROR: The specified path is inside a branch. Specify a different URL or a different repository layout.
<spiv> lifeless: +1
<spiv> lifeless: I've been increasingly tempted to add something like "start a smart server backed by self.get_url(...)" to TestCaseWithMemoryTransport too
<lifeless> IsoSchiz: I suggest filing a question on bzr-svn
<IsoSchiz> lifeless: never done that before. Is this some feature of Launchpad? Perhaps the 'Answers' section...?
<IsoSchiz> Ok, worked that out, ignore the last question.
<IsoSchiz> Thanks for your help lifeless.
<lifeless> IsoSchiz: np
<lifeless> spiv: so, its 15 round trips to init a bzr meta dir remotely
<lifeless> spiv: hows the polish on that branch coming
<lifeless> spiv: 15 -> 2 for initialize_on_format
<mwhudson> that sounds like a nice improvement :)
<lifeless> mwhudson: cheap too, server already has the RPC
<lifeless> it's use got lost during stacking cloning behaviour rearrangments
<mwhudson> oh right
<lifeless> bundle sent
<jelmer> lifeless: thanks!
<jelmer> lifeless: you forgot to mention that this also fixes initial push in a format unknown to the remote server
<jelmer> which I think has a bug or two open
<lifeless> jelmer: I don't think it alters that case at all
<jelmer> lifeless: not completely, no
<jelmer> lifeless: but at least you don't end up with a unusable branch on the remote side
<jelmer> oh, you do
<jelmer> it just gives the warning earlier
<jelmer> never mind me
<lifeless> jelmer: :P
<jelmer> I guess I was just too eager to see that bug fixed...
<lifeless> :)
 * igc lunch
<lifeless> so jelmer
<lifeless> if you read my patch, you could bb:approve it :)
<poolie> i'm going to push that EC2 build and its docs along a bit further
<lifeless> 40 calls to do init-repo url
<poolie> down from 100?
<lifeless> no
<lifeless> tested right now as a reasonable component to measure while working on push
<lifeless> spiv: ping; a test for a new verb - its test_remote for the client, test_smart for the request method backend?
<poolie> jam, if you're still up, which i suppose you're not, i'm going to mess with the ec2 machine now
<spiv> lifeless: that's right
<spiv> lifeless: nice results for the RPC count
<spiv> lifeless: I just fired off external_references / scan_unvalidated_index patch.
<lifeless> spiv: ping; it seems really hard to write a test for this using FakeClient, because of all 40 calls I need to emulate for backwards compatibility
<lifeless> spiv: I'd be happier using a hook to capture the calls and assert that it tried a newer one, and worked.
<lifeless> spiv: assuming there is some way to say 'give me a old server'
<lifeless> spiv: -> is there?
<spiv> An old server?  bzr-v2:// ?
<lifeless> let me pastebin my 'old servers work test' one sec
<spiv> (The client code usually knows better than to try new methods if the protocol encoding is only v2)
<spiv> You could also modify the request_handlers dict buried in the server instance somewhere...
<lifeless> spiv: uhm
<lifeless> so I don't really care if its a really-old-server
<lifeless> or just the server-before-I-write-this-method
<lifeless> http://paste.ubuntu.com/119949/
<lifeless> I want to be able to have that be the test
<lifeless> because it seems clear and complete, if we can be sure the server doesn't support the verb
<lifeless> thoughts/suggestions?
<spiv> TestRemotePackRepositoryAutoPack.test_backwards_compatibility does a small monkey-patch to achieve something a bit similar
<spiv> I don't quite follow the intent of that pastebinned test, though.
<spiv> Why is asserting that exactly 1 BzrDir.create_repository call a test that the client is backwards compatible with old servers?
<lifeless> well
<lifeless> we should try the call (most servers will be up to date
<lifeless> and it should still work :)
<lifeless> we shouldn't try more than once
<spiv> Oh, the missing bit of that test as written is the bit that makes that call not exist on the server?
<lifeless> yes
<spiv> If the assertion could be "there's exactly 1 BzrDir.create_repository call, and it got a no-such-method response", that'd be much clearer.
<spiv> But the existing logging doesn't lend itself to that...
<lifeless> does the smart server client hook show the result?
<lifeless> I don't think the precision gained is that important, if we're sure the server can't handle the call
<lifeless> we can test that by calling it directly, if we care
<spiv> It doesn't, but it'd be nice if it did.
<spiv> A brief comment can make it clear enough, we don't have to fall down a rabbit-hole...
<spiv> So I think ideally you'd be able to modify the server in the test to have no implementation for that method.
<spiv> Unfortunately it's a bit hard to get at the relevant commands dict atm, there's a little more refactoring needed to make that possible.
<spiv> You could modify the global request_handlers registry, though.
<lifeless> yeah try:finally for the win
<spiv> Yeah.  Or addCleanup, and hide all the mucking about in a helper.
<lifeless> http://paste.ubuntu.com/119961/
<lifeless> well
<lifeless> one line != mucking aorund
<spiv> I count six, but sure.  The test is readable enough.
<lifeless> spiv: in the finally block, but yeah I see what you mean. Next time, refactor++
 * spiv nods
<stub> I suspect I have a rather unusual problem I want to solve. I have a copy of a CVS tree, and I want to export a single file and its commit history to a bzr branch.
<stub> Is there any tool available that will import a single RCS style ,v file? I think it contains everything that is needed.
<lifeless> spiv: test_smart vs test_smart_request
<lifeless> spiv: the former has everything in it I'd expect to be in the latter
<lifeless> stub: take a full copy of the CVS tree. delete everything in the module the ,v file is in except the ,v file, and move it to the top of the module
<lifeless> stub: then use any CVS history importer (such as cvs-fastexport or cscvs or cvsps-import)
<spiv> lifeless: yeah, I can see that. And what's in test_smart_request could stand to be split up a bit too I think.
<lifeless> spiv: so I'm going to add to test_smart
<lifeless> spiv: because that has the test for FindRepository
<lifeless> spiv: also, exception handling
 * spiv nods
<lifeless> you've been improving that, how should I handle the main failures (no bzr dir present, repository already present)
<lifeless> or is it still just return an error with a custom string?
<stub> lifeless: Just trying that :-) Got to the point where cvsps-import is spitting out horrible errors, possibly due to me running 1.12? AttributeError: 'MinimalTree' object has no attribute 'get_file_with_stat'
<lifeless> stub: yes, seems like a version skew issue
<lifeless> spiv: so errors?
<spiv> lifeless: errors?
<lifeless> 16:33 < lifeless> spiv: also, exception handling
<lifeless> 16:33  * spiv nods
<lifeless> 16:34 < lifeless> you've been improving that, how should I handle the main failures (no bzr dir present, repository already present)
<lifeless> 16:34 < lifeless> or is it still just return an error with a custom string?
<spiv> Oh, I totally failed to read a couple of lines of IRC.
<spiv> lifeless: the currently defined errors can all be seen in the function at the bottom of bzrlib/remote.py
<spiv> lifeless: no bzr dir present should be 'nobranch' on the wire IIRC, which mirrors the confusing NotBranchError that bzrlib gives.
<spiv> lifeless: I don't think there's an appropriate error for repository already present.
<lifeless> I'll skip that case until it turns up then :P
<spiv> :)
<vila> hi all
 * fullermd waves vila around a bit.
<poolie> hi vila
<vila> I'm sure that will make for a good quote but I can't find the right title :-)
<lifeless> spiv: success
<lifeless> I'm really slow today :( cotton wool in the head
<lifeless> but its done
<lifeless> 19 rpc's less
<jfroy> so huh
<jfroy> is there a fast-import importer for Subversion that does support branches and tags and such trivial things :|
<Peng_> jfroy: Does it have to be fast-import, or would bzr-svn work?
<jfroy> I want to move away from svn
<jfroy> completely and for ever
<Peng_> Sounds good.
<jfroy> I guess I could force people to use rich roots.
<jfroy> (for the particular project in question)
<jfroy> But it felt that fast-import was a better fit than bzr-svn for the task of permanently migrating a set of branches.
<Peng_> Shrug. bzr-svn can do it. It doesn't stop you from moving away from svn forever.
<lifeless> spiv: bombs away
<lifeless> jfroy: svn-import is the recommended migration tool :)
<lifeless> jfroy: if you feel strongly about rich roots you could regenerate the output via fast-export | fast-import, but I wouldn't bother.
<jfroy> I don't actually know what rich roots are :p
<jfroy> Beyond the concern of carrying extra data for no reason.
<lifeless> its essential data we left out of the early formats
<lifeless> going to extra effort not to have it would be... counterproductive
<jfroy> "--standalone      Create standalone branches." <-- huh
<jfroy> lifeless: if it's essential, why is there still a distinction in the newer formats, e.g. 1.9 versus 1.9-rich-roots
<Peng_> jfroy: Because converting is slightly inconvenient, so it hasn't been forced on users yet.
<lifeless> it takes time and effort to convert; data discrepancies can show up so care needs to be taken; abentley is going to work on the overall thing soon I believe
<Peng_> "data discrepancies"?
<jfroy> I see
<lifeless> Peng_: parent mismatches mainly
<Peng_> You mean it exposes standard "bzr check/reconcile" stuff, or *causes* problems?
<lifeless> Peng_: exposes
<Peng_> Okay.
<lifeless> Peng_: unchecked branches don't always convert completely 100%, even though they should
<lifeless> we're regenerating all the inventories after all
<Peng_> That sounds ominious.
<lifeless> spiv: if you're still doing stuff, network_name could use a review, as could BzrDir.create_repository RPC verb
<poolie> bug 331416 sucks a bit
<ubottu> Launchpad bug 331416 in gdm "gdm fails with "the greeter application appears to be crashing" after upgrading to jaunty" [Undecided,New] https://launchpad.net/bugs/331416
<mae^> ohnoes! you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
<mae^> i did a push that timed out, now I'm getting that error
<lifeless> spiv: also I can't see the patch you said you sent in
<lifeless> mae^: right, do what it says :)
<mae^> what target directory? I'm trying to push to launchpad.
<lifeless> got to launchpad, there is a 'delete branch' button on your branch
<mae^> hmm.. what if someone else has made changes to the branch that I dont have locally? tough luck?
<Peng_> If it has no branch or repository, what changes could it be storing?
<mae^> oh, I found it .. the branch location changed when I changed the branch ownership
<mae^> thx
<beuno> poolie, what do you think about adding a space next to the semicolon on the progress bars?
<beuno> "Build phase: Adding file contents" instead of "Build phase:Adding file contents"
<lifeless> beuno: patches :)
<beuno> lifeless, of course. Just wanted to get extra agreement nods  :)
<asabil> hi all
<asabil> does anyone see the problem with this code: http://bazaar.launchpad.net/~asabil/%2Bjunk/bzr-filter-branch/annotate/head%3A/__init__.py ?
<asabil> I get the following traceback: http://pastebin.ca/1341535
<asabil> only when using the plugin inside a rich-root repository
<Mez> jelmer: using bzr-svn can I just import it to bzr and then "forget" that it was part of svn?
<Lo-lan-do> Mez: Yes.
<Mez> how ?
<Lo-lan-do> rm -r $svn_repo :-)
<Mez> Lo-lan-do: but surely bzr will still think "oh, I'm parented to $SVN_REPO"
<Lo-lan-do> Depends on how you did the import.
<Peng_> Mez: "bzr pull --remember", then?
<Mez> branched svn, so I can keep the history
<Lo-lan-do> If you ran "bzr checkout svn+ssh://...", then "bzr unbind" will unbind.
<Lo-lan-do> If you ran "bzr branch svn+ssh://...", then you're not bound.
<Lo-lan-do> bzr remembers the SVN URL as the parent location for subsequent pulls and merges, but that's about it.
<Lo-lan-do> You can remove the parent_location from .bzr/branch/branch.conf if you don't like to see it in "bzr info".
<beuno> statik, has your cron for updating bzr nightly gone to sleep and not woken up again?
<beuno> vila, why is bug 331288 incomplete?
<ubottu> Launchpad bug 331288 in bzr "Push should have an option to not stack" [Undecided,Incomplete] https://launchpad.net/bugs/331288
<vila> Because I didn't have time to test that it already works and I thought the bug reporter may do that :-)
<vila> beuno: well to test *again* should I say, because I indeed tested it days ago, but was in a hurry and didn't check all the things I should have checked :)
<beuno> vila, so maybe add a comment?  I'm sure jml will cry if he sees that you think he is incomplete
<vila> by marking it incomplete, I know either jml will come back after testing or *I* will get more time to test it properly
<vila> beuno: huh ? I added a comment saying it should work by using '--no-stacked' instead of '--not-stacked'
<vila> I sure remember having used --no-stacked
<beuno> vila, ah, I did not see that
<beuno> ignore me
<vila> beuno: Argh ! I hate that bug in launchpad: start typing a new comment, realize you should change the status or something, do that, watch your comment vanish :(
<vila> beuno: comment added again
<beuno> vila, that will be fixed soon-ish
<beuno> in an ajax-y kind of way
<vila> beuno: good :)
<vila> beuno: so you know about the problem already ?
<beuno> vila, yes, it's happened to me a few times as well
<asabil> anyone ?
<domas> hi! how to make 'bzr log' faster? it takes >24 hours on quite powerful machine
 * Lo-lan-do suddenly feels *his* performance problems are not that bad after all
<beuno> uhm
<lifeless> domas: wow, it shouldn't be *that* slow
<beuno> 24 hours seems a bit much
<beuno> domas, what version of bzr is that using?
<lifeless> domas: are you running log on a particular file, with -v, or just 'bzr log' ?
<luks> it's aliased to log -v, I bet
<domas> beuno: any, 1.12
<domas> lifeless: 'bzr log -v' on whole tree
<domas> it allocates ~800MB of memory
<domas> and oprofile says it is walking dictionaries all the time
<lifeless> domas: its a known limit of bzr, it has to do a whole diff on every step in the log output; we're fixing it
<domas> lifeless: I'd be happy to betatest :)
<domas> any kind of caching, etc :)
<lifeless> domas: there is an alpha quality branch at the moment, lp:~bzr/bzr/brisbane-core, where we are assembling the fix
<domas> lifeless: interesting, thanks!
<lifeless> domas: we need better disk data structures though; so there is a [somewhat costly] conversion to do to test
<domas> would that take 24 hours? :)
<lifeless> domas: there's also discussion on the list, and on the Roadmap page
<lifeless> domas: I don't know how long it will take on your repo; if its huge or very deep history it could take a while; but I would expect a matter of hours not days
<lifeless> we're only starting to optimise the conversion logic
<domas> I was tempted to start hacking bzr too
<lifeless> domas: I guess i'm saying - please do track this. We're planning a beta quality release for this in March
<domas> it was spending way more time in walking than calculating
<domas> lifeless: thanks, subscribed ;-)
<lifeless> cool
<lifeless> night everyone
<domas> lifeless: I'm playing with opengrok
<domas> it is awesome :)
<domas> it has bzr integration, but thats too slow on big trees
<ronny> opengrok?
<domas> http://dammit.lt:8180/source/xref/mysql-5.1.31/sql/
<domas> it is source repository browser with indexing
<domas> think, lxr on steroids
<ronny> hmm
<ronny> that reminds me how far i will have to go with anyvc if i want to make it neat
<vila> jam: ping
<jam> morning vila
<vila> morning :)
<vila> I'm trying to fix test_autopack_rpc_is_used_when_using_hpss failing for dev5 formats
<vila> It turns out we don't use hpss because InterPackToRemotePack rules out the specific autopack
<vila> Fixing that reveals that we don't have the right Packer
<vila> Which in turn can't be easily fixed because of our design
<ronny> jelmer: sup? whats missing in dulwich to give status info about the index/the workdir?
<vila> jam: because Packer is the root of two class hierarchies: one for the format one for some features (like reconcile)
<jam> vila: are you talking about for GC repos, or for chk repos?
<jam> AIUI chk repos use the same Packer
<vila> I need CHKReconcilePacker._process_inventory_lines ... somwehere it can't be accessed
<ronny> jelmer: btw, any chance to move dulwich to a bsd style license?
<vila> jam: hmm, I'm wrong, Packer doesn't define a hierarchy for formats, yey, I need to override Packer._process_inventory_lines without using a ReconcilePacker...
<jam> So... to start with, I wasn't sure where to push in the autopack RPC, which is why I left that test alone :)
<jam> I don't quite understand why to get autopack working, you need _process_inventory_lines ?
<vila> jam: let's rollback
<jam> As for stuff like "Packer", it would be reasonable to define class attributes
<jelmer> ronny: hi
<jam> So PackRepository._packer_class = Packer
<jam> CHKPackRepository._packer_class = CHKPacker
<jam> etc
<jelmer> ronny: We'll be merging some stuff from pyrite soon, that should include an index parser
<jam> or possible a registry
<ronny> jelmer: an api that compares to bzr's WorkingTree.iter_changes would be nice
<vila> InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo supports_chks
<vila> InterPackToRemotePack rules out using InterPackToRemotePack if any of the repo *doesn't* supports_chks
<vila> jam: see InterPackToRemotePack.is_compatible in repository.py
<vila> That seems wrong if both repo supports_chk, so I fixed that but then it fails because Packer._process_inventory_lines calls repo._find_file_ids_from_xml_inventory_lines
<jelmer> ronny: wrt BSD licensing; there would have to be a very good reason, such as another Open Source project that is definitely going to use Dulwich but is blocked by the licensing
<ronny> jelmer: at least lgpl?
<vila> jam: but ReconcilePacker._process_inventory_lines adresses precisely that
<vila> jam: is that clearer ?
<vila> jam: and do you agree about InterPackToRemotePack.is_compatible ?
<ronny> jelmer: since my encounter of not being able to combine different things cause one was glp2 only and the other was gpl3 only im not exactly accepting gpl any more
<jelmer> ronny: dulwich is GPLv2+ at the moment
<jam> vila:  think you were right in your first statement. InterPackToRemotePack rules out if any repo *does* support chks
<jam> Second, I don't really think we want to switch to using Packer based fetch
<jam> I'm pretty sure we are trying to get away from that
<jam> into the insert_record_stream(get_record_stream()) based APIs
<jam> So IMO, the real fix is to help insert_record_stream() && commit_write_group() trigger a remote autopack()
<jam> rather than trying to get it to use InterPackRepo code.
<jam> vila: does that make sense?
<vila> jam: At the highest level yes. Concretely it means I will push making that test pass lower in my task list and fix simpler ones first :)
<vila> time to shelf debug statements :)
<vila> jam: hmm, not yet, I should first understand where the insert_record_stream route will start
<vila> s/will start/should start/
<jelmer> ronny: I wouldn't be opposed to LGPL, but there would have to be a good enough reason and of course everybody else involved would have to be ok with relicensing as well
<ronny> hmk
<jam> vila: also note that Robert and Andrew are working on a new fetch command
<jam> which also should be preferred to Packer based work
<jam> and deals with Remote calls
<jam> as there is some overlap here, I agree that we should wait
<jam> if you *want* turn those into KnownFailure
<jam> with a  comment like
<vila> jam: reason enough to wait ? Or can you point
<jam> "Remote autopack calls is being postponed for improved fetching"
<vila> lol, s/RETURN/DELETE/ :)
<vila> jam: deal, I'll do that
<beuno> statik, has your cron for updating bzr nightly gone to sleep and not woken up again?
<statik> beuno: oh my i hope not.
 * statik looks
<statik> beuno: they are confused with this error: bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
 * statik upgrades bzr on the build machine
<beuno> statik, ah! the build machine doesn't install it's own versions?  :)
<statik> beuno: all fixed, and new packages are churning in the PPA now. thanks for letting me know it was stalled!
<beuno> statik, awesome, thanks for keeping this rolling, it's very useful to dogfood this stuff
<statik> np, i'm happy to be able to help the project in a small way
<vila> jam: in bzrdir.py we replaced bzrlib.workingtree_4.WorkingTreeFormat4 by bzrlib.workingtree.WorkingTreeFormat4. Is there  a resaon for not doing the same for bzrlib.workingtree_4.WorkingTreeFormat5 ?
<jam> no
<jam> we should use the workingtree.XXX ones
<vila> ok, will fix it in bzr.dev then
<vila> jam: already fixed there by.... you :)
<jam> yep, I thought so
<asabil> anyone to help out with the multiple root issue ?
<jam> statik: i'm gettting "build failures" fo rthe ~bzr-nightly-ppa
<jam> do you know why?
<statik> jam: i don't, i just fixed the system to start uploading daily builds again a couple hours ago (it was failing due to an old version of bzr on the build machine not understanding the branch format).
<statik> jam: i'll try to take a look today and see what is failing
<mwhudson> beuno: thanks for the LH reviews :)
<beuno> mwhudson, I tried to eat through as much LH as I could. Not sure if I managed or not.
<mwhudson> did you manage to try the diff js goo in IE?
<beuno> no, I'm in Berlin still
<beuno> and not back home til next week
<beuno> where I have all the evil stuff like windows machines
<mwhudson> ok
<mwhudson> i'll merge anyway i think :)
<beuno> yeah, we can fix it later on
<vila> jam: nearly off for the day, I pushed revno 3832 to bbc, the test suite is passing except for 1 failure and 4 errors
<vila> jam: 2 errors being AttributeError: 'CHKInventory' object has no attribute 'apply_delta' coming from bzrlib.tests.test_repository.TestDevelopment5FindRevisionOutsideSet, so dev5 specific
<mwhudson> hm
<mwhudson> i'
<mwhudson> i'm not sure i like the level of deviousness you can use in css
<mwhudson> all too tempting :)
<vila> mwhudson: Just do as you I feel, you will regret it anyway :)
<vila> mwhudson: Just do as you feel, you will regret it anyway :)
<vila> and one more joke ruined by a typo :)
<mwhudson> heh
<mwhudson> beuno: got time to give a visual opinion on coloring line numbers?
<beuno> mwhudson, I hear we will eventually get a full blown operating system made in css
<beuno> sure, shoot
<mwhudson> beuno: :)
<mwhudson> beuno: wondering what colour the indicated "cells" should be http://people.ubuntu.com/~mwh/ss.png
<beuno> mwhudson, one line is for removes
<beuno> and the other for adds, right?
<beuno> ah
<mwhudson> yes
<beuno> ok
<beuno> so
<beuno> how about a lighter tone of red, and a lighter tone of green?
<mwhudson> hm, that probably works
<Lo-lan-do> Maybe do both cells as light red and both cells as light green?
<Lo-lan-do> (Yay bikeshedding)
<mwhudson> beuno: try lp:~mwhudson/loggerhead/unified-by-default-sbs-by-ajax rev 287
<beuno> mwhudson, I like it!
<mwhudson> beuno: cool
<mwhudson> i replied to your review, but i think i'm going to merge the branch now
<beuno> mwhudson, sure, I'll reply back, but as I said, it's in a good state to land
<mwhudson> cool
<mwhudson> beuno: i spent most of yesterday when i wasn't being the CHR dude trying to move away from mootools, btw
<beuno> mwhudson, oh, that sounds like a fantastic thing to do
<beuno> the slider animations are going to be a PITA
<mwhudson> yeah, the animations are just commented out at the moment
<mwhudson> there seem to be totally weird ass interactions between window.addEvenHandler (mootools) and Y.on() (yui) wrt domready :/
<mwhudson> beuno: oh right, something I meant to ask
<mwhudson> beuno: i don't really understand how to spread code between different js files but have them share a Y object
<statik> jam: the nightly build seems to be failing because it's trying to use python2.6. Any idea why? http://launchpadlibrarian.net/22882024/buildlog_ubuntu-jaunty-i386.bzr_1.13~bzr9.04-4020-1_FAILEDTOBUILD.txt.gz
<statik> jam: I'm building the source packages on a hardy machine, definitely don't have any python2.6 there
<jam> statik: I don't know. Is python2.6 the default python on jaunty ?
<jam> That said, we *should* support python2.6
<jam> as vila works hard to ensure compatibility
<mwhudson> i think jaunty might *only* have 2.6...
<statik> jam: no, it's not even available in jaunty. yeah, things should absolutely run with python2.6, but the problem is that it's not installed in the chroot in the buildd
<jam> I see what you mean, though:
<jam> cd . && python2.6 setup.py build --build-base="/build/buildd/bzr-1.13~bzr9.04-4020/./build" --executable "/usr/bin/python" /bin/sh: python2.6: not found make: *** [python-build-stamp-2.6] Error 127 dpkg-buildpackage: failure: debian/rules build gave error exit status 2
<statik> xactly
<beuno> mwhudson, I've been trying to get that sliding animation to work in lzr-js. Will let you know if I do.
<jam> that is part of "update-config"
<jam> can you check your packaging branch?
<statik> sure, will have a look now
<jam> It at least seems to be generated from "debian/rules"
<beuno> mwhudson, as to sharing a Y object among different files...  it sounds tricky
<jam> And it is possible that the latest version from jelmer (for debian) uses python2.6
<statik> thats probably what it is
<jelmer> jam: debian doesn't have python2.6 yet :-)
<statik> jelmer: yeah, i'm stumped where this reference to 2.6 is coming from
<jam> statik: It sure looks like it is something with the build daemons themselves
<jam> the first thing it does is:
<jam> dh_clean  cd . && python2.6 setup.py clean -a /bin/sh: python2.6: not found make: [python-clean-2.6] Error 127 (ignored) cd . && python setup.py clean -a
<jam> statik: I'm also seeing a problem with "Pyrex" not being found
<jam> which would also be sort of a bad thing for the final built versions
<jam> since they don't have the .c extensions
<jam> I suppose we are a bit stuck....
<statik> jam: yeah, the packaging doesn't Build-Depends on python-pryex
<jam> we don't really want to depend on Pyrex for the final build, because we put the .c files in the tarballs
<jam> but for intermediate ones
<jam> we don't bother
<jelmer> statik: if you have 2.6 it might be trying it if it is thre defualt python
<jelmer> statik: we just define that we support all pythons since 2.4
<statik> jelmer: i don't, thats the weird thing. I'm building a source package on hardy, and uploading it to a jaunty PPA on launchpad
<statik> and python2.6 is nowhere in sight
<jelmer> statik: strange indeed :-/
<james_w> one thing is that it lists python2.4-dev, python2.5-dev when python-all-dev is probably a good idea
<james_w> it may be that it got caught in the middle when python2.6 was only partly default
<jelmer> james_w: ah, good point
<jelmer> james_w: strange, it's fine in the version in Debian
<ronny> lifeless: any plans to have signed tags? (something like git's tag object)
<jelmer> ronny: fwiw, there are already signed revisions
<ronny> jelmer: yeah, but not tags
<ronny> hmm
<ronny> time to add push/pull support to anyvc
<mwhudson> hm
<mwhudson> bzr search -s just broke on me
<mwhudson> oh, my bzr-search was way out of date
<lifeless> ronny: I thought gits tag object was just a blob/commit - I didn't see a special object type for it
<lifeless> asabil: I don't hink anyone trivially knows
<ronny> lifeless: its an own object type
<lifeless> asabil: I know I probably need to jump into a debugger to figure it out
<ronny> they have blob, tree, commit, tag
<lifeless> asabil: perhaps mail the list?
<ronny> tags can be put on any objects
<lifeless> ronny: ok
<ronny> (ie also blobs/trees)
<Obmar> Hi there, hopefully I am not asking a question that has been asked 1000 times before, but here goes.  I have bzr on my local computer.  I have init the project, add the files, commit the project.  Now I am trying to merge it to a centralized copy.  I have bind and merge and commit, but the files are not on the server.  The .bzr folder is there, and it says everything is fine, but the actual source code files are not in the folder.  What could I possibly be doin
<garyvdm> Obmar: 1. did you push to the central server?
<Obmar> Yes.
<Obmar> This is to a ftp://... if that makes any difference.
<RAOF> Obmar: bzr doesn't update the working tree when pushing.  This is what you're seeing.
<garyvdm> Obmar: 2. When you push to a remote protocal - it does not update the working tree.
<Obmar> The project folder did not exist before, but it was created, along with the .bzr subfolder.
<garyvdm> Obmar: Is this for a website?
<Obmar> So... maybe I am confused, how do I get it to update the working tree on the server?
<ronny> Obmar: all the history is within the bzr folder
<Obmar> garyvdm: No.
<ronny> Obmar: is this for some software on the server, or do you just need a repository there?
<Obmar> Just the repository.
<ronny> Obmar: if all you want to do is keep the history there, then you dont need to update on the server-side
<Obmar> But I develop on serveral different computers.
<Obmar> I need all the files and the history there.
<ronny> Obmar: you dont need a workingtree on the server, only the .bzr folder with the history
<Obmar> So when I go to a new computer, how will I work on the code?
<ronny> or is this an actual software that has to run on the server?
<ronny> Obmar: you pull the history
<Obmar> No, it does not run on the server.
<ronny> Obmar: the history implies the files
<Obmar> Are they in that subfolder somewhere then?
<Obmar> the .bzr folder I mean?
<ronny> Obmar: the history is in the .bzr dir
<Obmar> Ah, so it is not going to look like my local copy.
<Obmar> Since I have .bzr, src/, build, etc...
<Obmar> But I only see .bzr on the server copy.
<ronny> Obmar: on your local copy you have a branch with a working directory, on the server you only need the branch, not the working directory
<Obmar> Ok, I think I follow.
<Obmar> So the files are safely up there then.
<Obmar> I was getting a bit worried.
<Obmar> So when I do a pull on a different computer, I will get a working directory there?
<ronny> yes
<Obmar> Ah ha.  That is what I was missing.
<Obmar> So I was doing it right.  Just missed a concept.
<Obmar> Ok, second question, only sort of related.  I am using Eclipse, and I have the bzr plugin installed, but the only options under the team menu is Apply Patch and Disconnect.  All the other options are disabled (greyed out)
<ronny> no idea about eclispe
<Obmar> lol
<Obmar> Hopefully somebody does.
<ronny> i avoid it as its mostly wasting my ram and cpu time
<ronny> same goes for netbeans and other fscking big & laggy ide's
<Obmar> It is big.  Agreed.
<Obmar> It is what I hae for now.
<Obmar> It would be nice if I could get the bzr integration working though.
<lifeless> Obmar: did you follow the bzr eclipse faq?
<Obmar> Yes, as best as a could.
<Obmar> It is installed.
<Obmar> And the init command works.
<Obmar> The rest are disabled though.
<ronny> hmm
<lifeless> verterok: ^
<lifeless> Obmar: verterok is the author
<Obmar> verterok:  Any ideas?
<Obmar> So... on question 1...  I have a local repository..  the best path to "upload" that to the server is... push/bind/commit?
<Obmar> I mean, is that the right order?
<ronny> Obmar: if you bind, it will imply that each commit is pushed, thats nice for working on more than one computer, but not so nice if you want to work as interuption-free as possible
<ronny> lifeless: btw - i think i need bzr at least twice as fast as its currently
<Obmar> I like the bind idea, for me at least.  I am on fast links between all the locations.
<ronny> Obmar: ah, ok
<Obmar> One less thing to worry about.
<poolie> hello all
<Obmar> I just have to update...work...commit
<Obmar> I think that is all I have to do, if I understand the docs correctly.
<ronny> Obmar: im not fluent on the bind workflow, im on slow links/disconnected often
<lifeless> ronny: ok
<lifeless> ronny: we're working on that :P
<spiv> lifeless: gar, I screwed up my from address when sending a patch yesterday, re-sent.
<igc> morning
<poolie> hello igc
<poolie> today is going to be a good day for you :)
<poolie> i have a big block in my diary for content flittering
<lifeless> spiv: ah :P
<verterok> lifeless: thanks & hi
<verterok> Obmar: hi
<verterok> Obmar: could you check if there are errors in the error log view?
<verterok> Obmar: or in $WORKSPACE/.metadata/.log, related to bzr-eclipse?
<Obmar> verterok: http://pastebin.com/m6b21c84d
<Obmar> Looks like it
<igc> hi poolie. Time for a review today? :-)
<poolie> exactly
<poolie> see above
<verterok> Obmar: what version of xmloutput have you installed?
<verterok> Obmar: let me guess: bzr 1.12 and bzr-xmloutput <= 0.8.2?
<Obmar> Not sure how to tell.
<Obmar> verterok: Genius.
<Obmar> I didnt know which one.
<Obmar> So I went and got the latest.
<Obmar> All the menu options lit right up.
<Obmar> Thank you.
<verterok> Obmar: no problem, glad to help
 * verterok back to the sprint, bbl
<Obmar> verterok: Still here?
<Obmar> verterok: Trying to authenticate against FTP.
<Obmar> verterok: Nevermind just saw the limitations part of the site.
<lifeless> spiv: with patch please :)
<asabil> lifeless: ok thanks, I just sent a mail to the ML
<lifeless> spiv: reviewed; needs a little work
<lifeless> spiv: I forgot a vote line - bb:tweak
<jml> :(
<lifeless> jam: ping; like to high bandwidth discuss network_name
<jml> I'm pushing up a stacked branch to Launchpad, one that's already been pushed, and it is still pushing after ~40mins
<lifeless> jml: anything in the log?
<jml> yeah.
<lifeless> are you sure its stacked?
<jml> It was, at least: https://code.edge.launchpad.net/~jml/launchpad/cloud-style-changes
<lifeless> jml: 'bzr info lp:~jml/launchpad/cloud-style-changes' should tell you
<jml> lifeless: the Launchpad page I referred you to does basically the same thing :)
<jml> but still
<jml>      stacked on: /~launchpad-pqm/launchpad/devel
<poolie> jam, thanks for your comments on the EC2 thing.  i replied - how does that idea suit you of just leaving it up?
<jml> lifeless: https://pastebin.canonical.com/14025/
<jml> lifeless: the logs are filled with variations on that.
<lifeless> jml: its probing for a tonne of revisions it doesn't have
<jml> lifeless: what's causing that?
<jml> and what do I do about it?
<lifeless> jml: I don't know and let it run
<lifeless> file a bug afterwards with the log (trimmed to elide the repeated sections in the middle)
<poolie> igc, could you see today or soon about updating orcadas to run more benchmarks, including if possible the network ones?
<poolie> there should now be scripts there that let us turn on the slow network
<jml> HPSS calls: 7898 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x29a7b50> :)
<jml> it just finished then.
<spiv> walk_to_common_revisions is the usual problem.
<lifeless> I've 3 branches pending, all approved except the bottom one (network-names)
<lifeless> I get the feeling jam is done for the day, he commented - if someone could review and read our thread that would be great
<jelmer> lifeless: fwiw I'm happy to review some of the smart server stuff
<lifeless> jelmer: anytime :)
<jml> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/331823 fwiw
<ubottu> Ubuntu bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Undecided,New]
<lifeless> jelmer: the Repository.initialize branch probably addresses some of your 'getting branches we can't use' issues
<jelmer> lifeless: ok, I'll have a look
<igc> poolie: I'd like to leave that to Monday if I can - knee deep in code today that I need to get running before the weekend
<lifeless> jelmer: the network-name one is the only currently unapproved one
<lifeless> ok, running a full regression and getting food concurrently
<igc> poolie: as then I can run some big imports on the weekend
<jelmer> lifeless: I don't feel comfortable enough with that code to do review
<lifeless> jelmer: ok
<lifeless> jelmer: given all the work you do with custom formats I'm surprised though :)
<poolie> igc, ok makes sense
<jelmer> lifeless: that bit isn't the problem :-) It's more the smart server side of things
<lifeless> network-name doesn't touch the smart server
 * igc breakfast
<jelmer> lifeless: The code seems ok, the problem is the rationale behind the change
<jelmer> lifeless: In particular, you seem to make it possible to have streams that are not necessarily tied to a particular bzrdir format
<jelmer> lifeless: and potentially having multiple repository formats returning the same string
<jelmer> lifeless: wouldn't you just want a different format object for the stream ?
<lifeless> jelmer: they are tied to a particular repository format
<lifeless> jelmer: bzrdir formats are not particularly useful for the metadir set of flavours
<lifeless> jelmer: its a registry, so we have the registry uniqueness guarantee (and repositories *could* claim to be a byte-compatible format for compatibility, on the wire)
<lifeless> jelmer: so consider knits - the record_stream from knits, pack-0.92 are identical
<lifeless> from pack-1.6 and pack-1.9 they are identical too
<lifeless> the different between knits, pack-0.92 and pack-1.6,pack-1.9 is that the latter may generate different parents for file texts during reconcile, but for network streams all four will be identical - same serialisers
<lifeless> jelmer: so the goal is to be able to reconstitute a RepositoryFormat object in the smart server, to handle the stream even though we don't have the source repository available
<lifeless> brb
#bzr 2009-02-20
<lifeless> I really want a 'bzr edit-diff' which gives me the diff, lets me edit it, then saves the result back
<verterok> Obmar: yes, that's an ugly bug, need to get some time and fix it
<Obmar> verterok: That would be great.  I would love to be able to do bzr from in the IDE.
<lifeless> spiv: ping
<lifeless> spiv: the _commit_write_group check; I think that that may be better on the RepositoryPackCollection level ?
<spiv> lifeless: rather than on the KnitPackRepository?
<spiv> lifeless: sure, I essentially flipped a mental coin when deciding where to place that.
<lifeless> I've moved it down
<lifeless>     def _commit_write_group(self):
<lifeless>         all_missing = set()
<lifeless>         for prefix, versioned_file in (
<lifeless>                 ('revisions', self.repo.revisions),
<lifeless>                 ('inventories', self.repo.inventories),
<lifeless>                 ('texts', self.repo.texts),
<lifeless>                 ('signatures', self.repo.signatures),
<lifeless>                 ):
<lifeless>             # We use KnitVersionedFiles exclusively so can rely on _index.
<lifeless>             missing = versioned_file._index.get_missing_compression_parents()
<lifeless>             all_missing.update([(prefix,) + key for key in missing])
<lifeless>         if all_missing:
<lifeless>             raise errors.BzrCheckError(
<lifeless>                 "Repository %s has missing compression parent(s) %r "
<lifeless>                  % (self, sorted(all_missing)))
<lifeless> ^ ok ?
<lifeless> self.repo at the end obviosuly
<spiv> Looks ok.
<lifeless> spiv: ok, that branch is on its way to pqm
<lifeless> where is the next one?
<lifeless> spiv: ping
<poolie> (some people at) nasa \heart bzr
<poolie> yay
<lifeless> nice
<spiv> lifeless: tests all passing now I think; just removing a cruft
<lifeless> beuno: http://blog.crisp.se/davidbarnholdt/2009/02/18/1234986060000.html really is nice
<lifeless> spiv: well the scan api is gold
<lifeless> spiv: I'd like to take the next lowest layer on, or ?...?
<spiv> lifeless: I think I've removed the worst of the cruft now
<spiv> lifeless: I still haven't added a flag to add_records, but otherwise I'm happy with this
<spiv> lifeless: I'm pushing it up to lp:~spiv/bzr/missing-parents-integration
<lifeless> spiv: k, give me a shout when its done
<lifeless> spiv: also, have you had a chance to review network-name?
<lifeless> spiv: if not thats fine, I might interrupt poolie
<lifeless> who has the context for this
<spiv> lifeless: I haven't, but now is a good time for me to do so
<spiv> lifeless: reviewed, one typo found :)
<lifeless> spiv: bombs away
<lifeless> decided against a comment, because of too much duplication
 * spiv nods
<poolie> lifeless: nice drawings :)
<lifeless> spiv: so, I'll review this branch; make any changes i need, and you ack the changes?
<spiv> lifeless: +1
<lifeless> spiv: looking at it, it seems easier to put back the older buffer code, and just make a single call at the end with the new flag, to add_records
<lifeless> spiv: sound ok?
<spiv> lifeless: yep
<spiv> lifeless: having a single call to add_records would be more clearly correct, I think.  Less room for accidental double-insertion.
<spiv> (Which is a bug I noticed I had during our phone chat this morning...)
 * spiv -> lunch
<poolie> lifeless: ping for a quick question
<poolie> i'm just looking at mark's vcsrace on status
<poolie> the results are generally really good except for status which spends a considerable amount of user time compared to the competition
<poolie> i think this is because of overhead of building tuples from the dirstate etc
<lifeless> poolie: [waiting for the question]
<poolie> would you agree?
<poolie> from memory i mean
<lifeless> well
<lifeless> One planned experiment is to write a pure C implementation
<poolie> yes
<poolie> actually i see something interesting in the profile
<lifeless> we may be able to squeeze some more out of chdir
<poolie> the system time is actually pretty good
<lifeless> running up oprofile over it would be interesting too
<poolie> the interesting thing is that we're using the generic InterTree.compare
<lifeless> poolie: pending merge?
<poolie> because mark's measuring the special case of changes from the empty tree
<lifeless> oh
<poolie> i suspect dirstate just gives you an EmptyTree
<poolie> and this is unoptimized
<lifeless> grah
 * lifeless hates on special cases
<poolie> i may be wrong
<poolie> quick, add another special case :)
<lifeless> measurement is the only way to be sure :)
<poolie> well, it is definitely using the generic one
<poolie> hm no it's not literally EmptyTree, which is deprecated
<lifeless> spiv: get_missing_compression_parents: perhaps on _index only ?
<lifeless> spiv: I don't think it needs to be top level
<lifeless> spiv: actually scratch that, the tests would be ugly
<lifeless> spiv: its fine
<jml> crapzor.
<jml> it's doing it again
<jml> same branch. one more revision.
<jam> poolie: IIRC we've gone back and forth on the patch that removes the special case when there is no entries
<jam> at least, I seem to remember fixing that in the past
<jam> # the source revid must be in the target dirstate
<jam> if not (source._revision_id == NULL_REVISION or
<jam>     source._revision_id in target.get_parent_ids()):
<lifeless> spiv: done; bzr sending it
<jam> Looks like we should be handling the NULL tree
<jam> If we aren't, something else is wrong
<lifeless> spiv: mail sent; review @ will. next is suspend/resume yeah?
<PHPlover> hi when I use ftp push, Does it actually upload the files. So that if I were to have a HDD failure, i could retrieve those files from the FTP server?
<PHPlover> It does it just upload some kind of data about changes to the files [I Dont understand versioning systems]
<lifeless> PHPlover: it creates a database
<lifeless> PHPlover: you can inspect what it has uploaded by using bzr - e.g. 'bzr log URL'
<PHPlover> ok, and does that database store the complete data of every file in my project, Or just info about the files
<lifeless> it stores the complete copy of each commit, which includes the files that *are versioned*, but not those that are not
<lifeless> PHPlover: the easiest way to see what its done, is to 'bzr branch URL /tmp/spare-directory' and have a look at what bzr puts in spare-directory
<lifeless> poolie: ping
<lifeless> poolie: does bencode avoid \n ?, or can/should I avoid a \n some other way . (network_name currently has \n, but that breaks SmartServerRequest.do()
<spiv> lifeless: \n in HPSS args are fine with HPSS v3
<lifeless> spiv: interesting.
<spiv> bencode length prefixes strings.
<lifeless> spiv: how do a I register a verb to be only used with one HPSS version then ? :P
<lifeless>   File "/home/robertc/source/baz/push.roundtrips/bzrlib/remote.py", line 2002, in _translate_error
<lifeless>     raise errors.UnknownErrorFromSmartServer(err)
<lifeless> UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'do() takes exactly 4 arguments (3 given)')
<lifeless> the blackbox tests pass
<lifeless> but the per-repository RemoteRepositoryFormat-v2 tests are failing
<lifeless> for the reason-under-discussion
<spiv> Currently that's taken care of in the client; the client never tries sending various requests to older servers
<lifeless> ok, so I should guard based on a check?
<spiv> Right.  The client asks the medium if .is_remote_before((1,2)) or whatever.
<spiv> And also does _remember_remote_is_before((x,y)) when it notices a smart method is not implemented to save it trying that or other new methods again.
<lifeless> is that _protocol_ or _bzrlib version_
<lifeless> [how do I get these tests to work :P]
<spiv> It's the bzrlib version.
<spiv> When the protocol is v2, the medium immediately "remembers" that remote is before (1,6) (or whenever v3 was added).
<lifeless> ok, so its a lie, but don't look under the hook ?
<lifeless> *hood*
<spiv> Yeah.
<spiv> I'm not 100% happy with it, but it does the job.  Well, jobs.
<spiv> (Avoid trying calls that require \n in args and whatever that are new in v3, and also avoid repeatedly trying an RPC once we know the server doesn't implement it.)
<lifeless> where is the code so I can figure out what .is_remote_before to use
<lifeless> like is 1,6 right
<lifeless> or 1,2
<lifeless> or ?
 * spiv is looking
<lifeless> protocol_version in medium still returns '2' :P
<lifeless> or should I say is_before(1,13) ?
<spiv> Probalby 1,13 would be best.
 * spiv can't find where the remembered version is set low for v2 protocols.
<lifeless> ok I'm unblocked on that, though 1,13 fails the current version test :P
<lifeless> spiv: *and*
<lifeless> it still runs the verb on the Remotev2 tests
<lifeless> hmm, checking
<spiv> Ah, found it.
<lifeless> ok fixed
<lifeless> cool
<lifeless> so the branch for partial insertion is polished and up for review
<spiv> bzrlib/smart/client.py calls self._medium._remember_remote_is_before((1, 6))
<spiv> once it finds out that v3 doesn't work.
<spiv> Cool, I'll take a look.
<lifeless> I'm waiting on the next unit of work
<lifeless> the network data serialisation for record streams is also outstanding for review
<lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1234854080.11037.18.camel%40lifeless-64%3E
<lifeless> spiv: ok, and I've just flushed the new verbs to qm
<lifeless> *pqm*
<lifeless> spiv: how should we split up the remaining work? Want a quick call?
<spiv> lifeless: ok
<spiv> lifeless: (I'm reviewing the network serialisation atm)
<lifeless> ok, I'll ring you now if thats ok
<spiv> Yep
<spiv> lifeless: http://people.ubuntu.com/~andrew/bzr/streaming-push
<spiv> lifeless: ...nearly pushed
<spiv> lifeless: done.
<lifeless> spiv: cool
 * igc lunch
<lifeless> spiv: so RemoteVersionedFile has some of our fetch refactoring
<lifeless> spiv: it looks like RemoteVersionedFile is a little confused, the loom basically resets @ Very fetching
<lifeless> spiv: or something. econfused:P cherrypicking and reviewing
<spiv> lifeless: weird.
<lifeless> jam: dropping the group size will shrink things because of the full texts at new groups
<Peng_> mwhudson: ping?
<poolie1> igc, can you remind me why content-filtering needs to change dirstate?
<poolie1> would it be at all possible to avoid it?
<lifeless> poolie: sha on disk != sha in storage ?
<poolie1> well, of course that's true for filtering
<igc> it's been a while but what lifeless says sounds right
<igc> poolie1:^
<poolie1> it was more the next logical step after that that I'm thinking about
<lifeless> spiv: testing a massaged Very fetching with the lower layers removed
<lifeless> spiv: I'm keeping length_prefix, though really its in the wrong home
<Raawfle> aaargh
<lifeless> Raawfle: some context might help
<lifeless> spiv: as we knew, progress breaks
<lifeless> spiv: so I'm going to commit it, and then start working on the progress bars
<spiv> lifeless: sounds good
<lifeless> poolie: can you decode what this means for me ?
<lifeless> /home/robertc/source/baz/fetch.sinks/bzrlib/ui/__init__.py:91: UserWarning: ProgressTask(0/1, msg='fetch texts') is not the active task ProgressTask(None/None, msg='')
<lifeless>   % (task, self._task_stack[-1]))
<poolie1> lifeless: probably that you're missing a finally block
<poolie1> prior to the code that constructs  ProgressTask(0/1, msg='fetch texts')
<poolie1> hth
<lifeless> poolie1: ok, will look for that
<lifeless> poolie1: if it helps we have generators around generators
<poolie1> no, that doesn't help :-)
<poolie1> the previous pb seems to contain nothing
<poolie1> so you can probably just remove it
<lifeless> is previous a higher one?
<lifeless> or one that wasn't cleaned up from an earlier test?
<poolie1> so, there's supposed to be a stack
<poolie1> this message indicates that you tried to finish the one that's not on top of the stack
<poolie1> so actually "prior" is not necessarily true
<poolie1> so there are (at least) two here
<poolie1> A and B
<poolie1> it may be that B is conceptually inside A, and now all of A is finished but you forgot to finish B first
<poolie1> or, it may be that B is a sibling of A, and you forgot to finish A before starting B
<poolie1> if you see what i mean
<lifeless> yeh
<lifeless> I'm worried that generators are interacting badly
<lifeless> spiv and I overhauled fetch()
<lifeless> one answer is to remove the progress entirely for now
<poolie1> for many generators i'd say that giving an activity indicator may be more appropriate
<poolie1> because, firstly you may not know how many things are generating
<lifeless> indeed
<poolie1> and, as a technical reflection, finishing up is hard
<lifeless> ah found it
<lifeless> we have a function that passses a pb into a method
<lifeless> that method finishes it and rebinds it
<lifeless> I'll change it to an instance variable, bet it fixes it
<poolie1> hm as i may have said in a review, i think passing pbs around is whack
<poolie1> it's one thing i'd like to fix here
<poolie1> except in pretty special cases, a progress bar should correspond to a for loop in one function
<lifeless> poolie1: I'm not justifing the current code ;)
<poolie1> and the nesting of them i think can be done by the ui global :)
<poolie1> i know, i'm just repeating this thought in case you want to agree :)
<lifeless> oh, I agree
<lifeless> no warnings now, that was it
<poolie1> ok
<poolie1> well, i'm glad it wasn't spurious and didn't take too long to track down
<lifeless> :)
<poolie1> igc, so, i'm not quite done on filtering but it's not all that hadr
<poolie1> i am inclined to see if doing it on top of dirstate is within reach
<poolie1> at the least i'd like to document why
<lifeless> poolie1: did you see my comment about sha on disk and sha in repo?
<poolie1> yes but no but yes but
<poolie1> obviously they are different,
<poolie1> but this doesn't change dirstate to store both of them
<lifeless> what does it do
<poolie1> it seems to change it to record the filtered sha1
<poolie1> sorry, i mean the sha1 of running the input filters on the file
<mwhudson> Peng_: hola
<Peng_> mwhudson: Hi.
<Peng_> Um.
<Peng_> mwhudson: I have a dumb question about your changes to LH's served_url stuff. I used to monkeypatch served_url to return URLs relative to /bzr instead of /loggerhead, but now that doesn't work. So...what do you think I should do?
<mwhudson> Peng_: um
<Peng_> :D
<lifeless> spiv: sending it for review, I'm happy and only trivial changes; if you're happy with my arbitrary cleanups we can just land it
<mwhudson> Peng_: think of a way you'd like this to work and tell me about it :)
<Peng_> mwhudson: Heh. I was happy with how I was doing it before. :P
<mwhudson> Peng_: you can probably monkey patch BranchFileSystem.app_for_branch
<mwhudson> Peng_: alternatively, one could extract the calculation of the default value out into a method that you could then monkey patch
<Peng_> I'm barely awake enough to understand what that means, but I think it sounds good.
<spiv> lifeless: fancy that, I just sent you a review too.
<spiv> lifeless: If you only made arbitrary trivial cleanups to my code, then yes I'm definitely +1 on principle :)
<spiv> lifeless: I can eyeball it anyway if you want.
<lifeless> spiv: just sent it
<lifeless> spiv: its basically - delete the RVF stuff
<lifeless> spiv: fix progress bars
<lifeless> spiv: we can't do RemoteStreamSink until the vf network bytes lands
<spiv> I know.  I tried not to let immiment achievements cloud my review judgement, though...
<spiv> lifeless: there's some odd stuff in that diff you just sent; additions to the makefile etc.
<spiv> lifeless: perhaps the branch you sent has more recent bzr.dev than bzr send diffed against?
<lifeless> unlikely
<lifeless> however wrong parent is likely
<spiv> Ah, yeah.
<lifeless> resent
<poolie1> out to the shops before they close, will finish igc's review today though
<ronny> morning
<spiv> Heh, I see _length_prefix did sneak into that diff.
<lifeless> spiv: I kept it deliberately
 * spiv nods
<spiv> lifeless: reviewed (tweak)
 * spiv keeps reviewing
<lifeless> spiv: ok network serialisation on its way to pqm
<lifeless> spiv: so we can merge that into the fetch refactoring branch
<spiv> lifeless: just bb:approved your "insert record streams with missing compression parents" patch
<lifeless> excellent
<lifeless> I'll kick that off now
<lifeless> spiv: so what do we have left
<lifeless> suspend resume? is that up for review yet?
<spiv> Hmm, I don't think so.
<lifeless> so it depended on missing parents and partial streams
<lifeless> both are fully acked
<lifeless> why don't you polish that, and I'll get the network stream integrated with RemoteSink
<lifeless> which will fail on stacked branches until suspend resume is done
<spiv> Ok.  Let's see if I can figure out which branches to merge into suspend-resume to bring it up to date...
<lifeless> :P
<lifeless> so administrivia
<lifeless> I'd *love* to finish this today
<lifeless> but its after
<lifeless> 5
<lifeless> if you're up for a sprint-to-finish, so am I. And I'm sure we can convince poolie for some slack on Monday :)
<spiv> Oh that's right, we were sensible and made that a branch off bzr.dev.  That helps ;)
<spiv> I'm still going strong atm ;)
<lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1235097663.6233.119.camel%40lifeless-64%3E is what you need for suspendresume
<spiv> I'll probably need to stop about 6:30
<lifeless> the clock is on :)
<spiv> :)
<lifeless> you probably want bzr.dev too or that matter
<spiv> Yeah, already grabbed that :)
<lifeless> spiv: ok, failure in my streams bytes thing in reconcile
<lifeless> while I investigate that the other approved patch is on the way
<poolie1> igc, still around at all?
<igc> poolie1: yep
<poolie1> i'm going to send a review in a sec
<poolie1> do you want to talk about it/
<spiv> lifeless: http://rafb.net/p/wgjSMm15.html is failing on the assertRaises; because the add_lines after the resume_write_group doesn't actually make a record with a compression parent.
<spiv> lifeless: what's a good way to add a record with a compression parent there, should I crib from test_versionedfiles perhaps?
<spiv> With a *missing* compression parent, specifically...
<lifeless> spiv: you need two repos
<lifeless> in repo one you do add_lines(base, (), [... ... ...])
<spiv> lifeless: that's what I feared :)
 * spiv does that
<lifeless> and add_line(child, (base,), [.....])
<lifeless> then repo2.texts.insert_record_stream(repo1.texts.get_record_stream(base,...)
<lifeless> sorry not base there
<lifeless> just delta
 * spiv nods
<lifeless> or
<lifeless> use knit.make_pack_factory
<lifeless> to get a vf object
<lifeless> in lieu of a second repo
<spiv> Existing tests passing, I think...
<lifeless> cool
<spiv> Ok, wrote a test for filling in a missing parent after a suspend/resume, currently failing :)
<spiv> Fixing...
<lifeless> spiv: I'm modifying RemoteSink to fallback to _real when stacked, pending the stuff you're doing
<lifeless> spiv: minor tweak needed, our substreams need to encode a prefix record
<lifeless> spiv: dealing with the keywidth mismatch
<spiv> Oh, right.
<lifeless> so in do_chunk on the reader
<lifeless> does it know its a pack stream and give us only the bytes_record ?
<spiv> Ok, filling in a missing parent after suspend/resume works.
<lifeless> woooooooooooooo
<lifeless> ooooo
<lifeless> ooo
<lifeless> and the current branch is into ascii tests
<lifeless> which is fetch refactor
<spiv> Hmm, I think I need more context to understand your question.
<spiv> do_chunk is called as bytes of the request *body* arrive.
<lifeless> yes
<lifeless> SmartServerRepositoryInsertStream
<lifeless> I think it will be fine
<spiv> So long as the client is generating a request body stream of a pack, which IIRC it is...
<spiv> i.e. it's basically just sending what the ContainerWriter is emitting
<spiv> So that should be fine, yeah.
<vila> hi all (completely forget my ping this morning :)
<spiv> Ok, added what I think is the last test, that suspend/resume doesn't accidentally make an uncommittable write group committable.
<spiv> Not passing yet :)
<poolie1> hello vila
<vila> hi poolie1 :)
<spiv> lifeless: passing, just fixing up duplication added to make it pass
<lifeless> spiv: cool
<lifeless> spiv: I think I'm done too, bit of staring involved
<lifeless> spiv: the glue is a little awkward, pack -> bytes -> pack reader -> bytes -> NetworkRecordStream
<spiv> lifeless: ok, pushing
<spiv> lifeless: it'll be at http://people.ubuntu.com/~andrew/bzr/suspend-write-group shortly
<lifeless> spiv: was there a test to run to check this works
<lifeless> spiv: one branch landed
<lifeless> pulling .dev and sending the next
<spiv> lifeless: there were acceptance tests in that loom
<spiv> lifeless: although now that I look at it again, the test_push_smart_stacked_streaming_acceptance test is slightly wrong :)
<spiv> lifeless: we expect 2 insert_stream RPCs now, not 1.
<spiv> If things are working, that is :)
<lifeless> spiv: cool cool
<spiv> lifeless: so, my branch is pushed, and all tests seem to be passing here.
<spiv> (running a bigger selftest to be sure, but so far so good)
<lifeless> spiv: whats a good test to test RemoteSink ?
<spiv> lifeless: hmm
<lifeless> fetch tests pass
<jml> lifeless: https://code.edge.launchpad.net/~lifeless/subunit/polish/+merge/2735
<lifeless> dammit, its creating manually ><
<spiv> lifeless: I suppose a simple test_remote test that shows that RemoteRepo._get_sink().insert_stream(...) invokes the right RPC would be good.
<jml> lifeless: btw, "bzr send --no-bundle" to merge@code.launchpad.net Just Works.
<spiv> Possibly even with a stream of []  ;)
<spiv> I'm sending up the suspend-write-group branch for review
<lifeless> cool
<lifeless> resending partial inserts (typo :()
<spiv> :(
<lifeless> jml: thank; commonprefix?
<jml> lifeless: os.commonprefix.
<jml> lifeless: it's a blight on the standard library. only use it if you want your file operations to be broken
<spiv> lifeless: oh, heh, I already had that exact one-liner in my suspend-write-group branch.
<jml> lifeless: os.commonprefix('/foo/bar/baz', '/foo/baz/bop') => '/foo/ba'
<lifeless> spiv: the typo ?
<spiv> lifeless: yeah
<lifeless> spiv: :)
<lifeless> spiv: I don't see the patch
<lifeless> spiv: ok, its writing a pack directly
<poolie> night all
<spiv> lifeless: ok, patch sent.
<spiv> lifeless: I'm done for the evening, but I'm very happy with the shape of the resume_write_group code.  Maybe it's my Friday evening judgement, but I think that patch only has a few minors warts, rather than any glaring problems ;)
<spiv> lifeless: thanks for helping me get it into shape
 * spiv -> food, weekend, world of goo, etc!
<lifeless> spiv: approved
<lifeless> spiv: I'm going to keep plugging at joining these dots
 * lifeless will be begging for reviews I think
<spiv> lifeless: I'll pqm-submit it, thanks.
<lifeless> the dependent patch is onto ascii
<lifeless> should land fine I think
<lifeless> spiv: woo, 74 -> 60
<spiv> lifeless: the ratchet?
<lifeless> for non-stacked
<lifeless> stacked goes 99 -> 101
<spiv> Nice.
<lifeless> the latter is uninvestigated as yet
<lifeless> but I think its going to be due to my if block pending suspend integration
<spiv> Is stacked still hitting the thing in InterPackRepo that explicitly uses something dumb?
<lifeless> so commiting and sending for review
<spiv> (the "if len(fallback_repos) > 0" check)
<nhaines> I have a merge request from a friend who didn't set his 'whoami' info on the shared computer he was using.  How can I modify the commit email address before I merge into my main branch?
<lifeless> spiv: yes
<lifeless> nhaines: you can't, because commits are immutable; you can either degrade to a regular patch (do a merge, then bzr revert --forget-merges), or not
<nhaines> lifeless: both what I feared and what I needed to know.  Thanks.  :)
<lifeless> spiv: one more landed
<lifeless> I'm looking for a reviewer for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1235118639.6233.151.camel%40lifeless-64%3E
<ronny> lifeless: bzrlib/smart/protocol.py -> wouldnt just raise do?
<lifeless> ronny: no, interim revisions in called code trash state
<lifeless> s/revisions/exceptions./
<ronny> ah, i see
<lifeless> thats actually a pretty standard python recipe
<ronny> never ran across it
<ronny> wont that go away in python3 anyway?
<ronny> (afair they put the traces on the exception)
<faspell> \quit
<spiv> lifeless: haha, that diff removes _length_prefix again :)
<spiv> Ah, and moves it to a different file.
<spiv> lifeless: looks good.  bb:approve
<spiv> Ok, really gone for the night now.
<lifeless> spiv: ciao :
<lifeless> spiv: just finishing the whole thing off now :)
<ronny> lifeless: hmm, i made up a small testcase, and it doesnt seem to trash state, was this a bug in earlyer python?
<lifeless> ronny: possibly
<ronny> unless im misstaken http://paste.pocoo.org/show/104633 demonstrates that it works in 2.4/2.5
<lifeless> ronny: I'd need to check theexact way things propogate
<lifeless> your test does look plausible to me at ist consideration
<ronny> bbl, need to solve some snow issues
<lifeless> ok
<lifeless> 83 round trips
<lifeless> so 18 less
<lifeless> and massively less for non-muppet content
<EricHerman> I just installed using Bazaar-1.11-OSX10.5.dmg and I see a strange message: "WARNING: bzrlib version doesn't match the bzr program"
<EricHerman> which goes on to print: bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 11, 0, 'final', 0)
<EricHerman> which looks like a match to me.
<EricHerman> http://pastebin.com/m1260cb9a
<EricHerman> Any suggestion as to what I might look at next?
 * beuno pokes verterok and vila 
 * verterok is not here
<verterok> hi beuno
<beuno> hi verterok
<verterok> EricHerman: hi, check you have another bzrlib in your PYTHONPATH
<beuno> this is what you get for being an apple fanboy
<EricHerman> looking
<beuno> pings for support on it  ;)
<verterok> beuno: apple fan boy? where? I use Ubuntu ;)
<EricHerman> verterok, I do not have PYTHONPATH set in my envrionment
<beuno> verterok, oh, don't tempt me...
 * EricHerman tries find / -name bzrlib
<EricHerman> find only reports /Library/Python/2.5/site-packages/bzrlib
<verterok> EricHerman: weird, I didn't installed 1.11, but 1.10 works ok.
<verterok> EricHerman: I'll download and install 1.11, and report back if I hit any issues
<verterok> EricHerman: did you upgraded from a previous version?
<EricHerman> I /had/ 1.6 which was built from source, but I removed it.
<EricHerman> it's possible that there was something left over, but I don't know what that might have been.
 * domas hands over strace to Eric :)
<james_w> EricHerman: which bzr script are you running?
<EricHerman> james_w, I'm not sure how to answer that question. I envoke /usr/bin/bzr ....
<EricHerman> (that file itself does not have a version number in it)
<EricHerman> ls -ld $(which bzr)
<EricHerman> -rwxrwxr-x  1 root  wheel  4313 Mar 22  2008 /usr/bin/bzr
<EricHerman> date is suspicious on that, hmmm!
<james_w> EricHerman: yeah, just wondered if you had an old /usr/local/bin/bzr or something
<verterok> EricHerman: please check if you have a bzr in /usr/local/bin
<domas> 'which bzr'
<EricHerman> Indeed! but oddly it *also* gives that message.
<EricHerman> I think I'll try to remove everything and start again.
<verterok> EricHerman: good idea :)
<EricHerman>  well, having done a full rm -rf of all the potentailly bzr related stuff I could find on the system (with luck I didn't nuke *too* much!), then doing a reinstall using Bazaar-1.11-OSX10.5.dmg ... I no longer see the strange message. Conclusion: something stale on the filesystem was at issue. Had to be one of these: http://rafb.net/p/X85tuO44.html
<EricHerman> on a clean system Bazaar-1.11-OSX10.5.dmg should be just fine.
<harobed> hi, I can I do with bzr the same thing than svn status -r HEAD ?
<maxb> harobed: svn status -r HEAD is not a valid svn command
<harobed> sorry, svn status -u
<harobed> or svn diff -r HEAD
<harobed> to see differences between repository and local working copy
<Lo-lan-do> "bzr diff :parent --new ."
<Lo-lan-do> Or maybe "bzr diff :bound --new ." if you're in a checkout/bound branch.
<Lo-lan-do> (Not tested, but I think that should work)
<harobed> ok, I'll test it
<Lo-lan-do> Please tell me if it works, it might interest me in the future :-)
<Lo-lan-do> Although I usually do "bzr status" and "bzr missing :bound".
<harobed> I've this message : bzr: ERROR: No bound location assigned.
<harobed> ok, I've binded to parent bancsh
<harobed> branch
<harobed> bzr diff :bound --new . work as svn diff -r HEAD
<harobed> but I don't know how to do : svn status -u
<fullermd> Well.  If you don't want it to be a checkout, don't bind it...
<Lo-lan-do> bzr diff :bound --new . | lsdiff
<james_w> does "bzr status -r branch::bound" work?
<harobed> james_w: yes, it work
<Lo-lan-do> Er... I constantly get "Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)" messages, even after upgrading the server to 1.12...
<Lo-lan-do> (In a branch bound to a bzr+ssh://foo branch in a remote repo)
<Lo-lan-do> Hah.  It helps if I upgrade the correct server.
<james_w> heh :-)
 * Lo-lan-do hides
<Odd_Bloke> :D
<Lo-lan-do> Damn.  I upgraded my workstation to 1.12 and now I can't reinstall bzr-svn.
<Lo-lan-do> (Current bzr-svn depends on subvertpy, which is stuck in NEW)
<Lo-lan-do> I'll make do with a local install in the meantime.
<Odd_Bloke> Lo-lan-do: You could build subvertpy yourself.  jelmer has published the packaging branch somewhere.
<Lo-lan-do> Yeah, I did that already :-)
<jel> hey guys :)
<jel> What's the status of nested-tree support in bzr?  I see some stuff in the wiki about a branch jelmer was working on being merged in 0.15, and that it just requires a manual bzr add path but it doesn't seem to work -- just ignores the subtree, listing it as unknown.
<jel> That branch was back in 2005, so It's hard to believe it's not finished.  Was it abandoned?
<jam> vila: good morning
<jel> /join #mercurial
<jel> sorry guys; stupid irc client :)
<vila> jam: good morning
<jam> jel: it wasn't specifically abandoned, just focus of dev shifted a bit. IIRC abentley is planning on working on it near full-time in ~the  next month
<jam> vila: just thought I'd say hi. Also, a quick question about the EC2 machine
<jam> Are you interested in setting it up with my help? Or should I just do it?
<jel> jam: ah, that's great news.  Are there any details of how it will be implemented/used?
<jam> jel: So the original design was that if you did:
<jam> bzr branch $METAPROJECT project
<jam> cd project
<jam> bzr branch $SUBPROJECT subdir
<jam> bzr add subdir
<jam> bzr commit
<jam> Then you would have a "combined" project
<jam> such that in the future doing "bzr branch $METAPROJECT" would give you both
<jam> but the project histories would be versioned independently
<jam> just that when you do "bzr commit" in the outer-dir, it would recursively commit the children
<vila> jam: I'm still uncomfortable with using Windows remotely, I still plan to set one up as a VM locally (with an emphasis on using only free software and an automated setup) so I will certainly monitor what happen on the EC2 machine
<jam> and track the committed revision in the parent
<jel> jam: ok, cool, sounds like the old plan, which looked very usable :)
<jam> vila: k, I thought I might get you to write my documentation for me again. :) I have 3-4 emails about when I set up kerguelen
<jam> and I just need to turn it into a real "setting up a win32 build host" document
<vila> jam: certainly something I plan to do anyway :)
<jam> Since we're setting up yet-another host, it is a good time to do so
<jel> abentley: Is there a name for your nested-tree project, or a branch/feed somewhere where I can track its progress?
<vila> jam: yes, that's the "yet-another" that triggers my desire to automate it (and the aim to allow others to do it as well, no matter what degree of automation I'll achieve)
<abentley> jel: I haven't set anything up yet.
<jel> ok, thanks
<jel> abentley: Not to push you, but can you confirm that you're planning to work on it soon?  It's an important feature for me, and I need to make a decision on which vcs to use, is all.
<abentley> jel: I am planning to work on it soon.
<jel> k, thanks :)
<vila> abentley: have you seen my mail about iter_changes bogus indentation regarding tree-reference handling ?
<abentley> vila: Yes.  Thanks for that.  I'm surprised it didn't break any test cases.
<vila> abentley: yeah, same here, shame :-(
<barry> jam: ping
<jam> hi barry
<barry> jam: hi!  i upgraded code.python.org to bzr 1.12 today
<barry> jam: but i think i want to upgrade the repo formats of the mirrors
<beuno> barry, you can use recursive upgrade plugin: http://bazaar-vcs.org/BzrPlugins
<beuno> or
<barry> jam: we're on rich-root-pack right now.  thinking about 1.9-rich-root, but i'm trying to decide whether the performance improvement would be worth (potentially) forcing people to upgrade their clients
<beuno> jam has a nice script in contrib/
<jam> barry: from my experimentation with the python repo, I would say yes
<jam> but I don't create the policy for upgrading clients
<beuno> 0.92 -> 1.9 was a big improvment for me, FWIW
<jam> beuno: for python.org it is even better, because the bzr-svn conversion compresses astoundingly well
<jam> barry: I don't know how hard it is for your clients to upgrade
<jam> so I can't really make that decision for yo
<jam> you
<jam> I can say that for incremental updates
<jam> it should be at least 3x faster
<jam> for initial branch of everything, I know there is 20% less data to copy
<jam> but that isn't necessarily an across-the
<jam> sorry
<jam> 20% isn't necessarily worth upgrading clients
<barry> beuno, jam that's significant.  i don't think there are /that/ many users of the mirrors and it's mostly early adopters anyway
<jam> barry: so for *my* anecdote
<jam> doing "bzr up" for bzr.dev
<jam> went from 45s to 15s
<jam> when there are about 3 revisions to update
<jam> I would expect python.org to do even better
<santagada> sorry to ask but, 15 seconds is still a lot no?
<barry> jam: thanks.  sounds like it's worth it unless i get cries of objections
<jam> santagada: I was going to respond...
<jam> Anyway, it just took 20s to update 7 mainline revs == 67 ancestry revs
<jam> and all that over a dumb transport
<jam> I'm not entirely sure how long things should be, but given that connecting ssh to launchpad takes 7-8s...
<oldman> is it possible/easy to change the e-mail address associated with a commit that has been made?
<oldman> i.e., the `bzr whoami` entry
<oldman> or once its in, can you no longer do anyrthing about it?
<Odd_Bloke> oldman: You can 'uncommit' back to it, but that'll break your history.
<oldman> a simple sed -e 's/@example.com/@real.com/' of .bzr would not be safe?
<Odd_Bloke> oldman: I very much doubt it.
<oldman> ok
<oldman> so if I...
<oldman> bzr branch lp:project; bzr uncommit; bzr uncommit; bzr commit -m 'reapplied x'
<oldman> and then bzr push lp:project
<oldman> would that work? :)
<Odd_Bloke> oldman: You would have to 'bzr push --overwrite'.
<Odd_Bloke> And it would break anyone else's branch of lp:project.
<oldman> it would only break their branch if they were > the revno I uncommit to though wouldn't it?
<phinze> is there a quick way to clean up all ~1~ back ups in a working tree?
<jelmer> phinze, bzr clean-tree --detritus
<Peng_> (which is provided by bzrtools)
<phinze> beautiful
<jelmer> Peng_, See my last post to the mailing list :-)
<phinze> --detritus ...? what strange voodoo is this? :)
<LarstiQ> phinze: it's a beautiful English word akin to 'cruft'
<Peng_> jelmer: Well, it hasn't been merged yet. :P
<phinze> "debris: the remains of something that has been destroyed or broken up "
<phinze> nice
<phinze> hmm might it make sense to have an option to bzr switch that performs clean-tree as well?
<phinze> i use it on lightweight checkouts to switch branches and focus, and i don't need old detritus lying around
<jam> jelmer: quick question about svn import layouts
<jam> I'm accessing a repo which is of the form "trunk/project"
<jam> rather than "project/trunk"
<jam> do you have a standard format for that?
<jam> maybe it is the "itrunk" layouts
<jam> doesn't seem to work
<jelmer> jam, yeah, itrunk is for that
<jam> itrunk 1/2/3 always gives me "specified URL is under a branch"
<jam> The specific URL is: http://xdelta.googlecode.com/svn/trunk/xdelta3
<jelmer> jam, if you're interested in just that branch, "bzr branch" should work
<jam> Importing as "trunk" just worked, but gave me both projects
<jelmer> "bzr branch http://xdelta.googlecode.com/svn/trunk/xdelta3 xdelta3" should work
<jam> jelmer: it did... so why doesn't svn-import work?
<jelmer> jam, bzr branch always works, it assumes the URL you give it is a branch
<jelmer> svn-import imports multiple branches
<jelmer> so it has to guess what the layout is
<jam> sure. though I would have thought it matched the "itrunk" layout pretty closely
<jam> which is why it is strange that "bzr svn-import --layout=itrunk1" never worked
<jam> then again, it isn't clear (to me) what 'level' means
<jelmer> jam, which URL did you give it ? http://xdelta.googlecode.com/svn ?
<jam> http://xdelta.googlecode.com/svn/trunk/xdelta3
<jam> I should give it the root of the repo?
<jam> For auto-detect import: http://xdelta.googlecode.com/svn/trunk worked just fine
<jelmer> jam: svn-import on a branch should fail
<jelmer> http://xdelta.googlecode.com/svn/trunk doesn't work here:
<jelmer> bzr: ERROR: http://xdelta.googlecode.com/svn/trunk appears to contain a branch. For individual branches, use 'bzr branch'.
<jam> I just did "bzr svn-import  http://xdelta.googlecode.com/svn/trunk" I'll try to verify that
<jam> nope, you're right
<jam> I must have used .../svn the first time
<jam> jelmer: so would doing "bzr branch .../svn/trunk/xdelta3" give me the same final branch as "bzr svn-import --layout=itrunk1" ?
<jam> (are they compatible?)
<jelmer> jam, yes
<jelmer> jam, well, if you're using 0.5
<jam> jelmer: yeah, I ame
<jam> interestingly I get an error at the very end
<jam>   File "/home/jameinel/.bazaar/plugins/svn/revmeta.py", line 1188, in get_revision
<jam>     cached.metaiterators.add(metaiterator)
<jam>   File "/home/jameinel/.bazaar/plugins/svn/revmeta.py", line 963, in __hash__
<jam>     return hash((type(self), self.from_revnum, self.to_revnum, tuple(self.prefixes), hash(self.layou
<jam> t)))
<jam> TypeError: 'NoneType' object is not iterable
<jelmer> which bit is None ?
<jam> I don't know
<jam> self.prefixes probably
<jam> anyway, "bzr branch" is great for what I need. Just wanted to understand things a bit better.
<jam> thanks for your tie
<jam> time
<jelmer> jam, Thanks, I think what's wrong
<jelmer> jam, bug in itrunk1
 * jelmer fix0rs
<jam> :) \o/
<nevans> jelmer: for #332116, I had already tried svn-upgrade... but for some reason, it refuses to upgrade that branch.
<jelmer> nevans, what's the error?
<nevans> it successfully upgraded trunk and another branch.
<nevans> no error.  it just doesn't do anything.
<nevans> lemme try again.  I'll attach the bzr.log
<Peng_> jelmer: How much of an impact does svn 1.5 have on performance and whatnot?
<jelmer> Peng_, svn 1.5 or bzr-svn 0.5 ?
<Peng_> jelmer: svn 1.5.
<Peng_> jelmer: The revision "Use global needed variable." vanished from bzr-svn 0.5's history. Was that intentional?
<Peng_> I've got a mix of 1.3 and 1.4, so I'm wondering if it's worth doing anything about it. bzr-svn is already fast enough with them, I guess, but I dunno.
<jelmer> Peng_, the main advantage of 1.5 is that you can use revision proeprties for bzr-svn metadata
<jelmer> retrieving that metadata will also be faster with 1.5
<jelmer> other things won't be significantly faster
<jelmer> Peng_, yeah, it's correct that revision vanished
<Peng_> Poor, unloved revision. :(
<Peng_> Anyway, thanks for the information. :)
<rockstar> abentley, hey
<abentley> hey
<rockstar> abentley, I'm looking at the integrating with bazaar wiki page, and there's a line that reads:
<rockstar> source.create_checkout('/tmp/newBzrCheckout', None, True, accelerator_tree)
<rockstar> Does that operate in place, or return the checkout?  The wiki makes it look like it operates in place.
<jfroy> jelmer: good morning
<rockstar> abentley, and so that would make me think that source would change types.
<jelmer> jfroy, hi
<abentley> rockstar: I believe source.create_checkout returns the working tree.
<rockstar> abentley, okay, that's better.
<abentley> rockstar: It does not change the type of the branch.  The branch remains a branch.  It's just a branch that is checked out somewhere.
<rockstar> abentley, okay, so when I reference branch now, it's still the remote branch that I opened with Branch.open('lp:blah')
<abentley> Yes.
<jelmer> jam, any chance you can do a quick review of my InterBranch patch?
<jelmer> jam, That one would really help a lot of things wrt bzr-svn UI and performance and is a requirement for bzr-git pull from remote branches
<LaserJock> I can't seem to branch with bzr-svn 0.5
<jelmer> hi LaserJock
<jelmer> LaserJock, what doesn't work?
<LaserJock> I just get bzr: ERROR: Not a branch:
<jelmer> which SVN url?
<LaserJock> svn://anonsvn.kde.org/home/kde/trunk/extragear/sysadmin/kiosktool/
<LaserJock> svn co works fine
<jelmer> LaserJock, the layout for the KDE repository is hardcoded
<jelmer> LaserJock, try svn://anonsvn.kde.org/home/kde/trunk/extragear
<LaserJock> jelmer: ok, well that works
<LaserJock> jelmer: so is there a way to get sysadmin/kiosktool ?
<jelmer> LaserJock, you can set layout = itrunk3 in the configuration for the KDE URL
<jelmer> LaserJock, patches to bzrlib.plugins.svn.layout.custom.KDELayout are also welcome
<LaserJock> jelmer: where do you set layout = itrunk3 ?
<jelmer> LaserJock, ~/.bazaar/subversion.conf or ~/.bazaar/locations.conf
<jelmer> in the section related to the KDE repo
<LaserJock> jelmer: there isn't a KDE section yet as I haven't branched, can I make one or do I need to branch something first?
<jelmer> LaserJock, you can add one
<jelmer> LaserJock, you might want to add use-cache = False too
<LaserJock> jelmer: got it going
<LaserJock> jelmer: this is *way* faster than 0.4 . I've been stuck with svn for KDE but this definately seems usable
<jelmer> LaserJock, cool !
<jelmer> LaserJock, that was one of the main goals of 0.5
<jelmer> LaserJock, Ideally the KDELayout class should be customized to properly recognize all branches in the KDE svn repository
<jelmer> LaserJock: that would, among other things, fix "bzr svn-import svn://anonsvn.kde.org/home/kde"
<jelmer> abentley: Hi
<abentley> jelmer: hi
<jelmer> abentley: Is there some way to register a remote branch on Launchpad?
<abentley> jelmer: I believe so.
<jelmer> abentley: Any pointer ? Where should I be looking?
<abentley> Go to your profile page, hit the code tab, click the big orange "register a branch".
<jelmer> abentley: Ah, thanks
<abentley> jelmer: np
<jelmer> abentley: Do you happen to know if there's something similar for the remote API?
<abentley> jelmer: I don't know.
<jelmer> abentley: ok, thanks again
<jfroy> jelmer: is push now safe to use to create a new branch with bzr-svn?
<jfroy> the svn-push command is gone, but the release notes are not clear if push will work right now or is currently broken pending some changes to bzr
<jelmer> jfroy, svn-push still works for now
<jelmer> jfroy, "bzr push" working out of the box is waiting for a patch to enter bzr.dev
<jfroy> OK, so it's just gone from the command help topic.
<jelmer> jfroy: yep
<etenil> Hi there
<etenil> I'm having trouble splitting a tree with bzr
<etenil> doing bzr split only produces an error
<Peng_> ...What's the error?
<etenil> bzr: ERROR: No WorkingTree exists for "file:///home/guillaume/sandbox/bzr_tree/Bell/trunk/.bzr/checkout/".
<etenil> don't understand it
<Peng_> It seems "bzr split" needs the branch to have a working tree. You could run "bzr co" to create it and "bzr remove-tree" to remove it again afterwards.
 * Peng_ shrugs
<etenil> ?
<etenil> I'm trying to branch the tree and split from there maybe
<etenil> now it says:
<etenil> bzr: ERROR: To use this feature you must upgrade your branch at file:///home/guillaume/sandbox/bzr_branch/.
<etenil> I try a checkout as you suggested
<jelmer> etenil, I think you need to upgrade to a rich-root format (such as 1.9-rich-root) to be able to use split
<etenil> how can I upgrade the tree?
<etenil> is there a command?
<jelmer> bzr upgrade --1.9-rich-root
<etenil> ok, I'll give it a try
<etenil> bzr: ERROR: no such option: --1.9-rich-root
<etenil> -_-
<etenil> I can just use --rich-root
<etenil> from what the help says
<etenil> Once I have split my tree, will the created branch have its versions renumbered?
<Peng_> etenil: It would be better to use --rich-root-pack than --rich-root.
<Peng_> etenil: What version of bzr are you running?
<Peng_> jelmer: Not to be excessively stalky, but why did you just rename lp:bzr-svn's branch?
<Peng_> Oh, it's not mirrored now.
<jelmer> Peng_, Yep
<jelmer> Peng_, this should save me some explanation when people try lp:bzr-svn and it's out of date
<Peng_> Ah.
<Peng_> The email alerts for new revisions were nice, but oh well.
<jelmer> Peng_, ah, there's no emails for remote branches?
<Peng_> jelmer: I dunno. Probably not, since it doesn't show the log.
<jelmer> Peng_, ideal would be a mixture of mirrored and remote branches
<jelmer> where it would redirect .bzr to the actual branch but still keep a lp-specific mirror
<Peng_> That would be neat, but kind of confusing.
<Goundy> bzr update returns tree is up to date (rev 42) and my repo is at revision 43 (using launchpad)...
<Goundy> I don't know what to do :/
<Peng_> Goundy: "bzr pull"?
<Goundy> Peng ah
<Goundy> Peng I don't get it... I get an error ^^
<Peng_> You do?
<Goundy> Peng I think I understand I did a bzr pull and kicked out my mainline before ><
<Goundy> forgot
<Goundy> thank you Peng
<etenil> the conversion worked
<etenil> i try the split
<Peng_> Goundy: You figured it out? That's good. :)
<Goundy> Peng_ yea >_< thanks !
<Tak> jelmer: md 2.0b1 packages in debian/experimental
<jelmer> Tak, w00t!
<Tak> the libpython md-bzr backend is rocking
<etenil> that works!!!!
<jelmer> Tak, I'll give it a try :-)
<etenil> alright, thanx for your help all
<etenil> bye
<etenil> Hi again
<etenil> I have split up a directory from a tree
<etenil> but there are gaps in the revisions
<etenil> is it possible to renumber the revisions?
<jelmer> etenil, what do you mean with gaps?
<etenil> well
<etenil> my bzr tree comes from a svn tree. And many projects were in there. Some revisions are only relevant to some of them
<jelmer> etenil: bzr and svn revision numbers are different - the svn revision numbers are per-repository, the bzr revision numbers are per-branch
<etenil> or maybe I should split and renumber with svn then convert
<jelmer> etenil, if you have bzr-svn installed then "bzr log -v" will show the original svn revno as well as the bzr revno
<etenil> ok
<etenil> but I don't want to keep the svn tree
<jelmer> etenil, the information about the original svn revno is in the bzr tree
<etenil> I want to split it per project and port to bzr
<jelmer> etenil, why are you running "bzr split" btw? If you need just a subdir of the svn repository, you can just "bzr branch" that instead
<etenil> jelmer: that's ok, I think svndumpfilter can split the svn repo and renumber it
<etenil> I can import it after that
<lifeless> jelmer: 'bzr register-branch' ?
<jelmer> lifeless, that registers a mirrored rather than a remote branch
<lifeless> oh
<lifeless> is that a problem?
<jelmer> lifeless, in some situations it's useful to be able to register remote branches
<jelmer> since they don't have a delay
<jelmer> lifeless, not that I would register remote branches very often, being able to do it through the web ui keeps me happy enough
<lifeless> jam: hi
<jam> hi lifeless, just writing up some summary stuff about my latest version of gc, and I just put together an xdelta repo
<lifeless> I saw
<lifeless> is it faster than last time you looked at xdelta?
<jam> the way it is implemented right now, not really
<jam> I'm doing multi-parent with unlimited delta chains
<jam> it is faster to compress than gc
<jam> but slower to extract
<jam> (3m45s versus 10min to compress, but 1m30s versus 17s to extract)
<lifeless> very interesting
<lifeless> any feeling on why its faster? [Can we use the compressor in gc ?]
<jam> lifeless: why the compression is faster?
<jam> it probably has less *stuff* to compare against
<jam> doing multi-parent
<jam> means you are comparing 1k lines versus 2k lines
<jam> while gc is comparing with all texts inserted so far
<lifeless> OTOH gc doesn't have to build new dicts all the time
<jam> sure
<lifeless> I'm wondering if xdelta simply has a better compare logic we could adapt
<jam> xdelta is also written in C by people who have been spending a lot of time optimizing it :)
<jam> at least, more time than you and I have probably spent on GC
<jam> oh, and for the record, I should mention that the "repository-details" time for the knit repo is 30s
<jam> so it is ~18s to extract all texts for gc, 30s for knits, and currently 1m30s for xdelta
<jam> though when gc was experiencing bad paging, it was down at 7min
<jam> so I'm willing to give xdelta a bit of margin here.
<lifeless> me too
<lifeless> xdelta certainly has a good[same as knit] story for skinny packs/delta reuse
<jam> lifeless: I should also mention that your new changes to the streaming logic confuse existing plugins
<jam> "knit-delta-closure" isn't in the adapter registry
<lifeless> I'm very concerned about getting good compression out of it though
<jam> lifeless: well, for multiparent versus my best gc so far, I get 9M for xdelta, versus 11MB for gc
<jam> so at least *right now* the story is just fine
<lifeless> jam: yah, one reason we pushed hard on this is that its the start of the release cycle, best time for disruption
<lifeless> as far as being in the adapter registry, just try for fulltext
<lifeless> you can see the change in knit.py in insert_record_stream
<jam> k
<jam> anyway, I need to get going
<jam> have a good weekend, lifelessf
<lifeless> ciao
<lifeless> I'm going to send up the final parts this morning
<lifeless> if you have a chance to review it, would love that:)
<lifeless> jam: thats *very* interesting that mp is smaller than gc; even with reordered texts?
<ameoba_> I have a directory with a few hundred files in it.  I want to ignore most of them, but not all.  if I ignore $DIR/*, will it cause problems down the line if I want to add/modify specific files from there?  I'm asking because of the "Warning: the following files are version controlled and match your ignore pattern" when I added the ignore
<fullermd> ameoba_: No, it's just letting you know.
<ameoba_> fullermd-  that's what I was hoping for.  thx
<fullermd> ignore means "Don't add this file we we find it recursively".  It doesn't have any effect on files that are already versioned or added explicitly.
<phinze> uh oh, i think i broke shelve
<phinze> i shelved on a bound checkout before running bzr up and then tried to unshelve
<tyhicks> Trying to find an equivalent to git-cherry-pick. I want to grab individual patches from other branches and don't want a seperate merge message.
<tyhicks> Any tips for how I can do this?
<lifeless> phinze: it should unshelve fine; what happens?
<lifeless> tyhicks: merge -r x..y does a cherry pick
<lifeless> tyhicks: because its not a transitive link in the graph the old revisions are not shown in log; you do need to supply a commit message (but it's scriptable with a tiny bit of python if you are doing this a lot and want to carry the commit message and author across automatically)
<tyhicks> lifeless: IIRC, I have to do a commit afterwards and that creates another merge message
<lifeless> tyhicks: it will create a new commit object; just like git-cherry-pick does
<lifeless> tyhicks: it won't show as a merge, because cherry picks are not full merges
<spiv> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/332314
<ubottu> Error: Could not parse data returned by Ubuntu: HTTP Error 502: Bad Gateway (https://launchpad.net/bugs/332314/+text)
<lifeless> spiv: guess what
<spiv> lifeless: short story: the client isn't falling back when Repository.insert_stream is unavailable.
<lifeless> spiv: doh!
<lifeless> spiv: I'm seeing something very similar, in the stacked case, which hasn't landed yet
<lifeless> FAILED (failures=8, errors=19, known_failure_count=20)
<lifeless> spiv: are you going to do some bzr coding today?
<spiv> lifeless: sadly no :(
<lifeless> spiv: I'm hoping to get the stcked case up for review
<spiv> lifeless: I have to head up to the blue mountains today/tomorrow
<lifeless> nice
<spiv> "have to".  Woe is me ;)
<lifeless> spiv: hiking?
<spiv> A bunch of stuff, farewell party, visiting family, possibly a small bushwalk might happen too...
<lifeless> enjoy!
<spiv> Thanks!
<lifeless> can you look at remote.py, 1370
<lifeless> that looks like it should fallback fine to me
<lifeless> spiv: perhaps the stream is being eaten partly?
<spiv> lifeless: ah, hmm
<spiv> lifeless: It *might* be an interaction with body_stream?
<spiv> lifeless: oh!
<lifeless> I think the stream is consumed
<lifeless> the error is raised
<lifeless> remaining elements are consumed
<spiv> yes, I bet the stream is being at least partly consumed
<lifeless> no error, but data not getting there
<spiv> I'd only *expect* partly, but I've been wrong before.
<lifeless> your bug report shows the case that the entire stream is eaten
<spiv> Right -- but I was also only pushing one new rev.
<lifeless> thats why the pack is deleted (it showed up as a no-op insertion)
<lifeless> one rev has a inventory too at minimum
<lifeless> so 2 records
 * spiv nods
<lifeless> If I guard it with 1,13
<lifeless> and make it mandatory
<lifeless> that will be safe I think
<spiv> (That rev should have a text and sig, too)
<spiv> So long as some prior RPC notices that remote is not 1,13
<spiv> But that guard is a good idea anyway, avoid trying the RPC when we know it won't work.
<lifeless> if its mandatory - no fallback - then we won't insert a partial stream
<lifeless> thats the correctness aspect
<spiv> Oh, I see.
<spiv> An ugly hack would be to first try with a stream of []
<lifeless> garh no
<spiv> I definitely don't want that as the final solution.
<spiv> But it would fix the current bug that's breaking bzr.dev...
<spiv> Oh, right.  Of course, you are unlikely to get an error back until the whole stream is consumed,
<spiv> because the whole request is sent before a response is sent.
<spiv> So yeah, the entire stream will be consumed... so I guess you're thinking of moving the fallback logic to closer to where the stream is being generated?
<lifeless> assuming this passes is it ok, to stop people running trunk corrupting repos
<lifeless> http://paste.ubuntu.com/120786/
<spiv> _is_remote_before((1,13)) will not be true most of the time, though.
<spiv> Unless the server is *really* old ((1,6) or earlier)
<lifeless> so unknown is > everything?
<spiv> Nothing ever does _remember_remote_is_before((1,13)) or whatever the magic is.
<lifeless> I thought v3 got the servers version
<spiv> Right.  It assumes "current", and then ratchets down based purely on RPCs that are unknown.
<spiv> There's a header, but it's currently purely advisory.
<lifeless> ah
<lifeless> so this is critical to fix:P
<spiv> (And its value is not necessarily parseable, it's more intended for human-consumption)
<lifeless> uhm, inserting [] will probably work
<spiv> You could make a new version of get_parent_map that's only in 1.13 ;)
<jfroy> hey people, quick census / survey: what would you consider to be the "essential plug-ins you should have"?
<lifeless> jfroy: depends on what I'm doing
<jfroy> I'm building a bazaar distribution and I'm now selecting the plug-ins I will include along with core.
<spiv> jfroy: for me personally, it's bzrtools, loom, pqm, launchpad, gtk, svn
<lifeless> jfroy: but see my patch for bundling some plugins for a list of ones we concluded were good to bundle
<spiv> But it definitely depends on what the person is doing.
<spiv> lifeless: so I need to go
<jfroy> The target audience is people who use primary subversion (bzr-svn is already in), and people who may be using another DVCS, likely git.
<spiv> lifeless: I think you now have all the relevant info for this bug, though.
<lifeless> spiv: ok; I'll insert []
<jfroy> lifeless: where is that patch? mailing list, bug?
<lifeless> bb:approve for that?
<spiv> lifeless: ok
<lifeless> jfroy: bundle buggy somewhere; its not finished {doesn't run the install for each plugin}
<lifeless> spiv: I'm surprised the RemoteV2 tests dont' trigger this
<spiv> lifeless: yep.  Ideally add the _remember_remote_is_before / _remote_is_before guard like other client methods do.
<spiv> lifeless: RemoteV2 tests know _remote_is_before((1,6))...
<spiv> lifeless: oh!
<lifeless> spiv: I'll get the simplest possible correctness fix up now
<spiv> lifeless: RemoteV2 also triggers an instant UnknownSmartMethod when you try call_with_body_stream
<lifeless> spiv: ah
<spiv> lifeless: it never consumes the stream in that case, because the encoder knows it can't be done :)
<jfroy> lifeless: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1217210104.21600.106.camel%40lifeless-64%3E?
<spiv> lifeless: perhaps it should consume the stream, just to make it harder to get confused...
<spiv> lifeless: after all, the caller has to cope with a consumed stream anyway...
<lifeless> spiv: well, we could look at buffering the stream in a T join, until we know success/fail (HTTP can error before a post completes)
<lifeless> jfroy: yes
#bzr 2009-02-21
<spiv> lifeless: a smarter TCP server could too
<spiv> lifeless: I have a TODO comment somewhere about that
<lifeless> spiv: just committed pushing to pqm now
<rysiek|pl> hi all
<rysiek|pl> guys, I must be missing something obvious
<rysiek|pl> I have two branches
<rysiek|pl> trunk
<rysiek|pl> and, branched from trunk at rev4, dev
<rysiek|pl> there were two revisions in dev, so dev's at rev6
<rysiek|pl> cd trunk
<rysiek|pl> bzr merge ../dev
<rysiek|pl> got me what was expected in the logs
<lifeless> you have to commit after a merge
<rysiek|pl> but the files are just as they were in rev4!
<rysiek|pl> I did
<lifeless> ok
<lifeless> did you do a 'bzr revert .' in there by chance?
<rysiek|pl> where?
<lifeless> in the commands you ran
<rysiek|pl> no, I didn't use revert at all in that repo
<lifeless> bzr log -v will show you the diffs of what when on
<lifeless> I will bet that your merge shows up with no change
<rysiek|pl> nope
<rysiek|pl> as I have said
<lifeless> that is; cd trunk; bzr diff -r -2..-1 -> no change
<rysiek|pl> everything's fine and dandy in the logs
<rysiek|pl> there is *some* change
<rysiek|pl> as if it merged with rev5 not rev6
<rysiek|pl> hmm
<rysiek|pl> I overlooked that
<rysiek|pl> anywhoo, trunk is now at rev5
<rysiek|pl> dev is at rev6
<rysiek|pl> files at trunk are at what was in dev at rev5
<lifeless> what does 'bzr missing ../dev' show
<rysiek|pl> http://wklej.to/Fq9L
<lifeless> spiv: I can push ok with the [] fix; its off to pqm
<lifeless> rysiek|pl: it certainly thinks its fully merged
<rysiek|pl> it certainly does
<lifeless> rysiek|pl: we can test this:
<rysiek|pl> I'll give you both logs
<lifeless> please do the following: http://paste.ubuntu.com/120797/
<lifeless> (adjust paths as needed)
<rysiek|pl> lifeless: dev branch (actually named "rysiek") log: http://wklej.to/0SMp
<rysiek|pl> lifeless: and the trunk post merge: http://wklej.to/nsaT
<lifeless> rysiek|pl: I don't suppose that you've forgotten to commit in dev ?
<rysiek|pl> nay, it was at 6 when I merged, look at the log messages
<lifeless> rysiek|pl: *dev* not trunk
<rysiek|pl> a sec
<lifeless> rysiek|pl: dev has a change to   tracmail/templates/list_index.html
<lifeless> in rev 6 and not in rev 5
<lifeless> trunk has a change to tracmail/templates/list_index.html in the merge from dev
<rysiek|pl> http://paste.ubuntu.com/120800/
<lifeless> so rev6 of dev is almost certainly merged just fine
<rysiek|pl> hmm
<rysiek|pl> I can't be *that* stupid
<rysiek|pl> oh, ffs
<lifeless> :)
 * rysiek|pl bangs his head against a nearby wall... repeatedly
<rysiek|pl> at least we broke the bore on this channel
<lifeless> lol
<rysiek|pl> there are days that it's better not to get outta bed
<rysiek|pl> everything is neat and dandy now, of course
<lifeless> cool
<lifeless> afk for a while
<fullermd> Correct: There are occasionally days when it's better TO get out of bed...
<rysiek|pl> I think I'll agree to that
<rysiek|pl> yeah, definitely
<Peng_> Like when you've gotten a new bed and want to move over to it.
<fullermd> If you position it right, you can just sorta roll over.
<rysiek|pl> tested, works
<rysiek|pl> thanks guys, you solved my big problem
<rysiek|pl> now... just how do I move the other bed so that the laptop's power cord reaches the wall socket...
<spiv> lifeless: great
<spiv> lifeless: and thanks!
<jml> igc: you da man.
<lifeless> jml: 1.12 I think
<lifeless> spiv: np, I like things working
<lifeless> spiv: if the stream is always fully consumed(and I think it is) it will not have been a data loss issue
<jml> lifeless: thanks.
<jml> lifeless: if you'd like, you can move the notice and merge the NEWS patch :)
<lifeless> ok, stream push is now landed *and* usable :P
<lifeless> but not for stacked yet
<lifeless> testing streaming push to stacked repos now
<rysiek|pl> lifeless: thanks again
 * rysiek|pl get's back to bed
<rysiek|pl> cu all
<cammoblammo> Does anyone have any idea when a more recent bzr might go into Debian unstable?
<Goundy> hi
<Goundy> ERROR: Selected-file commit of merges is not supported yet
<Goundy> What the hell is that ? ^^
<Goundy> I've 2 branches at local: main/ and working/ I commit working and then merge it into main/ then I try to commit main (to push it later) it returns this error
<luks> do you want to merge the whole working branch or just a few files from the branch?
<Goundy> luks the wole working branch but then I want to have different commit message for every file
<Goundy> isn't it possible ?
<luks> not if you want all the commit to apear as merges
<luks> you can merge the whole branch, revert everything except one file and commit that
<Goundy> luks i don't really care all I'm interrested in is keeping my commit message
<Goundy> ah
<luks> and then cherry pick individual files from the working branch
<Goundy> luks sounds complicated nevermind am going to commit the whole branch with the same message :/
<Goundy> thank you
<luks> well
<luks> if you don't care about remembering the merge at all, you can just use bzr revert --forger-merges
<luks> bzr revert --forget-merges
<luks> and then selectively commit
<Goundy> Ah
<Goundy> luks this point isn't discussed in the documentation of bazaar :/
<Goundy> I think a book like svnbook could be very nice for that project :)
<luks> in which part of the documenation would you expect to find it?
<Goundy> luks well I've read the two documents for learning bazaar
<Goundy> luks is there a bzrbook project for the future ?
<luks> I don't know about anything that would attempt to be a complete book
<Goundy> ah okay.. That'd be nice then :)
<Goundy> like the svnbook => everything about svn is there..
<luks> a lot of work, I guess :)
<Goundy> Indeed
<Goundy> but bazaar represents a lot of work also :P
<Goundy> and such a book will encourage more and more developers to use this software
<weigon> hmm, how can I get the bzr version of the remote bzr server ? (in this case launchpad.net) ?
<lucypher> Hi, I can't undestand a thing ... How can I see that bzr ignores changes in a file?
<lucypher> I have a file called app/core.php I have pushed this file on the repository, but I want that the future changes I do to this file will be ignored from the revisions.
<lucypher> I've added it to .bzrignore but everytime I change the file it is changed upstream too.
<Pieter> you can only ignore untracked files
<lucypher> so there is no way to ignore changes in a file?
<lucypher> If I use bzr remove -keep app/core.php it will be removed from the repo?
<cammoblammo> Does anyone have any idea when a more recent bzr will find it's way into Debian unstable?
<Stanlin1> helkp
<Stanlin1> help
<Stanlin1> how to download again the changes from a trunk
<asabil> Stanlin1: bzr pull ?
<eferraiuolo> Noticed the OS X 10.4 bzr 1.12 binary has been posted... Should I expect the OS X 10.5 one soon?
<emgent> hello
<lifeless> hi
<emgent> seems that there is a block problem with new bzr and old bzr-tree
<emgent> emgent@enJoy:~/Scrivania$   bzr branch lp:~emgent/ubuntu-cve-tracker/universe-security-updates
<emgent> Format <RepositoryFormatKnit1> for lp-45944144:///~emgent/ubuntu-cve-tracker/universe-security-updates/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<emgent> Format <RepositoryFormatKnit1> for bzr+ssh://emgent@bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<emgent> \ [===========
<emgent> blocked on downloading branch..
<emgent> and if i do bzr upgrade and try bzr update on the same branch faild with error, beacuse dont found dir/.bzr/checkout/
<lifeless> emgent: uhm, if you hit ctrl-C it won't have finished the download
<lifeless> the upgrade needs to be done on the server - "bzr upgrade lp:~emgent/ubuntu-cve-tracker/universe-security-updates"
<emgent> ah kk
<emgent> understand. danke.
<RainCT> wgrant: so, can I give bzr a revision number when I create a stacked branch? I've just read the docs for it and they don't mention anything like this
<wgrant> RainCT: No, you can't.
<wgrant> Stacked branches don't let you fully do what you want.
<RainCT> So I'd have to  bzr revert -rX; bzr push --overwrite   the original branch?
<RainCT> so that all revisions newer than X get into the new branch?
<wgrant> I don't quite know.
<wgrant> I also don't think that a branch of a branch remains stacked.
<RainCT> err... what? :P
<wgrant> If I have a stacked branch, I don't think a branch of it will be stacked.
<RainCT> oh
<lifeless> RainCT: what are you trying to do ?
<RainCT> wgrant: right, seems like it doesn't. So stacked branches are only useful for the server (ie, the computer actually hosting them, to reduce space usage)?
<RainCT> >> I have a bzr branch which originally included source files for images, which makes it huge (>  100MB), but this was later removed. So, now I'd like to create a new branch with like the 200 last  commits (so that it doesn't include that mess and is faster to fetch the first time, but that 'bzr  diff' and such can still be used being offline in most cases) and having it linked to the original
<RainCT>  brnch i)n case it's necessary to look up earlier revisions. How can I do this?
<RainCT> lifeless: ^ :)
<lifeless> RainCT: so stacked branches can't be used offline
 * wgrant suspects history horizons to be necessary here.
<lifeless> RainCT: they download less data to get your local tree built and new commits go into the new branch only (until you merge to the original branch or some such).
<lifeless> RainCT: stacking will let you download less data, but it won't give you ofline support today
<lifeless> we'd like to add that
<RainCT> uhm.. Why do I get Â«Source format does not support stacking, using format: '1.6' Packs 5 (adds stacking support, requires bzr 1.6)Â» with Â«bzr branch --stacked <dir>Â»?
<RainCT> Â«bzr upgradeÂ» says it's already the most recent format, and I have 1.12-1~bazaar1~intrepid1 from your PPA
<lifeless> RainCT: because the source branch format isn't one that can stack on others
<wgrant> bzr upgrade will only take it to packs-0.92, the default.
<lifeless> RainCT: and we try to preserve formats when possible so that people don't have accidental upgrades occuring
<RainCT> does the format introducing stacks work with the bzr version from intrepid?
<lifeless> RainCT: and 'bzr upgrade' takes you to the default format, which we are conservative about changing, because most folk don't like requiring other users to have the latest-and-greatest tool to access their code
<wgrant> RainCT: Yes.
<wgrant> But not Hardy.
<wgrant> But the bzr PPA is always useful for fixing that.
<lifeless>        bzr |    1.6.1-1 |      intrepid | source, amd64, i386
<RainCT> okay, so how can I upgrade it?
<lifeless> yu don't need to
<lifeless> the branch --stacked worked
<wgrant> But 'bzr upgrade --1.6', otherwise.
<lifeless> it simply told you that it was changing the format of the target
<lifeless> so that you won't be surprised if someone with bzr 1.4 can't access the new branch
<RainCT> Oh. But it's taking ages to get a stacked branch from LP
<lifeless> you just did 'bzr branch --stacked lp:foo somewherelocal' ?
<RainCT> bzr branch --stacked lp:freevial
<lifeless> yeah
<lifeless> there is a bug :(
<lifeless> it is downloading each file in the project in a separate roundtrip
<RainCT> Oh. And is there a workaround for it?
<lifeless> yes, wait.
<lifeless> The bug is a flip-flop - we were really fast in 1.6 itself, but we used up too much memory
<lifeless> now we use very little memory but are slow
<lifeless> the next change to that inner loop should get a reasonable balance
<RainCT> memory shouldn't be a problem here, I have 3GB free..
<lifeless> yes, but the code doesn't know that
<RainCT> heh yeah, I mean for the workaround, in case it uses more memory.. although nevermind that because it's not me who is going to use it anyway :P
<lifeless> bzrlib/knit.py line 1338
<lifeless> instead of splitting by prefix, just do it in one hit; thats the prior version that ate memory like it was going out of fashion
<RainCT> uh.. line 1338 is  "try:"
<RainCT> and there's no split around there
<lifeless> oh, you don't have bzr.dev :P
<RainCT> hehe
<lifeless>         if include_delta_closure:
<lifeless>             # XXX: get_content_maps performs its own index queries; allow state
<lifeless>             # to be passed in.
<lifeless>             non_local_keys = needed_from_fallback - absent_keys
<lifeless>             prefix_split_keys = self._split_by_prefix(present_keys)
<RainCT> so I change the last line to   prefix_split_keys = present_keys   ?
<RainCT> *** Bazaar has encountered an internal error.       awesome :D
<RainCT> well, don't worry, I'll wait until there's a new version fixing this :)
<RainCT> wgrant, lifeless: thanks for your time!Ã§
<lifeless> RainCT: np, sorry that its not good in this area at the moment
<RainCT> good night
#bzr 2009-02-22
<KhaZ> Hi!  Quick question here.  I've historically ran one large depot in svn, with multiple projects inside of it.  I'm thinking of splitting them each into their own repositories - is there a 'smart' way of doing this, so as to keep revision history?
<lifeless> bzr svn-import will may just do the right thing
<lifeless> it will depend on how your svn repo is structured
<KhaZ> Sorry, I should have specified - I've currently bulk imported them into a bzr repo
<lifeless> using svn-import ?
<KhaZ> Yes.
<lifeless> and it didn't identify the branches for you ?
<KhaZ> So I've got one giant repo with allm y changes from svn (Yay svn-import!), and I'd rather not lose them as I break them into smaller repos.
<KhaZ> Well, I didn't do my svn repo as branches.  It was more just a series of directores inside of 'trunk'.
<lifeless> ok
<lifeless> well you can tell bzr-svn where the branches should be
<lifeless> then svn-import again, and it will split appropriately
<KhaZ> lifeless: Is there any thing I can do the bzr depot?  I've grown rather smitten with bzr and have been doing changes against it, instead of svn.
<lifeless> KhaZ: well, you can use bzr split, but it will still keep the older history as being one-big-depot
<lifeless> so if you're splitting for size reasons it won't help you, but if you'resplitting just for clarity it will do what you need
<KhaZ> lifeless: So, say I have directories A, B, C, and I want to split them into their own depot.  Are you saying it'll keep all the histories, but only branch the contents?
<KhaZ> (i.e., I'll have branch 'A' with only contents from A, but histories from B and C as well?)
<lifeless> yes
<lifeless> because one commit back would be the big tree
<lifeless> what split does is essentially bzr branch your depot, delete everything except the named directory (e.g. A) and then commit
<KhaZ> And there's no way to obliterate history in bzr?
<lifeless> not directly no
<lifeless> you could fast-export your depot then fast-import-filter it back in
<KhaZ> Hrmm.  I guess I'll have to think about this.
<lifeless> the fast-export approach soundslike its the closest fit to what you're asking for
<lifeless> (its a bzr plugin)
<KhaZ> lifeless: Ah, neat.  I'll have to check that out.
<KhaZ> Thanks for spitballin' with me lifeless .
<lifeless> np
<lifeless> jml: around?
<jml> lifeless: am now.
<lifeless> what would you like to see in subunit before an announcement to tip
<lifeless> or alternatively
<lifeless> what things are 'it really should have' for subunit that it doesn't
<lifeless> jml: ^
<jml> lifeless: a web page with some friendly guff + documentation.
<jml> lifeless: not sure what else
<jml> lifeless: some kind of effort to integrate with nose, maybe
<lifeless> what would that do?
<jml> lifeless: get nose to print subunit output
<lifeless> ah, tell it to use a subunit TestResult?
<lifeless> https://edge.launchpad.net/subunit isn't sufficient guff?
<lifeless> bug 332770
<ubottu> Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770
<lifeless> jml: with pycon coming up it seems worth trying to get a 'release' done
<jml> lifeless: I think a more friendly "how to" style document would be a good idea
<lifeless> jml: do  you have any interest in writing it ?
<jml> lifeless: yes.
<lifeless> cool
<jml> lifeless: but before pycon? ... we'll see.
<lifeless> jml: what would you expect the commands 'subunit-filter' and 'subunit-ls' to do
<lifeless> abentley: the --no- option stuff - was that exposing something optparse does anyway, or custom for bzr?
<scode> I would like to use bzr with a workflow similar to what is often used with e.g. darcs/git, where I have my 'upstream' repository that I have branched on multiple places. I then want to commit and periodically push from all these places, but I do not want to do a bunch of merges all the time.
<scode> I have vague recollection of there being a way to do a "flat" merge that does not track the merge history to accomplish this, but I cannot find it now.
<scode> I.e., the problem isn't that I have to use "bzr merge", but rather that I do not want to litter the history with a lot of bogus merges that do not actually represent merges frmo the perspective of the workflow.
<luks> by flat merges you mean joining multiple commits into one?
<luks> or re-applying the patches from the merge branch?
<lifeless> scode: well, if you actually have flat history there won't be merges at all
<lifeless> scode: so if its just you on many machines
<scode> I want to merge the changes into my wc without bzr actually treating it like a merge.
<scode> Example workflow:
<scode> * branch to A and B
<lifeless> scode: you can just sit down, bzr pull, commit push etc
<scode> * add file in A, commit, push
<scode> * add file in B, commit push -> bork because I need to merge, merge, push -> upstream now has a merge in the history
<lifeless> scode: so if you have committed in A and B concurrently, you need to merge
<scode> lifeless: Yes, but it's very easy to forget to push , and sometimes I may not have access to do so.
<lifeless> scode: you ahve two choices, don't actually commit in B until you pull, or rebase
<scode> Using the rebase plugin?
<lifeless> yah
<lifeless> its how many git users avoid merges
<lifeless> I don't think merges are an issue myself - if you have actually done concurrent changes they just reflect reality after all :)
<scode> Well, in git I don't end up with having to merge by default at all, assuming no conflicting changes.
<scode> And definitely not with darcs.
<scode> lifeless: Well, in this case it's not very useful and just confusing to be keeping all that merge info in the history.
<scode> lifeless: Especially since the branches are not really branches workflow wise, and have no identification.
<scode> Just n random branches.
<scode> Anyways.
<scode> lifeless: Thanks!
<lifeless> scode: so you can also
<lifeless> merge --pull
<lifeless> (or just pull)
<lifeless> git doesn't have magic here - a fast forward pull is either an exact match, or a rebase, or an implicit merge
<lifeless> (where it merges for you)
<scode> lifeless: Yeah, but since git doesn't track merges it doesn't really matter :)
<luks> it does
<scode> In the case of darcs there's definitely no difference at least, I could be wrong about git.
<lifeless> scode: you mean in log? (git does track merges, exactly the same as bzr - a list of N parents to a commit object)
<scode> In the sense of not affecting revision numbers, etc since your branch is just a sequence of hashes.
<scode> Though I guess it doesn't look too nice if you ever want to check out the branching history.
<scode> I suppose what I really want in this case is simply darcs semantics.
<lifeless> scode: yes, darcs semantics are quite nice in some respects
<lifeless> jml: if you're around, I have a subunit-ls too; pondering same-branch/different-branch
<nabob> hi
<abentley> lifeless: The hidden, automatic nature of the no- options is custom.
<pisi> Stupid question but something that always pisses me off with web based VC viewers: how could I checkout http://bzr.tensixtyone.com/pytikitag/files ? which is the URL for bzr ?
<james_w> it's not clear
<james_w> unfortunately there is no way to know, as it is possible to set up access to the branches in many ways
<pisi> is there some standard or something that I could try?
<james_w> well, using the same URL often works (without the "/files" bit)
<james_w> but in this case it doesn't seem to
<Peng_> Loggerhead trunk can now serve bzr, and gives the URL for it.
<alf> Hello, in my new job I have to use svn for revision control. Being very fond of bzr I have been thinking of using bzr-svn to interact with the subversion repository.
<alf> I am whether this can cause any problems for other using the svn repository (through normal svn)?
<alf> + wondering
<alf> eg the file/revision properties that bzr-svn uses
<beuno> alf, I don't think so, I know many people who use bzr-svn to interact with svn at work
<andresj> hello, whats the difference between `mkdir one; cd one; bzr init .; bzr pull /some/path;` and `mkdir two; cd two; bzr branch /some/path .`
<andresj> ?
<alf> beuno: Well, I am going to give it a try and hope for the best!
<alf> Is there a way for bzr-svn to record merges in logs?
<alf> I mean, to also include the logs of the merged revisions in the svn log entry
<beuno> alf, I don't really know, i haven't used it myself
<james_w> andresj: doesn't the second create two branches?
<james_w> andresj: ah, misread, the second puts the branch in ./two/path/, the first in ./one/ I believe
<james_w> hey beuno
<lifeless> andresj: the second will probably error, as branch creates a branch
<lifeless> andresj: other than that they are essentially identical
<lifeless> andresj: the latter can be spelt 'bzr branch /some/path two'
<james_w> hey lifeless
<lifeless> hi james_w
<lifeless> alf: apparently some svn servers have a commit hook that includes diffs to file properties; bzr-svn can create noise there, but thats all
<andresj> lifeless: wait what about an error with the second one?  `bzr branch /some/path .` should make the current directory the branch
<lifeless> andresj: 'mkdir .' -> fail
<lifeless> andresj: 'bzr branch foo bar' does a mkdir bar
<andresj> hum, really? oh but i see what you mean---so they basically do the same thing. thank you, lifeless :)
<beuno> huya james_w!
<lifeless> andresj: the major difference is that the format won't be preserved
<andresj> hold on a second, please, lifeless
<andresj> (stupid old router ;P)
<andresj> ok im back :)
<andresj> what format wont be preserved, lifeless?
<lifeless> andresj: e.g. if /some/path is something non-default, like a loom, 'bzr branch' will preserve that, but doing a manual init won't.
<andresj> hum... i see, i see---so ill be sure to branch instead of init, pull from now :P
<lifeless> andresj: http://paste.ubuntu.com/121561/
<andresj> lifeless: http://paste.ubuntu.com/121562/ ;P
<lifeless> andresj: heh
<igc> morning
<mwhudson> hi igc
<igc> hi mwhudson
<lifeless> jml: when you get a chance, after work or so; subunit - new branch to review
<jml> lifeless: ahh right.
<jml> lifeless: so, in answer to your earlier question....
<jml> lifeless: I'd expect subunit-filter to be a thing like grep that used higher-level subunit concepts, rather than regexen
<jml> lifeless: and I don't have a clear idea of what subunit-ls would do -- discover tests in ... what?
<ronny> subunit?
<lifeless> jml: it outputs just their names
<lifeless> jml: like lsdiff outputs the files altered in a patch
<jml> ronny: https://launchpad.net/subunit
<ronny> looks usefull
<ronny> does the python child support things like nose?
<lifeless> bug 332770
<ubottu> Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770
<lifeless> ronny: the python child is a unittest.TestResult
<ronny> oh, sad
<lifeless> ronny: so anything that honours that protocol will work with subunit
<ronny> i really dislike unittest tho
<lifeless> nose is basically unittest, last I looked
<lifeless> though they seem to be going slowly mad
<ronny> well, it hides away the pain
<ronny> lifeless: i could use a tool that can set up different envs with different versions of a tool
<ronny> so i can run anyvc's unittests against all supported versions of hg, bzr, dulwich, subvertpy
<lifeless> jml: does testtools have load_tests support yet? or scenarios?
<jml> lifeless: spiv has a patch up for scenarios
<lifeless> ronny: bzr has interface tests for this purpose; we write tests to an interface and parameterise the tests
<jml> lifeless: I'm a bit suspicious of load_tests, partly due to ignorance.
<ronny> lifeless: thats what i do in anyvc, too
<spiv> jml: API xenophobia?
<lifeless> jml: its my third attempt at that problem, I think its the right one
<ronny> currently i run against one version of each tool
<ronny> i'd prefer to be able to run against multiple versions
<lifeless> jml: I'd be happy to discuss
<lifeless> ronny: right, so test parameterisation setting python paths; and subunit to get a fresh interpreter for each, ftw
<jml> lifeless: it's possible. everything else in testtools (IIRC) is things that have been used in more than one project.
<jml> [modulo grammar]
<jml> lifeless: but likewise, am happy to talk about it later.
<lifeless> jml: load_tests is simply a hook for TestLoader, between implicit discovery and actual use.
<ronny> lifeless: i'd like to have a way to pass the parameters as something like pkg_resource requirements or something, and setting up a custom virtualenv for each
<lifeless> ronny: yes, that would be trivial glue on top
<lifeless> the parameters would be in your scenario definitions
<lifeless> your external test case proxies would turn those into virtualenv however you want to do that
<ronny> lifeless: sounds nice
<ronny> lifeless: hmm, the protocol seems confusing, does it have any base?
<ronny> lifeless: got a bnf gramar or something like that?
<lifeless> spiv: ping
<lifeless> ronny: not really, it was designed to be primarily human readable
<ronny> oh :(
<lifeless> ronny: I can whip up a BNF at some point; its nearly a BNF anyhow in the README
<spiv> lifeless: pong
<lifeless> spiv: what is the mechanism by which pack-names is refreshed when the autopack rpc is used?
<lifeless> spiv: streaming push needs the same thing
<spiv> lifeless: bzrlib/smart/packrepository.py
<spiv> lifeless: the verb just relies on _pack_collection.autopack() to DTRT
<lifeless> spiv: I mean on the client
<spiv> Oh, right
<lifeless> self._real_repository - how does it see the new pack
<lifeless> is there a 'refresh thyself' method I can call from RemoteSink ?
<spiv> self._real_repository._pack_collection.reload_pack_names()
<lifeless> I die a little every time
<spiv> That line in remote.py is preceded by a comment saying that perhaps the automatic retry logic will make that unnecessary...
<lifeless> spiv: it doesn't
<lifeless> spiv: for streaming push
<lifeless> spiv: because no file IO errors occur, we just have a new pack that the real repo does not know about
<spiv> Ah, yeah.  Unless an autopack did occur, of course.
<spiv> But not in the general case.
<lifeless> :!./bzr --no-plugins selftest branch_implementations.*Remote
<lifeless> passes
<ronny> lifeless: another thing i dont get is that obsession with xunit
<lifeless> ronny: reusable code is good
<ronny> lifeless: but xunit isnt exactly nice in python
<lifeless> unittest is somewhat fugly
<lifeless> but that was barely even a transliteration of xUnit
<lifeless> py.test makes my want to cry
<ronny> 1:1 transliterations never end well :(
<ronny> lifeless: dont ever support it
<lifeless> doctest has caused enough grief that we should sue the author
<lifeless> 'crimes against humanity'
<ronny> these insane fuckers dont deserve support ;P
<mwhudson> i think when it comes down to the ugly details of testing "real" code things like "xunit offends my sensibilities" go flying out of the window
<ronny> py.lib and py.test are damn messed up
<lifeless> spiv: so coordination call?
<spiv> lifeless: sounds good
<lifeless> skype or pots
<spiv> either's fine with me
<ronny> i wouldnt mind unittests so much if unittest keept the tests more readable and used pythonic patterns
<ronny> eh unittest i mean
<ronny> the problem is, it works, so we are stuck with it
<santagada> I really enjoy py.test... but doctests drives me crazy
<ronny> santagada: py.test is only fun till it breaks things
<ronny> then it wil lbe impossible to debug it cause of the insane things in it
<santagada> ronny: I only used it in pypy, so it never broke anything...
<santagada> ronny: I got I little insane trying to learn how to write a plugin for it
<santagada> but after you get the hang of it it is quite straightforward
<santagada> I think the biggest problem is lack of real docs, about internals and all
<ronny> i ditched it for nosetest
<ronny> less magic more docs
<ronny> lifeless: btw, how are the nose devs starting to go insane?
<santagada> ronny: nosetest is cool, but less magic also mean less cool features
<ronny> santagada: what do you think is missing?
<ronny> the more magic is involved the harder debugging real breakages gets
<santagada> specially when you assert something py.test has much more information about the variables involved
<ronny> nosetest -d enables assert introspection
<santagada> this is probably new
<ronny> been there since ages
<ronny> afair its also allmost ported to jython, ironpython and python3
<santagada> either I didn't notice it or it doesn't work like py.test
<ronny> it doesnt do weird magic onless you ask it to
<santagada> ronny: have you tried the one from twisted?
<santagada> trial I think
<ronny> yeah, behaved weird, no idea if it was my fault
<ronny> im kinda allergic to the crimes twisted generates
<spiv> abentley: bundlebuggy
<spiv> abentley: bundlebuggy is 502ing
<abentley> spiv: restarted
<ronny> santagada: im thinking about writing an own one later
<ronny> lifeless: why is the stream like test: thelabel\nresult: thelabel [...]
<ronny> wouldnt it be enough to just pass the results
<mwhudson> ronny: you seem very opinionated :)
<ronny> mwhudson: yeah
<santagada> ronny: please don't do it... create a plugin for py.test or nose
<ronny> most likely for nose
<ronny> i'd like it to report to a dbus location
<spiv> abentley: thanks!
<santagada> see, something easy to do with py.test, probably the same with nose
<santagada> gtg
<ronny> lifeless: it would be nice if there was a way to track extra stuff like tracebacks or stdout/stderr for the tests
<lifeless> ronny: the nose devs seem to be slowly adding py.test magic
<lifeless> ronny: I should track it more closely, because thats as accurate and precise as I can be at the moment
<lifeless> ronny: re: trial, trial is largely sane now thanks to jml
<lifeless> ronny: re: the duplication, its to catch interrupted streams
<lifeless> ronny: and hung tests
<lifeless> start, finish catches hung tests
<lifeless> start THING, finish THING -> catches interrupted tests (start FOO, start BAR, finish BAR, and similar)
<lifeless> spiv: down to 63 calls for non-stacked
<jml> lifeless: trial has been improved now by many people since I was actively working on it.
<lifeless> jml: I credit you with unfucking it when it was at its worst
<lifeless> jml: the rest is just folk understanding that it can be good
<lifeless> jelmer: ping
<ronny> lifeless: do you see any reasonable way to hook into getting extra data like timings, stdout/stderr produced by each test and others?
<lifeless> ronny: sure, as long as its in the test comment area of the protocol its captured and put in the RemoteBacktrace
<lifeless> timings -> use the time: tag
<ronny> ah, k
<ronny> i'll have to get more into it
<lifeless> I need to add builtin generation of time: tags in the python client
<lifeless> for now its just defined in the protocol, for folk doing benchmark work
<lifeless> ronny: one of my main uses today is:
<lifeless> bzr selftest --subunit > tests.log
<ronny> lifeless: btw, why do you leave many ways to spell some things like test vs testing?
<lifeless> subunit-filter < tests.log | subunit-ls > failing.list
<lifeless> bzr selftest --load-list failing.list
<lifeless> and loop
<lifeless> (with hacking in the middle)
<ronny> woot
<lifeless> only loads tests that failed the previous time around
<lifeless> ronny: test|testing|etc etc - generous in what you accept, strict in what you emit :)
<lifeless> ronny: some folk are funny about what they want to see
<ronny> hmm, i wonder if there is a reasonable way to deal with generator-tests
<lifeless> do you mean factories that create many tests?
<ronny> yeah
<ronny> their test id's are a bit messy in nose
<lifeless> for subunit it doesn't care - it doesn't require unique ids
<lifeless> but its the same really as bzr's test scenarios
<lifeless> have you seen our ids ?
<ronny> no
<ronny> i guess you guys just rerun the full generator?
<lifeless> test_merge_sorted_range_stop_include_forward(BzrBranchFormat5)
<ronny> (or do you have a way to figure what part to rerun)
<lifeless> for loading tests do you mean ?
<ronny> yeah
<lifeless> we generate all the scenarios and filter
<spiv> It'd be possible to do better than that with the load_tests hook, if we cared.
<spiv> (I think)
<ronny> ie skip scenario generators that completely passed?
<lifeless> ronny: pass the filter into the generator
<spiv> Right.
<lifeless> spiv: be difficult to balance filter generalism with actual skipping though
<spiv> At the moment generating a scenario is sufficiently cheap that we don't care.
<spiv> lifeless: yeah
<spiv> lifeless: see also "if we cared" ;)
<ronny> wouldnt i have to manage filtering myself then?
<spiv> Well, I'd imagine we'd provide filtering by default in our TestScenarioApplier or whatever its called.
<lifeless> ronny: you could ignore the parameter if you didn't care
<lifeless> myself, I think the current solution is simple and sane
 * spiv agrees with lifeless
<ronny> lifeless: are there any conventions for the result metadata?
<ronny> (ie the comment block)
<ronny> just want to know it it would make sense to even try parsing
<lifeless> ronny: the python client writes the stacktrace in a way that can be reconstituted
<lifeless> ronny: but other languages may not - e.g. the C client could just 'SEGFAULT' :P
<lifeless> spiv: heh:     self.assertEqual(1, autopack_calls + streaming_calls)
<lifeless> AssertionError: not equal:
<lifeless> a = 1
<lifeless> b = 4
<lifeless> spiv: yay for tests eh what
<ronny> hmm
<spiv> lifeless: :)
<ronny> i really wish things like self.assertEqual(a,b) would go away for assert a==b
<lifeless> ronny: I like my tests to work with pyo files :)
<ronny> lifeless: i kinda hate that optimazion - also - who the heck tests that way (bzr selftests are an exception thi)
<lifeless> spiv: I want remember_remote_is_after()
<lifeless> ronny: it is an odd optimisation :P
<spiv> ronny: not all assertions are about equality, though...
<spiv> lifeless: (not that I doubt you do want that) what for?
<spiv> lifeless: the existing infrastructure for coping with different client/server versions is definitely a bit too simple.  At least it isn't a bit too complex, though ;)
<ronny> spiv: i dont see any reason why most of those self.assertFoo couldnt go away for just assert
<lifeless> spiv: after I know that streaming push works
<lifeless> spiv: or perhaps medium.verb_exists(verb)
<spiv> ronny: grep for "def assert" in bzrlib/tests sometime
<spiv> ronny: the base assertion methods on TestCase aren't so interesting
<lifeless> spiv: 60 and 85 now
<lifeless> spiv: bzr search -s assert
<lifeless> spiv: much more useful :)
<spiv> ronny: it's the domain-specific ones that any sizeable project starts growing that really interesting.
<jml> (and actually, assert methods are kind of lame)
<ronny> spiv: the ones i have seen so far use only self.assertEqual
<ronny> hmm
<lifeless> jml: I'm thinking of dropping subunit.RemotedTestCase from the id of RemotedTestCase's
<lifeless> jml: thoughts
<jml> lifeless: I manually drop it in Tribunal
<lifeless> jml: ok, I'll nuke it tonight
<jml> lifeless: cool.
#bzr 2010-02-22
<mkanat> lifeless: A modification to "bzr patch" would probably be the place, yeah?
<lifeless> mkanat: yes, that might make sense. or import-patch, a new command.
<mkanat> Yeah. Although I'd like to see "patch" do other nice things, too (like understand renames), so it might just make sense to improve it.
<bob2> meoblast001: struct module isn't that bad
<lifeless> mornink poolie
<poolie> hello there
<lifeless> mkanat: I think it would surprise people to have 'patch' do a commit ;). I think there are two use cases, but probably we want common code paths internally.
<mkanat> lifeless: Well, yeah, doing a commit would be surprising for sure. :-)
<lifeless> mkanat: but thats what I want it to do; commit on a temp branch and merge back
<mkanat> Ah, okay.
<lifeless> mkanat: and you said you'd like that as well :>
<meoblast001> bob2: yeah, but how can i guarantee that it's 4 bytes bigendian?
<mkanat> lifeless: Yeah, for sure. bzr diffs include date info, so you could even do it automatically.
<lifeless> meoblast001: by the format you give it
<mkanat> lifeless: If no revno was specified.
<meoblast001> ah, ok
<lifeless> pydoc struct
<lifeless> hmm, functions there have bad docs; you'll want the python online docs.
<lifeless> mbarnett: are you around
<jml> the pypy people are interested in getting benchmarks from various python projects
<lifeless> awesome
<jml> does bzr have some benchmark scripts to share?
<lifeless> usertest
<lifeless> its kindof a plugin
<poolie> hello jml
<lifeless> it runs bzr against real-worldish scenarios
<lifeless> and the 'bzr' it runs can be differnet versions, or run in customised ways
<lifeless> so it should be easy to tweak it to say 'pypy bzr' rather than 'bzr'
<lifeless> poolie: I've just submitted a 'use subunit' patch to PQM, that spiv reviewed over the weekend.
<poolie> ok...
<lifeless> poolie: should be no fallout, but if there is its my fault, sic me onto it.
<poolie> actually when you mean 'to pqm'
<poolie> do you mean changing pqm, or changing bzrlib?
<lifeless> pqm.bazaar-vcs.org
<lifeless> changing bzrlibs Makefile
<poolie> :/
<poolie> you know sometimes people say "but i'll give people a chance to object"
<lifeless> poolie: I was of the understanding that it was simply tuits missing to do this; so I found somes.
<lifeless> poolie: it was up in the queue for over a day; and its easy to back out
<lifeless> poolie: I didn't think it was contentious
<poolie> i think it's worth a try
<poolie> i'm just saying saturday night to monday morning is not really likely to have people see it
<poolie> so this makes subunit a hard dependency to run bzr check
<poolie> that might be worth documenting
<lifeless> 'make check' specifically
<poolie> s//make check
<lifeless> not selftest, which is what we generally advise.  Yes, good point, I'll add some doc
<poolie> i'm pretty sure that pqm's mail stuff is not 8-bit clean therefore it the stream parser will crash
<poolie> but we'll see
<poolie> istr it reads it as lines and reinserts \ns
<poolie> but it may work
<lifeless> poolie: I don't think that the weekend should really be specially treated; we only have 24 hours of non-core-people-working coverage regardless; and we more core committers than staff paid to work on bzr [at this point in time]
<lifeless> poolie: once it lands I'll send a broken patch through to see how it handles it
<poolie> i think there's pretty clearly more activity from both staff and nonstaff developers during the week
<poolie> anyhow
<poolie> if that works it'll be good
<poolie> s/if/when :)
<lifeless> we don't have an official quiet-period where things approved get a chance to be looked over by other people at the moment; I don't understand why patches put in in the weekend should get one, and ones in the week not get one.
<lifeless> I'm not trying to be difficult, I really don't see the connection
<lifeless> we do have a 'use judgment' angle; the flipside to that is that people will
<exarkun> I'm noticing some issues with running 'bzr svn-import' against the same repository multiple times concurrently
<exarkun> I'm going to file a ticket or two about it I guess
<lifeless> poolie: it failed to land anyhow; subunit isn't in the chroot (which is odd because we had it in the chroot a few months back; possibly before we upgraded the chroot though)
<poolie> so
<poolie> people tend to have comments on changes to infrastructure
<poolie> it's just polite to give them a chance to express those opinions
<poolie> considering the review concluded at midnight on sunday(!) looks a bit like routing around it
<poolie> i think the actual change is fine
<lifeless> If I had submitted it at 1am I could understand that perspective; but I submitted it at 11:30am or so
<poolie> i expect it will break but it should be fixable, and it's worth fixing
<lifeless> very much not avoiding things; everything to do with spiv's sleep schedule :)
<lifeless> something about this leaves me unsettled. I need to mull on it I think.
<mkanat> mwhudson: Any new crashes?
<twb> I'm rolling binary packages from a bzr repository.  I want a way to get a short, monotonically increasing string to describe the repository state.  Bonus points if it is in <last tag name>+<revisions since last tag> format rather than just <number of revisions>.
<twb> The git equivalent is "git describe --tags" and the hg equivalent is hg parents --template '{latesttag}+{latesttagdistance}\n'
<lifeless> twb: bzr revno
<lifeless> you'll want to set the 'is a mainline' flag to stop people pushing altered trunks though
<lifeless> append_revisions_only=True
<mwhudson> mkanat: no
<mkanat> mwhudson: Okay.
<twb> v=$(bzr tags | tail -1); v=${v%% *}+$(($(bzr revno) - ${v##* }))
<fullermd> That sounds...   unuseful.
<fullermd> For one things, tags sorts by the tag name, and for another, they may not be on integral revnos.
<twb> You have fractional revnos?
<fullermd> Not exactly, but they read that way.
<twb> Blergh
<twb> These packages aren't important, so I'll use that shitty code until it breaks
<twb> Is it just me, or is bzr export REALLY slow on a --lightweight checkout?
<fullermd> If the branch is very far away, that wouldn't be surprising.
<twb> It's lp:dosage, fwiw
<fullermd> Across the internet easily qualifies as "very far away"   :)
<twb> I notice that bzr export eats the existing file instead of writing to a temp file and then doing a final move.
<twb> i.e. while bzr export is running, or if it is interrupted, the old tarball is bogus
<fullermd> Well, it's probably not really designed for its destination to exist already.
<meoblast001> lifeless: in the doc for bzrlib.branch.ChangeBranchTipParams, i can't find anything about commit author
<lifeless> meoblast001: branch/repository.get_revision(new_revid).authors
<meoblast001> ah, ok
<meoblast001> uh oh, bazaar choked on my plugin
<meoblast001> lifeless: is the bzrlib.branch.ChangeBranchTipParams my branch/repository?
<meoblast001> or is that a member of it
<meoblast001> or do i just use "branch"
<lifeless> meoblast001: it has a branch attribute
<lifeless> see the pydoc for i
<lifeless> it
<meoblast001> ah, ok, i see now
<meoblast001> there seems to be a lot of "branch" in Bazaar :P
<meoblast001> lifeless: is there a place i could go to see all the members of this branch, that way i can stop nagging you :P
<lifeless> meoblast001: pydoc + the source
<lifeless> there are apidocs mwhudson publishes somewhere
<meoblast001> i tried bzrlib.branch.ChangeBranchTipParams.branch, but got no Python documentation found for 'bzrlib.branch.ChangeBranchTipParams.branch'
<meoblast001> but then again, i shouldn't be guessing, as this is my first day ever writing Python code
<meoblast001> and i don't even know where the source to those .py files lie
<lifeless> meoblast001: just do pydoc bzrlib.branch.ChangeBranchTipParams
<lifeless> the branch attribute is a 'bzrlib.branch.Branch'
<meoblast001> lifeless: i did that
<lifeless> so pydoc bzrlib.branch.Branch
<meoblast001> i'm so lost of what derives from what, what already exists
<meoblast001> ok, thanks
<meoblast001> lifeless: i can't find repository or get_revision
<meoblast001> oh yay, i managed to crash pydoc
<meoblast001> lifeless: is there an online documentation for this?
<meoblast001> it would probably be easier for me
<lifeless> yes, mwhudson has apidocs published
<lifeless> mwhudson: where are they?
<mwhudson> lifeless: python.net/~mwh/bzrlibapi
<mwhudson> might be a bit out of date now actually
<lifeless> meoblast001: ^
<meoblast001> ok, thanks
<meoblast001> i hope i can do this >.<
<lifeless> you could mail the list and ask for help
<lifeless> folk do that quite regularly.
<meoblast001> i think my Python knowledge is just horrible
<meoblast001> i can't understand if i'm supposed to be using branch.Branch, or branch.repository, or result.branch
<meoblast001> probably would be easier for me to write a Git plugin but i don't use Git
<lifeless> meoblast001: the params object you're given has a branch attribute
<lifeless> that is a branch object
<meoblast001> ok
<meoblast001> that's what i was wondering
<lifeless> meoblast001: it is an instance of bzrlib.branch.Branch
<meoblast001> there is no get_revision() function in Branch though, according to the docs
<lifeless> meoblast001: thats right. you want branch.repository.get_revision()
<lifeless> where branch is the branch object you're starting from
<meoblast001> hm, it's not listing a member named repository in the docs
<meoblast001> http://python.net/~mwh/bzrlibapi/bzrlib.branch.Branch.repository.html < also does not exist
<lifeless> meoblast001: so your function is called with an object. I'm going to call that 'params'
<lifeless> 'params.branch' is a Branch instance.
<meoblast001> ah, ok
<lifeless> Branch instances have a repository attribute. So 'params.branch.repository' is an instance of bzrlib.repository.Repository
<lifeless> meoblast001: you can examine this interactively.
<meoblast001> what does get_revision(new_revid) return?
<lifeless> define your hook function as
<lifeless> def myhook(params):
<lifeless>     import pdb;pdb.set_trace()
<lifeless> now do a pull or something in a test branch
<lifeless> you'll drop into pdb
<lifeless> you can use 'pp params' to pretty print params
<lifeless> dir(params) to see the attributes of params
<meoblast001> yay
<meoblast001> found the revision object
<lifeless> 'vars(params)' to see its variables and their values
<meoblast001> hm, can't find a list of its members though
<meoblast001> only its member functions
<lifeless> the revision object docs are a bit weak
<lifeless> however
<lifeless> vars(revisionobject)
<lifeless> should print something sensible
<meoblast001> silly me, // does not comment Python code >.<
 * meoblast001 needs to use #
<lifeless> using pdb will probably help you explore the system a lot
<lifeless> even if it has a little learning curve
<meoblast001> yeah, i'm getting no arguments passed to my function
<meoblast001> Post_Change_Branch_Tip() takes exactly 1 argument (0 given)
<meoblast001> i set it with branch.Branch.hooks.install_named_hook ('post_change_branch_tip', Post_Change_Branch_Tip, 'Announce Commit')
<lifeless> show me the definition of Post_Change_Branch_Tip
<meoblast001> http://pastebin.com/d79e4cd50
<lifeless> line 46 is your problem
<lifeless> you are calling your hook; don't do that.
<lifeless> once its installed bzr will call it at the right time.
<meoblast001> oh >.<
<meoblast001> how did i leave that there
<meoblast001> i was doing some independent tests without Bazaar for a bit there, must have forgotten to remove that line
<lifeless> if you put '  import pdb; pdb.set_trace()' at line 25, then when bzr calls it, you will be put into a debugger.
<meoblast001> just to check that my backend could properly process the results
<meoblast001> it doesn't actually list the vars
<meoblast001> isn't that what vars() is supposed to do?
<lifeless> no
<lifeless> its a function
<lifeless> so you need to print its output
<lifeless> if you are in a read-evaluate-print-loop, results are printed automatically
<meoblast001> ah, ok
<lifeless> which is what pdb would put you in
<meoblast001> print vars (result.branch.repository.get_revision (new_revno))
<meoblast001> not printing
<meoblast001> does vars return a string?
 * meoblast001 googles
<meoblast001> lifeless: this pdb, is it extremely useful?
<lifeless> yes
<lifeless> meoblast001: just put this in as your hook function
<lifeless> def myhook(params):
<lifeless>     import pdb;pdb.set_trace()
<lifeless> and then install it as normal - bzrlib.branch.Branch.hooks.install_named_hook('....
<meoblast001> still nothing
<meoblast001> the only real issue i'm having is here
<meoblast001> print vars (result.branch.repository.get_revision (new_revno))
<meoblast001> nothing is being printed
<meoblast001> i'm going to do a full test on this, see if it all runs well
<lifeless> meoblast001: well, by nothing, what do you mean?
<lifeless> if you do a pull or ap ush with the little hook I gave you, bzr should put you into a interactive prompt
<lifeless> note that you need to do that locally, not on your server
<lifeless> because on the server it can't show you the prompt :)
<meoblast001> ok
<meoblast001> well i'm going to do this one last test, then i'll try that if it does not work
<meoblast001> lifeless: aparently new_revid doesn't exist
<meoblast001> i'm assuming i need result.new_revid?
<lifeless> yes
<meoblast001> lifeless: all works except for one thing
<meoblast001> i need a way to obtain the branch name
<meoblast001> oh, and an integer of the latest revision number
<meoblast001> i have a var dump though
<lifeless> meoblast001: branch.nick may be what you want; and new_revno from the params object
<meoblast001> lifeless: i guess there's always result.branch._last_revision_info_cache[0]?
<meoblast001> ah, silly me
<lifeless> no, _ prefixes mean 'private' by convention in bzr
<meoblast001> new_revno is there
<meoblast001> ah, ok
<meoblast001> ok, let's fire up the server and see how well this works
<meoblast001> oops, forgot to copy over the new version
<meoblast001> lifeless: what's bother me is that it's not giving me any information on where the error is
<meoblast001> i thought that was the advantage to using an interpreted language
<meoblast001> bzr: ERROR: exceptions.TypeError: coercing to Unicode: need string or buffer, int found
<meoblast001> that's all i get
<lifeless> meoblast001: I have suggested that you test locally
<meoblast001> yes, i'm doing that
<lifeless> meoblast001: if you are testing on your server, you'll need to check the .bzr.log on the server
<meoblast001> this seems to be getting called at every bzr commit and bzr uncommit
<meoblast001> so i am getting output
<lifeless> meoblast001: if you're testing locally, set BZR_PDB=1
<lifeless> e.g.
<lifeless> BZR_PDB=1 bzr uncommit
<meoblast001> as a shell variable?
<lifeless> yes
<meoblast001> get the exact same output
<meoblast001> is result.new_revno an integer?
<lifeless> it should put you into pdb
<meoblast001> because i treat it as one
<meoblast001> it didn't
<lifeless> why did you say 'forgot to copy over the new version' and 'time to fire up the server', if you are testing locally.
<meoblast001> ah, that's because this is a networking plugin
<meoblast001> the server is a plugin for my IRC bot
<meoblast001> it runs in a thread, waiting for signals from version control systems giving it details about the commits made
<lifeless> ok
<lifeless> and the branch you are testing on is on your local disk
<lifeless> and not a bound branch
<lifeless> and you're testing by doing a commit in it ?
<meoblast001> it's just a random branch i created with bzr init
<meoblast001> and it's on my local system
<lifeless> ok
<meoblast001> i'm testing by doing a commit
<lifeless> what bzr version?
<lifeless> check ~/.bzr.log, it should have the full backtrace there regardless
<meoblast001> Bazaar (bzr) 2.0.2
<meoblast001> hm, i wonder if i typed something wrong, it's complaining about no get_revision function
<meoblast001> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'get_revision'
<meoblast001> and i'm correct ;) i did type something wrong
<meoblast001> dang, it just keeps finding problems
<meoblast001> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'respository'
<lifeless> rep not resp
<meoblast001> oh >.<
<meoblast001> i've been all out of it today
<meoblast001> lifeless: yay, it works now :)
<meoblast001> <nitrobot> randproj: Revision Committed by Braden Walters <meoblast@aol.com>: Initial Commit
<lifeless> great
<meoblast001> now i just need to get the commit number off of it
<meoblast001> lifeless: i'd have to bot come in here to show you guys, but i'd probably get kick/banned ;)
<lifeless> I think for a commit or two it would be fine
<lifeless> is vcannounce generic?
<lifeless> like cia?
<lifeless> if so you might want to publish your plugin for others to use
<meoblast001> lifeless: my bot is a plugin-based bot
<meoblast001> written in C
<meoblast001> Nitrobot is the name of the bot, VCAnnounce is the name of the plugin i just wrote
<meoblast001> and i will be publishing my plugin in the nitrobot-plugins package
<meoblast001> i'll connect him now for one test
<nitrobot> randproj: Revision 2 Committed by Braden Walters <meoblast@aol.com>: Added file "file"
<meoblast001> lifeless: see :)
<meoblast001> !quit thepassword
<lifeless> grats
<meoblast001> thanks
<meoblast001> and also thanks for the great amount of help you provided on the Python side
<lifeless> de nada
<meoblast001> lifeless: once i'm done cleaning up the code (will probably do that tomorrow or later tonight), should i publish a link to where the plugin can be found somewhere?
<meoblast001> as you were saying i might want to publish it
<lifeless> yes, the bzr plugins wiki page :)
<meoblast001> ok, the Bazaar plugin is no good though without the bot and the bot plugin, so i'm assuming a link would be most appropriate?
<spiv> lifeless: yes, Command.add_cleanup is in 2.1
<meoblast001> hopefully that script will be as useful to others as it will be to me
<meoblast001> i hated having 2 bots sitting in my channel at the same time
<lifeless> spiv: doh
<lifeless> meoblast001: well you'll want a link to the bzr plugin, and a link to your bot
<meoblast001> ok, i'll do that tomorrow :)
<meoblast001> actually, i only have to do endianness conversions right now really, so i  could finish that up tonight
<mwhudson> more up to date api docs at http://people.canonical.com/~mwh/bzrlibapi/ now btw
<lifeless> mwhudson: can't use the old api?
<mwhudson> lifeless: you mean old server?
<lifeless> url
<mwhudson> it's not very well maintained these days
<lifeless> <- brain has melted
<mwhudson> i'll set up a redirect
<lifeless> mwhudson: can you delete them at least, so that people don't read only stuff
<mwhudson> sure
<spiv> lifeless: why doh?  Hmm, well I guess I ought to have listed some of that change in NEWS under API Changes (as well as Improvements, where it is mentioned)
<lifeless> spiv: because that makes it harder to rethink the change to be better
<spiv> lifeless: *nod*
<spiv> lifeless: (I thought that might be what you meant, but wanted to be sure)
<spiv> FWIW it landed on Jan 11.
<spiv> So, relatively late in the cycle, but still 10 days before rc1.
<spiv> And a full month before the final release.
<spiv> Ideally that should have been ample time to notice any issues :/
<meoblast001> now, time to do a test install on my server
<meoblast001> where would i put a plugin if i want it to apply for every user?
<lifeless> spiv: I don't think you did anything wrong.
<mwhudson> lifeless: redirect in place
<lifeless> spiv: its roughly the halting problem to always know in advance.
<spiv> lifeless: sure
<spiv> lifeless: I'm just wondering aloud if there's a deficiency in our process that we easily improve
<spiv> lifeless: nothing is springing to my mind, but then, my mind isn't at work today either :)
<lifeless> spiv: poolie and I spent some time today talking about a similar problem.
<poolie> hullo
<lifeless> I don't think tht the obvious options [more mandatory review time and similar] would help.
<lifeless> sorry, woud be a net improvement
<spiv> Ah well, I'm happy to have provided another data point then, as well as another feature ;)
<spiv> *nod*
<poolie> what is the 'it' here?
<lifeless> poolie: Command.run not being safe to call anymore.
<spiv> The best I can think of is "get more testing from plugin authors and plugin users", but even that's a bit vague.
<spiv> (and easier said than done)
<lifeless> poolie: which didn't stand out during review; it was obvious to the right eyeballs, but how do you get them on it in time?
<spiv> I do think I made a mistake in not writing an API Changes entry for that change.
<spiv> I'm not sure that would have brought it to the attention of the right eyeballs, but it might have.
<lifeless> I think that if you had thought it was an API change you might have noticed it as being a problem, in fact
<spiv> Right, there's also a degree of chicken-and-egg in that statement :)
<meoblast001> is there a location for global Bazaar plugins?
<spiv> meoblast001: the system-wide bzrlib/plugins dir, IIRC
<spiv> meoblast001: (check the location of bzrlib by running 'bzr version')
<meoblast001> ok, thanks
<lifeless> spiv: perhaps one thing we could say is 'ask yourself, does this change the safety of calling what I changed, or does it stop calling something it once [promised] to call'
<lifeless> spiv: as part of the regular 'think about it' part of review
<lifeless> EOD; see you tomorrow.
<thumper> night lifeless
<poolie> spiv, lend me your thoughts on the retrospective
<spiv> poolie: basically, +1
<spiv> poolie: picking the focus features is the tricky bit
<spiv> poolie: that's worked ok for us when we've had a really clear goal for a release, e.g. "2a must be robust and fast before we can declare 2.0"
<poolie> spiv, was there anything else you particularly noticed as good or bad this cycle?
<spiv> (sorry, was interrupted by baby)
<spiv> The motivation for focus features seems harder when they are just "nice to have"
<spiv> I think the cycle worked pretty well.  It still seems hard to get plugin authors to reliably notice problematic changes until after a release, though.
<spiv> But I think even there we've probably done better than previously.
<vila> hi all !
<lifeless> spiv: I think the issue with plugins is that many plugin authors don't run trunk, and don't want to
 * vila wonders why he's a channel operator....
<lifeless> spiv: and the current api churn on trunk makes it even less attractive
<spiv> *nod*
<lifeless> vila: you have chanserv /nickserv setup to auto op you when it can
<vila> lifeless: sure, but why *can* I ? :D
<lifeless> spiv: I'd like us to totally reverse the deprecation policy to what we had before; that is a much nicer rid, and conducive to running trunk
<lifeless> vila: because you're a core committer
<lifeless> vila: please change your setup though, to not op you automatically; helps avoid channel trolls
<spiv> lifeless: yeah, abentley at least seems to find the current policy worse
<vila> lifeless: but you and spiv and poolie are too .... ha ok
<lifeless> vila: yes, see<-
<poolie> hello vila, welcome back
<vila> hey poolie !
<lifeless> spiv: I replied to the thread saying I too find it worse.
<poolie> so
<spiv> I definitely thinking we need to find a way to encourage plugin authors (and keen plugin users) to track bzr trunk.
<poolie> i get discouraged from running plugin tests
<poolie> there seem to be too many broken windows
<poolie> i don't think the previous policy for apis was good enough
<spiv> But I'm not a plugin author, so I'm happy to let those who are make suggestions about what will help.
<poolie> there were some cases where people spent half an hour changing something and days working out how to deprecate it
<poolie> this is not a good tradeoff
<lifeless> poolie: I agree that that is a bad ratio; I've not experienced it myself
<poolie> i think this was a patch of vila i had in mind
<poolie> yes
<spiv> I think in general a plugin cannot rely on something like 'require_api(x.y.z.b3)' until x.y.z.b3 has been released, but this means that trunk is almost always a version that a plugin can't safely rely on.
<spiv> But at the same time, we want plugins to be tested with trunk.
<lifeless> spiv: that aspect of the current system doesn't bother me so much
<lifeless> spiv: its the 'whaaay, lets not deprecate anymore' that bothers me
<vila> poolie: the one about SubUnitFeature ?
<poolie> i forget
<vila> poolie: I didn't spend *days*, merely hours and mainly because the parameter order tricked both of us and led to an infinite recursion IIRC
<vila> but I miss the context so...
 * vila triages mail
<poolie> so
<poolie> i think if it's easy to keep something supported we should
<poolie> i don't think we should take for granted that doing any large amount of work in bzr is worthwhile
<lifeless> poolie: we didn't take that for granted before
<lifeless> poolie: I landed lots of patches of the kind 'too hard to deprecate, not doing so'
<poolie> ok
<lifeless> poolie: we don't seem to be trying at all at the moment
<lifeless> and I have two problems with this, as a user/advocate
<lifeless> firstly stable release to stable releae should do deprecations where we can
<lifeless> we've made these release jumps 6 months of rolled up work
<lifeless> so they are much bigger than they were before (in potential delta)
<lifeless> that, to me makes the benefit of a deprecation much greater.
<lifeless> and the risk of confusion to someone upgrading a plugin larger
<lifeless> secondly, deprecations add value to users - they have saved me lots of log grepping in the past, when someone else changed something.
<lifeless> and I think this is an experience other authors have had
<poolie> i can see how that helps authors but not users
<lifeless> when a plugin stops working with no visible indication, the user has to debug this.
<lifeless> a deprecation does two things; it keeps the plugin working, and if it fails at doing that, then it at least tells them
<poolie> hm
<poolie> but it's probably not going to stop with no visible indication
<lifeless> compare a Warning + AttributeError vs just an AttributeError
<lifeless> anyhow, I said this on the list
<lifeless> where everyone can participate  :)
<poolie> i'd be ok to reiterate that people should deprecate unless it is too hard
<poolie> it seems like there might be some better option though
<poolie> or something complementary
<Speedy2> www.search2.net
<poolie> spam
<igc> hi all
<lifeless> poolie: I'm disabling autoops
<lifeless> igc: can you do '/msg NickServ SET NOOP ON'
<lifeless> igc: and then leave and rejoin #bzr? testing fallout from the expanded access lists we did last week
<igc> lifeless: done
<lifeless> ok great
<lifeless> if you need to become operator do this:
<lifeless>  /msg chanserv op #bzr
<lifeless> an to stop being an operator
<lifeless>  /deop igc
<lifeless> igc: actually, I think I've found the root cause, youcan undo that if yu want
<lifeless> thee instructions to become/drop root still spply
<radoe> Are 2 minutes to create a new local branch from an existing branch of bzr-2.1 sources normal?
<poolie> radoe, do you have a shared repository locally?
<radoe> poolie: no, this test was without a shared repo, so I think it has to copy over the whole history, right?
<poolie> yes
<poolie> still seems a bit slow
<radoe> poolie: yes, I had the same feeling about beeing a tad slow in this local branching case.
<radoe> For more than a minute it stays at "Fetching revisions:Get stream source", having one CPU core running at 100%
<poolie> radoe, could it be the repositories are in different formats or something?
<radoe> poolie: both are "Standalone tree (format: 2a)". Further branching from the just-branched branch takes about the same time.
<Coke> Hi! I have a 1.5 version on server and 2.0.4 on my client, it takes like 2 minutes to transfer 62k of data, it does max 1k/s and most of the time even less. This is on a LAN!!! Needless to say, this is getting frustrating, is there a quick fix to mend this problem?
<poolie> Coke, so the obvious first step would be to upgrade the server to 2.1 or 2.0
<Coke> actually, there's no bzr server
<Coke> I use sftp
<Coke> My bad.
<poolie> ok
<Coke> So there's just the 2.0.4 client
<poolie> that's still kind of surprising
<poolie> what does bzr info show in that branch?
<Coke> location, checkout of branch and format pack-0.92
<bialix> hi poolie
<mathrick> Coke: and you're sure you can get normal sftp transfers at better speeds?
<poolie> hi bialix
<bialix> poolie: I've made 1.0.0rc2 release of bzr-explorer
<poolie> bialix, i saw, that's great
<poolie> thanks
<bialix> that's minimum I can do for Ian
<bialix> I don't know is anybody working on including bzr-explorer to Lucid?
<jelmer> bialix: AndrewSB is I think
<bialix> ok
<bialix> hi jelmer
<bialix> have a minute? you've asked about icon
<jelmer> bialix: He's the packager of bzr-explorer for Debian and Ubuntu, I'm not sure if he's specifically working on 1.0.0.rc2 though
<bialix> jelmer: that's ok
<poolie> he'll probably do it if you poke him
<poolie> i think ian will be away a bit this week
<bialix> poolie: any specific plans for 2.2? does nested trees have a chance?
<poolie> bialix, i was just talking to vila about that
<poolie> i think we should pick a thing
<poolie> Coke, did you work it out?
 * bialix waves at vila
<poolie> i was saying to vila maybe we should either all get onto merge/conflict, or he should leave it
<poolie> it seems a bit slow and he's having trouble getting good reviews
<poolie> vila, if you're piloting this week you're going to be busy
<vila> http://wiki.bazaar.canonical.com/PatchPilot says jam is the patch pilot this week, I plan to be *next* week
 * bialix nods
<poolie> oops
<poolie> sorry
<poolie> must be sleepy
<vila> no worries, but go get some sleep :D
 * fullermd waves at vila.
 * vila waves back to fullermd and bialix enthusiastically
<bialix> hi fullermd
<fullermd> ... some day, people in my own TZ will get their acts together and be around at the same time as I am...
<bialix> :-)
<vila> fullermd: why don't you just move where the sun shines during your work hours :) It really helps you know...
<fullermd> Sun...   shines?!  But what about my sensitive skin?
<poolie> sure shines here, 37C today
<vila> Oh, no need for direct exposure, but the light....
 * fullermd shudders.
<fullermd> It burns us, preciouss!
<poolie> bialix, so i would like us to agree on a specific thing for 2.2, but i don't want a thread where everyone names their favourite bug
 * vila throws some snow balls at poolie
<bialix> poolie: yep
<poolie> i recognize there's useful data in it but it just seems likely to cause disappointment if we don't go for whatever is most loudly demanded
<poolie> ooh that's nice
<bialix> poolie: I'm a bit tired with my scmproj and I have to rewrite big part of it, so I'm asking
<bialix> nested trees deferred for ~ 1 year
<poolie> so we could try to merge nested trees
<poolie> i wonder if it's too intrusive of a way to put it in
<poolie> in some ways we should just clear the decks and do it
<poolie> i wonder if we can do anything in the core to allow plugins to do this really well
<poolie> oh, there are some user questions open on lp if anyone wants to answer them
<vila> Ideally we should ad hooks or whatever is needed in core to *allow* a plugin (or several) to implement nested trees
<Coke> poolie: no luck
<poolie> right, that would be nicer
<poolie> ok i'm going to call it a night
<poolie> have a good day europe
<Coke> still as slow
<vila> Doing it via plugins lower the constraints about compatibility while allowing experiments
<poolie> right
<Coke> nn
<vila> poolie: have a nice night
<poolie> also, maybe has a cleaner architecture
<bialix> today the limit of either scmproj or bzr-externals is lack of snapshots
<fullermd> A problem with trials like that is that figuring out just what sorta hooks are needed is the lions share of _doing_ it   :|
<bialix> i.e. they don't record revision-ids of entire tree
<vila> fullermd: that could be driven by the plugin authors
<vila> bialix: revids of nested trees ?
<bialix> vila: I'm not sure hooks will help there
<fullermd> Yeah.  Has to be, really.  But it risks turning into a long serialized HCF sorta process.
<jelmer> vila: they just point at the tip of a branch, not a specific revision
<bialix> there is need to run some operations recursively in all trees'
<jelmer> whereas nested trees in their current form only support specific revisions, not tip
<bialix> fullermd: HCF?
<bialix> vila: yes
<bialix> jelmer: ?
<jelmer> bialix: nested trees as aaron has implemented them only support snapshots
<vila> jelmer: ':tip' as a special revid like ':null' ?
<jelmer> (If I understand the terminology right)
<bialix> jelmer: that's good
<vila> urgh, non-sense
<bialix> jelmer: one can easily implement: for $each-subtree do bzr pull
<fullermd> bialix: "Halt and Catch Fire".  No real relevance, I was just being whimsical.
<jelmer> vila: well, the tip of the branch, no matter what revspec you use to describe it :-)
<jelmer> vila: tip: would be one way of supporting non-snapshots with the current bzr nested tree storage format
<jelmer> bialix: pulling a subtree is a change to the parent tree
<vila> jelmer: hmm, I said non-sense because if you want to refer to a particular revision for a tree you don't want the nested tree to change
<vila> so, yes, you want some mechanism in place to update or not when you pull, merge, etc
<bialix> jelmer: believe me: I have much more problems because of lack of snapshots
<bialix> jelmer: I don't understand
<bialix> what it means: pulling a subtree is a change to the parent tree?
<bialix> if I change subtree I should commit this changes to parent tree, yes, that's right
<jelmer> I think I should probably get out of this discussion because I'm only familiar with the nested tree terminology, not with the scmproj terminology.
<bialix> I'm not very familiar with nested trees terminology, bad
<bialix> how nested trees called the entire saved state of all subtrees?
<bialix> in hg they save revids to .hgsubstate
<lifeless> bialix: it doesn't have that concept
<lifeless> its just part of the inventory
<lifeless> and only refers to the immediate children.
<lifeless> its recursive, so deeper children are referred to by their containing tree.
<bialix> so there should be a way to update inventory for desired revision
<lifeless> yes, there is an api call
<bialix> IIUC it's similar to textual changes?
<lifeless> yes
<bialix> but the subtrees all live in separate branches, right? so I should be able to update just specific subtree
<bialix> if there is no built-in way, then we can call API in the plugin
<lifeless> bialix: I don't understand the question
<bialix> lifeless: there is nested by value and by reference
<bialix> I'm talking about by reference case
<lifeless> yes
<lifeless> I guet that
<bialix> referenced subtree lives outside main tree IIUC
<lifeless> I don't know what you mean by 'update just specific substree'
<lifeless> do you mean 'update the referenced revision'
<bialix> so if it external than we should be able to pull/push it
<lifeless> or 'do an update on the local tree for the subtree'
<bialix> I mean cd subtree; bzr pull
<lifeless> sure, just do it
<lifeless> nothing else needed
<lifeless> the next commit in the parent tree will notice and record it
<bialix> brilliant
<naoki_> Hi, all.
<naoki_> https://code.launchpad.net/~songofacandy/bzr/fix-524560/+merge/19737
<naoki_> I found 'N' mode on msdn.
<naoki_> http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx
<naoki_> This mode means open file with os.O_NOINHERIT.
<naoki_> And I test the mode on Linux. 'N' is just ignored.
<naoki_> Currently, my bugfix branch make osutils.open and use it instead of builtin open.
<naoki_> osutils.open adds 'N' on win32, osutils.open is builtin open on Linux.
<naoki_> Can I use 'N' on Linux?
<naoki_> If I can, I'll remove osutils.open and add 'N' for open() in transport.local
<Mez> "secret service operation failed" ...
<Mez> doesn't sound good.
<Mez> I don't like secrets in my system
<vila> Mez: And how is that related to bzr ?
<jelmer> naoki_: that sounds reasonable
<naoki_> manpage for fopen describe modes.
<naoki_> posix modes: r, r+, w, w+, a, a+
<naoki_> glibc extension (trailing chars): c, e, m, x
<naoki_> I don't know other libc's fopen extension.
<naoki_> Using 'N' only on win32 is safe because glibc and other libc can use 'N' for some meaning...
<naoki_> BTW, what name is suitable for osutils.open? open_noinherit? open_safe?
<chromakode> hey folks, can you give me any suggestions on how to extract all code lines touched by a specific author?
<jelmer> chromakode: from Python code or from the command line?
<chromakode> either way is fine
<jelmer> chromakode: from the command-line the easiest thing to do is probably to loop over all files in the working tree, run "bzr annotate" on them and grep
<chromakode> that's a good idea! though it won't include past code
<chromakode> I guess you could do it for each revno
<Tak> could grep the log for the author, then annotate from there
<jelmer> chromakode: from python it should be possible to find all changed lines by using a combination of the log and the annotate code
<chromakode> thank you, I can work off that :)
<chromakode> if I end up writing a script to do this, I'll post it here.
<rubbs> I'd like that ^
<_TiN_> Hi, I'm trying server bzr through apache with mod_wsgi, and the "app" return nothing. This is my wsgi script http://dpaste.com/163148/ and the output is a clean list, just []
<_TiN_> :-/
<poolie> hi jam, shall we talk?
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.1.0final has gone gold, time to build installers!
<shodan45> what options do I need for bzr to make a .patch file that works with patch?
<marienz> none?
<marienz> that is: I'm pretty sure I've fed "bzr di" output to patch
<marienz> shodan45: ^^^
<shodan45> marienz, ok, then what options to patch do I need? none? because it sure doesn't work for me :/
<lifeless> shodan45: when you apply it, pass -p0 to patch
<lifeless> or is it p1, I think its p0
<marienz> shodan45: I think it's -p0 but it might be -p1. I usually need to try both with --dry-run.
<marienz> actually it's probably -p1
<shodan45> ok, I thought for sure I tried both -p0 and -p1, but -p0 worked
<shodan45> thanks :)
<_TiN_> Howto disable the comprobation SSL certificates?
<_TiN_> bzr push bzr+https://myurl
<_TiN_> bzr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
<_TiN_> /s/comprobation/check
<mwhudson> _TiN_: using a https+urllib:// url will work i think
<_TiN_> mwhudson: this just work on cloning, when i try push doesn't work because the protocol is bzr+http[s]
<bob2> heh
<bob2> can you append +urllib to that?
<_TiN_> bob2: unsupported protocol
<_TiN_> bzr+https+urllib or urllib+bzr+https or bzr+urllib+https
<mwhudson> bzr+ shouldn't be necessary
<_TiN_> mwhudson: the push doesn't work with http[s]+urllib
<_TiN_> mwhudson: in this link say http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html?highlight=mod_python#pushing-over-bzr-http
<spiv> _TiN_: that doc is out-of-date, or at least misleading.  You can omit the 'bzr+' prefix on http URLs; bzr will automatically probe for a smart server and use it anyway.
<spiv> _TiN_: you might be encountering some other problem, of course :(
<_TiN_> spiv: noup, whitout bzr+ prefix doesn't work, but uninstall pycurl it's work :-)
<_TiN_> thanks verterok ;-)
<spiv> _TiN_: and https+urllib didn't work?
<spiv> Odd.
<verterok> _TiN_: you'r welcome :)
<spiv> _TiN_: anyway, please file a bug :)
<spiv> _TiN_: we want this stuff to Just Work
<verterok> spiv: heya!
<verterok> spiv: I can't uninstall pycurl so I'm stuck with this bug ;)
<spiv> verterok: maybe you should file it then? :)
<spiv> (Or is it already filed?)
<verterok> spiv: I can't uninstall pycurl so I'm stuck with this bug ;)
<verterok> spiv: I keep getting: bzr: ERROR: Unsupported protocol for url "urllib+https://trac.usla.org.ar/bzr/prueba_bzr"
<verterok> spiv: and with reverse order, I get the user/pass prompt but: bzr: ERROR: Not a branch: "https+urllib://trac.usla.org.ar/bzr/prueba_bzr/".
<verterok> spiv: I think it's https://bugs.edge.launchpad.net/bzr/+bug/82086
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged]
<spiv> verterok: right, https+urllib is the correct prefix
<spiv> verterok: but the https+urllib variant should work
<verterok> spiv: so, it might be a server config issue?
<spiv> Possibly!
<verterok> _TiN_: ^ :)
<spiv> verterok: add -Dhpss to the command line, and maybe -Dhttp too, and pastebin the ~/.bzr.log (after sanitising it for passwords etc), or attach it to a bug
<verterok> spiv: ok
<spiv> verterok: also, perhaps try installing lp:bzr-ping, and try 'bzr ping URL'
<spiv> It fails for me, but I don't know the username and password, so that's unsurprising :)
<verterok> spiv: pastebin: http://pastebin.ubuntu.com/381915/
 * verterok branching bzr-ping
<_TiN_> verterok: this through varnish http, and https pound+varnish
<spiv> So, it appears to be talking to the smart server ok via HTTP
<spiv> But then it tries to read /bzr/prueba_bzr/.bzr/branch-format
<spiv> via regular HTTP
<spiv> And that gets a 404
<spiv> So, a server config issue, I think, although bzr should give clearer errors in this case.
<spiv> (Although perhaps bzr could try falling back to trying to read only via the smart server)
<_TiN_> may be with AliasMatch directive
<verterok> spiv: oh, nice. thanks for looking to the logs :)
<spiv> verterok: cool.  So please file a bug and attach that, because I'm pretty sure that bzr can do better here.  (and because I'm not really here today)
<verterok> spiv: oh, ok.
<verterok> spiv: will do it
#bzr 2010-02-23
<poolie> igc, does explorer have any launchpad-api client code yet?
<poolie> spiv, can you triage bug 526132 if you know about it
<ubottu> Launchpad bug 526132 in bzr "no clear error message when failing to push using http transport" [Undecided,New] https://launchpad.net/bugs/526132
<spiv> poolie: sure, doing now
<_TiN_> spiv: there work with https+urllib, thanks
<_TiN_> /s/there/it
<spiv> _TiN_: you're welcome
<_TiN_> spiv: where is the rst of http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/http_smart_server.html I can send a patch, to explain how to really make it work
<spiv> _TiN_: doc/en/user-guide/http_smart_server.txt in the bzr source tree
<spiv> Hmm, we really should have a small footer on every doc page saying which file to make patches against.
<spiv> _TiN_: thanks!
<_TiN_> yw :-)
<lifeless> jelmer: ping
<jelmer> lifeless, pongish
<lifeless> jelmer: I haven't read the code yet, but wanted to discuss named branch opening
<lifeless> what does your patch change?
<jelmer> lifeless: it basically adds a name argument to BzrDir.open_branch(), BzrDir.destroy_branch() and BzrDir.create_branch()
<jelmer> then checks that they raise NoColocatedBranchSupport if a name is actually specified
<lifeless> ok; does it set limits (e.g. is a name 'foo/bar' supported (I'd like that :>)
<lifeless> for Branch.open, thats where the url support will come in ?
<lifeless> have you done the url parameter support yet ?
<jelmer> The URL parameter support isn't done yet, that's up next
<lifeless> ok this is sounding nice
<lifeless> I'll try and review this weekend
<jelmer> thanks :-)
<Kilroo> If I had a commit at revision x that did nothing but add a 1.5gb zipped .mov file to the repository and I wanted to get rid of it, would the best way to do so be branching from revision x-1 and them merging from x+1 to the present or what?
<Kilroo> I'm curious because of what my boss did to one of our subversion repos and how much the linux sysadmin is dragging his feet over fixing it.
<maxb> If the aim is to remove the huge file from the history completely, merge would not acheive your goal
<maxb> You'd want rebase, I guess, though bzr's rebase plugin has some problems that I happen to be working on fixing
<Kilroo> Hm. Ok.
<Kilroo> The aim would be to fix it so that people trying to branch from it would actually be able to do so without getting an out-of-memory error, which I guess means I would want rebase.
<dOxxx> good evening
<meoblast001> good evening to you dOxxx
<poolie> i wonder if we should have a news file per x.y series
<poolie> merging them into just one is a bit weird
<poolie> though getting to grep just one is useflu
<mwhudson> jelmer: incremental import failure :( https://code.staging.launchpad.net/~kiko/linux/2.6.31
<meoblast001> i was thinking
<meoblast001> then i had a panic attack
<meoblast001> when you do `bzr uncommit`, does it keep a record of the commit?
<dOxxx> yes
<meoblast001> oh jeez
<meoblast001> forever?
<dOxxx> the modifications get added back into your working tree
<dOxxx> and the message is remembered for when you next run bzr commit
<dOxxx> i.e. it looks like you hadn't run bzr commit
<meoblast001> i've uncommitted things and then recommitted them more than a few times
<meoblast001> once i recommit, are they removed?
<dOxxx> I'm not sure what you mean...
<meoblast001> i do uncommit
<meoblast001> then do bzr commit
<meoblast001> i've done that quite a few times
<dOxxx> that's fine
<meoblast001> every commit i've uncommitted, are those completely removed once i commit?
<dOxxx> I'm not 100% certain, but I believe that revision will no longer exist in the branch. Essentially it's replaced by the new revision you create with the second commit.
<meoblast001> ok
<meoblast001> hopefully you're right
<dOxxx> :)
<meoblast001> or i'll have another panic attack
<dOxxx> I'm not a core developer, just a part time contributor, so you may want to verify by posting to https://answers.launchpad.net/bzr or on the mailing list.
<meoblast001> ok, thanks
<jml> is there a command to mirror a repo?
<dOxxx> scp?
<dOxxx> ;)
<jml> download all branches in a repo -- pulling ones we already have, branching new ones?
<dOxxx> I think the bzr mirror plugin does that
<dOxxx> https://launchpad.net/bzr-mirror
<jml> dOxxx, thanks -- it's not mentioned on the BzrPlugins page on the wiki
<dOxxx> np
<meoblast001> hm, it says "Uncommit leaves the working tree ready for a new commit.  The only change   it may make is to restore any pending merges that were present before   the commit."
<meoblast001> i'm not sure what that means though
<dOxxx_away> it means that if you were to then run bzr commit again, it would appear as if you had never run bzr uncommit
<dOxxx_away> seeya later
<jml> no, that doesn't do what I want.
<mwhudson> jml: i think something like rsync might be your best bet
<mwhudson> i guess you could do something involving all_revision_ids and fetch, but it seems like it's going to be a bit expensive, one way or the other
<jml> mwhudson, well, I was thinking something a little like Repository.open(...).find_branches
<jml> mwhudson, then doing some set operations
<mwhudson> jml: that won't find "dead heads" i.e. revisions in the repo that are not in the ancestry of any branch in the repo
<mwhudson> jml: i guess looking at the code for bzrtools 'heads' command will probably be instructive
<jml> mwhudson, I don't think we care about that
<mwhudson> jml: on in that case, what you said sounds fine
 * poolie is merging 2.1 back to trunk
<poolie> overrideAttr is a big win
<poolie> causes a lot of conflicts though
<_TiN_> spiv: i have the doc patch, now?
<spiv> _TiN_: I don't understand your question.  Are you asking where to send a patch?
<lifeless> mwhudson: can you recommend a small git repo to do bzr git tests with? I know you're finished...
<wgrant> lifeless: linux!
<lifeless> wgrant: FSVO small
 * wgrant has used http://git.samba.org/?p=jelmer/dulwich.git
<lifeless> jelmer: hi
<lifeless> jelmer: why does bzr-git register a network format? do you do native network streaming ?
<jelmer> lifeless, moin
<jelmer> lifeless, we don't, but things broke when we didn't
<jelmer> I don't remember the details
<lifeless> jelmer: oh. did you file a bug?
<jelmer> no, I don't recall thinking that this was one
<lifeless> yeah, it wasn't meant to be an API break
<lifeless> it was meant to add an optimised path to determine the control dir format over the smart server
<jelmer> mwhudson, hi
<wgrant> Is update-sourcecode broken for anyone else?
<wgrant> It can't find bzrlib.branch.
<lifeless> wgrant: #launchpad-dev ? :>
<lifeless> thats (I don't know)
<wgrant> lifeless: Oops, thought I was there. Sorry.
<lifeless> wgrant: nothing to be sorry about
<vila> hi all
<jelmer> moin vila
<poolie> hello vila, jelmer
<vila> hi jelemer, poolie
<vila> jelmer, in bug #525752, I realized you were referring tips, I asked for revids in case nobody can look at it before the tips change :D
<ubottu> Launchpad bug 525752 in bzr "No final name for trans_id" [Medium,Confirmed] https://launchpad.net/bugs/525752
<poolie> a traceback might help there too
<jelmer> vila: ah, k
<jelmer> I'll add them
<poolie> vila, i'm at the moment merging 2.1 and 2.0 back to trunk
<poolie> there are quite a few real conflicts
<poolie> i mention this just to save you trying to resolve them too
<vila> poolie: I saw you mentioned conflicts related to overrideAttr, I'm  a bit surprised... are there a lot ? hard to resolve ?
<vila> poolie: thks for that
<poolie> quite a few
<poolie> at first i thought it was a merge bug but i think people really have done different cleanups on the two
<poolie> branches since we last merged
<vila> hmm, bad, I thought we were merging back to trunk regularly enough....
<poolie> hm
<poolie> actually no, i think the criss-cross is being handled poorly
<vila> poolie: try remerge --weave maybe ?
<poolie> --lca did much better
<poolie> maybe we should look at changing some defaults here
<poolie> it's been discussed before
<bob2> best. flag. ever.
<poolie> heh
<vila> bob2: you know it means Least Common Ancestor right ?
<bob2> no!
<bob2> I mean yes!
<poolie> vila, do you know off hand how fsencoding is originally set?
<vila> defaultfilesysencding or default to utf8 from memory
<vila> sys.default...()
<poolie> but i mean how would a user change it?
<vila> in osutils search for fs_enc ?
<vila> no no no, no user is allowed to do that :D
<vila> seriously, I don't think we have a hook for that
<vila> _fs_enc = sys.getfilesystemencoding() or 'utf-8'
<vila> so, set at load time
<vila> poolie: what use case do you have in mind ?
<vila> lifeless: by the way, still no T-shirt here, any news from your side ?
<poolie> vila, things like bug 526263
<ubottu> Launchpad bug 526263 in bzr "bzr crash on 'bzr st' (unicode problem?) (dup-of: 488519)" [Undecided,New] https://launchpad.net/bugs/526263
<ubottu> Launchpad bug 488519 in bzr "[master] UnicodeDecodeError in osutils.walkdirs with non-ascii filenames" [High,Confirmed] https://launchpad.net/bugs/488519
<poolie> it would be nice to say "you need to set X"
<poolie> perhaps hacking site.py will do it
<vila> fsenc: 'ANSI_X3.4-1968' is another name for ascii, we use utf8 in that case
<poolie> i know
<vila> .. and your comment is exactly what I would have said
<poolie> i mean i know it's ascii
<poolie> but it looks like we're not using utf8
<vila> yeah, sorry, your comment wasn't in the first page
<vila> weird, if I read osutils._walkdirs_utf8 correctly, we use UTF8DirReader in that case or emit a warning about extensions failing to load
<vila> grr, we really need to display unicode exceptions correctly, the exception objects have the string as an attribute... why python doesn't display it is... censored
<vila> poolie: tweaking LC_TYPE and LANG sould be the way to go
<poolie> could you suggest that too him then?
<poolie> we should show them better
<lifeless> vila: nope
<lifeless> jml: did the t-shirt get returned to you/
<poolie> nearly <100 New bugs
<lifeless> poolie: bug 523703
<ubottu> Launchpad bug 523703 in bzr "inconsistent view of revision numbers on stacked remote branch lp:~lifeless/ubuntu/lucid/apt/bug-22354" [Medium,Confirmed] https://launchpad.net/bugs/523703
<lifeless> poolie: I think your retitling is wrong
<lifeless> poolie: both jam and I think its deeper than revnos
<poolie> ok, retitle away then
<poolie> good night
<lifeless> gnight
<vila> gnight
<Anteru> Hi
<Anteru> Just installed bzr 2.1 final, and I'm getting an empty toolbar in bazaar explorer ... known issue or am I doing something wrong? (This is on Windows)
<naoki_> Anteru: It is known issue.
<Anteru> Any workaround
<Anteru> ?
<naoki_> https://launchpad.net/bzr-explorer/+download
<Anteru> thanks
<naoki_> Please try 1.0.0rc2
<Anteru> works, thanks
<wgrant> I'm merging a branch into trunk. A file in the branch collided with an unversioned file in my checkout of trunk. bzr said "Moved existing file <filename> to <filename>.moved."
<wgrant> But it seems the one from the branch is .moved, not the one that existed in the trunk checkout.
<wgrant> Oh, no, ignore me, I'm just crazy.
<eelik> question about bzr-svn documentation in http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html
<eelik> "Merging trunk to your feature branch" says: merging trunk into your feature branch should be avoided
<eelik> but then it shows how trunk is merged to feature branch and feature branch back to trunk
<eelik> "Instead, use merge to reintegrate your changes back to the mainline."
<eelik> It seems to be conflicting with itself because it first tells NOT to merge to feature branch, but then shows how it can be done safely
<eelik> The "Instead" part talks about merging to trunk vs. pushing/pulling to trunk, not merging to trunk vs. merging to feature branch
<eelik> The question is: should merging trunk into feature branch be avoided or not?
<bigjools> it's done routinely in Launchpad development
<eelik> So, the first clause in the doc is misleading?
<bigjools> oh, this is subversion
<bigjools> all bets are off :)
<bigjools> jelmer will be around later, he'll know
 * bialix waves
<gnomefreak> i keep getting errors about connection when pulling a branch? is this known?
<rubbs> gnomefreak: can you post the error?
<gnomefreak> http://paste.ubuntu.com/382281/ rubbs i was just pastebinning it :
<maxb> "Permission denied (publickey)." indicates you are failing to authenticate to Launchpad
<maxb> Check that:
<gnomefreak> maxb: the key or in all
<maxb> 1. You've run bzr launchpad-login <your lp user id>
<maxb> 2. Your Launchpad user has a ssh key associated
<maxb> 3. You actually have that ssh key available locally
<gnomefreak> i do or at least i did
<maxb> Run 'ssh your-lp-user-id@bazaar.launchpad.net'. It should print "No shells on this server"
<gnomefreak> ok trying
<gnomefreak> Permission denied (publickey).
<maxb> So the problem is at the ssh level, before bzr ever actually gets to do anything
<gnomefreak> maxb: i tried renaming ~/.ssh and tried again i get same error
<maxb> Do you use a ssh-agent? Does it know about your key?
<gnomefreak> i thought i was
<jpds> gnomefreak: Try: ssh-add -l
<gnomefreak> ok i forgot to install it after re installing it seems
<gnomefreak> no identities
<gnomefreak> ok trying a few things. ill let you know what happens
<jam> eelik: what should be avoided is merging trunk => feature and the *pushing* => trunk
<jam> merging trunk => feature and merging feature => trunk is probably be fine
<james_w> hi jam
<jam> morning james_w
<james_w> your possible_transports fix, or something else, fixed the fd leak issue, so thanks!
<jam> james_w: probably the possible_transports
<jam> given that it was opening up 2 sockets for every file
<jam> it wanted to download
<jam> (one to lp.net, one to lplib.net)
<jam> james_w: can you start a totem import?
<james_w> have you started on another failure class, or have you switched to some other task
<jam> or... have me understand why we don't have one
<james_w> jam: you can do it!
<jam> currently working on windows installer
<james_w> http://package-import.ubuntu.com/status/totem.html
<james_w> which I'm tempted to just retry
<jam> check hottest says "lp:ubuntu/totem" has no default branch
<james_w> "locked 0 seconds ago" would indicate it trying to double lock
<jam> is it possible we have a broken object somewhere?
<jam> but yes, 0s definitely indicates a double lock
<jam> anyway, when i get back to this it will probably be either bug #508254 or bug #513282
<ubottu> Launchpad bug 508254 in udd "Failure to import with 'too many open files'" [Medium,Confirmed] https://launchpad.net/bugs/508254
<ubottu> Launchpad bug 513282 in udd "is marked but not imported" [High,Triaged] https://launchpad.net/bugs/513282
<jam> they both are tied with 3 failures
<jam> though apparently 508254 is already fixed?
<james_w> yeah
<james_w> it's imported both samba and OO.org, which were both hit by it
<bialix> .ÑÑ ÑÑÐ¼ÑÑ ÑÐµ Ð¾ÑÑ
<bialix> >	/me waves at jam
<jam> hi bialix
<james_w> jam: you realise the lists in the bugs aren't exhaustive?
<james_w> when you said "both tied with 3 failures"
<jam> bialix: was that just a typo? I tried to translate it from russian, and I get:
<jam> http://translate.google.com/#ru|en|%0A%D1%8C%D1%83%20%D1%86%D1%84%D0%BC%D1%83%D1%8B%20%D1%84%D0%B5%20%D0%BE%D1%84%D1%8C
<jam> james_w: hottest100 has 3 packages affected with the first, and 3 affected with the second
<jam> the 2 highest impact bugs
<james_w> ah, I see
<bialix> jam: no, it was english in russian layout
<jam> bialix: yeah, I did that a lot with dvorak / qwerty
<james_w> jam: does it put the output somewhere, or would I have to run it locally?
<jam> james_w: we cache the last run in 'status'
<jam> I just ran it, but I'm going to remove 508254 and run it again
<jam> http://paste.ubuntu.com/382294/
<jam> summary of delta for last run
<james_w> jam: could you paste me all the info? I'd like to take a look
<jam> james_w: http://paste.ubuntu.com/382295/
<jam> the full status file
<jam> found at
<jam> lp:~canonical-bazaar/udd/hottest100 filename status
<jam> bzr cat lp:~canonical-bazaar/udd/hottest100/status
<james_w> thanks
<jam> should give the value for whoever ran it last and committed it
<jam> I'll be updating it again now
<jam> though it takes a while to run from here
<jam> lots of lp api round trips
<jml> lifeless, it did
<GaryvdM> Hi all
 * GaryvdM seeks johnf
<jelmer> GaryvdM, he's in Australia, I doubt he's around at the moment
<jelmer> also, hi :-)
<GaryvdM> Hi jelmer
<james_w> jam: https://code.edge.launchpad.net/~james-w/udd/hottest100-updates/+merge/19975 is some updates with fresher information
<GaryvdM> His package in the bzr ppa for bzr 2.1.0 final has a smaller version than tho 2.1.0rc2 package in the beta ppa
<jelmer> it's not named 2.1.0~rc2 ?
<GaryvdM> I made the rc2  2.1.0~rc2-0~bazaar2~karmic1  (which probably should have been  	 2.1.0~rc2-0~bazaar2~karmic1
<GaryvdM> which probably should have been  	 2.1.0-0~rc2-0~bazaar2~karmic1
<GaryvdM> His final is  bzr - 2.1.0~bazaar1.9.10
<gnomefreak> maxb: using an old ~/.ssh seems to work. thanks for the help
<jam> james_w: merging now and re-running
<james_w> thanks jam
<james_w> I didn't check if it didn't bother running the test for a package with a bug, so nothing may change
<jam> james_w: http://pastebin.ubuntu.com/382314/
<jam> it skips if it thinks there is a bug
<james_w> ok
<james_w> and things like "kde" will make it skip checking the package branch?
<jam> I think so
<jam> it sums to 100
<james_w> because AIUI that's not something that will have a bearing on the package branch
<jam> sure, I'll update the script a bit
<jam> james_w: maybe you can help me understand the 'special' tag as well
<jam> stuff like 'hplib' and 'initramfs-tools'
<james_w> that's something to do with whether there should be an upstream import
<jam> AIUI they have strange upstreams
<james_w> I think hplip might have no public VCS
<jam> yeah, so that shouldn't disqualify packaing, right?
<james_w> I don't know why initramfs-tools is in that category
<james_w> correct
<jam> I think some of it was just for us to focus on getting the whole stack working
<james_w> I think only package-bug shoud
<jam> and if we couldn't import an upstream
<james_w> right
<jam> then we just skipped that one for now
<jam> but for the summary, it has been useful to know about packaging separately
<jam> so I'll work on that
<james_w> thanks
<james_w> I just saw at one point "there is a lower number of ok package branches, so that seems to be the area of most concern", and if the number of ok package branches can't exceed the number of ok upstream branches that would seem to be a bad way to asses it
<jam> actually, the upstream check is done after the packaging check
<jam> only explicitly excluded ones fell differently
<james_w> ok
<cr3> if I run bzr builddeb -S in pexpect.run(), it seems to stall forever. any ideas what might be going on? attaching to the process using gdb only shows that the process is waiting
<james_w> debuild may be prompting you for something
<james_w> perhaps passphrase to sign?
<james_w> or one of it's "you appear to be doing this, we think you mean that, do you want to continue with this?" prompts
<jam> james_w: current totals, trying to only filter out upstream based on special flags: http://paste.ubuntu.com/382330/
<jam> 76 ok, 8 missing packages, 4 out of date, a small handful of bugs
<jam> james_w: should I include "old_version" rather than missing package?
<cr3> james_w: I get a prompt for "This package has a Debian revision number but there does not seem to be...", so pexpect seems to prompt properly.
<jam> though some old-versions became 'ok'
<james_w> jam: what are there meanings?
<jam> (grub became ok, glibc became no_source_package)
<james_w> their
<jam> old-version was supposed to be stuff like firefox which moves to a new project each release
<cr3> james_w: by the way, calling debuild --no-tgz-check -S in pexpect.run works just fine
<jam> (mozilla-thunderbird vs thunderbird, etc)
<jam> glibc vs eglibc
<james_w> cr3: well, builddeb doesn't pass --no-tgz-check
<jam> I think 'linux-restricted-modules' also moved around somehow
<james_w> I'm not sure
<james_w> what's "broken"?
 * james_w remembers the README
<cr3> james_w: yeah, I'm not sure how big a deal that really is
<jam> james_w: if we get an exception trying to read the bzr branch that isn't 'no default branch' it is 'broken'
<james_w> ah
<jam> openoffice.org seems to be saying it is at revision 'null:'
<james_w> yeah, it's having trouble pushing it to LP
<james_w> I just had it start to try again
<jam> so what do you think, should we just not worry about packaging for 'old-version'?
<jam> special also seems to be a mixed bag
<jam> but again, some specials end up 'ok'
<james_w> we should have packaging for special
<james_w> old-version we should have packaging, but it may not have a lucid branch
<jam> right
<jam> linux-restricted-modules seems the only broken special
<james_w> broken how?
<james_w> as it "broken"?
<jam> no, "no_source_package"
<james_w> ah, it's old_version really I guess
<james_w> I don't remember where that stuff lives now
<jam> sure
<jam> well, I think it is 'special' in that there is no clear upstream
<jam> but 'old-version' in that it isn't packaged their either
<jam> I'll poke
<jam> see what I get
<jam> I'll probably just make old-version be a package import flag
<jam> and 'special' be an upstream flag
<Ng> is there a way to have bzr use non-zero return codes on errors?
<jelmer> ng: it should do so already
<jelmer> if not, that's a bug
<Ng> jelmer: I'm prepared to believe it's a config or plugin issue on my end, but.. http://paste.ubuntu.com/382346/
<jelmer> Ng: hmm
<jelmer> Ng: Not sure what's happening there - please file a bug
<jelmer> I think we should be returning 1 in that case
<awilkins> I'm getting 3  : http://pastebin.ubuntu.com/382352/
<awilkins> That's for a root-owned folder with no read permissions for ag though ; don't know what config Ng has
<Ng> my /etc/.bzr is root:root 700
<Ng> jelmer: done, bug #526551 :)
<ubottu> Launchpad bug 526551 in bzr "Not getting a non-zero return code on error" [Undecided,New] https://launchpad.net/bugs/526551
<jelmer> Ng: thanks
<Ng> I stuck in some obviously relevant things about which plugins I have where
<GaryvdM> jelmer: I'm trying to merge the bzr ppa package branches with debian unstable. Are there any tools to help resolve conflicts in debian/changelog?
<jam> Ng: generally we would file the bug against bzr itself, rather than 'bzr (Ubuntu)'
<jam> we return 3 on otherwise unhandled exceptions, I don't know why you would be getting 0
<GaryvdM> jelmer: since it is just a ppa, can I replace the entries from the ppa with the entries from debian?
<Christoph^> Hi, I have a question about bzr:
<Ng> jam: oh, sorry, I just did "ubuntu-bug bzr" out of habit
<Ng> I wonder if it's the pager plugin
<Ng> yeah, it is :(
<Christoph^> In my working directory, I have a configuration file. Is it possible to say that this configuration file should not be exported for releases, exporting a sample config file instead?
 * mtaylor complains: while I've got bzr commit going in one window, it would be great if bzr diff still worked
 * mtaylor understands locks are needed to prevent changes,  but still allowing reads wouldn't hurt anyone... :)
<jelmer> mtaylor: I believe there's an open bug about this :-)
<mtaylor> jelmer: yay!
<GaryvdM> mtaylor: You can also use bzr qcommit
<jam> mtaylor: there is a structure that is read and written in place, so reading it while updating it could cause reads of corrupted data
<jam> that said, there is bug #98836
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,In progress] https://launchpad.net/bugs/98836
<jelmer> GaryvdM: No, that's not really possible
<jelmer> GaryvdM, You can wait for 2.1.1 :-)
<jam> there is also 'bzr commit --show-diffs'
<mhall119|work> how can I set my working copy to a specific revision in a repository?
<GaryvdM> jelmer: re commit/diff or merging changelog
<jam> mhall119|work: bzr revert -r X
<mhall119|work> I can do hg update -r $rev
<jam> in bzr 2.1.0 I believe 'bzr update -r X' also works
<jam> sort of depends what you want the end result to be
<mhall119|work> no, revert isn't what I want
<GaryvdM> +1 for bzr update -r
<mhall119|work> I'm on bzr 2.0.3
<mhall119|work> which is the latest in karmic
<jelmer> GaryvdM: regarding version numbers
<awilkins> verterok, I think the update to 2.1 has busted a bunch of stuff in bzr-java-lib
<GaryvdM> jelmer: ok, thanks
 * Ng hrms at bzr diff. It seems like it doesn't imply the equivalent of diff -N, I just get told "=== added file 'foo'". Am I being blind and missing the option that will show me the contents of that file?
<awilkins> Ng, That seems odd, I'm getting the contents for added files in a vanilla diff command
<jelmer> Ng: is the file empty perhaps?
<Ng> I seem to have the most broken bzr install in the world ;)
<Ng> jelmer: good point, well made
<jam> james_w: current status summary: http://paste.ubuntu.com/382390/
<mhall119|work> okay, I can bzr branch -r $rev lp:$project
<mhall119|work> that'll work
<jam> so we currently have 25 'failures', 9 of which are packages we don't really care about
<mhall119|work> then bzr pull -r $rev
<james_w> jam: cool, good to know, thanks
<bialix> hi GaryvdM! and bye
<jam> which is up from... 18 ok when we started the check-hottest.py script :)
<verterok> awilkins: oh, I didn't tried it with 2.1, will take a look tonight
<verterok> awilkins: could be bzr-xmloutput compatibility issues?
<renpytom> Is there a way to convert a branch to use a repository?
<GaryvdM> renpytom: I *think* bzr reconfigure
<renpytom> GaryvdM, thanks!
<GaryvdM> renpytom: bzr reconfigure --use-shared
<Christoph^> In my working directory, I have a configuration file. Is it possible to say that this configuration file should not be exported for releases, exporting a sample config file instead?
<GaryvdM> Christoph^: Maybe make a release branch. Change the configuration file in this branch. When you do a release, merge your trunk into the release branch, and export from there.
<renpytom> GaryvdM, it worked for me. Thanks again.
<GaryvdM> renpytom: pleasure
<Christoph^> GaryvdM: uhm, ok
<jfroy|work> morning ya'all
<Adys> Is there a way to run a specific command/file when I run bzr update?
<Adys> eg. compressing my css/js
<mkanat> Adys: You could write a plugin that hooked on_branch_tip_change
<mkanat> Or whatever that hook is called.
<mkanat> post_change_branch_tip
<fullermd> Wouldn't expect that to be the best choice, since there's no reason to assume the branch would change.
<jam> fullermd, mkanat: we don't have a 'wt changed' hook yet, so post_branch_tip_changed is the current best to chose
<jam> choose
<Adys> mkanat, jam: What about committing changes without having them stick in the branch?
<Adys> I dunno if that's clear, I just wouldn't want compressed js/css in every changelog
<jam> Adys: I don't quite understand what you mean
<jam> why do you want to commit the compressed files ?
<jam> if you just auto-generate them
<Adys> Well, apparently java is the only choice I have to compress javascript efficiently, and I'm not installing that on the server
<Adys> so I'd need it on my computer
<jam> if you are using 'bzr-upload' I *think* that supports uploading files that aren't versioned
<Adys> http://wiki.bazaar.canonical.com/BazaarUploadForWebDev
<Adys> looking good. ill have a test run :)
<Adys> jam: nevermind, apparently you need them in your working tree
<jam> do they need to be versioned?
<Adys> yea looks like it
<keithy> hi, is there a way to view a single file in a remote repo
<keithy> like bzr cat
<jam> keithy: bzr cat $REMOTE_BRANCH/path
<keithy> tired that
<keithy> ah http://bazaar.launchpad.net/~keithy/cuis/testing/files
<keithy> could be a problem
<keithy> oh it works now
<keithy> bzr: ERROR: Permission denied: "Cannot create 'build.sh'. Only Bazaar branches are allowed."
<keithy> bzr cat  lp:~keithy/cuis/testing/build.sh
<keithy> thats what I was trying to do
<keithy> the file is there http://bazaar.launchpad.net/~keithy/cuis/testing/annotate/head%3A/build.sh
<keithy> lets try another branch
<GaryvdM> Jelmer: The ppa versions of bzr have debian/bzr-doc.install, but debian unstable does not.
<keithy> nope
<GaryvdM> Jelmer: Is there a reason for this, or is it a bug?
<keithy> jam sorry your suggesting doesnt seem to work
<jam> keithy: works here: bzr cat -r -1 http://bazaar.launchpad.net/~keithy/cuis/testing/build.sh
<jam> you may need the -r -1, not sure
<jam> bzr cat lp:~keithy/cuis/testing/build.sh also worked for me, but that is going over bzr+ssh with my configuration
<GaryvdM> jam: bzr cat lp:~keithy/cuis/testing/build.sh does not work for me
<GaryvdM> bzr: ERROR: Permission denied: "Cannot create 'build.sh'. Only Bazaar branches are allowed."
<jam> GaryvdM: hmm.. just failed, I spoke a bit too soon
<GaryvdM> Maybe platform specific bug
<jam> shouldn't be trying to create a file
<jam> you know what...
<jam> I know the bug
<jam> they were just talking about it (mwhudson and lifeless)
<jam> the code hosting server aborts if you supply it any file that isn't .bzr
<jam> even for reading
<jam> see the recent bug about wanting to unload 'bzr-git'
<jam> because it was probing for .git directories
<GaryvdM> ah
<keithy> hmm
<keithy> it doesnt translate line endings
<jam> keithy: cat gives you the 'canonical' version
<GaryvdM> jam: Intresting: You can do bzr qbrowse lp:~keithy/cuis/testing and then right click on build.sh, but not bzr qcat lp:~keithy/cuis/testing/build.sh
<jam> GaryvdM: right, the issue is that we are probing for build.sh/.bzr/format
<jam> and codehosting says "you are not allowed to create that file"
<jam> which you aren't
<GaryvdM> Ah
<jam> but you should get NoSuchFile when trying to *read* it
<keithy> k
<keithy> ty
<GaryvdM> Ah
<GaryvdM> err sorry - wrong window had focus
<awilkins> verterok, some of the commands seem to be missing attributes, but there also seems to be issues where the client code isn't receiving any output from STDOUT
<verterok> awilkins: oh, ok. I need to take a look to 2.1 soon
<verterok> awilkins: please file a bug about this, in bzr-java-lib or bzr-xmloutput
<awilkins> verterok, Got 13 fails and 9 errors on the test suite.. I'll check out a branch of 2.0.x and make sure that the version difference is really the problem
<verterok> awilkins: ok, thanks!
<GaryvdM> ~/qbzr/wd/qbzr $ bzr rocks --Derror
<GaryvdM> bzr: ERROR: no such option: --Derror
<GaryvdM> Huh???
<lifeless> -Derror
<lifeless> not --Derror
<lifeless> the option is -D, the value given to it is error, or evil, or hpss etc
<GaryvdM> Ah, thanks lifeless
<GaryvdM> lifeless: Good morning to you. :-)
<lifeless> :) moin moin
<RumblePure> I checked out a branch to my laptop. Having modified the code over a couple of days, I wanted to commit back to my stationary.
<RumblePure> I did this trough bzr+ssh. Problem is my stationary had switched ip-number (dont have dyndns at the moment).
<RumblePure> On my laptop in dir .bzr I found a conf file that contained the bzr+ssh://213.45.... address, and so I changed it, and could connect.
<RumblePure> My question is, should I instead had used some kind of command to change the address?
<lifeless> 'bzr switch'
<RumblePure> aaaah, ok!
<RumblePure> but no harm made now that I changed the conf-file manually right? I mean bzr switch would do the same, right?
<lifeless> probably
<lifeless> depends which conf file you mean and what command you ran; you didn't give any details ;)
<RumblePure> yaiks! probably is not reassuring! ;-)
<lifeless> what command were you running that was erroring
<lifeless> [probably would have done the same thing] is what I meant
<lifeless> didn't mean to scare you
<RumblePure> I did bzr commit that simply could not find my stationary through ssh since it had changed ip-number
<RumblePure> So I found the address in .bzr/branch/branch.conf (variable named bound_location) and changed it.
<RumblePure> Then I could run bzr commit.
<RumblePure> Would bzr switch had changed the same file?
<lifeless> yes
<RumblePure> aaaaah, thx so much lifeless!
<RumblePure> spooky nick by the name :-P
<RumblePure> another thing, so when I had changed the address and did bzr commit, it complained about conflicts regarding a file.
<RumblePure> But the weird thing is that that file was under revision control! It was under control on my stationary before i checked out to my laptop!
<lifeless> RumblePure: that means you already had the conflcts locally; bzr st would have shown you that.
<RumblePure> Why do you think there was a problem with the file even if it was under revision control?
<lifeless> a conflict means that it had not merged cleanly
<lifeless> you have more info about the specific case than I do
<RumblePure> well there is no more info because I dealt with the problem. What's frustrating is that I really can't be sure what i did. :-/
<RumblePure> I did bzr resolve file_name, and that messed up the file (added stuff like "<<<<< TREE" to some lines in the file).
<RumblePure> Then I could do bzr commit, and after that I changed the file bac manually on my stationary. In hindsight, I really would like to know what that was about :-/
<RumblePure> *changed the file back
<newz2000> Hi, is there a way to make bzr ignore changes to file permissions for a particular commit?
<lifeless> newz2000: revert or shelve the change
<lifeless> RumblePure: bzr resolve did not add the <<< markers
<lifeless> RumblePure: 'bzr update' would have added them.
<newz2000> ah, ok, thanks lifeless
<RumblePure> lifeless you're right. I did run bzr update too. Just didn't think that caused it.
<RumblePure> But dare to take a guess what the conflict was about? Did the file somehow differ between my laptop and stationary? Of course it did! I had been working on it on my laptop :-/
<lifeless> and you had done another commit on your stationary after starting work on it on your laptop
<RumblePure> lifeless I'm not sure if I did so but that can really be the case! I'll settle with that as a likely explanation in my speculations. :-)
<lifeless> if you had not, you would not have needed to update
<eelik> jam: thanks for the answer :)
<lifeless> bzr log -n0 can tell you
<RumblePure> thx very much lifeless, you put some extra effort to help me in this guesswork. appreciated.
<eelik> jam: I think the first clause in http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html#merging-trunk-to-your-feature-branch is inaccurate or erroneous
<eelik> clause -> sentence
<herbtea> hello all, I'm a newbie to irc and bazaar
<herbtea> I'm hoping someone can help me out with a question I haven't been able to find in answer to in the documentation
<herbtea> In the bazaar explorer options>behavior there is something called "workspace Model" with different options
<herbtea> Options like, shared repository, feature-branches, etc. where can I find out what each of those options do?
<rubbs> herbtea: I'm not sure on where you can find the info, but I could probably tell you what they all mean.
<herbtea> excellent, I'm all ears
<GaryvdM> This may help: http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_your_workspace.html
<rubbs> Shared repos are a common root directory that all branches underneath share history. This is great for space saving.
<rubbs> feature branches are just branches you create to implement a particular branch.
<herbtea> how about collocated branches and plain branch?
<rubbs> er...
<herbtea> thanks GaryvdM, I'll check that out
<rubbs> plain branches are just that, one branch with no special features. All the history is stored at that branches location
<rubbs> collocated branches are branches that share one particular workspace.
<rubbs> so you can "switch" between branches in the same directory
<rubbs> collocated brances are similar to Git's workflow if that helps (probably doesn't if you've never used git)
<herbtea> thanks rubbs, this will give me some more info to ponder
<herbtea> I'm a web developer who is finally taking the plunge into using a VCS
<herbtea> lots to think about in terms of what type of structure makes the most sense for my workflow
<rubbs> herbtea: np. I would suggest trying out the feature branch workflow.
<rubbs> might be hard to understand at first, but once you get it, it's very powerful
<herbtea> how do I specify a person I'm chatting with?
<herbtea> what's the syntax
<herbtea> rubbs: test
<herbtea> ahh
<rubbs> well, most of the time you can just chat in the main room and to get the attention of them, you just type their name
<rubbs> herbtea: yep, you did it right
<herbtea> kewl :)
<herbtea> rubbs: so yeah, I think the feature branch is what I've been considering
<rubbs> if you need to (not always recommended because group chats can benifet others and others can chime in) you can type "/msg nickname message" and it will open a private chat with nickname
<herbtea> thanks
<herbtea> is there a help function to access with this type of info?
<rubbs> yes,
<rubbs> "bzr help" will get you started
<rubbs> "bzr help topics" is also nice.
<rubbs> bzr help and a command will give you specific help with a command.
<herbtea> great, I'll be doing some more reading
<rubbs> np. and feel free to come back and ask questions.
<awilkins> Is there a way to stop bazaar loading bundled plugins (the ones in dist-packages/bzrlib/plugins) but still load the ones on BZR_PLUGIN_PATH ?
<herbtea> quit
<herbtea> bzr help
<rubbs> herbtea: to quit irc type "/quit" or sometimes "/bye" or "/exit" work too
<herbtea> ahh, thanks bro
<rubbs> np, I had to learn too!
<awilkins> e.g. for testing purposes, even if you are running from a source tarball it still insists on loading plugins from this location.. in fact, isn't this a bug? It's rather confounding testing of 2.0.4 vs 2.1.0 because news_merge isn't compatible with the older release.
<gregcoit> a terminology question: is "bzr branch" appropriate for grabbing code from launchpad w/o an account (i don't need to push changes back)?
<lifeless> awilkins: yes
<lifeless> awilkins: set the bzr plugins path
<lifeless> gregcoit: yes
<gregcoit> lifeless: thanks!
<Peng> gregcoit: Although performance over http:// isn't as good.
<awilkins> lifeless, That doesn't seem to override the behaviour of loading plugins from /usr/lib/python2.6/dist-packages/bzrlib/plugins, but I'll just check
<rubbs> gregcoit: yes, because branch only means to "clone" the branch. Push would require an account
<gregcoit> rubbs: as would co, right?
<gregcoit> Peng: not a huge issue in this case I think - but good to know!
<rubbs> gregcoit: no, co would just clone the very last revision. Branch takes down the whole branch history.
<gregcoit> rubbs: ahh, so maybe co is a better option...
<Peng> Ehh.
<lifeless> awilkins: there is definitely a way. hmm
<Peng> Especially over http://, I wouldn't be surprised if checkout was really inefficient.
<rubbs> gregcoit: yeah, if you're just trying to just get the latest snapshot.
<lifeless> rubbs: 'co' does a full branch by default
<Peng> And you need a decent chunk of the history to extract the latest revision from.
<lifeless> gregcoit: 'branch' is fine
<rubbs> gregcoit: oh I'm wrong please see lifeless's comment abouve.
<gregcoit> lifeless: ok, branch is it = thanks!
<gregcoit> rubbs: np - that's the beauty of irc - crowd sourced support
<lifeless> rubbs: the difference between co and branch is that you use 'update + commit' in one, and 'pull/merge + commit+push' in the other
<lifeless> rubbs: co --lightweight downloads only the working files : but does so /much/ less efficiently. Do Not Use Over The Internet.
<rubbs> lifeless: ah thanks, so you have to explicitly say lightweight to make it act like svn?
<rubbs> lifeless: ah, ok. cool. thanks
<lifeless> depends on what you mean by 'act like svn'
<rubbs> just meant checked out the working tree, but you answered my question as I posted it.
<lifeless> if you mean 'use update and commit with what it outputs', that what it does and why it exists.
<lifeless> rubbs: well, even with --lightweight its not acting like svn
<lifeless> rubbs: svn keeps a cache of the unmodified files, bzr does not.
<lifeless> rubbs: and svn has a wire protocol optimised for this style of working - bzr does not.
<rubbs> ah I c, ok then thanks!
<thumper> lifeless: how do you do a partial checkout?
<thumper> lifeless: just a subtree
<rubbs> I don't think that's possible.
<thumper> I recall reading something somewhere about it though
<lifeless> thumper: views
<thumper> lifeless: how do you create a view?
<lifeless> bzr help view
<thumper> bzr help views?
<gregcoit> lol
<gregcoit> jinx
<lifeless> note that using a view still requires all the history
<lifeless> it does not save disk space usage by bzr; but it does avoid having files outside the view in your work area.
<GaryvdM> Hi poolie
<poolie> hello GaryvdM
<GaryvdM> Bla - This office that I'm working at, I have to be out before 12, else I'm locked in till tommorow.
<GaryvdM> Bye all.
<poolie> ok
<poolie> bye
<mwhudson> this doesn't seem like it should be that hard
<mwhudson> what's the easiest way, in a test, to get a standalone branch with a repository that has two heads?
<lifeless> get_branch_builder or whatever
<mkanat> mwhudson: Sooo...no more hangs?
<mwhudson> mkanat: not that i've been informed of, no
<mwhudson> nearly a week now...
<lifeless> mwhudson: so you get a branch builer
<lifeless> start branch
<mkanat> mwhudson: Okay.
<lifeless> do a commit adding root
<lifeless> do a commit with implicit parent
<mkanat> mwhudson: What an annoying time for it to be stable.
<lifeless> do a commit with explicit parent of the first commit
<lifeless> voila, two heads
<lifeless> there are plenty of tests that do that now
<mwhudson> oh, maybe that'
<mwhudson> s where i'm going wrong: not adding the root
<lifeless> if you look at bzrlib's tests
<lifeless> for anything using bb, you'll see the first thing is an added file for the root; cargo cult that.
<mwhudson> lifeless: thanks
<mwhudson> finally a failing test
<mathrick> jelmer: hi
<mathrick> http://pastebin.com/vYVMNWjf
<mathrick> a nice crasher in dulwhich
<mathrick> it tries to do map.read(), without actually defining map, so it ends up going to the built-in function
<mathrick> oh, I see, it was supposed to be mmap
<mathrick> hmm, no
<gregcoit> can I make a new branch from a dir in a branch using bzr?
#bzr 2010-02-24
<bob2> as in branch a subtree of an existing branch?  you can try "split", but I don't think it's production-y yet
<mathrick> okay, so the correct fix is to s/map.//
 * mathrick hugs bzr blame
<gregcoit> bob2: the option is to copy the dir to another place and init is as a new bzr branch, right?
<bob2> yeah, but that loses history
<bob2> you could also branch the whole thing, delete everything else and then move the files in this one dir to the root
<gregcoit> bob2: oh, that works too - thanks!
<mathrick> is there some trick to get bzr blame to find where a particular line has disappeared?
<lifeless> use gannotate and click around versions
<lifeless> is what most people seem to do
<mathrick> aha
<mathrick> http://bazaar.pastebin.com/GaJP7cRb
<mathrick> any idea what's wrong?
<dOxxx> yarr
<poolie> mathrick: this looks like an already fixed bug, are you up to date?
<mathrick> poolie: 2.1.0
<poolie> and also in bzr-git?
<mathrick> bzr git is r721
<poolie> sorry
<poolie> suggest you file or look for a bzr-git bug then
<mathrick> ok
<keithy> when I do bzr cat <remote url> it changes my remote directory setting how do I stop it?
<lifeless> what do you mean?
<keithy> I think I misunderstood the error
<keithy> I got a "permanently redirected" report
<keithy> << is tired
<keithy> btw if you are interested in how I am using bzr for squeak/cuis http://smalltalkers.pbworks.com
<poolie> thanks keithy
<poolie> how are things working out?
<keithy> in what respect?
<poolie> just with bzr and lp
<keithy> I am suffering form spiderman syndrome...."with great power comes great responsibility"
<keithy> very well indeed
<keithy> some quibbles with the squeak licence
<keithy> I dont think people in the OSI community realise how much trouble they caused
<poolie> i heard about some of that
<keithy> it has taken something like 10 years to relicence squeak, all because of two paragraphs in the licence that arent relevant any more
<keithy> for example
<keithy> the licence says, you cant distribute apples fonts
<keithy> but readers of the licence dont think to ask if there are any apple fonts in the product to distribute
<keithy> the last remnant was removed 6 years ago
<keithy> Apart from that
<poolie> right
<keithy> In a week or so
<poolie> i see your point about the difficulty of updating things that predate OSI
<keithy> exactly, it was very disingenious of them
<keithy> especially when squeak was a pioneer of OS for commercial purposes
<keithy> the SqueakL was actually designed to enable reuse for commercial purposes
<bob2> who is 'them'?
<keithy> unlinke Gnu etc
<keithy> squeak was developed by a team in the Apple Technology Group
<keithy> this team was originally at Zero parc
<keithy> xerox
<keithy> parc
<poolie> ok
<keithy> The system was released by xerox to the public by publishing the full spec in a book, the famous blue book
<poolie> so, i hope we work something out
<poolie> rebooting, biab
<poolie> i know, i read it years ago
<poolie> it's pretty cool that it's out there
<keithy> its on the net now
<poolie> rebooting, biab
<poolie> i'm thinking about just removing the attempted fix for bug 456077 from 2.0 because of the fallout it caused
<ubottu> Launchpad bug 456077 in bzr "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [High,In progress] https://launchpad.net/bugs/456077
<poolie> lifeless: ping, teddybear wanted on this
<lifeless> poolie: voice?
<poolie> irc will do
<poolie> just about whether to revert the cross-format fetch warning in 2.0
<lifeless> what was the fallout
<poolie> warnings during upgrade
<poolie> and the message is not always very clear, eg bug 513157
<ubottu> Launchpad bug 513157 in bzr "warning about on-the-fly upgrades to "(remote)", and when upgrading" [Medium,Confirmed] https://launchpad.net/bugs/513157
<lifeless> right
<lifeless> uhm, I think the upgrade one is easy enough; squelch the warning before starting upgrade.
<lifeless> the clarity one, seems like polishon the format %s that spiv worked on in france
<lifeless> so, I would attempt to finish it off rather than revert it, myself.
<poolie> i guess the fallout is not so severe that it needs to be immediately pulled
<poolie> yeah
<poolie> ok
<poolie> thanks
<lifeless> poolie: no probs
<lifeless> poolie: are you doing  https://bugs.edge.launchpad.net/bzr/+bug/515356 too?
<ubottu> Launchpad bug 515356 in bzr "unnecessary message about conversion during upgrade" [Medium,Confirmed]
<poolie> yes
<lifeless> cool; was wondering as its not assigne
<poolie> i'm not doing it right now
<poolie> i'm going to fix the underlying fetch thing first
<poolie> is bug 388269 a dupe of bug 435048?
<ubottu> Launchpad bug 388269 in bzr "getting a branch into an empty shared repository takes a long time to figure out revisions to send" [High,Triaged] https://launchpad.net/bugs/388269
<ubottu> Launchpad bug 435048 in bzr "many get_parent_map calls during walk to common revisions" [Medium,Confirmed] https://launchpad.net/bugs/435048
<lifeless> I think so
<lifeless> if not a dupe then remarkably similar
<parthm> Hello, based on the discussion on bug 503670 'bzr grep', I have created a bzr-grep plugin explained here https://bugs.launchpad.net/bzr/+bug/503670/comments/11
<ubottu> Launchpad bug 503670 in bzr "bzr grep should be builtin" [Medium,In progress]
<ubottu> Launchpad bug 503670 in bzr "bzr grep should be builtin" [Medium,In progress] https://launchpad.net/bugs/503670
<parthm> I would appreciate any review comments this as I am still new to bzrlib API. Whats a good launchpad mechanism for this? Probably the comments can be left on the bug listing?
<parthm> Another question, I am planning to work on the test cases, any pointers would be much appreciated.
<poolie> parthm: there wasn't a bzr-grep already?
<parthm> I could find anything. I saw bzr-search and ~vila/bzr/grep which was unix only.
<poolie> ok
<poolie> so i don't think there's any particular way to say please review this from scratch
<poolie> other than making an empty trunk branch
<poolie> then proposing a merge of all your code into that
<poolie> which would work ok
<parthm> Sounds ok. So for the purpose of review, I would just branch the trunk and put in the grep folder so the comments can be tracked.
<parthm> What would be a good way to create tests? Basically, I need to create a working tree, add files and file content. then run "bzr grep" on it pattern matching on output.
<Kilroo> ...I think I just figured out a set of process I can use to let my team treat our non-versioned ftp servers at work as if they are under version control with all the people who use raw ftp as a sort of "ghost committer."
<Kilroo> I'm not sure though. Gotta think about that. It may require either more steps to follow when committing, or finding somewhere I can put a bzr smart server and getting rather creative with hooks.
<GaryvdM> Hi vila
<poolie> hi GaryvdM, vila
<GaryvdM> Hi poolie
<wgrant> Where is the bzr documentation?
<wgrant> The "Get Help" link on the website doesn't seem to lead there.
<GaryvdM> http://doc.bazaar.canonical.com/en/
<wgrant> Thanks. How does a normal user get there?
<poolie> which website?
<wgrant> http://bazaar.canonical.com/
<bob2> "Documentation" link at the top left
<bob2> or at the bottom
<wgrant> Ah, so to get help I don't actually use the "Get Help" link.
<poolie> easily fixed
<bob2> if you say so
<poolie> with sudo_sarcasm
<poolie> wgrant: howzat
<wgrant> poolie: Looks good. Thanks!
 * wgrant wonders if 90000 users is really a stat that wants to be widely advertised.
<GaryvdM> wgrant: a often quoted figger for world wide developers is 9 mil. Based on that, bazaar is used by 1%
<GaryvdM> Hmm, dose not sound to good.
<poolie> it's very hard to estimate usage of open source
<wgrant> So it's probably a bad idea to try.
<poolie> is that on our homepage now, or elsewhere?
<GaryvdM> vila: I wanted to talk to you about releasing bzr-gtk. I pop back later.
<wgrant> poolie: It's on the homepage.
<wgrant> Otherwise the website is pretty nice now.
<wgrant> Particularly with the compelling linked logos at the bottom.
<poolie> thanks
<poolie> wgrant: how about the project count
<poolie> and the link to the popcon page?
<wgrant> Popcon needs to die, not be linked to from anywhere :/
<poolie>     Bazaar is used by thousands of people around the world on both open
<poolie>     and closed projects, including<br/>
<wgrant> +1
<poolie> gary?
<poolie> maybe s/thousands of//
<wgrant> I considered that. It's hard to say.
<poolie>     Bazaar is used by thousands of projects, both open and closed,
<poolie>     including<br/>
<wgrant> That works.
<wgrant> And is far more likely to be accurate.
<wgrant> And cannot easily be interpreted as being a very low number.
<poolie> k
<poolie> cron will update it in a bit
<wgrant> Thanks.
<poolie> not at all, thanks for the review
<vila> hi all
<wgrant> poolie: Oh, I see that the number wasn't actually pulled out of nowhere.
<wgrant> poolie: But popcon is completely the wrong order of magnitude to use.
<poolie> cause it undercounts?
<wgrant> BzrPopularity oddly states the numbers as facts.
<wgrant> poolie: It's not enabled by default, and the option is well hidden.
<wgrant> I don't know anybody who has it on.
<poolie> well, it's a fact (i presume) that's what it reports
<poolie> right
<poolie> me :)
<poolie> but feel free to update the wiki page
<wgrant> Ah, it is a wiki page. I see.
<wgrant> See, the most popular popcon package has only 1.4 million installations. We have quite a few more users than that.
<poolie> sure, you're quite right
<etenil> Hi all
<etenil> I made the mistake to branch manually (copy-paste of directory). And I have commited some changes in both branches now. How can I make the branch aware that it diverged from the trunk?
<bob2> copying branches is fine
<etenil> yeah, but merging them will be a problem
<bob2> why?
<bob2> bzr merge /the/other/one
<etenil> well, they don't know where they diverged no?
<bob2> sure they do
<etenil> ah
<etenil> does bzr compare the history or something?
<bob2> yes
<etenil> oh I see
<bob2> branch doesn't do anything inherently magic
<etenil> there was no need to worry then
<bob2> you can use 'cp -a' if you prefer
<etenil> ok
<etenil> I was afraid to have done something dumb :)
<etenil> thank you for your help bob2
<bob2> well, back them both up first if you're worried :)
<etenil> ok
<etenil> thanks a lot
<bialix> jaÑÐ ÑÑ
<bialix> jam: hi
<bialix> jam: about next windows installer: please use qbzr 0.18.1 for it, not 0.18.2
<jam> bialix: why is that?
<jam> ah, found your email
<jam> bug #524483
<ubottu> Launchpad bug 524483 in qbzr "qrevert: Select all checked even if there is some files unchecked" [High,Fix released] https://launchpad.net/bugs/524483
<bialix> Ð¾ÑÑÐ https://bugs.launchpad.net/bugs/526933
<ubottu> Launchpad bug 526933 in qbzr "qadd inadvertantly adds all my ignored files " [Critical,Confirmed]
<bialix> jam: https://bugs.launchpad.net/bugs/526933
<bialix> sorry
<aquarius> yo, bzr people. Imagine, hypothetically, that I'd got a branch merged into the trunk of my project and everyone hated me for it, so I now want to submit a new branch which removes the changes that the previous one made. What's the easiest way to create this new branch?
<aquarius> do I just branch trunk, do bzr diff -r -5..-6 > patchfile (or whatever revision my branch landed in), then patch -p0 < patchfile and bzr commit?
<aquarius> that seems a bit long-winded
<james_w> aquarius: branch trunk
<james_w> bzr merge -r -6..-5 .
<james_w> bzr commit
<james_w> bzr push lp:...
<aquarius> haha! you can merge from yourself?
<james_w> propose merge
<aquarius> smart. I didn't know you could do that :)
<james_w> yep
<aquarius> I knew you'd know a better way than making a patch file. Cheers, pal :P
<james_w> and doing the revision range backwards applies the reverse diff
<IslandUsurper> wait. -5..-6 *is* the backwards diff
<james_w> aquarius: err yeah, what IslandUsurper said :-)
<aquarius> james_w, I knew what you meant. negative numbers. It's the opposite of the opposite of what you think :)
<aquarius> vds, ^ :-)
<vds> aquarius: yup
<CaMason> how can I show which files were edited at a specific revision
<Peng> CaMason: bzr st -c 123
<Peng> CaMason: Probably
<rubbs> CaMason: try bzr annotate filename
<rubbs> er...
<rubbs> yeah I miss understood your question
<rubbs> peng's answer might be better.
<Peng> My answer is the best! :D Probably.
<rubbs> heh
<CaMason> thx :)
<stefanlsd> Hi, is it possible to remove a tag?
<stefanlsd> oh ok. tag --delete works. i was using -d and it wasnt
<mathrick> stefanlsd: -d means --directory
<bialix> channel trolls? really>
 * bialix summons garyvdm
<Peng> Eh? Trolls? Where?
<bialix> banner said: [freenode-info] channel trolls and no channel staff around to help?
<bialix> only channel staff has weapon?
<bialix> evening Peng, btw
<Peng> Hi. :)
<bialix> anybody seen new Joel Spolsky's project? http://hginit.com/index.html   Looks like very nice tutorial
<Peng> Hehe, "Mercurial tutorial" rhymes.
<bialix> I wonder why people started bashing svn
<Peng> Because it's terrible, like Boxbot.
<fullermd> It's ugly, and its mother dresses it funny.
<bialix> Peng, Boxbot is http://gunnerkrigg.wikia.com/wiki/Boxbot ?
<Peng> bialix: Yes.
<bialix> nobody likes boxbot
<bialix> but Martin Fowler does rate svn highly
<bialix> and he don't like a Feature Branches
<bialix> is not it's funny?
<gregcoit> i'd like to make a co a branch from launchpad, then branch that co, make changes to the new branch, and push the changes to a new branch on launchpad (without effecting the original branch on launchpad).  Is that sane/o-able?
<gregcoit> er, do-able
<bialix> gregcoit: almost
<gregcoit> well, almost if close.  :)  what am I missing?
<fullermd> Sure, though within the confines of that the co isn't doing anything.
<bialix> gregcoit: it's a bit hard to read your slang
<gregcoit> bialix: yeah, i'm new to bzr terminology
<bialix> gregcoit: you can omit the step of co
<gregcoit> bialix: what I'm trying to do is take a part of a branch and make it into a new branch with history preserved while keeping the original branch unaffected
<bialix> co wo nt he lp yo
<gregcoit> kk - I can see that
<fullermd> Hey!  No Swahili in #bzr!
<bialix> I hear you the white master
<fullermd> When you run 'branch', you're creating a new independent branch.  Things done to it don't affect the original, unless you do things like 'push' that are designed to doing things inter-branch.
<bialix> gregcoit: to extract part of the tree and preserve history.. it's not very easy
<gregcoit> bialix: well, copy might be a betterterm than extract - I don't want to affect the orginal branch contents
<bialix> every branch is separate copy
<gregcoit> bialix: ahh, ok, perfect
<gregcoit> bialix: thanks for talking me through this
<bialix> may I advice you to read tutorial?
<bialix> I'm not really sure I understand your intent
<gregcoit> not a bad idea....
<bialix> hmmm, Kiln is really attempting to be launchpad competitor
<maxb> Except Launchpad doesn't even attempt to enter the "here it is, you can run it on your own server if you like" market
<lifeless> moin
<poolie> hi jam?
<jam> morning poolie
<poolie> how are things?
<jam> going pretty well
<poolie> hi all
<ctrlsoft> 'morning poolie
<spiv> Morning.
<lifeless> vila: ping
<poolie> hi ctrlsoft
<ctrlsoft> poolie: fwiw I managed to get colocated branches in a git repo partially working, I can now list and access them using the patch I proposed to bzr.dev and an additional small change to bzr.dev
<RAOF> ctrlsoft: YOU ARE MY HERO
<ctrlsoft> RAOF: :-) Please note the "in a git repo", this doesn't work in a native Bazaar branch yet and it's still a prototype at this point.
<RAOF> The *only* reason I want colocated branches is so that I can switch to bzr as my full-time git client.
<RAOF> Which means being able to pull & push non-master branches.
 * RAOF imagines a world where reading âgit help addâ doesn't happen quite so often
<poolie> that's great
<lifeless> jelmer: nice
<lifeless> Peng: was Peng taken on twitteR?
<RickCogley> hi - I'm a newbie at version control and at bazaar, and have bzr set up from the latest package on an os x server. Can I ask: when I set up a central repository, what are people doing? Setting up a single repository (e.g. organization name "acme") and putting projects under that, or, are people setting up multiple repositories... ?
<lifeless> RickCogley: repositories are just for storage optimisation: when making a new branch in a repository from another branch in the same repository no data needs to be copied around
<lifeless> RickCogley: this has several implications: many repositories are the norm - every user usually has a repository on their machine
<lifeless> secondly, you don't need to worry about them until you are up and running, they are an optional facility.
<lifeless> lastly, whether you make one for all your projects, or one per project, is totally up to you.
<maxb> Although for performance and disk-space reasons they rapidly become less optional if your project is large
<RickCogley> Thanks lifeless and maxb. We are thinking we'd like to have a single central repository so that we can back it up, but I can see that perhaps if you were doing dev for clients, you might want multiple ones to make sure things are kept separate.
<lifeless> maxb: yes, but that users having to get it 'right' at the start leads to analysis paralysis
<RickCogley> lifeless, ok, so it's kind of "ready, fire, aim" ?
<lifeless> RickCogley: the use or not of repositories won't affect backups (except for the size of data: as a new user that is unlikely to worry you for a while)
<lifeless> RickCogley: yup. My advice: *completely ignore* repositories for at least a week
<lifeless> get used to branching, pushing, pulling, merging
<maxb> I'd agree with that for a user. I think a server admin setting up a central server might want to have a think about them up front
<lifeless> maxb: ONLY if the admin is already fluent with bzr.
<mathrick> <RAOF> The *only* reason I want colocated branches is so that I can switch to bzr as my full-time git client. <-- oooooh
<lifeless> maxb: otherwise they don't have the context to make the right decisions.
<RickCogley> I guess the idea is to just get used to it and you can merge things into a repository later... ?
<lifeless> maxb: and as repositories are just storage optimisation, its easy to add them in later, or remove them.
<mathrick> and yes, git help whatever takes up way too big a chunk of my time spent interacting with git
<RickCogley> lifeless, ok, I see.
<lifeless> RickCogley: 'repository' is just a database. If you don't make one, bzr makes one when you run any of 'init' 'branch' 'checkout' 'push'
<lifeless> RickCogley: let bzr do that while you learn the user facing concepts and concerns.
<lifeless> RickCogley: /none/ of the every day bzr commands manipulate repositories. They all work with 'branches' and 'trees'.
<RickCogley> lifeless, so in other words, you make a branch anyway when you check it out of a repository (not yet sure how to do that but...) and then the commands just work on your local copy. ?
<lifeless> you can't check out of a repository; its just a database
<lifeless> you check out of a branch
<lifeless> delete the work repository from your vocab; its not needed.
<lifeless> s/work/word/
<bialix> mathrick: but do you will miss index?
<mathrick> not at all
<mathrick> index just gets in my way
<mathrick> I use git when I have to, not by choice
<RAOF> bialix: For me, the index is an incovenient version of âbzr shelveâ
<bialix> it seems there are 2 kinds of people: who loves index and who's not
<RickCogley> *check out of a branch* *check out of a branch* *check out of a branch* :-)
<lifeless> RickCogley: yup :)
<bialix> RAOF: is not it's reverse thing?
<RAOF> bialix: Which is one of the reasons it's inconvenient :).  Mostly I want to commit my changes.
<RAOF> That's the default case.
<mathrick> bialix: index is used so rarely it doesn't make sense to make it the central element of everything
<bialix> ok ok
<RAOF> If I want to take some of my changes out, I'll *explicitly* do so, using a (more powerful) explicit command.
<bialix> just too many people around me buzzing how's cool index
<mathrick> actually I use the interactive plugin to do most of my change management
<mathrick> so I just go bzr ci and pick logical sets of changes until I have zero left
<lifeless> poolie: pig
<lifeless> sorry!
<lifeless> poolie: ping
<RickCogley> lifeless, may I ask: what is the strategy if you want to let visitors to a site download the latest version of a script, like a perl or shell script?
<bialix> lifeless: !
#bzr 2010-02-25
<mathrick> lifeless: nothing wrong with pigs! They're really smart
<lifeless> RickCogley: to run locally ?
<lifeless> mathrick: sure; I just didn't mean to say that to poolie, complement or not.
<RickCogley> yes, I have some shell and perl scripts which I'm thinking of making available, and I would like to let people download them and use them. But as painlessly as possible on my side. I.e. the latest version is "just there" for people to get.
<poolie> hello
 * bialix waves
<poolie> hello bialix
<poolie> did you actually mean to ping at all?
<bialix> you? me? not. lifeless is
<poolie> sorry that line was directed to lifeless
<poolie> just saying hello to you
<lifeless> poolie: hi
<lifeless> I was confused by your comment not to use fix committed
<lifeless> I've just reread the guidelines and see now that we've changed our process
<poolie> yup
<poolie> i don't think the distinction is reliable
<poolie> cause things may bounce from review etc
<poolie> also launchpad may get rid of the distinction
<poolie> there is a thread about it
<lifeless> are we able to search for 'in progress with commit in a branch' though ?
<lifeless> I know mpt's opinion on this
<lifeless> ah yes, I thought it was recent
<lifeless> anyhow, its trivia
<lifeless> I will adjust
<lifeless> poolie: I would like to note though, that in progress is also unreliable, as people can flit from one thing to another
<poolie> to me 'in progress' ought to mean 'some work has been invested in this'
<poolie> therefore all else being equal, there is a higher return in finishing it off
<poolie> just how valuable the work is, is a bit hard to capture in an enum
<lifeless> a dial would be nicec
<lifeless> I think you have it on the spot there
<lifeless> to me 'fix committed' is 'nearly there'
<lifeless> whereas 'in progress' would be 'I think I can'
<lifeless> if that makes sense
<lifeless> [I'm not arguing to use F-C, just saying I see the issue and feel frustrated that LP is such a coarse model of how thins work]
<Peng> lifeless: I dunno if it was taken -- it probably was, though. I just don't use it as much anymore. Too many other Pengs around.
<poolie> lifeless: i desire a similar thing for mps too
<poolie> ie to sort them into 'needs lots more work' and 'pp should jfdi'
 * poolie is getting back into bug 456077; it's now working but needs to suppress the warning during upgrade
<ubottu> Launchpad bug 456077 in bzr/2.0 "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [High,In progress] https://launchpad.net/bugs/456077
<poolie> happily the tests now automatically detect that the message is printed there and shouldn't be
<poolie> spiv, hi?
<spiv> Hey.
<poolie> coffee? :)
<thumper> poolie: just had one thanks
<spiv> Always :)
<poolie> so
<poolie> we could actually have coffee or catch up, if vincent will let you
<poolie> also just wanted to see how you were getting on
<poolie> bialix: i think the import tariff stuff is promising
<bialix> poolie: about adding gettext to bzr core
<poolie> we can check if we're actually as lazy as we want to be
<bialix> gettext is loading mo file from disk and parse it
<spiv> Hmm.  Today or tomorrow?  Tomorrow would probably work better for me.
<bialix> poolie: so we can make it lazy till we need translations actually
<bialix> poolie: maybe some sort of lazy_registry will help
<bialix> poolie: I need to think about it
<lifeless> tomorrow avo I can do
<lifeless> bialix: for gettext, I think lazy is pointless
<poolie> bialix: is this to avoid loading the .mo file, or loading gettext itself?
<lifeless> bialix: either we use it, and we'll need it on every invocation, or we don't use it and don't need it.
<bialix> lifeless: not so fast!
<bialix> poolie: to read/parse mo
<bialix> lifeless: you don;t need gettext when you run status and it prints no results, right?
<poolie> good point
<bialix> today bzr has very long startup
<bialix> comparing to hg, you know
<lifeless> bialix: we long stuff even in that case.
<bialix> maybe mo parsing won't be significant
<poolie> right, we want to pull that down, not add to it
<lifeless> bialix: and some of what we log is stuff that we'd also output under other circumstances
<poolie> so we need to draw a line as far as what is translatted
<poolie> i'm not sure that mutter stuff should be
<poolie> though that's true there is not a clear distinction between internal and user-facing messages
<poolie> yte
<poolie> yet*
<bialix> no sense to write translated strings to .bzr.log at all
<lifeless> I agree we want to reduce the startup time; I'm just saying that *if* we start doing translations, we should expect to pay the gettext library load time + mo parsing on 99% of invocations
<poolie> well
<bialix> you won't be able to understand bug reports :-P
<poolie> we should aim to make it fast enough that even if it is loaded, it doesn't kill us
<poolie> :)
<lifeless> poolie: agreed.
<poolie> making the test suite pass under LANG=ru would be nice
<poolie> i don't think it does now
<lifeless> my point is simply that lazy only applies usefully when you *can* avoid work
<poolie> yep
<poolie> a bit like caching
<lifeless> oh, and, also like caching, doing lazy is itself work.
<bialix> lifeless: actually gettext.py has some cache inside
<bialix> but it search the disk anyway every time
<bialix> it will be slow on windows
<bialix> we can just subclass GNUTranslations class and make it lazy to load mo
<bialix> then we pay penalty only on each string that should be translated
<lifeless> I think this is a case for benchmarking
<bialix> poolie: btw, about your recent ui changes, we may want to make the note/info metods to write translated strings only to termina;
<bialix> and english to .bzr.log
<poolie> interesting
<bialix> this is very important IMO
<poolie> maybe
<poolie> i think we need to detangle the log from the ui a bit more
<poolie> perhaps logging everything done to the ui makes sense
<poolie> but it's still a bit weird atm
<bialix> I'm not quite understand
<poolie> so
<poolie> for example, some tests that want to know about messages to the user look in the equivalent of .bzr.log
<poolie> inside the test
<poolie> this is a bit weird
<poolie> some of the methods in trace.py are to do with logging, and some with user interaction
<poolie> this kind of thing
<bialix> I don't follow
<bialix> we should not run tests with real translations
<bialix> rather with zzz pseudo translations, which was invented by igc
<poolie> ok
<poolie> at the moment some tests fail just because we expect system exceptions to be in english
<bialix> gettext is only half of the i18n and l10n
<bialix> ah, yes
<bialix> OSError stuff
<bialix> yep, they are done so inside python itself
<bialix> btw, this was changed only in 2.5
<bialix> 2.4 always prints english
<bialix> at least for me
<poolie> i agree we don't want the tests to know about every possible translation
<bialix> also there will be desire to localize dates in bzr log
<bialix> I have no idea how to test such things properly
<poolie> it will take some creativity
<poolie> i'm suggesting as a first step we avoid any accidental dependency on english in the tests
<bialix> or just disable it for selftest
<bialix> btw, in qbzr we don't enable gettext when we run selftest
<bialix> ditto for bzr-explorer
<poolie> james_w: if there's something you think would be a much better main focus than merge/resolve, please do speak up
<james_w> I think it has its merits
<james_w> and is a focus that will bring something to all stakeholders
<poolie> k
<poolie> i think so too
<poolie> if there are particular bugs you can nominate them too at any point
<poolie> spiv, i'm sure you understand this but it's not quite clear in your recent mails
<poolie> which is that some things like os.read need special handling but can be handled correctly
<poolie> whereas some just cannot be done correctly
<poolie> perhaps clarifying this is less useful than just fixing the bug though :)
<spiv> poolie: right
<spiv> poolie: so until_no_eintr is currently correctly handling basically that case for us, read from a pipe
<spiv> Unfortunately it seems all the other uses are broken.
<spiv> That said, siginterrupt side-steps the whole mess for us quite nicely.
<poolie> k
<poolie> it may not work on all platforms
<poolie> but it may cover enough of them
<spiv> Yeah.
<mwhudson> there are only three platforms anyway these days!
<herbtea> hello all
<spiv> mwhudson: hardy, karmic and lucid?
<poolie> lol
<mwhudson> poolie: not quite what i meant, but that'll do
 * fullermd looks disgruntled   :p
<mwhudson> fullermd: os x is almost like freebsd, right?
 * mwhudson runs away and stops trolling
<lifeless> mwhudson: contagious huh ;>
<fullermd> Don't mach me hurt you!
<poolie> actually more seriously perhaps we should only run ppas for them
<poolie> if that made it any easier
<poolie> it's probably not much easier though
<poolie> abentley: i guess you're asleep?
<abentley> poolie, hi.
<poolie> hi
<poolie> i was just running tests in a bzr 2.0 branch
<lifeless> 2230 or so, I'd guess.
<poolie> and bzrtools's fail
<poolie> because it checks the version when running the command, not when running the tests
<poolie> so i was just thinking about this
<lifeless> poolie: there is a test_selftest test that fails with bzrtools; its not really bzrtools fault though. I'm sure you are seeing more, I'm just mentioning one that I saw this morning.
<poolie> it's not really urgent
<poolie> this is different
<poolie> essentially it runs its tests regardless of bzr version, but they can't possibly pass on 2.0
<poolie> so anyhow
<poolie> - it's interesting not to grumble until someone actually uses the command
<poolie> kind of cleaner than failing to load
<poolie> - iwbni this was done through the standard channels, perhaps
<poolie> - iwbni if the tests also skipped, or refused to load, if the commands aren't going to run
<abentley> poolie, I see.  The version mismatch checking is only done with the commands now, because people complained about bzrtools warning them when they were running irrelevant commands.
<poolie> yeah
<poolie> it's quite nice actually
<poolie> perhaps that should be the standard thing
<poolie> obviously it is a bit more difficult for plugins that act through hooks
<abentley> I was just about to say that.
<abentley> I guess I can add a version check to the bztools test_suite method.
<poolie> and return []?
<poolie> (semantically not literally)
<poolie> anyhow separately, teddybears, i would like a way to cancel some user warnings systematically
<poolie> istm it would be clean to give the uifactory a list of ones that have been squelched
<poolie> then upgrade() can squelch the cross-format fetch warning for the duration of its run
<abentley> poolie, no, I'd probably just emit a warning.  I wouldn't want to interfere with actually testing bzrtools.
<lifeless> one thing that occurs to me
<lifeless> if you're doing per command version locking
<poolie> ok, but at least some of the tests can't possibly pass, because they will examine the bzrlib version then fail
<lifeless> is that you could use the test suite to tell you when commands break, and only change those commands to be requiring new versions
<poolie> so we could say they are expected to fail
<poolie> that would be interesting
<poolie> at the moment this is the same check across all commands, but applied at invocation time
<poolie> but you could do that
<lifeless> put an attribute on the class; define a base value so most classes don't need to set it, sort of thing.
<poolie> right
<poolie> it would be interesting to consider how to do this for other things
<poolie> in principle you could only complain about bzr-svn when you actually try to use a svn repo
<abentley> lifeless, it's an interesting idea, but would it be useful?  Most people will not have mismatches, assuming they use packaged versions.
<poolie> it may be overkill
<poolie> what i would like to get to is to get myself out of the habit of always testing with --no-plugins
<poolie> by removing snags when they appear
<lifeless> abentley: it would make it easier for devs to run with plugins enabled during test runs of core
<lifeless> abentley: s/would/might/
<abentley> lifeless, so you would disable the tests for a command if there was a version incompatibility?
<lifeless> abentley: I think gracefully show that the incompatibility is there, rather than hard-fail
<lifeless> abentley: so to upgrade bzrtools, one would change the version lock, and they would start executing, and failing if there is a problem.
<abentley> lifeless, yes, but what about the functions used by those commands?  Those typically also have tests, and would not be version-locked.
<lifeless> abentley: two angles occur to me: How often do they actually break? And perhaps you will get patches.
<abentley> lifeless, and it's the functions that are likely to be incompatible.  Most of the commands are thin wrappers.
<abentley> lifeless, breaks have become pretty unusual, both in commands and in functions.
<poolie> so perhaps you could just relax the maximum-version limit?
<poolie> in this case i'm actually going back to an earlier version
<poolie> so if it's marked incompatible, it probably really is
<poolie> which is fine
<poolie> but i just want the tests to do something clean
<poolie> like report a missing dependency
<abentley> poolie, I'm thinking of relaxing the limit during test runs.  In my testing 2.0 passes with bzrtools trunk when I do that.
<abentley> poolie, I can relax the minimum-version limit, but I canna predict tha futurre, so changing the maximum-version limit is riskier.
<poolie> yeah it's tough to say if it's better to get some false alarms or to get users complaining about weird attributeerrors when it does go out of date
<spiv> How about emitting a warning about possible version-mismatch only when an error occurs?
<poolie> could be good
<spiv> Ideally only on TypeErrors and AttributeErrors, but probably other kinds will happen sometimes.
<spiv> It depends on if the breakage is "doesn't even run" or "starts to run then leaves a broken mess"
<spiv> If the latter can occur, you really do want to bias towards fail early.
<herbtea> hi all, I'm a new bazaar user and I'm using explorer and I hope somebody can answer a question for me
<herbtea> I've created a shared repository with a trunk
<herbtea> added project directory and files from a new project
<herbtea> so far so good
<herbtea> when I click on the Local Changes tab for this repository there is a message " No parent location defined yet", what do I need to do to define the parent location?
<spiv> Typically that's automatically set when you first 'bzr pull', or when you create a branch by doing 'bzr branch URL'
<spiv> I'm not sure that it makes sense to set it for your case, but if you want to I'd guess that pulling from another location would do it.
<spiv> (I'm not sure how to use explorer to do that, sorry)
<abentley> poolie, lifeless, I've made the change in the 2.0, 2.1 and trunk series.
<herbtea> spiv: thanks for the info. Still not 100% clear on the best process for setting up my project for versioning
<poolie> abentley: which one?
<herbtea> spiv: I did a bzr init-repo on a top level dir, then a bzr init on the trunk
<herbtea> spiv: I then added my proj dir and files to the trunk and did a commit
<spiv> (I'm a bit curious about why you thought you should set that location?)
<herbtea> which location?
<spiv> Well, you asked "what do I need to do to define the parent location?", which suggests you thought you should set it.
<herbtea> yes
<spiv> But that's a tangent to your current question, so ignore that if you like.
<herbtea> I'm getting what appears to be an error message in explorer
<herbtea> explorer says "No parent location defined yet"
<spiv> The init-repo, init, add, then commit sounds good.
<spiv> Ok, sounds like something that could be improved in explorer.
<abentley> poolie, disabling the version check while commands are running.
<herbtea> so, this is all local, I have a server that I want to be the main project repository, do I simply copy this top level dir I just created to the server?
<spiv> Ah, ok.  You can do that, although you'll want to 'bzr remove-tree' on the server afterwards to be tidy.
<herbtea> ok, just the rev history on the server?
<spiv> Or, you can 'bzr init-repo' the location on the server, then 'bzr push' your trunk to server
<spiv> Right.
<herbtea> kewl
<herbtea> using the locations.conf, is there a way I can specify the parent location of a branch?
<spiv> IIRC it's set in the branch's own .bzr/branch/branch.conf, but it might be possible to set it in locations.conf too
<spiv> It would be the 'parent_location' option.
<herbtea> thanks, I'll give that a go and see if that clears the error message in explorer
<herbtea> thanks for your help spiv :)
<bialix> garyyyyyy
<herbtea> bye all
 * bialix -> zzz
<Leemp> Question: Is there a good private hosting system for bzr? Eg, a software suite you can install that matches some of the feature sets Github and BitBucket provide?
<Leemp> Ie, i need it private and not public.. so Launch won't work for me.. sadly.
<bob2> you can run launchpad yourself if you like!
<bob2> there's bzr-trac, too
<lifeless> you can also pay for private launchpad hosting
<lifeless> if you want
<Leemp> lifeless: !? They're doing that now?
<Leemp> lifeless: Last i checked, ages ago, they weren't heh.
<poolie> Leemp, https://answers.edge.launchpad.net/launchpad/+faq/208
<poolie> says beta but it's in production
<Leemp> poolie: Ah, still a bit expensive when compared to Git/HG it seems though
<Leemp> poolie: Or are they offering different plans eventually/now, than they list in that faq
<Leemp> And i wonder if that's per project..
<poolie> per project
<Leemp> Ouch :o
<poolie> not that it's not per user or per repo
<poolie> or per project group, i would imagine
<poolie> s/not/note
<bob2> depending on what project means, that's competitive with github at least
<Leemp> bob2: Well it depends on size i suppose. For me though, a personal small developer, $5/mo gets me 5 projects iirc on github.
<bob2> 5 repositories
<Leemp> Separate issue tracking for each one, etc
<Leemp> bob2: Does launchpad group all the features it provides per repo? or per "project"? .. We're getting cross terms anyway heh.
<Leemp> bob2: Eg, would i still have 5 separate issue trackings, and whatnot, with launchpad? Or only a single issue tracking, for a single "project"?
<poolie> Leemp: i suggest you mail them or ask in #launchpad
<Leemp> poolie: Righto, conversation slid that way i guess :)
<Leemp> So on the bzr side of things
<Leemp> There's a trac mod, and i can run launchpad myself.
<poolie> right
<poolie> spiv, lifeless, can i have a quick review on the ui_factory side of https://code.edge.launchpad.net/~mbp/bzr/456077-cross-format-fetch/+merge/20041
<poolie> ie adding a show_user_warning(warning_id, **) that can be turned off by a flag
<spiv> poolie: looks ok to me
<spiv> I'll add a slightly longer review to the proposal :)
<poolie> thanks
<RyNy_> having a problem branching from LaunchPad
<poolie> k
<RyNy_> This is my error
<RyNy_> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<spiv> RyNy_: pastebin the full error?
<RyNy_> Sorry, how?
<spiv> RyNy_: paste it into http://pastebin.com/, then share the resulting URL here
<RyNy_> Spiv: sorry how do I get more of an error? That's all I see in Terminal.
<RyNy_> This is the command: bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2
<spiv> RyNy_: interesting, often there's more text than that
<spiv> RyNy_: could you paste the most recent section of you ~/.bzr.log, then?
<poolie> RyNy_: at a guess your ssh command to connect is not working
<poolie> what does  'ssh bazaar.launchpad.net' do?
<RyNy_> spiv: there's not anything more in the log file.
<RyNy_> I also had this error on a different server trying to branch from the same source:
<RyNy_>  bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~pantheon-developers/projectmercury/bcfg2/".
<Peng> That's correct. It's not.
<Peng> That branch does not exist,.
<RyNy_> Peng: What am I doing wrong? Is it the ~ ?
<RyNy_> Peng: If it is any help here is the URL for the project: https://code.launchpad.net/projectmercury
<Peng_> RyNy_: The only existing branch in that project is lp:~pantheon-developers/projectmercury/trunk (which you can also refer to with the shorthand lp:projectmercury)
<RyNy_> Peng: Thanks, so the branch doesn't exist. I see that now by looking at the project site at LaunchPad.
<RyNy_> Question: I suppose if it did exist then it would appear on that URL under the branches tab, right?
<Peng> Uh-huh.
<RyNy_> Peng: Cool. I do see a bcfg2 file at http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files.
<RyNy_> Suppose if I were to guess what the correct path should be, it would be http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/
<Peng> What are you trying to do, exactly?
<spiv> Correct path for what?
<Peng> Those two URLs are for the Loggerhead web viewer running in bazaar.launchpad.net.
<spiv> That's a correct path for viewing the 'bcfg2' directory of the ~pantheon-developers/projectmercury/trunk branch via the web viewer.
<spiv> But it's not a valid location to use with 'bzr branch'
<RyNy_> I'm trying to branch from Project Mercury, which is a high performance Drupal installation. I'm following the install directions, but they broke on that branch command.
<Peng> "bzr branch lp:projectmercury"
<RyNy_> You can see the install directions at: http://groups.drupal.org/node/50408
<Peng> Where are these instructi -- thanks. :D
<spiv> RyNy_: my guess is those instructions are out of date
<spiv> RyNy_: I think someone probably renamed (or deleted?) the ~pantheon-developers/projectmercury/bcfg2 branch
<RyNy_> I commented where I got stuck. Search on the page for bzr branch lp:~pantheon-developers/projectmercury/bcfg2 /var/lib/bcfg2
<poolie>  spiv, could it be that https://bugs.edge.launchpad.net/bzr/+bug/280608 has already been fixed by you?
<ubottu> Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress]
<spiv> poolie: it could be!
<spiv> poolie: off the top of my head, I'm not certain.  I have certainly touched code in that area, and may well have fixed that.
<spiv> poolie: but I couldn't be sure without trying to reproduce, I think.
<RyNy_> ubottu: sorry, what that directed to me? Launchpad bug 280608
<spiv> poolie: I'd guess about 70% likely to have fixed that
<ubottu> Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Medium,In progress] https://launchpad.net/bugs/280608
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<spiv> RyNy_: no, that bug was for me
<spiv> RyNy_: right, I see your comments
<spiv> RyNy_: the simple fact is that there is currently no lp:~pantheon-developers/projectmercury/bcfg2 branch
<RyNy_> Spiv: ok so I'm not loco, just bad branching instructions?
<Peng> RyNy_: Well, out-of-date instructions.
<RyNy_> That helps I suppose. Just have to wait for the instructions to be updated or better.
<RyNy_> Thanks for your help.
<spiv> RyNy_: right.  I expect they were good once, but have gone stale because that branch has gone
<spiv> RyNy_: If I had to guess,
<spiv> RyNy_: I would try either using lp:projectmercury branch instead, and if that fails, using the 'bcfg2' inside that branch instead.
<spiv> RyNy_: but that's just guesswork :)
<spiv> RyNy_: also, the errors you've pasted into that wiki page have the extra text I was looking for before when you first joined this channel.  Argh!  :)
<spiv> (Even though that turned out to be unimportant)
<poolie> :)
<RyNy_> Spiv: sorry the wiki comments were from a couple nights ago. If you were to guess the correct bcfg2 path, what would it be?
<spiv> RyNy_: well, https://code.launchpad.net/~pantheon-developers/projectmercury/ only shows one branch
<spiv> RyNy_: and as you've noticed that branch has a bcfg2 directory (as you can see at the http://bazaar.launchpad.net/~pantheon-developers/projectmercury/trunk/files/head%3A/bcfg2/ link)
<spiv> RyNy_: so there aren't many options; probably those instructions either expect that entire branch, or that subdirectory of that branch, or something that isn't there at all.
<RyNy_> Spiv: so is the command I'm looking for bzr branch lp:~pantheon-developers/projectmercury/trunk/bcfg2 /var/lib/bcfg2
<spiv> RyNy_: I don't know
<spiv> RyNy_: Actually
<spiv> RyNy_: I know it's not that command, because that's not a branch
<spiv> RyNy_: (you can't 'bzr branch' a subdirectory of a branch)
<spiv> RyNy_: You might need "bzr branch lp:projectmercury" /var/lib/bcfg2
<spiv> er,
<spiv> "bzr branch lp:projectmercury /var/lib/bcfg2"
<Peng> RyNy_: Ask the Project Mercury people or, failing that, someone else who knows what bcfg2 is.
<spiv> Or you might need "bzr branch lp:projectmercury /tmp/projectmercury && cp -a /tmp/projectmercury/bcfg2 /var/lib/bcfg2" to just grab that subdirectory
<spiv> Or maybe something else; I really don't know.
<Peng> RyNy_: Try spiv's suggestions first, of course, but you should still report to them that their docs are out-of-date.
<RyNy_> Cool, on the branches page of their LaunchPad page that is the only branch. I'll contact them again and see if I can get some help.
<RyNy_> You guys have been very helpful. Thanks!
<spiv> You're welcome.
<Peng> :)
<poolie> spiv, can you suggest anything to https://answers.launchpad.net/bzr/+question/102270 ?
<vila> hi all !
 * fullermd waves at vila.
<vila> fullermd: \o_
<fullermd> vila: BTW, fix to paramiko port committed {to,yester}day, so the unadorned port won't break with setuptools.
<fullermd> Now if only a new version of paramiko would be released that didn't crap on pycrypto...
<vila> fullermd: good to know !
<vila> I dislike that kind of workaround otherwise as I tend to forget.... what was I speaking about ?
<fullermd> Eh?  Who're you?
<spiv> poolie: sure
<spiv> poolie: (short answer: post_branch_tip_change + TipChangeRejected)
<spiv> I mean, s/post/pre/, of course
<poolie> thanks
 * poolie fixed a bug with 7 dupes, that's a nice feeling
 * spiv finishes for the day, time to swim
<poolie> me too
<poolie> cheerio
<poolie> hi vila, bye vila
<spiv> poolie: oh, that looks like a nice bug to have fixed!
<spiv> I might review that later tonight.
 * spiv -> really gone
<vila> poolie: lol
<vila> lifeless: pong ?
<poolie> hi vila
<vila> poolie: Are you back or a poolie's clone ? :D
<poolie> really here
<ronny> hi, where can i get something like rebase?
<poolie> my desktop is a bit sad
<vila> good ;)
<poolie> ronny: bzr-rewrite
<vila> ronny: lp:bzr-rebase ?
<vila> ronny: right, lp:bzr-rebase redirects to https://edge.launchpad.net/bzr-rewrite anyway
<ronny> hmm
<ronny> i reverted to using diff, pull --overwrite;patch
<lifeless> vila: I was thinkin we should finish the parallel stuff
<vila> lifeless: <shudder> I'd love too... What TZ are you in these days ?
<lifeless> GMT+12 more or less
<vila> NZ ?
<lifeless> waking early in .au
<Kamping_Kaiser> very early
<vila> AFAIR, your main objection was about compatibility with EC2-like setups, I still have to investigate how I can test that locally (I haven't even look at --parallel=?? damn, bzr help selftest doesn't even mention the possible values :-/)
 * bialix waves at vila
<vila> bialix: _o/
<bialix> _o>
<vila> lol
<fullermd> Offsides.  5 yard penalty.
<vila> fullermd: I'm affraid neither bialix nor I can undesrtand that :D
<poolie> i'd like to do something that suggests missing commands be installed from plugins
<poolie> i think we talked about this before
<vila> poolie: with beuno I think
<fullermd> vila: Oh, it doesn't really mean much.
<vila> poolie: AFAIR lifeless and beuno talked about some kind of registry but I now wonder if a bzr-guess-like approach couldn't be easier
<lifeless> the registry is built
<lifeless> just needs populating
<lifeless> Thats why I wrote the plugin metadata scanner
<lifeless> in principle, all you need to do is:
<lifeless>  - write a plugin which hooks command not found (like -guess does)
<lifeless>  - give it a static dict of metadata
<lifeless>  - write a script to analyse the plugin metadata for as many plugins as you can get your hands on and shove it into that dict every now and then,
<lifeless> vila: yes, that was my main objection.
<lifeless> [parallel]
<poolie> yeah
<poolie> though {'rebase', 'https://launchpad.net/bzr-rewrite'} would solve 50% of it ;-)
<lifeless> sure
<lifeless> I would support someone starting that way
<lifeless> though bzr branch lp:plugin-info is pretty easy too
<lifeless> I'd finish it off myself, but its not top of my TODO pile
<Kamping_Kaiser> wonder why pulling lp:bzr on consecutive days can give me file conflicts
 * Kamping_Kaiser blames rouge pixels
<bob2> any local diffs?
<Kamping_Kaiser> nope.
<Kamping_Kaiser> i'm doing an 'mr up', and theres almost always 1 or 2 bzr repos conflict out (or not apply their changes). i've not dug into mr to discover if it has a timeout of some sort on doing updates
<Kamping_Kaiser> even with an update, i find it odd to wind up with conflicts
<bob2> ah, not bzr itself?
<Kamping_Kaiser> todays conflict was lp:bzr
<Kamping_Kaiser> i don't know how bzr is called by mr to do the update though
<johnf> Is there an easy way to have the working tree updated on the server when using bzr+ssh where all the work is done server side?
<vila> johnf: lp:bzr-push-and-update
<johnf> vila: I just realised that it does actually do what I want. I misread it before, thanks
<johnf> vila: isn't that client side?
<vila> johnf: it is
<vila> oooh, you mean you want the tree to updated automatically like with some hook ?
<johnf> I was after something that worked on the server so that I don't have to reply on my users having a plugin installed
<johnf> yes
<vila> hmm
<johnf> or even it could just push on the server to a different location
<johnf> but somewhere on the server I want an up to date working tree
<johnf> maybe I can get automirror to do what I want
<vila> could be
<vila> I don't know about pre-canned solutions for that myself, but others may
<gioele> hello
<bialix> hello
<jml> hi
<jml> I'm writing a plugin
<jml> it's designed to replace a hook that Twisted is using to require all trunk commits to add "news fragment files"
<jml> I figure that pre_change_branch_tip is the right kind of hook
<jml> but I'm not sure whether in that hook I should check each new revision individually, or whether I should check the result of the whole
<Lo-lan-do> Hi all
<Lo-lan-do> Remind me again how I fetch ghost revisions from another repository that has them?
<jelmer> Lo-lan-do, bzr fetch-ghosts
<Lo-lan-do> Aha, thanks.
<jelmer> jml: I'm not sure I understand your question correctly
<jelmer> jml: but it'll be called only once if you pull in a lot of revisions into mainline, for example
<abentley> jam: around?
<muffinresearch> on the subject of pre_change_branch_tip is there an easy way of introspecting the type of change made e.g, push, commit, uncommit etc?
<muffinresearch> sorry meant post_change_branch_tip not pre
<jelmer> muffinresearch, you can register to individual hooks for those
<muffinresearch> jelmer: This is running on the server rather than the client.
<lifeless> the server doesn't know in that case
<jelmer> muffinresearch: does post_change_branch_tip run on the server ?
<lifeless> jelmer: yes
<jelmer> ah, nice
<lifeless> jelmer: (another reason to use it in zeitgeist :P)
<jelmer> lifeless, actually for zeitgeist you'd want client side hooks since that's where your zeitgeist daemon is running
<lifeless> jelmer: that hook runs on both sides
<lifeless> I was meaning if you push to your laptop from somewhere
<jelmer> ah, right
<muffinresearch> Right now I'm looking at the revnos to work out if it's a commit which feels a bit clunky.
<mathrick> jelmer: poke?
<jelmer> mathrick, hello
<mathrick> did you see the crasher about map.read() not being a method I ran into yesterday?
<jelmer> yeah, that'd already been fixed just not pushed yet
<jelmer> see lp:dulwich
<mathrick> ah
<mathrick> good then
<mathrick> and the other bug about annotate? This one I filed properly in launchpad
<mathrick> https://bugs.launchpad.net/bzr-git/+bug/526792 this one
<ubottu> Launchpad bug 526792 in bzr-git "Revision not present error in annotate" [Undecided,New]
<mathrick> poolie said it looked like a bug that's been fixed already in bzr itself, but I'm pretty up to date
 * mathrick notes he still doesn't understand how the new package structure for bzr is supposed to work, so far it seems to mean no new versions for karmic and no gains
<jelmer> mathrick: that looks like a bzr core bug to me
<mathrick> ok, how do I diagnose it then?
<jelmer> mathrick, what do you mean with new package structure?
<mathrick> the thing where PPA no longer gets packages
<mathrick> I think it's supposed to be replaced by main repo uploads, except that I get none in karmic
<mathrick> so overall I'm left out in the cold
<jelmer> mathrick: I think Gary has just fixed the PPA
<mathrick> oh, lemme take a look
<mathrick> jelmer: I might be confused, but last time I complained about it, I got told it was in the middle of a policy change and there was a thread I didn't have the time to read properly
<jelmer> mathrick: My understanding was also that the idea was to just have recent versions of bzr in backports for older Ubuntu releases
<jelmer> but I'm not involved in that part of Bazaar, so I'm not sure what the status or exact plans are
<jelmer> poolie should know more, we should ask him when he's back
<mathrick> right
<mathrick> mathrick@hatsumi:~/elisp/dist/dvc$ bzr log lp:bzr -r 4797.19.2..-1
<mathrick> bzr: ERROR: Start revision not found in left-hand history of end revision.
<mathrick> huh?
<mathrick> what does that mean?
<mathrick> it means it wants me to say -n0, but that's a crappy error message
<jelmer> mathrick, please file a bug
<mathrick> yeah, doing that now
<vila> mathrick: please explain what you were trying to achieve with that command
<jelmer> mathrick, thanks
<jelmer> vila: do you happen to know what the status/plans for bzr in the backports for older Ubuntu releases is?
<mathrick> vila: see everything that happened on the main bzr branch since 2.1.0 got released
<mathrick> I started with tag:bzr-2.1.0 and that's the revision it corresponds to
<vila> jelmer: AIUI, it's hapening. slowly
<jelmer> mathrick: you should also be able to just use tag:2.1.0 rather than the version number
<mathrick> jelmer: I did that, but thought the error was because of that at first
<jelmer> mathrick: although admittedly that isn't an excuse for giving such a bad error message
<mathrick> which is why I switched to the explicit revno
<mathrick> but that doesn't help anything, since that's completely not what bzr was complaining about
<jelmer> vila: ah, thanks. This is mainly waiting for SRU's to get approved?
<vila> the bad error message is a consequence of an optimization... abstraction leak ftl :-/
<vila> jelmer: that's what I understand yes
<mathrick> why does it error out when I want to start with a merge anyway?
<mathrick> vila: oh
<vila> mathrick: if you have a up-to-date bzr.dev, 'bzr missing lp:bzr/2.1' will better answer your question I think
<mathrick> I don't, which is why I didn't do it locally
<mathrick> I love that bzr lets me ask questions about remote repos
<mathrick> and I get annoyed each time git tells me I don't need that because it's not as "efficient"
<mathrick> vila: so there's no way to give two explicit locations to bzr missing?
 * mathrick thinks absolutely everything should accept a location or -d
<vila> mathrick: the only trick I can think of then is using 'bzr qlog lp:bzr/2.1 lp:bzr' :-/
<mathrick> that's such a boon when trying to nagivate a forest of branches you need to find a specific change in, but don't want or need to download
<vila> mathrick: please meet bialix about generic -d :-D
<mathrick> heh
<mathrick> can I file a bug about it, or is there one already?
<vila> mathrick: note that the qlog trick allows you to navigate at will and should clearly shows what each branch is missing from the other
<mathrick> yeah, a browser in this situation is probably the best option
<mathrick> but the point stands
<mathrick> seriously, operating on arbitrary locations is to bzr what rebase -i is to git
<vila> mathrick: I don't remember of hand, if you have good arguments, feel free to file a new one, it's sometimes easier to de-dupe
<mathrick> ie. the reason to switch
<vila> mathrick: I agree with -d, I think it could be implemented quite easily but it may require checking all commands for consistency
<jelmer> mathrick: did the annotate error occur with a recent version of bzr? what does "bzr check" say?
<mathrick> speaking of killer features, it should be mentioned in bold on the "reasons to switch to bzr" page
<mathrick> jelmer: 2.1.0
<mathrick> lemme try
<mathrick> https://bugs.launchpad.net/bzr/+bug/527878
<ubottu> Launchpad bug 527878 in bzr "All commands should accept an explicit location or -d" [Undecided,New]
<mathrick> jelmer: http://pastebin.com/2mhRe15K
<mathrick> btw, it's a colocated repo, that is I'm using bzr-colo with it
<x_dimitri> how does one set one's identity per banch using qconfig?
<jelmer> mathrick: does bzr reconcile fix it perhaps?
<mathrick> I can try
<mathrick> what's "inconsistent parents" btw?
<mathrick> hmm
<jelmer> text revision parents that aren't set correctly
<mathrick> I think it just got confused
<mathrick> http://pastebin.com/aFEbpfbM <-- is that supposed to happen?
<mathrick> ~/Dev/ is my shared repo
<jelmer> mathrick: that looks ok
<jelmer> mathrick: Does annotate work now?
<mathrick> nope, though I'm hitting several bugs at once it seems
<mathrick> nope, same bug, and a couple of other ones
<jelmer> mathrick: what other ones?
<mathrick> sorry, apparently I need a new battery for my laptop
<mathrick> did anything happen since <mathrick> nope, same bug, and a couple of other ones ?
<jelmer> mathrick, yeah, I asked what other bugs you were hitting?
<mathrick> jelmer: ah, the impossibility of annotating a file that's not currently in the working tree (ie. removed or renamed)
<jelmer> mathrick, doesn't -r allow you to do that?
<mathrick> nope
<mathrick> jelmer: http://pastebin.com/6VkcBi8J
<jelmer> does bzr check still report errors?
<GaryvdM> mathrick: Hmm annotate -r  does not work on a deleted file. Thats a bug. qannotate works though.
<mathrick> sec
<mathrick> GaryvdM: oh, interesting
<mathrick> jelmer: yep, still 201 inconsistent parents
<mathrick> which I still don't quite understand what are
<jelmer> mathrick: "bzr reconcile" should fix those..
<mathrick> but apparently it didn't :\
<mathrick> I did it again, just to be sure, and it still didn't fix anything
<mathrick> and apparently I can't clone from it either
<mathrick> though curiously enough, I can branch within the colocated workspace
<mathrick> so it might have something to do with the colocated branches, bzr branch . /tmp/test errors out with revision not present, but bzr branch colo:trunk /tmp/test works
<ubuntujenkins> Hi guys I am working with the ubuntu manual project and we are going to capture screen shots for all 40 languages that it is translated in. We are in the process of devleoping a program to deal with them. We were thinking of setting up a bzr branch to with subfolders for each language and within those one for each chapter. How ever we would like our program (quickshot) to only pull the folder for the relevant language. is
<ubuntujenkins>  this possible? or will I have to make forty branches?
<mathrick> ubuntujenkins: AFAIK, no, at this point it's not possible to pull a partial repo
<mathrick> it's a requested feature, but it's not trivial to implement in bzr, which is fundamentally organised around the notion of the tree as the atomic unit of change
<ubuntujenkins> ok thanks mathrick that was a very fast response. forty branches it is
<mathrick> ubuntujenkins: nested branches is the name of the feature that'll eventually lead there, but it's still not there to be enabled by default
<ubuntujenkins> do we know when it will be avalible?
<fullermd> Mmmm.  I think that's slightly misleading...
<mathrick> fullermd: if it is, please correct me :)
 * mathrick apologises for any factual errors
<fullermd> Nested branches don't let you pull around parts of branches, they just make it easier to lay out multiple branches.
<ubuntujenkins> so i am right I can't do nested branches yet? I wish you could
<mathrick> ah, yeah, but with nested branches + splits it'd be possible to get a layout that pretty mimics the desired effect
<fullermd> Well, you can manually put one branch "inside" another.  That works fine; just that the "outer" branch doesn't know anything about the "inner" one.
<ubuntujenkins> that seams point less some people have requested that we have it possible to pull one huge branch so that they can compile the manual in multiple languages.
<fullermd> Right, that's what nested trees would give you; it would automate bundling all 40 (or however many) branches together in a particular layout.
<ubuntujenkins> but I coun't pull them as one big one right?
<fullermd> With nested trees, you would be able to.  You can't now, no.
<mathrick> ubuntujenkins: small spelling nitpicks: "however", "pointless", "seems" (seams is a different, unrelated word)
<fullermd> (well, you can multi-pull to sorta fake it, but I presume you actually mean 'branch' when you say 'pull' there, not the actual 'pull' command)
<ubuntujenkins> I ment pull all 40 branches as if it was one big branch
<mathrick> ubuntujenkins: you can't do it now, but you could with nested branches, which are not finished yet
<mathrick> in other words, no you can't, sorry
<ubuntujenkins> cool thanks for your help guys sorry I got a bit confused in the middle of all that.
<fullermd> There are...   things that it's pointless to say after you /part.
 * fullermd goes back into his hole
<mathrick> heh
 * fullermd blinks.
<fullermd> It's Thursday?  The heck?  What happened to Tuesday?
<vila> alzheimer again....
 * fullermd sighs.
<fullermd> Once again, the world fails to conform to my expectations.  This is becoming a serious problem.  Somebody needs to be taken to task.
<vila> hehe
<jam> hi abentley, sorry I was out this morning with a sick child
<jam> hey vila
<vila> hey jam!
<abentley> jam, hi.
<abentley> I was wondering whether you had any insight into the memory consumption issue I posed about in canonical-bazaar.
<jam> haven't gotten to that folder yet, let me go check
<jam> so... this is with 2.1?
<jam> initial branch was specifically cut by about 50% for branching launchpad in the 2.1 series
<jam> abentley: the other possibility would be to try changing the fetch to be "unordered" rather than "groupcompress"
<jam> oh, and is this client-side, server-side? local branching?
<abentley> jam, this was branching using bzr.dev 5051, from Launchpad to local over bzr+ssh.
<jam> and IIRC lp uses 64-bit python, which averages 50-100% more memory consumption than 32-bit python
<abentley> jam, the memory consumption I experienced was on my laptop which runs 32-bit Ubuntu.
<jam> abentley: k, so the memory consumption you were seeing was on the client side?
<jam> and do you know *when*?
<jam> it could be during fetch, or it could be during building the working tree
<jam> for example
<jam> or if you know what stage of fetch
<abentley> It was steadily increasing during fetch.  The highest I saw was 600m+
<jam> I *do* know some places that could be trimmed a bit more, but was trying to figure out the tradeoffs
<jam> abentley: then how did you figure 1.8GB peak ?
<abentley> jam: I saw it at 1.8, but it was finishing up, and I can't swear whether it was writing pack files or what.
<jam> k
<jam> do you know if the codebase has large files?
<abentley> I do know it was before the message about building a working tree was printed on my terminal.
<jam> like say a ~400MB file in there?
<abentley> But the system was thrashing a lot at that point.
<jam> the repacking code is specifically a bit wasteful of memory sometimes
<jam> hence 'unordered' could fix it as it wouldn't try to pack-on-the-fly as much
<abentley> I can say the size of the repo is 571 M and the total size of the standalone branch, including working tree is 609M
<abentley> So the largest a file could be would be 38M
<jam> abentley: well, it could be 600M and you just have a whole bunch of 10byte files :)
<jam> oh sorry, I missed that last part
<jam> sure
<jam> seems odd
<jam> is there a lot of history? (how many revisions, etc)
<jam> how wide is the tree?
<abentley> jam, it's a conversion from bzr-svn, so the history might be wacky.
<abentley> jam, are you able to see the branch page?  If so, you are a "bzr expert" and can download it for yourself.
<jam> I don't think I am, but I can check
<jam> abentley: nope, permission denied
<abentley> jam: i can mirror it to devpad for you, if it helps.
<jam> abentley: would make it easier for me to test, yes
<jam> preferably an exact copy using lftp if you could
<jam> so that we don't run into 'slightly different pack layout' issues
<abentley> jam, I'm using hitchhiker.
<jam> that's fine
<jam> I just mean a mirror of the push side
<jam> rather than 'bzr branch'
<abentley> jam, mirrored to: ~abentley/economist
<jam> hmm... there only seems to be 1 pack file, is that true on the hosted side?
<BasicOSX> Is there a way to convert a "bzr co sftp://host/repo" to a "bzr branch sftp://host/repo" ?
<jam> BasicOSX: bzr unbind
<BasicOSX> jam:  that's awesome ty
<abentley> jam, yes.
<GaryvdM> jelmer: is this the latest dulwich branch with debian packaging: http://bzr.debian.org/users/jelmer/dulwich/unstable/ ?
<GaryvdM> (I could not find any others, but it worries me that it is in your user folder, not some where else.)
<x_dimitri> how does one do the equivalent of "bzr whoami --branch USER_DETAILS" with qconfig?
<GaryvdM> x_dimitri: you can't at the moment.
<x_dimitri> GaryvdM: :-(
<GaryvdM> x_dimitri: There is bug logged.
<x_dimitri> GaryvdM: :-)
<mathrick> speaking of which, is there something like bzr config?
<GaryvdM> Nope
<mathrick> it'd be a bit nicer than mucking around with text files, especially for per-branch settings, which require you to type the full path in ~/.bazaar/bazaar.conf
<NfNitLoop> So I was watching this talk by Linus to Google about git.  And he seemed to be adamant about the fact that git hashes all of its contents so that it can be verified.  (no disk corruption, no tampering.)
<NfNitLoop> bzr doesn't do something similar?
<NfNitLoop> I mean, if I do 'bzr check' and there was corruption or tampering, it'd find it, no?
<mathrick> NfNitLoop: yes and no
<mathrick> it hashes everything, but by default doesn't require signing
<mathrick> so you can't actually *verify* anything unless it's signed
<mathrick> but the same is really true for git
<mathrick> long story short: everything git has, bzr has too
<mathrick> at least as far as being tamper-proof goes
<NfNitLoop> Oh.  Where does it store these hashes?
<mathrick> NfNitLoop: bzr actually is a bit better, since git is tied to sha1. So if collision attacks against sha1 are found, like for md5, you're screwed. Whereas with bzr it'd be a matter of providing another hash algorithm to be used
<NfNitLoop> what do you mean you can't "verify" anything unless it's signed?   I just mean verify that someone who gives you version {id} is actually the same as version {id} that you have, or had in the past.
<mathrick> NfNitLoop: in the repository, it's a property of the changeset
<GaryvdM> NfNitLoop: It stores them in the repo with the revision properties.
<NfNitLoop> aah.    And that hash includes the hashes from its parents?
<mathrick> yes
<NfNitLoop> awesome.
<NfNitLoop> Yeah, Linus's talk seemd a bit ...  inaccurate in places.
<GaryvdM> NfNitLoop: you will see it if you do bzr cat-revision -r x
<NfNitLoop> He claimed git was the only thing to do that.
<mathrick> NfNitLoop: git isn't particularly more secure than anything else
<mathrick> bzr and hg do that, monotone gets even more paranoid
<mathrick> darcs hashes too
<mathrick> really, it's the easiest way to do it if you're making a DVCS, so I'd be surprised to see anyone else do it differenetly
<GaryvdM> NfNitLoop: that talk is old.
<mathrick> s/et/t/
<NfNitLoop> I thought it was given this month.
<mathrick> GaryvdM: but it was just as untrue when he said that :)
<GaryvdM> Yes
<mathrick> NfNitLoop: if so, it must be a new one
<mathrick> the google talk he gave is, dunno, 1.5 years old?
<GaryvdM> NfNitLoop: was it the one at google?
<NfNitLoop> yeah.
<GaryvdM> May 2007
<NfNitLoop> Oh yeah.
<NfNitLoop> Someone only just recently posted it to a blog I read.  (HackerNews).
<NfNitLoop> so it was dated this month on the blog, but yeah it's from 2007.
<NfNitLoop> still, even then some of what he said didn't seem that accurate.
<mathrick> NfNitLoop: Linus is a prick, to use the technical term, and it's not entirely uncommon to sacrifice accuracy to increase the emotional value of what he says
<mathrick> so you need to take that into account when you read / listen to anything by him
<mathrick> *uncommon for him
<GaryvdM> Is he git? (excuse the pun)
<GaryvdM> *Is he a git?
<mathrick> you could say so :)
<mathrick> personally I think it's a real pity he grew to be the face of much of the FLOSS
<mathrick> because we really have people who are just as smart, and aren't unbearable, obnoxious pricks
<NfNitLoop> Heh.
<GaryvdM> Jelmer told me that he name git git as a tribute to Andrew  Tridgell.
<GaryvdM> *named
<rubbs> I heard he named it after himself... but I could be hearing it wrong
<rubbs> I've got to learn git for a new job... it seems that you have to use some convoluted workflows to get it to work right.
<rubbs> that could just be me too.
<mathrick> rubbs: nope
<NfNitLoop> I played around with it a bit because a coworker really likes it.   Much prefer bzr's simplicity/flexibility.
<mathrick> that seems to be the essence of Linus's products. You use them the way Linus meant them to be used, or not at all
<mathrick> everyone else be damned
<mathrick> I don't understand why it needs to be so complicated, but it is
<rubbs> I just don't care for the colocated branches or the index.
<mathrick> it has some good features, like colocated branches (though they are incredibly confusing if you don't know about them) and rebase -i
<mathrick> but we already have bzr-colo and rebase -i is a political issue, really
<NfNitLoop> My officemate is reading http://hginit.com/   and trying to figure out why he should bother with DSCMs.
<mathrick> rubbs: colocated branches are incredibly useful in certain scenarios
<NfNitLoop> I'm apparently not that great at articulating it.
<rubbs> NfNitLoop: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
<rubbs> that's the article that really convinced me
<mathrick> namely, when you don't want to / can't afford to reconfigure everything to use a branch in another dir
<rubbs> also for Hg, but easily adapted to any DVCS
<mathrick> NfNitLoop: it's not obvious at first, so it's understandable
<rubbs> mathrick: oh I'm sure it's useful, and in many ways I can see why, but I don't really need to worry about it.
<mathrick> NfNitLoop: you can tell him that DVCs are better because make collaboration easy in a way that's natural for humans, not in a way that's somewhat easier for your sysadmin to setup
<mathrick> not to mention they're easier to setup to boot
<ubuntujenkins> how do I merge lp:~ubuntu-manual/quickshot/screenshots-de into lp:~ubuntu-manual/quickshot/screenshots-ump?
<mathrick> rubbs: sure, I haven't used them until recently, when I had to work on a git project, but then I actually got hooked up, because said project happens to depend on several external config files pointing to the right place, and with colocated branches I can just switch in-place to test if a bug is upstream or the result of my hacking
<GaryvdM> ubuntujenkins:
<GaryvdM> bzr branch lp:~ubuntu-manual/quickshot/screenshots-um
<GaryvdM> If you have not allready
<GaryvdM> cd screenshots-um
<ubuntujenkins> yep I have the branches on my computer
<mathrick> you can also say bzr merge lp:~ubuntu-manual/quickshot/screenshots-de -d lp:~ubuntu-manual/quickshot/screenshots-ump
<GaryvdM> bzr merge lp:~ubuntu-manual/quickshot/screenshots-de
<mathrick> but if you have them locally, then just do what GaryvdM says
<GaryvdM> mathrick: you cant merge into a remote branch
<mathrick> no?
<NfNitLoop> mathrick: He's arguing that with merge-tracking in SVN that you can do all of this in SVN too... which I'm not quite sure how to counter.
<mathrick> you should be able to
<GaryvdM> ubuntujenkins: resolve conflicts
<NfNitLoop> other than the fact that it "feels" more natural to create lots of branches with bzr.
<ubuntujenkins> well I get the error bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<GaryvdM> ubuntujenkins: commit
<NfNitLoop> since it's easier, and doesn't pollute the central repo.
<mathrick> NfNitLoop: except it's an afterthought for svn, and even svn devs admit it's not quite ready for production use yet
<NfNitLoop> mathrick: Oh really?
<mathrick> NfNitLoop: bzr is easier, faster, less buggy and produces smaller trees
<GaryvdM> ubuntujenkins: ah, hold on a sec, let me have a look at the contents
<NfNitLoop> mathrick: How is it not ready for production use?  That's how we do merges here.
<mathrick> NfNitLoop: and svn STILL doesn't give you offline commits
<mathrick> NfNitLoop: it has many failure modes
<NfNitLoop> mathrick: Right.  He conceded that point.
<GaryvdM> mathrick: merge needs a working tree, which bzr does not touch if the branch is remote
<NfNitLoop> mathrick: any idea where I might find a list of those?   *googles*
<ubuntujenkins> thanks GaryvdM its suprising how confusing this gets
<mathrick> offline commits are awesome, not because you necessarily have to be on a plane all the time, but because it really means you can start a repo absolutely anywhere, at any time
<mathrick> GaryvdM: ah
<mathrick> ubuntujenkins: you'll get used
<mathrick> NfNitLoop: with self-contained repos, all I need to share my repo with you is email. I can literally just zip my tree and send it to you, and have done so many times
<mathrick> and if I ever get on a plane or train, which I occasionally do, I can work on everything I have branched, even if I haven't planned for this
<NfNitLoop> mathrick: Yep.  He's already agreed that that is nice.
<mathrick> and most of the time, bzr repos are still smaller than svn's checkouts :)
<NfNitLoop> But he's pointed out that everyone says that DSCMs are SOOOooo much better at merging without giving concrete examples of how.
<mathrick> lemme see if I can find it
<NfNitLoop> and he's claiming that svn 1.5+ basically handle merging well enough now.
<ubuntujenkins> basically screenshots-ump contains a folder for each language, screenshots-de contains a folder for each chapter I need to be able to merge screenshots-de into screenshots-ump/de (GaryvdM
<NfNitLoop> Hell, using bzr is simpler just because it remembers parent/push branches.  having to 'svn merge http://repo/path/path/to/branch/blah" is a pain in itself. :p
<mathrick> NfNitLoop: btw, I don't know if what I said about hashes and tamper-proofness is true for svn. It's not a DVCs, so it might very well not have that built-in
<mathrick> NfNitLoop: yeah, that is a good point
<GaryvdM> ubuntujenkins: will you need to merge one lanuage in to another?
<mathrick> http://portal.acm.org/citation.cfm?id=1572196&dl=GUIDE&coll=GUIDE&CFID=77717344&CFTOKEN=95162572 <-- heh
<GaryvdM> ubuntujenkins: to do what you asked, you need to do:
<ubuntujenkins> Garyvdm I will have another branch for each language. The idea is they are collated into one giant branch with a folder for each language.
<GaryvdM> The one big branch is where you want to end up?
<NfNitLoop> mathrick: Oh I'm sure it doesn't for svn.
<GaryvdM> ubuntujenkins: to do what you asked, you need to do:
<GaryvdM> screenshots-ump/ $ bzr merge screenshots-de -r 0..-1
<GaryvdM> screenshots-ump/ $ bzr mv  screenshots-de screenshots-ump/de
<GaryvdM> and commit
<mathrick> NfNitLoop: another thing is that svn doesn't really look at the whole tree, only at the changed files. So you can actually get unbuildable trees from two tested patches, even though the commits are supposed to be atomic
<ubuntujenkins> GaryvdM thanks I will give it a go
<mathrick> NfNitLoop: that can get very tricky, particularly when you do more extensive merges
<GaryvdM> ubuntujenkins: and after you have done that, look at bzr qlog, which will give you a better understanding of what you have done.
<mathrick> NfNitLoop: and SVN still doesn't let you commit if you don't have commit access to the repo, which might, or might not be a problem for you in particular. But in general making people unable to version they changes just because they're not blessed is stupid and will eventually come to bite you when you don't expect it
<mathrick> because you brough someone from another team to look at some particular problem, or whatever
<NfNitLoop> *nod*   being able to commit a change and  then share it regardless of central repo permissions is quite nice.
<NfNitLoop> but in the corporate world not exactly desired.
<NfNitLoop> (shhhh).  ;)
<NfNitLoop> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync
<mathrick> it's mostly a strawman, because it doesn't influence the central repo in any way
<NfNitLoop> So I found the --reintegrate option there and pointed the coworker at it.
<mathrick> you just get to collaborate the same way you can speak to each other without going through your manager
<NfNitLoop> apparently you have to tell SVN which *direction* your merging, and after reintegrating w/ trunk your feature branch can't be merged anymore.
<NfNitLoop> that's basically a deal breaker for me, at least.
<NfNitLoop> you're*
<GaryvdM> NfNitLoop: With bzr, you also give merge a direction.
<NfNitLoop> eh?
<GaryvdM> But the not being able to remerge in svn does suck
<NfNitLoop> you just say: bzr merge source [dest]
<NfNitLoop> but in SVn you have to specify --reintegrate if [dest] is trunk, from which source had been branched.
<GaryvdM> dest$ bzr merge source
<NfNitLoop> whereas bzr figures it out.
<NfNitLoop> and any other sane DSCM.
<mathrick> NfNitLoop: oh man, this is cumbersome as hell
<mathrick> bzr just keeps track of all that for you
<mathrick> so the whole thing is down to one command: bzr push
<NfNitLoop> yup.
<mathrick> "In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again." <-- seriously?
<mathrick> that's stupid
<mathrick> so there you have it
<mathrick> you *still* can't merge properly
<fullermd> Wow.  That's special.
<mathrick> it's slightly less retarded now
<mathrick> NfNitLoop: so tell your coworker that this kills the most common use for branches: branching out releases and fixing bugs on them while keeping the development in trunk without giving up the bugfixes
<mathrick> you normally do it by cd release-1.0; hack hack hack; bzr commit; bzr push
<mathrick> and presto, trunk has the same fix now
<mathrick> I can't see how you could possibly do that with the broken svn model
<GaryvdM> ubuntujenkins: were you successful?
<ubuntujenkins> GaryvdM yes and no still working on it
<ubuntujenkins> GaryvdM I have achived what I wanted to, bzr mv didn't work but I found a way to do thanks for your help
<GaryvdM> Good
<GaryvdM> ubuntujenkins: did you look at qlog?
<ubuntujenkins> erm should it be in .bzr? I think I did something wrong as I have no .bzr
<ubuntujenkins> o I do have .bzr
<GaryvdM> ubuntujenkins: run it in the branch that you did the merge in
<GaryvdM> screenshots-ump/ $ bzr qlog
<ubuntujenkins> bzr: ERROR: unknown command "qlog" is what I get I have a bad felling :-(
<GaryvdM> sudo apt-get install qbzr
<GaryvdM> ubuntujenkins: ^ to install it
<ubuntujenkins> just installing it now.
<ubuntujenkins> wow thats a shiny way of showing the changes  :)
<ubuntujenkins> I shall set up another branch and give it ago agian thanks GaryvdM
<GaryvdM> :-) Hopefully it will help you to understand things better
<NfNitLoop> (whoops, was afk for a bit)
<NfNitLoop> mathrick: actually, I'm pretty sure you couldn't do 'cd release-1.0; hack; bzr commit; bzr commit
<NfNitLoop> er, bzr push
<NfNitLoop> the trunk would have diverged by then, and a push would complain.
<NfNitLoop> you'd have to do a merge into trunk.
<NfNitLoop> but yeah, being able to have long-lasting branches that don't break when you do a reintegrate is a good thing. :p
<alex-weej> halp! i installed bzr fastimport from launchpad with: "python setup.py install" and it worked, but when i run bzr fastimport or bzr fast-import it whinges about it being an unknown command
<NfNitLoop> alex-weej: it may have installed under a different Python version's package lib.
<NfNitLoop> is bzr using the same version of python that 'python setup.py install' used?
<NfNitLoop> (try python -v ; bzr version)
<alex-weej> i haven't configured it otherwise -- everything is stock ubuntu 9.10
<alex-weej> 264,  on both
<mathrick> hmm, is there an env variable to tell bzr not to warn about dumb terminals?
<alex-weej> does bzr have a cache of commands or something?
<GaryvdM> alex-weej: no, it get's them from the plugins each time it runs
<alex-weej> damn this is blocking my work -- anyone have any working way of converting a git repo to a bzr one?
<GaryvdM> alex-weej: bzr-git?
<alex-weej> that can do migration?
<GaryvdM> Yes, you can even push back to git later.
<rioch> I've committed a change but not pushed it, but since then made some more changes. If I undo the commit, will I lose my changes? I want to recommit everything under the one change.
<GaryvdM> rioch: That will work.
<GaryvdM> rioch: Just *do not* revert after you uncommit.
<tasslehoff> Hey. I've tried bzr for the first time today, after git-on-windows frustrations. I followed the git-svn example in the docs to checkout trunk and create a work branch. <hack-commit-hack-commit>, then merge changes from work to trunk. In the merge, is it possible to make bzr do the same commits to trunk that I did to work, instead of doing one big commit?
<rioch> I will uncommit, and then commit again, that right?
<tasslehoff> hmm. did anyone understand that? :)
<GaryvdM> rioch: Yes
<rioch> thanks
<GaryvdM> tasslehoff: Yes. do bzr push <svn location>
<alex-weej> ok this is really f***ed up, i just installed bzr-git and now i get bzr git
<alex-weej> bzr: ERROR: unknown command "git"
<alex-weej> why is bzr doing this to me!? :(
<GaryvdM> alex-weej: There is no bzr git command, but,,,
<tasslehoff> GaryvdM: great. this will work if I followed "A Simple Example" from http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/svn_plugin.html?
<GaryvdM> alex-weej: with bzr-git, you can do bzr branch <url to git branch>
<alex-weej> if it's a local file, how does it know it's git
<GaryvdM> alex-weej: Not sure.
<GaryvdM> I think it looks for a .git folder.
<alex-weej> dulwich has something to do with git i guess
<alex-weej> alex@whoosh:~/Desktop/XPRESbzr$ bzr branch /home/alex/Work/Geo-Net/XPRES/Code
<alex-weej> bzr: ERROR: dulwich.errors.ChecksumMismatch: Checksum mismatch: Expected 6378e115d5922cf04385f515f5b3627b61971843, got 54524545000051b6002d3120340a736861726500
<GaryvdM> alex-weej: Yes, dulwich is a library that bzr-git uses
<alex-weej> ok so it knows it's a git repo, it's just bailing for some reason :(
<GaryvdM> jelmer: Any ideas ^
<GaryvdM> tasslehoff: Do bzr log/bzr qlog. If you do bzr push, What you see in log will end up in svn.
<tasslehoff> GaryvdM: thanks.
<GaryvdM> tasslehoff: Provided what you have has not diverge from the svn branch
<GaryvdM> alex-weej: that error suggests that the branch is corrupt
<alex-weej> git seems to still work OK with it with no warnings
 * alex-weej is just pushing git to svn and branching the svn repo instead
<GaryvdM> alex-weej: I'm not sure then
<tasslehoff> GaryvdM: ok.
<guilhembi> jam: hello! I have a 425MB file in my shared repo, "repository/uploads/something.reconcile" (I ran "bzr reconcile" yesterday), can I remove it?
<alex-weej> if i have a branch already in "mybranch" can i just create a folder, bzr init-repo, and copy "mybranch" in as-is?
<alex-weej> actually that defeats the purpose
<alex-weej> how do i do this properly ;)
<GaryvdM> alex-weej: after you move the branch, do bzr reconfigure --use-shared
<GaryvdM> in the branch
<GaryvdM> Or
<GaryvdM> bzr branch in the shared repo, then remove the old branch.
<alex-weej> GaryvdM, reconfigure worked fine, thanks
<jam> guilhembi: yes
<jam> it is a temporary pack file for the reconcile work
<guilhembi> jam: thanks!
<jam> 'upload' is a staging area
<jam> so if nothing is actually writing to the repo, the files there are trash
<guilhembi> ok
<jam> i'm surprised it was left behind without us cleaning it up
<jam> was there an error while running reconcile?
<guilhembi> the command did return "0", no error.
<guilhembi> Tomorrow I'll set up a "check -v" job, to verify the state of the repo.
<guilhembi> jam: thanks again. Off to bed.
<jam> sleep well
<x_dimitri> I've just done a qdiff on over 50 files. It displays the diff for each file in turn. How do I terminate the entire process without having to go through all the files?
<GaryvdM> crtl-c
<x_dimitri> that doesn't work
<x_dimitri> in fact, I've cloed the terminal from which I ran the command
<x_dimitri> ...closed the terminal...
<x_dimitri> the qdiff gui keeps popping up for each file
<GaryvdM> Oh - qdiff
<GaryvdM> did you do a command line gobbing?
<poolfool> Is there a C interface into bzrlib?
<x_dimitri> got it. I used ps to find it's parent process and killed that
<GaryvdM> i.e. bzr qdiff foo*?
<x_dimitri> GaryvdM: nope, I actualyl ran bzr qlog, then did a diff from the qlog gui
<GaryvdM> x_dimitri: Thats odd.
<x_dimitri> how so?
<GaryvdM> I don't know why its doing that
<GaryvdM> x_dimitri: Could you describe the steps to reproduce that?
<x_dimitri> ok, l'll give it a try
<x_dimitri> commit a couple of new files, perhaps 100 :-)
<x_dimitri> do "bzr qlog"
<x_dimitri> in teh qlog gui, double-click on the  line that records the commit
<GaryvdM> x_dimitri: I get one window for all the files.
<x_dimitri> hmm...
<x_dimitri> thats' different...
<x_dimitri> let me have a look again
<GaryvdM> x_dimitri: are you maybe using --using meld or something else?
<x_dimitri> yes
<x_dimitri> I'm using meld
<GaryvdM> Ah ok. I know about that, I hope to fix soon.
<GaryvdM> The built in diff will open one window.
<x_dimitri> yup, you're right. Using the builtin diff shows all in one window
<x_dimitri> well, at least I know how to stop the 'infinite' windows when using meld
<GaryvdM> Night all
<jam> abentley: reply to the list. But basically they have a 300+ MB .sql.gz and a 180MB .sql.gz
<jam> and it is in --rich-root-pack and not --2a
<jam> anyway, I'm off for now.
<jam> But if they remove those files completely, their repo goes from 570MB to ~30MB, etc.
<jasonlife> if I follow the centralized workflow, what is the good way to handle central repo?   After I clone from the central repo and fix a bug in a branch of my local repo, do I have to push the branch to central repo?
<GungaDin> Hi
<GungaDin> I have one branch which is a checkout of a remote branch... is it possible to reflect changes in the remote branch without committing them, in the other branch?
<NfNitLoop> Huh?
<NfNitLoop> You want to commit directly to the remote branch, but not locally?
<spiv> GungaDin: what do you mean by "changes in the remote branch"?
<GungaDin> I want the checkout to reflect the remote branch without having to commit all the time and updating in the checkout.
<spiv> Oh ok.  It sounds like you don't want to use a checkout at all.
<poolie> jasonlife, typically you will have a checkout of your central trunk
<spiv> You just want an ordinary branch that you can do "bzr pull" in.
<poolie> merge your feature changes into that, and commit
<poolie> and then everyone will see them
<jasonlife> poolie: Is it normal create branch in central repo? For example, my software periodically release new version.. Do I have create new branch for each version on central repo?
<jasonlife> Do I have to
<poolie> jasonlife, it depends on whether you do bugfix updates to those releases
<poolie> but yes, it's probably a good idea to make a new central branch for each release
#bzr 2010-02-26
<igc> hi all
<igc> hi poolie, spiv
<poolie> hi igc
<mkanat> mwhudson: Hey hey. Sooo.... :-)
<mwhudson> mkanat: no news is good news!
<mkanat> mwhudson: Sigh. Not for me! :-)
<mwhudson> although bugs that just evaporate are always a bit diconcerting
<mkanat> mwhudson: Well, from the trace that you gave me, if that trace was in fact taken at the hang time, it looked like an OS-level problem.
<mwhudson> mkanat: the admins are all in one timezone this week, so it's possible that outages are being fixed in more of a hurry than usual and not reported
<gregcoit> anu idea on how to fix a "bzr: ERROR: exceptions.AssertionError: Unknown kind 'absent' " issue?
<gregcoit> google indicates it happens on revert, but I haven't done a revert on this b..ranch
<gregcoit> er, branch...
<spiv> gregcoit: pastebin the full traceback?
<gregcoit> spiv: sure
<spiv> gregcoit: (also, please file a bug report, but hopefully we can find an easy workaround for you in the meantime)
<gregcoit> spiv: http://pastebin.com/FGEhnVA2
<gregcoit> spiv: np
<spiv> gregcoit: pastebin the output of "bzr st" ?
<gregcoit> http://pastebin.com/tEin1iJc - aha
<gregcoit> I think I see the problem
<gregcoit> OTHER and THIS
<gregcoit> it's not that way on launchpad, but my guess is this confilct has to be fixed before merge will work...
<spiv> gregcoit: the presence of conflicts shouldn't matter
<jblue> Hello,  I've run into a problem with loggerhead 1.17, but I'm not sure if it's a bug or a configuration issue.  Looking for some assistance. Here are the errors I'm seeing:  http://pastebin.com/fj24CxgB
<spiv> gregcoit: (although it is a bit weird to use 'bzr merge --force', are you sure you want to merge multiple branches in a single commit?)
<spiv> jblue: looks like it's expecting a different version of the 'simplejson' modue
<spiv> module, rather
<gregcoit> spiv: you're right - that didn't fix it...
<jblue> @spiv - it's odd, I'm using the one it came with
<spiv> jblue: ok, then I have no idea :)
<gregcoit> spiv: what I'm trying to do is download updates from launchpad without loosing changes i've made locally...
<spiv> gregcoit: it does to me look like a bug related to trying to apply a merge to a tree that already has some changes, though.
<spiv> So it's possible that if you commit the changes you already have (and you do need to resolve conflicts before you can do that) that then this merge will succeed
<gregcoit> spiv: did we just say the same thing?  My understanding of bzr terminology is weak
<gregcoit> spiv: oh, commit locally!
<gregcoit> right?
<spiv> Right.
<gregcoit> so i'm not changing the stuff on launchpad...
<gregcoit> brilliant!
<spiv> Right.
<jblue> @spiv, just curious, whats making you think it's a version issue with simplejson?
<gregcoit> spiv: that worked - thanks!!!
<spiv> Typically, the way you keep your own set of changes to a project while tracking updates from the official version is that you make a branch (e.g. 'bzr branch lp:foo'), then in that branch you can make and commit your changes, and you can merge and commit updates using "bzr merge" (and then bzr commit, resolving conflicts first if any)
<gregcoit> spiv: kk
<spiv> You usually want to avoid mixing your own edits with merges, so that it's easy to tell them apart later, which is why 'bzr merge' will require the --force option in that situation.
<spiv> (So you don't accidentally mix unrelated changes)
<spiv> gregcoit: glad I could help :)
<spiv> jblue: just that it's reporting that the 'dumps' attribute is missing from that module
<jblue> so dumps attrib is related to versioning?  (my python is weak)
<spiv> jblue: if it's the right version, then you've probably got something more confusing like a circular import or something going on
<spiv> jblue: no, I just mean that the program expected to find something in that module, and it wasn't there.  A likely cause for that sort of thing is that the module isn't the module it expected.
<jblue> ah ok, gotcha. I think I'll backup the existing loggerhead directory, and re-install, then do a diff between the two installations to see if I can identify the problem (assuming the newer install works)
<Peng> jblue: There's something wrong with your simplejson install, not Loggerhead, unless you created a file called simplejson.py in Loggerhead's directory or something.
<Peng> jblue: Older versions of Loggerhead did not use simplejson; that's why you didn't experience this problem before.
<Peng> jblue: By the way, the dumps function existed in the oldest version of simplejson I can find, before it was even called simplejson, so ISTM your installation is broken, not out-of-date.
<jblue> yeah it's likely that the install is broken.
<Peng> jblue: Just curious, what version of Python are you using?
<jblue> umm lemme check
<jblue> python 2.5.2ubuntu0
<jblue> er.. ubuntu1
<Peng> Ah.
<jblue> basically 2.5.2
<Peng> Well, you can do "python -c 'import simplejson; print simplejson.__file__'" to see where the install is.
<Peng> Also, Ubuntu has a package for it, python-simplejsonm.
<gregcoit> strange question - is there a way to bzr ci changes without providing a description of changes?  ie: put bzr ci in a script?
<Peng> Err, without the m
<Peng> gregcoit: Why not just pass -m ""?
<gregcoit> or does it know to now ask for a description if there is no controlling termimnal
<gregcoit> -m  I'll look at that - thanks!
<Peng> Or, preferably, a somewhat less useless message.
<gregcoit> Peng: ahh, gotcha - yeah, that works
<jblue> looks like it's installed.  So does simplejson have to be symlinked into the loggerhead directory or something?
<Peng> jblue: No.
<Peng> jblue: It just has to be not completely broken.
<jblue> hrm..
<Peng> jblue: Just out of curiosity, try this: python -c "from simplejson import dumps"
<jblue> yay!
<Peng> Yay?
<jblue> okay, you were right, it was looking for simplejson, which I didn't have installed
<jblue> I had to restart serve-branches before it would work
<Peng> If you didn't have simplejson installed, the error message should be different.
<Peng> It would just die with an ImportError. It found some module called "simplejson".
<jblue> odd
<Peng> Indeed.
<Peng> What exactly did you do to fix it? apt-get install python-simplejson?
<jblue> I don't play with python enough to have simplejson installed without it coming from a .deb package
<jblue> yep that exactly
<Peng> Did you do "python -c 'import simplejson; print simplejson.__file__'" before installing it?
<jblue> the rest of loggerhead was working
<jblue> no I didn't, I apt-get installed just before you told me to do that
<Peng> Oh, darn.
<jblue> I can apt-get remove, and run that command, just for curiosity
<Peng> Well, I suspect you have some broken copy of simplejson sitting somewhere in your PYTHONPATH. That'd make it easier to finmd.
<Peng> find*
<jblue> well that box has been upgraded, so it's possible an older copy of python had that file sitting around somewhere
<jblue> in any case, thanks for your help
<Peng> :)
<Peng> If you do have a broken copy of simplejson somewhere, it shouldn't cause problems, but it'd still be good to take care of.
<Peng> If only for cleanliness.
<jblue> yeah, I'm run 'find' on  /usr/, see if it comes up with anything
<jblue> Aha!
<jblue> root@pse-tools-vcs:/usr# find . -name simplejson
<jblue> ./share/python-support/python-simplejson/simplejson
<jblue> ./share/doc/python-simplejson/docs/simplejson
<jblue> ./lib/python-support/python-simplejson/python2.5/simplejson
<jblue> ./lib/python-support/python-simplejson/python2.4/simplejson
<jblue> whoops.. should've pastbin'd that
<jblue> looks like I have python2.4 still on that system.. with simplejson, wonder if that was what it was referencing
<Peng> It shouldn't have, unless your PYTHONPATH is weird or Loggerhead was running with Python 2.4.
<Peng> (Does Loggerhead even support Python 2.4?)
<jblue> No idea
<Peng> I mean, it's probably intended to be compatible with 2.4, but I doubt it's tested regularly...
<mwhudson> i expect loggerhead still works with 2.4
<mwhudson> but yeah, haven't tried for a few months
<jblue> I dunno, weird stuff.. most likely because of the layered upgrades this system has gone through
<mkanat> Yes, it works with 2.4.
<Peng> You run it with 2.4?
<mkanat> Peng: Yeah, that's what's on RHEL5.
<Peng> Ah.
<herbtea> hello all
<herbtea> Is there a means of setting a default path to my local project repository
 * igc lunch
<herbtea> It is on a different drive than where the bzr.exe runs
<herbtea> and I'm tired of having to type the full path to the project directory
<herbtea> any help on whether I can set a default path to my local repository would be greatly appreciated :)
<herbtea> bye
<Peng> Uh-oh, Loggerhead wants something that got removed. Fun.
<Peng> (get_revision_inventory)
 * igc bbl
<vila> hi all !
<poolie> hello vila!
<vila> hey poolie
<tasslehoff> I'm trying to get started with bzr and its eclipse plugin at the same time. After setup I tried a team->status, and it says "Executing xmlstatus C:\src\bazaar\work" forever.
<tasslehoff> another Q: I used bzr-svn to check out a trunk, and create a branch called work. After doing some commits in work, what is the preferred way of getting them back into svn? In trunk I did a pull of new commits from work, and all of a sudden they were commited upstream. Surprised me a bit :)
<Anteru> Hi
<Anteru> I just tried Bazaar 2.1.0 on Windows 7/x64, and I got a very weird issue: Running bzr takes literally minutes to execute, no matter what I do. Even bzr help stalls for 3-4 minutes
<Anteru> Task manager says bazaar is reading ~10 kib/s ...
<Anteru> 2.0.4 works flawlessly
<Anteru> Machine speed shouldn't be limiting here _at all_
<Anteru> Any idea where to start troubleshooting?
<Anteru> Bah, seems to be Sophos AV
<poolie> tasslehoff, i think normally people commit in a bzr checkout of their bzr branch
<poolie> nice nick btw
<tasslehoff> poolie: thanks :)
<tasslehoff> poolie: hm. I didn't understand your reply. I followed the Simple Example from http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/svn_plugin.html, but when I do multiple commits in my workbranch, I want them to appear as multiple commits in trunk/svn as well. pulling from work->trunk seems to solve this, but it automatically pushes to svn as well. not a problem really, but I need to understand this :)
<poolie> tasslehoff, so, bzr's normal model is that you'll just make one commit to trunk rolling up all the changes for that feature
<poolie> you can later look inside that commit to see the individual parts
<poolie> i think this is also true once it's gone into svn
<poolie> if you want them to look like individual commits _on trunk_ then yes you need to pull
<tasslehoff> poolie: ok. if I have multiple commits in work that will be one commit in trunk, is there a way to automatically get a trunk commit message with all the work commit messages?
<poolie> tasslehoff, i'm not sure about in svn
<poolie> i think bzr-email or bzr-hookless-email can be configured to do that
<tasslehoff> poolie: not in svn yet. I meant if I do a local merge commit from work->trunk
<poolie> yes, bzr-email should support that
<tasslehoff> poolie: thanks
<Kamping_Kaiser> pointless question, but i want to be really sure on this: bzr tracks changes per *commit*, so cherry picking individual commits preserves the details of the change, wheres pulling an individual file *won't* track details?
<jelmer> Kamping_Kaiser: what do you mean by details of the change, exactly?
<Kamping_Kaiser> jelmer: committer/diff/commit message largely. i'm trying to decide if i should rebase a branch and pull out individual changes into a diff or try cherry picking out individual commits from the branch
<Kamping_Kaiser> yes, i acknowledge that i've failed to use the tool correctly if i'm in this possition :/
<jelmer> Kamping_Kaiser: cherry picking of revisions won't preserve the commit message etc
<jelmer> Kamping_Kaiser: the replay command does
<Kamping_Kaiser> jelmer: I'll check its help, thanks.
<MvG> I've got a usr-committed branch containing a fix, committed against current trunk. I want to turn that fix into a Daggy Fix, i.e. move it somewhere just after the error occurred, and more importantly, before a branching point between series. How would I do this and maintain as much metadata as possible? Cherry-Picking feels like I'd have to migrate one commit at a time, and deal with author and commit messages manually.
<MvG> jelmer, is your rebase plugin up to this task? I think I used it to do just that in the past, but somehow can't figure out the proper invocation just now.
<bialix> MvG: hi, there is replay command in rebase(rewrite) plugin
<bialix> MvG: also, you may just use branch point as base revision for DaggyFix
<MvG> bialix: thx, replay sounds good.
<bialix> the fix for diff in trac sounds very promising, btw!
<MvG> That's the one I want to replay. :-)
<bialix> :-) I've thought the same
<MvG> trac-bzr 0.3.2 released. :-)
<bialix> \o/
<bialix> MvG: many thanks!
<MvG> bialix: np. The thanks should really go to James Teh for identifying and fixing the problem. I'll benefit a lot from that myself as well.
<bialix> of course. but you maintain trac-bzr and do releases, and build/upload eggs
<bialix> so I can easily update my installation now
<igc> hi bialix
<igc> bialix: thanks for the rc2 release btw
<bialix> hi igc
<igc> bialix: hi
<bialix> igc: you've asked me -- so I've helped you
<igc> bialix: really, really appreciated
<bialix> np
<bialix> I'm planning to release qbzr 0.18.3 tomorrow
<bialix> igc: do we need to pack rc3
<bialix> ?
<igc> bialix: I'm not planning an rc3 at this stage
<bialix> well, ok
<bialix> it's just easier for me to do releases in row
<igc> bialix: but I'm certainly hoping some of the treewidget bugs can be sorted out soon -gary's doing a good job working through them it seems
<bialix> igc: I've updated POT on LP, btw, but it seems some strings are not marked for translations. Have no time to investigate right now
<igc> bialix: bug 395175 is my biggest worry right now
<ubottu> Launchpad bug 395175 in bzr-explorer "Refresh action can cause segmentation fault or freeze" [High,Confirmed] https://launchpad.net/bugs/395175
<igc> that and Windows packaging
<bialix> igc: I think running it via valgrind is good idea
<bialix> I might help with Windows packaging, but on;y on the next weekend, sorry
<bialix> I think today is better solution -- is to use our own rc2 installer
<bialix> igc: at least as workaround for packaging issue
<parthm> hello. I am trying to understand bzrlib sources. I am somewhat unclear on the terms. whats a basis_tree?
<bialix> parthm: it's a revision tree of latest committed revision of current working tree, usually
<parthm> ok. thanks. if i get revisionspec from a user and i need to look at its content i do a rev.as_tree(context_branch) first right?
<parthm> i am wondering what i pass for context_branch?
<parthm> basically i am working on bzr-grep and trying to figure out what the best way to cat files of the tree based on revspec given by the user.
<bialix> look at the implementation of cmd_cat in bzr maybe
<bialix> AFAIK you are need to use something like repo.revision_tree(revid)
<parthm> ok. thanks bialix.
 * parthm goes digging into bzrlib code.
<smoser> is there a way to see '--fixes' after the fact ? i can't see it anywhere in log
<smoser> ie: bzr commit --fixes "lp:1" -m "mission accomplished"
<smoser> but then, how can i later see what fixed lp:1 ?
<luks> I think it's in bzr log in recent version of bzr
<luks> and it's been in bzr qlog since it was introduced
<luks> in bzr qlog you can even search by bug numbers
<smoser> hm.. i've 2.0.4 (lucid)
<smoser> rm -Rf foo && bzr init foo && ( cd foo && echo "bar" > wark && bzr add wark && bzr commit --fixes lp:1 -m "foo world" && bzr log )
<smoser> doesn't show anything
<smoser> related to lp:1
<smoser> ok. next question, how can i figure out what format a branch is in ?
<smoser> never mind. found that.
<maxb> smoser: On lucid, you should have 2.1.0, which would show you the fixes info
<smoser> hm..
<smoser> hm... i wonder how i didn't have that version. now i do.
<parthm> In bzrlib, if I have a Tree or RevisionSpec object, how can I get the revno?
<bialix> parthm: from Tree -- most likely there is no way
<bialix> RevisionSpec has special method
<bialix> mmm, you can get revid from RevisionSpec, but to obtain revno you have to have branch
<parthm> bialix: I see as_revision_id but nothing for the revno. RevisionInfo seems to have an attribute revno, but I don't know how to get RevisionInfo.
<bialix> parthm: revno makes sense only in the context of a branch
<bialix> RevisionInfo.from_revision_id(branch, revid)
<parthm> hmm. I am basically getting bzr-grep to work with history and have a tree and revspec. http://pastebin.com/QprGpETR
<parthm> Oh. ok. I think wt.branch should be usable.
<bialix> yep
<bialix> parthm: look at plugin file-revno
<bialix> id_to_revno = branch.get_revision_id_to_revno_map()
<bialix> and resulting revno string is ".".join([str(n) for n in id_to_revno[rev_id]])
<bialix> partm: &
<bialix> partm: ^
<bialix> because revno can be dotted you have to join it to get string
<parthm> Oh. ok. so I get get it directly from the branch. will try.
<bialix> beware: branch.get_revision_id_to_revno_map() this is very expensive operation
<maxb> Wouldn't it make a lot of sense for bzr to cache that map on disk?
<maxb> Surely inspecting it must happen a lot more often than commit / pull happens
<bialix> maxb: igc wrote plugin to cache this info IIRC
<maxb> Has it been considered whether it would be sensible for bzr core to cache it?
<bialix> but it's not in the core. for some reason core devs don't do caches in first place
 * bialix not quite understand maxb's question
<maxb> OK - Why is it not done in core?
<parthm> bialix: that worked nicely. thanks. now with the rspec given I can grep history for a particular rev and print revno in the result.
<bialix> IIRC someone (lifeless?) said that caches makes the performance problems less visible for them
<bialix> so core devs trying to increase the speed in firts place
<bialix> and then suddenly nobody has the time and inspiration to write caching solution
<bialix> partm: nice
<bialix> maxb: so I think situation is far from ideal
<maxb> Hmm. I agree with "caches makes the performance problems less visible" in general. However, it seems to me that assigning revnos is an intrinsically complex operation that could be done once at tip-change and would not consume much space on disk to store
<bialix> yes, I agree
<bialix> maybe if igc has polished his plugin more it would find the path to the core
<bialix> unfortunately igc is busy with some other serious problems
<bialix> and nobody else working on this
<bialix> stalemat
<parthm> got to go. bye. thanks for your help bialix.
 * bialix waves
 * bialix waves bye
<lifeless> maxb: a revnocache is actually fairly large; pulling down 10MB of data while talking to a remote server hurts performance a lot.
<lifeless> maxb: our early file formats were essentially using a revno cache
<lifeless> maxb: add to that that partial rewrites over the network are really complex
<lifeless> maxb: and that this is a per branch overhead, so you pay a lot of duplication costs.
<lifeless> maxb: we'd /love/ a robust revno oracle; but its not actually all that simple
<maxb> What if it was only ever used locally - never transmitted over dumb transports?
<maxb> You could have the time saved for local and smart access, without incurring any additional bandwidth
<lifeless> maxb: I believe thats what the current revnocache does
<lifeless> is it sufficient is an interesting question
<lifeless> I don't have a good answer
<maxb> What's the current thinking, if any, on doing that in bzr core?
<lifeless> I can give you my thinking
<lifeless> which is that john has done amazing work working around python being silly and slow, with his frozen graph stuff
<lifeless> so we really should be able to do revno calculation pretty speedily now
<lifeless> and someone should look at that
<nDuff> What's the state of bzrp4? It appears to refer to adapt_modules, which looks like it was removed some time ago...
<barry> hi folks, is there a bzr-pipeline that works with bzr 2.1 yet?
<barry> oh, there's bug 527775
<ubottu> Launchpad bug 527775 in bzr-pipeline "bzr-pipeline does not work with bzr 2.1 API" [Undecided,New] https://launchpad.net/bugs/527775
<lifeless> nDuff: probably stale
<lifeless> james_w: how's your  offline bugs db going?
<lifeless> james_w: will it offer local-edit-and-queuing?
<james_w> I sort of have a cache working
<james_w> that's what I want to do, but I haven't started that bit yet
<lifeless> cool, I look forward to it
<james_w> I'm kind of surprised that I couldn't find an existing twisted HTTP caching client
<kirkland> where's the best place to get a more recent bzr version for hardy?
<kirkland> is there an official ppa or somethign?
<lifeless> yes
<lifeless> its on the downloads  page in the website
 * kirkland found it, thanks.
#bzr 2010-02-27
<jono> hi all
<jono> is there a Python bazaar module that I can use to check out code?
<Peng> jono: import bzrlib. Aside from some build code and about 20 lines in the "bzr" executable, that's the entirety of bzr.
<jono> Peng so I can use it to check out code?
<Peng> jono: I don't know what exactly you mean by "check out code", but probably.
<jono> Peng bzr branch lp:foo
<jono> peng are there docs anywhere for it
<jono> ?
<jono> ahaha found them
<Peng> jono: That should be easy enough to do, but I honestly do not know how. You could check out bzrlib/builtins.py:cmd_branch to see how "bzr branch" does it, or maybe the docs give an example.
<jono> ok cool
<jono> I want to add an example to Acire :)
<Peng> subprocess.call(['bzr', 'branch', 'lp:foo']) is cheating, right? ;D
<Peng> (Sorry, I shouldn't encourage that.)
<jono> haha
<jono> that *is* cheating
<jono> :)
<jono> Peng any idea what the full qualified path of a branch on LP is?
<jono> remote_branch = Branch.open("lp:python-snippets")
<jono> does not work
<Peng> Your code should ask the directory service, which I also do not know how to do.
<Peng> s/should/might have to/
<jono> can anyone else help me figure this out?
<jono> thanks Peng
 * Peng inserts several *shrug*s
<jono> lol
<jono> lifeless, surely you must know :)
<jono> you are an expect among these parts :)
<Peng> He's gone. :<
<chromakode> hey #bzr, can I revert/remove a specific commit from the history?
<chromakode> (a bad merge)
<Peng> You can revert the changes it made -- "bzr merge . -r 50..49" or so -- but you can't remove the revision from history.
<Peng> Well, if it's the most recent revision, you can use "bzr revert -r -2", or even "bzr uncommit" to remove it from history. (But the latter would be a pain for users if you've already pushed it.)
<chromakode> yeah -- it's already got commits on top of it
<chromakode> :(
<chromakode> best is to revert. I didn't know you could do a range backwards!
<chromakode> Peng: what exactly are the revnos I should pick for that example?
<chromakode> I want to get rid of revno 88, retaining 89 and 90
<Peng> chromakode: Should be 88..87, but try it and see.
<Peng> You can always "bzr revert" if it goes horribly wrong.
<chromakode> neato!
<fullermd> Er, "revert -r-2" wouldn't remove anything from history...
<chromakode> he was saying uncommit would remove it from the history
<chromakode> I suppose you'd commit back the following 2 commits
<chromakode> this looks good. thanks.
<Peng> Yeah, that was worded a bit badly.
<chromakode> Peng: so, if the revnos are in reversed order, it treats the diff in reverse?
<chromakode> that's really cool
<Peng> Right. :D
<chromakode> hmm. it's giving me a lot of conflicts.
<chromakode> is there any way to tell it "use the merge-tree version!"?
<Peng> "bzr resolve" can do it, at least if you're using a very recent version of bzr.dev.
<chromakode> checked there :(
<Peng> Um, it shouldn't conflict too badly, unless, well, a lot of conflicting changes have been made since.
<chromakode> urgh.
<chromakode> yes. they have. to every header file
 * chromakode slaps his teammates
<wgrant> If I'm using a lightweight checkout with a treeless repository, is there some way to store uncommitted changes before I switch, like switch-pipe does? Should I just shelve?
<fullermd> shelve should work.  Whether unshelve will work well...
<fullermd> I'd guess it probably should, at least as well as e.g. an update across that pair of revs with local changes.
<wgrant> Hm, so the shelf is stored in the checkout. I seeeeee.
 * wgrant checks how pipeline does it.
<fullermd> Yeah, shelf is WT-local.
<wgrant> Ah, it uses shelf but directs it to the branch. Hmm.
<lifeless> wgrant: bzr shelve; bzr switch; bzr unshelve - will work fine.
<lifeless> wgrant: as the checkout is constant in the environment you described
<wgrant> lifeless: Right, but is there a way to store uncommitted changes in the branch?
<lifeless> no
<lifeless> commit them to a new branch
<lifeless> or to a tag
<lifeless> or something
<lifeless> why though?
<wgrant> I thought I'd try lightweight checkouts, since Launchpad trees are huge and slow, and it seems to work well with pipeline.
<lifeless> sure
<lifeless> that doesn't answer the question
<lifeless> why do you need to stash the change, not commit it, and tie it to the branch
<wgrant> lifeless: I might have realised half-way through a change that it needs a change in a some other branch.
<wgrant> Although I guess that's more covered by the pipeline case.
<lifeless> wgrant: sure; shelve; switch; make change; commit; switch back; merge; commit; unshelve.
<wgrant> lifeless: I guess. It's just a bit different from the great workflow that pipeline gives.
<lifeless> wgrant: sure; you're working with the primitives.
<lifeless> wgrant: what I *don't* get is how that is different
<lifeless> as in, I don't see where the changes are stashed affecting your use case
<wgrant> I sort of like attaching the changes to their branch.
<wgrant> Makes it easy to keep track of them.
<wgrant> If they're attached to the branch I can be lazy and shelve without a message.
<fullermd> You can always commit them and uncommit them later.  Unless you forget, of course.
<wgrant> True.
<lifeless> wgrant: changes to the core to make it better sought after
<lifeless> personally, in my pending dir I shelve everything to one space, no comments, and I don't get more or less confused
<lifeless> wgrant: we could though, when shelving default to attaching the nick as a comment
<lifeless> what do you think?
<wgrant> lifeless: That might be handy.
<lifeless> file a bug
<wgrant> Also, last time I tried this shelve didn't let me get a diff. It might be more usable now that it does.
<wgrant> Is there a repo: or similar branch alias?
<lifeless> what would that mean
<j^> hi, is there an example somewhere of how to use post_change_branch_tip
<lifeless> sure, theres a few plugins around now that use it
<wgrant> lifeless: It would be an alias for the repo of the current branch, so I could say bzr switch repo:somebranch
<lifeless> wgrant: just say 'bzr switch somebranch'
<lifeless> wgrant: it will dtrt
<j^> i.e. http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html?highlight=post_change_branch_tip
<wgrant> lifeless: ...oh. That is nice.
<j^> links to http://doc.bazaar-vcs.org/en/plugin-guide
<j^> which gives 404
<lifeless> j^: hmm, not sure about that
<lifeless> anyhow
<spiv> j^: http://doc.bazaar.canonical.com/plugins/en/ works
<j^> still confused about how post_change_branch_tip works
<lifeless> http://github.com/djmitche/buildbot/blob/06ce8e7e79b2ffa1a301ac45c7155899d6a0e6da/contrib/bzr_buildbot.py has an example of it
<spiv> j^: the bzr-email plugin has an example of using it, see http://bazaar.launchpad.net/~bzr/bzr-email/trunk/annotate/head%3A/__init__.py#L106
<lifeless> j^: but what are you confused about in particulalr
<lifeless> spiv: google for the hook name, its interesting on the 2nd and later pagers
<j^> i have a server where several people push changes to, i want to run a command on the server each time someone pushes new versions, post_change_branch_tip seamed to be the right hook, can not make out how to enable it on the server though
<lifeless> j^: install it on the server
<lifeless> e.g. if you have a setup.py, run setup.py so as to install it into bzrlib/plugins/ wherever that is in your python path
<spiv> j^: as lifeless says, install the plugin with the hook on the server (and install it system-wide, so that it will be loaded by any user that runs 'bzr'), and make sure people push using the smart server (e.g. bzr+ssh, not sftp).
 * spiv wanders off
<lifeless> hmm
<lifeless> I was sure I had writted a diff hook
<lifeless> spiv: I would love news_merge to use ReST parser
<lifeless> spiv: my other NEWS files use alternative section markers
<lifeless> spiv: lp:bzr-commitfromnews
<jelmer__> was the darcs 2.4 release announcement just cross-posted to the bazaar and git lists?
<jelmer> moin lifeless, spiv
<jelmer> lifeless: Happy birthday!
<lifeless> jelmer: thanks ;)
<jelmer> lifeless, will commitfromnews also use --fixes ?
<fullermd> jelmer: It wasn't cross-posted.  The mails were just re-arranged after it was sent, allowing it to appear on any list that's convenient   :p
<lifeless> and moin
<lifeless> jelmer: hi
<jelmer> lifeless: hello
<lifeless> jelmer: I'd like it to do --fixes automatically, haven't looked at what is needed yet.
<lifeless> jelmer: I filed a bug when I registered the project saying this; if you wanted to fixit :)
<jelmer> lifeless: Ah, sorry
<jelmer> lifeless: it works well, btw
<jelmer> thanks for publishing it
<lifeless> my pleasure
<lifeless> I'm trying to be a bit rougher on development friction
<jelmer> what do you mean with development friction?
<jelmer> I haven't heard friction being used in this context, only as something that exists between people.
<lifeless> I mean between me and machine
<lifeless> and me and tools
<lifeless> http://en.wikipedia.org/wiki/Friction
<lifeless> effort put into writing code = F
<lifeless> things that sap that effort and make it get less work done = Ff
<lifeless> I *think* the concept of interpersonal friction comes from the analogy between anger and heat
<lifeless> as the energy friction bleeds off is heat
<jelmer> lifeless: Ah, thanks.
<lifeless> jelmer: if you'd like to add fixes support that would be awesome
<jelmer> lifeless: I might have a look at that when I have a moment to spare.
<lifeless> :P
<lifeless> I'll probably look at it when I need to use a fixes clause
<lifeless> I just haven't so far
<jelmer> having --fixes might actually save me quite some time
<maxb> I have a svn repository, with lots of legacy branches that are merged to trunk, but there's no metadata to say so. (Before svnmerge, or 1.5 merge tracking, and not svk). Is manually mangling in some bzr-svn bzr:merge revprops a neat trick or a terrible shoot-self-in-foot idea?
<jelmer> I usually forget to specify --fixes, then I uncommit, look up the bug number in NEWS and recommit with --fixes
<lifeless> jelmer: so, when I forget I ignore it ;P
<lifeless> jelmer: but you might want to just fix the process next time - to make time on the basis that you'll save time :>
<jelmer> heh
<jelmer> maxb: It's a good way to shoot yourself in the foot..
<maxb> hmm. It seemed so tempting
<maxb> Anything in particular I'm liable to break?
<jelmer> maxb: if you're sure there are no branches out there that were created from that svn repo using bzr-svn you could attempt it
<maxb> I can ensure that
<lifeless> maxb: the revids from bzr-svn are deterministic
<maxb> which is indeed a great thing about it
<lifeless> maxb: so if anyone else, ever, runs bzr-svn, they wouldn't be able to merge with you
<maxb> Presumably, yes, they will, if I've munged the svn repo before anyone ever bzr-svn's it
<lifeless> maxb: or perhaps it is 'if anyone else ever has, ...'
<lifeless> right
<maxb> It's a company repository, and freshly cvs2svn-ed, so I can state confidently that there are no prior bzr-svn-ifications in the wild
<jelmer> maxb: ah, should indeed be possible in that case.
<maxb> Unfortunately I couldn't sell a direct cvs2bzr to the powers that be :-)
<jelmer> maxb: please note that bzr-svn doesn't interpret svn:merge
<maxb> oh. that's unfortunate. I may have to have a go at hacking on that, then
<maxb> Presumably there's no reason why it couldn't, just no one's written the code?
<maxb> Oh, except I'd be glibly ignoring subtree mergeinfo
<jelmer> maxb: There is a reason, bzr doesn't support tracking cherrypicks
<jelmer> maxb: So you have to do analysis of the svn:mergeinfo data to see if *all* revisions for a particular path are merged before you can add the last revision in svn:mergeinfo for that path as a parent
<maxb> tricky, but doable
<jelmer> maxb: Expensive, performance-wise.
<jelmer> It also requires a mapping format change.
<jelmer> personally I'd rather see somebody investigate the possibility of tracking cherrypicks, even if we don't start doing smart things with that data yet.
<maxb> Even if you did track cherrypicks, you'd still want to resolve them into full-ancestry merges when that was the actual case
<jelmer> yes, but that logic would be in bazaar, not bzr-svn
<maxb> true
<jelmer> (.. and bzr-hg and bzr-git)
<maxb> hg and git track cherrypicks ?
<jelmer> git does at least, on a revision level
<maxb> whoa, I completely missed that
<jelmer> it does it (at least optionally) by simply putting the sha of the cherrypicked commit in the newly created commit
<jelmer> I'm not sure if it actually uses it do improve merge quality
<lifeless> AFAIK it doesn't
<maxb> I think my next step is to spend some more time poring over bzr-svn's guts
<lifeless> I wish lp mailed me back saying 'your bug might be a dup, look at XYZ'
 * lifeless files bugs
<jelmer> lifeless: Yes, me too.
<jelmer> maxb: tbh, I don't think that sort of analysis would belong in the default bzr-svn mapping.
<jelmer> maxb: I don't want to discourage you, but I think I should mention that upfront.
<maxb> jelmer: It's a fair comment. It might be desirable only for people using bzr-svn for a onetime migration away from svn
<jelmer> maxb: it's also only a temporary solution, since it we would need another mapping change (and an upgrade path) when proper cherrypicking support in bzrlib would be added
<maxb> The mapping issue is a hard one, but I'm already contemplating using a custom-hacked bzr-svn to migrate some slightly screwy history out of svn anyway
<maxb> (The problem there is tags which don't show up in bzr because they were made from a mixed-revision working copy, so bzr-svn treats them as branches)
<maxb> I guess I'll need to make sure I also change the revision-id generation so that they are different to what an unhacked bzr-svn expects
<lifeless> jelmer: bug 529227 bug 529226
<ubottu> Launchpad bug 529227 in launchpad "wishlist: show candidate dups on all bugs / provide a way to scan for duplicates of a bug" [Undecided,New] https://launchpad.net/bugs/529227
<ubottu> Launchpad bug 529226 in launchpad "wishlist: tell me about dupes when I file-by-email" [Undecided,New] https://launchpad.net/bugs/529226
<jelmer> maxb: You can just create a new mapping format
<jelmer> maxb: That should change the revid as well
<jelmer> maxb: actually, you should be able to just use a vanilla bzr-svn plugin and provide your own plugin that registers a new mapping format that does what you need.
<maxb> interesting. It's clear that I need to spend some more time learning about the internals :-)
<Demosthenes> can someone tell me what this python error means? bazaar quit working today at noon and returns this on every invocation. http://pastebin.com/wpgG4hsX
<beuno> Demosthenes, I have no idea what that error is, but you are using a very old version of bzr
<Demosthenes> lenny standard
<maxb> Demosthenes: I'm guessing it means that a .pyc file has been corrupted
<Demosthenes> i'm checking files now
<maxb> I'd start wondering about the health of your hard disk :-(
<maxb> I'd also strongly recommend upgrading bzr if you use it regularly. Debian stable is far too stable for an active project like Bazaar
<jelmer> lifeless: Thanks, subscribing
<Peng> Presumably /usr/lib/python2.5/socket.pyc
<Demosthenes> maxb: i'm seriously concerned myself, as i haven't made changes in a bit...
<Demosthenes> i'm running a compare against my last backup for /usr
<Demosthenes> eww i'm having some files i'd never change not match...
#bzr 2010-02-28
<Demosthenes> wow, thats *REALLY* odd. i killed off 4L-gui and a few defunct 4L-cli processes, and bzr works now.
<Demosthenes> WTF
<Demosthenes> i don't see any differences in /usr, /lib, or /bin that would indicate i was hacked. the only diffs are .gz files that are package documentation, and they pass gzip -t
<Demosthenes> has a later bzr been backported to lenny?
<ed-209> how come whenever I anonymously access launchpad, bzr works fine, but when I try to set up an account with SSH keys and all, it jus fails out?
<Demosthenes> ed-209: ssh -vvv and watch
<spiv> lifeless: I'd welcome patches for news_merge (of course)
<spiv> lifeless: it's pretty hackish in various ways
<spiv> lifeless: Partly because of the stupidly simple parser
<spiv> lifeless: partly because it uses Merge3.merge_regions, but it expects lines and I want to feed it other kinds of blocks of text
<spiv> lifeless: or rather, it doesn't really want to feed Merge3 lines at all, but ideally two-tuples, e.g. [('section', 'Bug Fixes'), ('bullet', '* Fix crash in frobber.'), ...]
<lifeless> spiv: Activation energy is still too low; I may patch it in future
<lifeless> spiv: but if you can patch it in work time, we both win :)
<lifeless> \o/ test suite loop closed.
<thumper> lifeless: you around?
<lifeless> thumper: hi, yeah, just making testr rock
<thumper> lifeless: I'm starting a new python project
<thumper> lifeless: and I want some test infrastructure
<thumper> lifeless: what do you recommend?
<thumper> lifeless: I have nothing right now
<lifeless> testrepository
<lifeless> and testtools
<thumper> lifeless: automatic discovery if possible
<thumper> is it packaged?
<lifeless> uhm, if you want that you can use the discover module
<lifeless> [I don't really like automatic discovery, but thats me :P]
<thumper> I can register I suppose
<thumper> I want a simple way to just run the tests...
<lifeless> can I show you something
<thumper> sure
<lifeless> branch lp:testrepository
<lifeless> install python-testresources and python-testscenarios and python-testtools
<thumper> python-testscenarios not found
<lifeless> you are running lucid, yea?
<thumper> no
<lifeless> ah
<lifeless> add the subunit PPA
<thumper> which is?
<lifeless> sudo add-apt-repository ppa:subunit/ppa
<thumper> lifeless: got muffins in the oven
<thumper> lifeless: got that installed
<thumper> but the oven is calling
<lifeless> ok
<lifeless> I'll be here
<lifeless> thumper: oh, also you might like lp:commitfromnews; its verra useful :)
<thumper> lifeless: not a branch
<lifeless> sorry
<lifeless> bzr-commitfromnews
<thumper> which does?
<lifeless> diffs NEWS to suggest commit messages
<lifeless> oh, you'll also need python-subunit installed
<lifeless> sorry, you're getting a full stack here ;)
<thumper> it better be worth it
<lifeless> I think you'll like it
<lifeless> I've just pushed rev 88 of testrepository, probably worth having
<lifeless> anyhow, there are two main things here
<lifeless> I want to show you the layout I used in testrepository, as I'm pretty happy with that
<lifeless> and I want to show you testrepository itself
<lifeless> as I think its an excellent workflow
<lifeless> brb in a couple of minutes, organising dinnery things.
<lifeless> have a poke aroun testrepository's code base; try 'make check' etc
<lifeless> thumper: ok, back
<phix> hey
<phix> what's new?
<lifeless> hi
<lifeless> stuff :P
<phix> nice
<phix> ummm, I am suprised this channel is still here
<lifeless> why?
<phix> Well, git has been pretty stable for the last few years now
<lifeless> so? Thats git, this is bzr.
<lifeless> We're gaining users faster than ever
<fullermd> RCS has been rock-stable for decades   :p
<phix> yeah but git kind of makes bzr look like cvs
<lifeless> phix: I think that comparison is false
<thumper> phix: no one likes trolls
<phix> ok ok, I will give you some credit, more like svn :P
<phix> hehe
<phix> thumper: aawwww
<phix> I m not trolling though
<lifeless> phix: Is that a considered opinion, or a joke?
<phix> no no no, bzr is the joke actually :)
<phix> well no, the fact that ppl still use it is I suppose
<phix> any way
<phix> I am off :)
<phix> see you guys in #git soon for sure
<lifeless> phix: thats either hostile or a troll, and neither is particularly friendly or encouraging.
<phix> oh
<phix> revert phix
<fullermd> Oh, sweet.  Now I have the perfect answer to people who tell me I'm not funny!
<phix> :P
<lifeless> fullermd: I think you mean reset --hard -q --patch ./
<fullermd> I...  do?
<lifeless> fullermd: I picked a classic command new git users get confused by
<fullermd> Well, it apparently works, 'cuz I'm confused why I'd mean it   :p
<lifeless> fullermd: its 'revert' spelt git style
<fullermd> Oh.
<fullermd> I didn't say 'revert'.
<lifeless> fullermd: what was your perfect answer then ?
<fullermd> Well, that I use bzr, so obviously I'm a joke.  Presumably a good one, naturally.
<lifeless> ah
<lifeless> unless its dark humour
<lifeless> uhm
<lifeless> this is a wtf moment:
<lifeless> make docs
<lifeless> python -c "import shutil; shutil.copyfile('NEWS', 'doc/en/release-notes/NEWS.txt')"
<lifeless> I think if we have Make, we can surely assume 'cp' ?
<fullermd> That should be implemented with inline ASM, to be more optimized.
<lifeless> you're here all week right? So you might improve.. :)
<fullermd> Don't forget to tip your waitress!
<lifeless> <3 commitfromnews
<bialix> hi igc
<Kamping_Kaiser> is there a bzr plugin to mark bugs in debbugs pending on commit to a bzr repo? (I can't imagine i'm the only person to wonder this, but i've not seen it asked before)
<lifeless> bzr builddeb would be a good place to put that
<lifeless> its really 'bzr-debian' :P
<Kamping_Kaiser> ok , I'll check to see what it does :)
<Kamping_Kaiser> hehe
<igc> hi bialix
<bialix> Marco Polo is good codename, the first great explorer, right?
 * bialix uploading installer now
<bialix> igc: installer done
<igc> bialix: certainly one of the better known early explorers
<igc> bialix: thanks for the installer too
<bialix> :-)
<igc> bialix: http://en.wikipedia.org/wiki/Exploration
<bialix> igc: I have an theory that every "project" in human life takes about 9 months to get somewhere. your bzr-explorer is another confirmation ;-)
<lifeless> heh
<lifeless> I'm only just getting to where I want testing to be, after 14 years
<igc> bialix: I just hope it's stable enough to warrant 1.0
<bialix> lifeless: I don't say about maturity
<lifeless> :P
<fullermd> Ogod, I hope this project will be done in less time than that   :(
<bialix> the question is what this for you
 * bialix waves hi to all
<lifeless> igc: grats on 1.0.0
<dsuch> Hi, I'm using bzrlib in a piece of software of mine and I'm wondering if it's safe to keep a reference to a WorkingTree instance in multiple processes?
<dsuch> Am I not going to get hit by some weird race condition sooner or later? (Just wondering, not that I have seen anything like that so far)
<dsuch> I'm currently using 2.1.0
<dsuch> Or, alternatively, can those subprocesses have their own separate WorkingTrees pointing to the same repository location? I guess that should be safe?
<lifeless> dsuch: do you mean 'are WorkingTree methods correctly locked' ?
<lifeless> dsuch: and the answer is 'we think so' ;)
<dsuch> yea, guess that was the question :)
<dsuch> thanks
<dsuch> lifeless: and if I don't share those objects, there sure will be no problems at all, right?
<lifeless> what do you mean by share
<dsuch> share as in multiple threads have the same WorkingTree instance assigned to them
<dsuch> but it's not that I really want it
<dsuch> in fact, I could as well have each thread/subprocess use its own WorkingTree object so there would be no sharing of a WorkingTree instance's state at all
<lifeless> so
<dsuch> and that, if I understand it correctly, should be perfectly safe?
<lifeless> on unix, os locks are not exclusive across threads
<lifeless> you can stomp on yourself trivially.
<lifeless> *processes* are safe.
<lifeless> *threads* are not.
<dsuch> mhm
<lifeless> even if you have separate WorkingTree objects, in different threads, you could zerg your dirstate file
<dsuch> got it
<lifeless> dirstate2, *when* we get to it, will not use OS locks at all, and won't have this risk.
<dsuch> I fear to ask what a dirstate is :) I take it it's some important internal repo structure?
<lifeless> yes
<dsuch> ok
<lifeless> .bzr/checkout/dirstate
<lifeless> it lists all the files in the tree
<lifeless> and their inode fingerprint
<lifeless> merge status
<dsuch> okay so it is important :)
<lifeless> semantic changes to this file are locked with a dir-lock, which is safe even in threads.
<lifeless> however, readonly locks can do cache-updates to this file
<lifeless> and they are only protected by an OS lock
<lifeless> which as I mentioned is not actually as safe as one might hope
<dsuch> I see.
<lifeless> gnight
<lifeless> if you have more questions, just ask, I'm sure someone will answer eventually :)
<dsuch> sure, thanks again lifeless
<dsuch> hope you get better ;-)
<dsuch> (sorry, couldn't resist)
<felixhummel_> hi! how would you put files under version control that belong to one project, but live in different directories scattered across the whole file system?
<felixhummel_> e.g. all hand-edited configuration files of a ubuntu box
<jelmer> felixhummel_: Generally the configuration files of a ubuntu box would be in /etc
<jelmer> felixhummel_: other than that, you should be able to use symlinks to a versioned directory
<felixhummel_> jelmer: so you would do ``cd /etc; bzr init .; bzr add hosts``?
<jelmer> felixhummel_: basically, yeah
<jelmer> felixhummel_: I'm using the etckeeper app to maintain my /etc
<jelmer> it wraps around bzr and takes care of e.g. invoking bzr commit when you upgrade or install packages
<felixhummel_> looks like etckeeper fits my use case perfectly. thanks, jelmer!
<jelmer> felixhummel_: you're welcome
<jelmer> maxb: the bzr-rewrite trunk should be fixed now
<ajeans> hello
<ajeans> I have a question about "./bzr selftest", and yahoo couldn"t find the answer for me
<ajeans> :)
<ajeans> ".bzr selftest" runs all the bzr unit tests (> 25000), what is the command to run one
<ajeans> (sorry) only one of the unit tests (e.g. tests contained in bzrlib/tests/test_osutils.py) ?
<fullermd> ajeans: Either giving it a substring as an argument, or using -s and a class prefix.
<ajeans> @fullermd: From the root, I am trying "./bzr selftest -s TestStatus" and also tried "./bzr selftest bzrlib/tests/test_status.py", with no success
<ajeans> @fullermd: Thanks for the information, you can pass the method name to only run it
<ajeans> ./bzr selftest --help had some information about it.
<ajeans> I was hoping to simply pass the Class name to execute all the tests within, but I can still list all the methods manually... thanks again
<fullermd> ajeans: You can use -s to pass the class name, it just has to be fully qualified.  e.g., "-s bzrlib.tests.test_foo.TestFoo....."
<fullermd> Or 'selftest test_foo'.  The former is faster because it doesn't have to build the full list of all the tests then search through it.
<mgedmin> long-term wishlist: automatic mirroring of my bzr branch
<mgedmin> sort of like bzr bind or manual bzr push after each commit, but without having to wait for the push
<mgedmin> let the push happen in the background, opportunistically
<ubuntujenkins> if I do bzr merge lp:~ubuntu-manual/ubuntu-manual-screenshots/bg -r 0..-1 does that update the status of the branch in lanuchpad?
<jelmer> ubuntujenkins: it might mark a merge proposal as "merged" if there is a merge proposal for that merge
<jelmer> otherwise it won't affect the status of the branch
<ubuntujenkins> weird I the status has changed from devolpment to merged. I don't know why its anoying as I have to change it back on 47 branches now
<ubuntujenkins> thanks for your help jelmer
<ajeans> @fullermd: thanks for the explanation, it works perfectly :)
<maxb> jelmer: Excellent! But, now there's a 'trunk', a 'rebase-trunk', and a 'trunk-mirrorred' ... it's a bit confusing
<jelmer> maxb: trunk is the right one
<jelmer> it's also registered as the development focus
<maxb> Sure.. but why the others?
<jelmer> historical reasons
<maxb> oh. stacked branches prevent deletion?
<maxb> perhaps set them as 'Abandoned' if they are no longer relevant?
<jelmer> maxb: feel free to do so
<maxb> jelmer: I'm pretty sure only the branch owner can
<jelmer> maxb: the branch status isn't really useful at the moment imho, and I have too much branches to set all of their statuses appropriately
<maxb> I find the branch status quite useful - it would be nice to at least have ones with 'trunk' in their name which are no longer relevant hidden from the project's default branch listing
<jelmer> maxb: isn't that what the development focus is for though?
<lifeless> moin
<jelmer> maxb: I've changed the status for these two branches to abandoned, although I don't really see the problem tbh
<jelmer> hey lifeless
<jelmer> oh, looks like I could remove them after all
<jelmer> lifeless: if you could give some quick feedback on my named-branches patch, that'd still be much appreciated :-)
<lifeless> jelmer: ah yes, I knew I forgot something this weekend
<lifeless> jelmer: shall do
<jelmer> maxb, if your merge request is still relevant, can you please resubmit it against lp:bzr-rewrite?
<mgedmin> time bzr rocks on a Nokia N900 --> 1.72 seconds wall-clock time
<mgedmin> seems a bit on the high-side
<mgedmin> it's a 600 MHz ARM CPU
<lifeless> if you run it again?
<mgedmin> lifeless, varies between 2.32s and 1.38s (I suspect cpufreq)
<lifeless> wow
<mgedmin> this is 2.0.2, I should package a newer version...
<jono> hey all
<jono> anyone here used the bzrlib python module?
<lifeless> yes
<lifeless> bah
<thumper> lifeless: hey
<lifeless> hi
<thumper> lifeless: when we did stacking we decided that the server should hit to the bzr client to stack
<thumper> lifeless: do you know if the --no-stacked (or similar) option can or does ignore the suggestion?
<lifeless> it should, it doesn't
<thumper> s/hit/hint/
<thumper> lifeless: is there a bug?
<lifeless> I'm sure of it
<slangasek> is anyone here using pristine-tar for importing of upstream tarballs outside of LP?
<lifeless> aie aie
<slangasek> lifeless: I was trying to work off http://www.advogato.org/person/robertc/diary/130.html to do bzrification and debianization of a new source package, but import-dsc doesn't seem to have usefully imported the autotoolage
<slangasek> is there an undocumented step I'm missing?
<slangasek> rather, it imported it as part of a single commit with the Debian stuff
<lifeless> let me just see what post that is
<lifeless> rbtcollins.wordpress.com has better urls
<lifeless> ah yes
<slangasek> well, rbtcollins.wordpress.com is not what you have linked from Planet Debian :)
<lifeless> meh :P
<lifeless> ok, so import-dsc does two imports
<lifeless> a tarball, accessible from 'bzr tags'
<lifeless> and a debianised
<lifeless> look at 'bzr log -n0' or at 'bzr tags'
<slangasek> neither shows me what I'm looking for
<lifeless> the upstream-XYZ tag should be precisely the tarball contents
<slangasek> does it matter that this is 3.0 (quilt) ?
<lifeless> probably, AFAICT quilt-3.0 is a <censored>-<censored>
<lifeless> uhm
<slangasek> there's no 3.0 (bzr) format
<slangasek> and 3.0 (native) is n/a
<slangasek> and I have an upstream tar.bz2
<lifeless> slangasek: pastebin bzr tags and bzr log -n0 somewhere
<slangasek> http://paste.ubuntu.com/385962/, http://paste.ubuntu.com/385963/
<lifeless> ok, no upstream- tag
<slangasek> I'll mention that when following the directions as written, import-dsc first gave me an error about 'bzr add'ing debian/changelog first
<slangasek> and rather than doing this, I moved my debian/ dir aside
<slangasek> so if I'm meant to actually do the 'bzr add', I can go back and try that
<lifeless> do you have the session in history, so I can see it?
<slangasek> I can uncommit and do it again? :)
<lifeless> no
<lifeless> you can start from a fresh branch though
<slangasek> ok
<lifeless> *don't* branch from this branch
<slangasek> yep
<slangasek> lifeless: http://paste.ubuntu.com/385965/
<lifeless> slangasek: and bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk is an *upstream* branch - no packaging in it at all ?
<lifeless> slangasek: the debian dir shouldn't be present: the revert step in my instructions is to remove the packaging (because it said debianise as normal :P)
<slangasek> correct
<igc> morning
<slangasek> but 'bzr revert' doesn't delete new files
<lifeless> slangasek: heh
<lifeless> slangasek: anyhow, yes, you are right to not have the debian dir present
<slangasek> so I inferred, when I got the error, that this is what you wanted, so I moved debian/ away :)
<lifeless> ok
<lifeless> and what happens then
<slangasek> http://paste.ubuntu.com/385967/
<slangasek> single commit, no upstream tag
<lifeless> can you paste the dsc
<slangasek> (this is with bzr-builddeb 22, btw; Debian unstable seems to be a version behind Ubuntu)
<lifeless> and check there is only one dsc in the dir above
<lifeless> slangasek: generally you will want bzr-builddeb trunk :P
<slangasek> http://paste.ubuntu.com/385968/
<slangasek> no, generally *I* want to be dogfooding what's actually in the distro ;)
<slangasek> yes, there's only one .dsc
<lifeless> this is very strange
<lifeless> I'd like you to try trunk.
<lifeless> if it doesn't work, file a bug.
<slangasek> ok - url?
<lifeless> if it does, file a different bug
<lifeless> bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
<slangasek> lifeless: yep, works with trunk
<lifeless> slangasek: so; you want a newer package ;)
<slangasek> (another wrinkle: had an out-of-date version of bzr in my Debian env, updated from bzr 2.0 to 2.1 to get builddeb trunk to work; and I can't seem to use the old builddeb in unstable with new bzr...)
<lifeless> jml: are you online?
<slangasek> looks like bzr-builddeb 2.3 is in experimental, I'll double-check with that also
<slangasek> 2.3 also works correctly
<slangasek> so someone needs to put 2.3 in unstable
<slangasek> jelmer: ^^ :)
<jono_> mwhudson, around?
<mwhudson> jono_: just about to have lunch, but can hang around a bit ... how can i help?
<jono_> mwhudson, I am just starting hacking with bzrlib - is there a short example of checking out a branch?
<jono_> mwhudson, actually, forget it
<jono_> I figured it out :)
<mwhudson> jono_: heh
<jono_> thanks!
<mwhudson> jono_: generally to find out how command 'foo' works
<mwhudson> look for cmd_foo in bzrlib/builtins.py
 * mwhudson afk for a few then
<jono_> right thanks!
<jono_> cheers pal
<jono_> I will add some examples to python-snippets
<jono_> would be awesome if you could submit some more :)
<Daviey> There is no stopping jono_ now!
<jono_> Daviey, :)
<jono_> just hacking Acire to check out the code directly from bzr
<jono_> then no dailly PPA is needed :)
<lifeless> jono_: hi
<jono_> hey lifeless
<lifeless> jono_: your mail server is naffed
<poolie> hello jono, lifeless
<jono_> lifeless, yeah, I know
<lifeless> jono_: I emaile you a week ago with the answer to this :P
<jono_> 1and1 having troubles
<jono_> lifeless,
<jono_> ahhh
<jono_> can you forward it to jono AT ubuntu DOT com?
<lifeless> when you pinged me, then disconnected ;P
<jono_> hah
<lifeless> jono_: sure
<jono_> thanks!
<lifeless> poolie: there is a gift for you in the tribunal review queue ;)
<poolie> heh, thanks
<poolie> btw did you see my grief on friday was due to a fsck bug?
<lifeless> poolie: I didn't see the resolution of it, no.
<lifeless> thats good news.
<poolie> my machine is still down but at least the problem is known
<poolie> it's actually fairly obvious where it must be
<poolie> ironically similar to some bugs we had in dirstate
<poolie> in this case, it incorrectly sorts things that are lexicographically before '.' i think
<lifeless> heh
<lifeless> so 'do not fsck and you will be fine'
<lifeless>  ?
<poolie> do not use -D
<poolie> *afaik, there may be other problems
<poolie> actually since the manpage says it may resort directories sometimes even without -D
<poolie> i don't think that's enough
<poolie> and you can't upgrade without fscking
<lifeless> mwhudson: is the link in http://doc.bazaar.canonical.com/bzr.dev/developers/#developing-using-bzrlib stale? (to the api docs)
#bzr 2011-02-21
<poolie> hi all
<poolie>  Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jameinel
<poolie> do you see any problem with https://code.launchpad.net/~bialix/bzr/2.2-configobj/+merge/50507 spiv
<poolie> nm, i don't think there is one
<spiv> If it's the same as a patch from upstream, I don't see a problem.
<poolie> i just asked because there seemed to be some worry on the bug
<poolie> but i think it's spurious
<spiv> Except perhaps that it leaves the version of configobj in the tree vs. upstream a bit hard to describe?
<poolie> perhaps we should delete it for 2.4
<poolie> there was a mail thread
<poolie> i think it's only needed on hardy?
<poolie> anyhow, not urgent today
<spiv> It'd be nice; we do currently have startup speed improvements in our copy that upstream probably doesn't have.
<spiv> Because we simply comment out some functionality we don't use that requires some expensive imports, but presumably upstream cares about those features...
<poolie> mm i see
<vila> hi all
<vila> let's try again: HI ALL
<vila> . o O (Resounding silence...)
<beuno> OH HAI vila!
<Tak> bonjour!
<vila> :-D
<vila> bialix: ping, yeah, I know, you're not there, but may be you grep the logs ;)
<maxb> Hmm, no PP - anyone fancy looking at a pretty trivial review in a rather dusty plugin? :-)   https://code.launchpad.net/~maxb/bzr-cvsps-import/fix-test/+merge/50421
<vila> HUH ? no PP ? wtf ? poolie updated it and I see no trace of further updates... :(
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jameinel | 2.3.0 is officially out ! (RM: vila)
<vila> *blink*
<vila> maxb: this is fix looks and feels correct, yet... I should miss something. Why did it fail ?
<jelmer> it also looks good here, but my CVS foo is weak.
<maxb> Because of paths containing /./ which were not expected
<vila> Haaaa
<maxb> I don't think the test can ever have been run successfully
<vila> maxb: approved
<maxb> Elsewhere I might have been tempted to apply normpath liberally, but since this test was already testing an _underscore method, it felt right to test the internals
<jelmer> maxb: did r64 break the testsuite?
<maxb> oh
<maxb> yes it probably did
<maxb> hmm
<maxb> Perhaps this deserves further examination then
<jml> fwiw, the _LockWarner error I talked about the other day isn't going away of its own accord.
<jml> I've had it come up in numerous other test runs.
<nordin> Hello guys, I'm a bit new here. Normally on Linux, I work with Git, but on Windows I want to try Bazaar because I want to introduce it at our company (we're using the old M$'s SourceSafe).
<beuno> hiya nordin
<nordin> So I started a Windows project using Visual Studio and initialized the project from Bazaar desktop GUI tool. I made from VS some canges and want to see if changes are shown with the bazar tool. But it doesn't show any changes. Can someone guide me a bit?
<nordin> hello beuno :)
<nordin> the changes can only be shown, if I add a file using the bazaar tool.
<rubbs> nordin: have you tried the refresh button at all? IIRC it only auto refreshes every 10 mins, but it's been a while for me.
<nordin> Yes I refreshed it too, forgot to mention that.
<rubbs> wait, so you haven't added the files to bzr yet? if that's the case Bzr can't tell any changes unless they've been added to the repository
<rubbs> or are you saying it won't even recognize new files?
<nordin> I also created an empty file and want to see if bazaar can see that a file has created, but also nothing. So I deleted the .bzr map and the trunk, re-initialized it, because I thought I might initialized it in the wrong directory.
<nordin> Same result.
<nordin> rubbs: no it won't recognise.
<nordin> Maybe you can provide me a good link?
<nordin> I used bazaar's documents for windows system based tutorials, but that's where I ended up now.
<rubbs> nordin: sorry it's been over a year since I've use bzr on windows now. I wish I could help more, but there are others on the chan who may be able to help more
<Peng> /1/1
<Peng> erk, sorry
<nordin> rubbs: no problem, I do see red marked text saying I haven't defined parent location yet...
<vila> new p-i running on package-import.local \o/
<fullermd> bzr seems to get confused sometimes with its relative paths   :|
<vila> fullermd: it depends...
<vila> . o O (You just asked for that one ;)
<mgz> there are some interesting bugs filed recently.
<fullermd> Well, lots of things depend, but I think 'crashing' qualifies as confusion   :p
<mgz> bug 720853 is particularly fun.
<ubot5> Launchpad bug 720853 in bzr (Ubuntu) "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [Undecided,New] https://launchpad.net/bugs/720853
<montywi> hi!
<montywi> Does anyone have a clue for what to do when you get in bzr gcommit "on bzr gcommit I get "unknown error 'sp1f-makefile.am-20010411110351-k5iezflkcrh2r5dzkgl3zuhr3cxtnsa7'"
<montywi> I got the same error in two different source trees (sharing a common .bzr directory)
<poolie> hi montywi
<montywi> poolie: hi!
 * mneptok hugs poolie 
<montywi> Any clue of what to do?
<poolie> uh, i guess look for more information about the error in .bzr.log
<poolie> with just that it's hard to tell what it means
<montywi> I have a really big merge just done and would hate to have to do it again....
<montywi> .bzr.log has nothing about this
<mneptok> montywi: hopefully that disk issue is not to blame in any way.
<montywi> it says 'All changes applied successfully"
<montywi> this happend before disk crashed
<mneptok> ah, OK
<maxb> Is it possible you could try "bzr commit" on the commandline to establish whether we are talking about a core or bzr-gtk problem?
<poolie> hm, perhaps then try the commit from the command line? see if it can be reproduced?
<montywi> The only clue I have is that the above is an old modified file, but in another branch
<poolie> do you know what version of bzr you're using?
<montywi> 2.1.0
<montywi> if I do 'bzr update' and then bzr gcommit, I get the message 'nothing to commit'
<montywi> Testing by modifing one file and doing bzr commit
<montywi> when testing by doing a small modification, it worked
<montywi> how to test if the tree is correct?  is bzr check enough?
<poolie> yes
<poolie> checking you can make another checkout of it would be a way to get external validation
<montywi> ok, will try
<montywi> i was able to do a bzr pull from another machine for the library
<montywi> now doing bzr check
<montywi> which of course takes a VERY long time
<poolie> it could be tuned, or usefully check just the tree
<montywi> still working
<montywi> checking commit contents:inventories 0/2
<montywi> this has not changed for the last 10 min
<montywi> there is a \ before the checking commit contents
<montywi> is this supposed to 'rotate' to show that something is happening?
<montywi> it's not changing, which is confusing as it's impossible to see bzr check is doing anything...
<poolie> it is supposed to spin
<poolie> i would try an strace on it
<poolie> tbh if you want to see if your tree is ok, rather than checking all history, i'd just try branching from it
<montywi> i did manage to do a branch from it
<montywi> strace shows a lot of seek_set calls
<fullermd> FWIW, my experience with significant check's is that the spinner is stalled _way_ more often than not.
<montywi> but it's hard to say if this is in a loop or not
<montywi> this is happening millions of times:
<montywi> open("/home/my/.bzr/repository/packs/95bf270064open("/home/my/.bzr/repository/packs/95bf270064246246a06e2f3d9639ceb5.pack", O_RDONLY) = 26
<montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
<montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
<montywi> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000
<montywi> lseek(26, 0, SEEK_SET)                  = 0
<montywi> read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096
<montywi> lseek(26, 52871168, SEEK_SET)           = 52871168
<montywi> read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f<j\316\271\243\1\"\3246246a06e2f3d9639ceb5.pack", O_RDONLY) = 26
<montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
<montywi> fstat(26, {st_mode=S_IFREG|0664, st_size=144334478, ...}) = 0
<montywi> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffe228c2000
<montywi> lseek(26, 0, SEEK_SET)                  = 0
<montywi> read(26, "Bazaar pack format 1 (introduced"..., 4096) = 4096
<montywi> lseek(26, 52871168, SEEK_SET)           = 52871168
<montywi> read(26, "\325\214H\"!\r(\243e}\252\273(\10\205\340\223\321f<j\316\271\243\1\"\3
<montywi> sorry, a bit more than I intended....
<montywi> still it does the above over and over again, with slightly different addresses
<poolie> ok, so i think it is actually checking history
<montywi> still, adding a simple cache for the above should speed up things 100x
<montywi> poolie: I am just worried that I got the error message twice (in different directories) when doing merges
<montywi> looks like it takes 'forever'
<montywi> I will go to sleep and see what it says in the morning...
<mtaylor> is there a ui for getting at revision properties yet?
<soren> mtaylor: Sure!
<soren> mtaylor: "bzr cat-revision"
<jelmer> mtaylor: I'm not sure if displaying raw revision properties has much use; you can add formatters for revision properties though, and there are a few standard formatters (such as for the "bugs", "authors" and "nick" revision properties)
<poolie> hi jelmer
<jelmer> 'morning poolie
#bzr 2011-02-22
<poolie> hi spiv
<spiv> Hi poolie
<poolie> hi there
<poolie> hi spiv
<poolie> i'm just about to confirm the sprint on the 16th may
<poolie> that's still ok with you?
<spiv> I'll double-check, just a sec
<spiv> Yep, that's fine.
<poolie> cool
<maxb> poolie: whereabouts in London are you going to be?
<poolie> millbank
<poolie> do you want to come by?
<maxb> nice, I could probably even come by bike :-)
<poolie> good
<fullermd> Blah.  I wish revert took globs...
<fullermd> Would be handy in resurrecting piles of files.
<poolie> huh, nice idea
<quotemstr> Down that road lies madness.
<fullermd> Nah, I'm right here.
<chx> hi. it seems i messed up big time. how can i restore? I have merge din trunk, committed that, then pushed Pushed up to revision 18093. then it said "conflicting tags" and I have deleted that conflicted tag and now all revisions after 18093 are gone! they are in that one commit (because it's the previous-HEAD merge) -- is there a way to restore the commit history? :(
<poolie> hi chk
<poolie> chx
<chx> poolie: hi
<chx> poolie: i am in a panic pretty much.
<poolie> it's ok
<poolie> i'm not sure how the tags come into this y
<poolie> so you merged trunk, and pushed your branch on top of trunk, and now you wish you hadn't?
<poolie> are we talking about a push --overwrite, or something else?
<chx> just a push... then i saw what i did then i tried a bzr uncommit... it's lp:examiner -- alas it's private but i am more than glad to add you to help me fix up this mess
<poolie> so if you do 'bzr log -n0 -r -1' does that show you all your trunk revisions?
<chx> it does but not with the original commit numbers
<chx> it says     revno: 18091.1.25 and it was 18116
<chx> (I must note that 18091+25 is 116)
<Peng> Right. The revision numbers are irrelevant and depend on your point of view; the revisions are still the same.
<chx> Well, it's all fine, but basically i need to get https://bazaar.launchpad.net/~examiner-dev/examiner/trunk/revision/18116 working by tomorrow morning :/
<poolie> so can you tell me, in order, what you did?
<poolie> maybe if you temporarily subscribe me (~mbp) to that branch it will help
<chx> poolie: http://ex.privatepaste.com/8e40d70b5e
<chx> poolie: added
<chx> poolie: in short i did everything to make sure i am messed up.
<chx> I also failed because the Drupal community after all migrates to git not bzr on Thursday :(
<fullermd> So many people these days just won't go that extra mile to make sure they're messed up.  They just keep hoping it'll happen by chance...
<fullermd> Which it does, of course.  But still, so sad, the lack of effort...
<chx> fullermd: i think i went the extra mile by pushing committing and uncommitting.
<chx> fullermd: even i have no idea where the hell i am.
<fullermd> See?  True artistry.  I doff my cap, sir.
<Peng> chx: You made a good effort, but I've seen better.
<chx> Should I laugh or cry?
<fullermd> I think the only honest answer is "yes".
<chx> poolie: is it very bad :( ?
<poolie> no i think your revision is still there
<poolie> why did you reconfigure then uncommit?
<poolie> actually
<poolie> if you can see the revision you want in 'bzr log -n0 --show-ids' you should be able to just do 'bzr pull . -r revid:WHATEVER' to go back to it
<chx> because... i wanted to reconfigure from the beginning, that was the only thing i wanted to do but then i saw what happened and i tried to back out
<poolie> i'm not sure if that's what you're already trying to do in the last line?
<chx> i pulled the uncomitted revision back yes
<chx> i have the lost revisions there yes but if i commit that again then i will have all the "newer" revisions under that one id
<chx> ie the 'official' number will be  18091.1.25 instead of 18116 :(
<poolie> hm, you don't need to commit after a pull
<chx> a very 'hatchet' solution would be to uncommit 18093 and 18092 and then (with some script?) commit back the revisions one by one and then finally commit whatever 18092 contained.
<chx> (which i have saved anyways)
<fullermd> That would be really hatchetish...
<fullermd> From the description, it sounds like all you did was merge trunk into a feature branch and pushed it.  The way back is just to create a copy of trunk as it was, push --overwrite it, then merge your branch into trunk and push it from there.
<poolie> just looking at it
<poolie> yes, it seems like what fullermd says is correct
<chx> fullermd: as it was? but how can i get trunk as it was???
<fullermd> Create a new tmp branch from 18091.1.25 (or whatever the latest that was trunk is), and push --overwrite that over turnk.
<fullermd> The old revs are still there; they aren't subsumed or anything, they just have a different number because of the way things are organized now.
<poolie> let's just make sure we have the right thing before we overwrite it
<poolie> correct
<chx> 18091.1.26 was the last.
<fullermd> 'k.  So, `bzr branch -r18091.1.26 $MINE tmp`.  Then look at tmp; it should look like trunk did beforehand.
<chx> ooooh pretty!
<chx> it does.
 * chx dances
<poolie> :)
<chx> revno: 18117 [merge]
<chx> YAY
<chx> now...?
<chx> bzr push --overwrite lp:examiner?
<fullermd> Yes, that should stuff it back to where you were beforehand.
<chx> and then what i should rtfm about these X.Y.Z revision numbers? Saw them during merging before, but honestly never understood 'em.
<fullermd> Then you can either (a) merge $MINE, accepting the 'extra', 'unnecessary' merge rev on top, or (b) merge $MINE before the merge of trunk, making it as if you were just landing the feature branch, then push that.
<chx> poolie: hm, so all i can do is deactivate you, can't delete? oh well.
<fullermd> Try looking at <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering>.  If it doesn't help...  well, I don't have time to do anything about it, sadly, but I'd still like to know about it.
<chx> catastrophe averted. thanks fullermd and poolie.
<fullermd> Sweet.  Now I can go _cause_ a catastrophe, and the scales will balance out.
<chx> so basically i created a branch ( which was not my intention ) merged in trunk and then made that branch the mainline somehow?
 * chx is crafty.
<poolie> it sounds like you crafted a branch which was trunk merged into you, and pushed that over trunk
<chx> poolie: how did i manage to do that without push --overwrite?
<fullermd> Because you weren't overwriting anything; the revision tree you were pushing was a superset of the one already existing.
<fullermd> It just happened to be one where some of the revs previously on the mainline were "off to the side".
<chx> so is this a bug, a misfeature or should i just buzz off?
<fullermd> Well, it's neither of the prior...   maybe it's a 'gotcha'.
<fullermd> Think of it as an emergent property of the nonlinearity of history.
<chx> lol, i come from a socialist country even those had a linear history it was just changing in time :p
<chx>  There is an append_revisions_only branch configuration variable which can be set to help this; it will make bzr refuse to do any operations that would change the mainline
 * chx digs where those things are set
<fullermd> There's a 'config' command (new in 2.3, I think?).  I don't know if it works remotely.
<poolie> yeah, i was going to suggest that
<fullermd> If not, you can probably do it on LP via some sftp'ing and manual editing of the branch.conf.  Not difficult, though a step or two above trivial.
<poolie> 'config' should work remotely
<chx> fullermd: questions. if i just change branch.conf and commit -- works?
<chx> ah
<chx> understood.
<fullermd> Well, you need to change the branch.conf on LP, since that's where somebody might be push'ing too.
<chx> if i set append_revisions_only then uncommit will stop working?
<fullermd> Yes, that's one of the effects; since uncommit pops off the top commit, it removes something from the mainline.
<fullermd> (uncommit of stuff that gets to LP, of course; it won't affect what you do on an unconnected local branch of it)
<chx> https://bugs.launchpad.net/bzr/+bug/605067
<chx> i want this it seems.
<chx> probably last question, can bzr push --overwrite cause data loss?
<fullermd> Semantic quibbles aside, yes.
<fullermd> push alone will refuse to work if the result of making the remote branch a duplicate of your local would result in revisions that were previously in it no longer being so.  --overwrite becomes a "do-it-anyway"
<poolie> so
<poolie> you can normally get back from that by using 'bzr heads' but it is basically a --force type option
 * fullermd crams a couple more 'result's in that sentence, just for fun.
<fullermd> Yeah.  It doesn't actually _remove_ the "lost" revs from the repo, but they're no longer in the branch, and you'd have to know that they're there and explicitly look for them to find them.
<chx> poolie: that was an answer to push --overwrite?
<chx> poolie: i feel much safer if yes.
<fullermd> So, technically speaking, they're not quite really disappeared from existence, but it's the next best (worst?) thing.
<chx> so there is bascailly no 'nuclear' option that would remove a revision for good from the repo?
<fullermd> It's pretty much the same as when you uncommit; the rev you popped off is still _there_, but it's no longer connected to the branch.  You can recover it, but you have to know it's there and go looking for it.
<fullermd> (after all, uncommit isn't at the branch/repo level any different than push --overwrite'ing yourself  ;)
<fullermd> Not at the UI level currently.
<fullermd> Actually, there was a PoC-ish 'gc' plugin at one time, I think.  No idea if it still works (or if it ever worked well enough to really be used)
<chx> You know? I am glad.
<chx> :)
<fullermd> Pbbt.  You just wait'll the next time you commit a 10 gig coredump   :p
<chx> We are PHP developers...
<chx> We commit PHP files and puppet config files.
<chx> so hopefully no 10gigs.
<fullermd> I was doing a data import thing some years back (in PHP).
<fullermd> Working on the code for the import was tricky.  And parsing the input data files took a long time (minutes), so it was real slow testing out the post-parse code.
<chx> ( I know what you are thinking, this si a php developer that's why he is so clueless, i am learning python, but currently php puts bread on the table )
<fullermd> I figured I could shortcut it by just doing the parse one, serialize()'ing out the parsed array, and writing a little script that just had that serialization assigned to a var, deserialized it, and went on its merry way.
<fullermd> (obviously, a brilliant plan.  But then, I thought of it, so naturally...)
<chx> lol.
<fullermd> Turned into about an 80 meg .php script for testing; just a $foo = "longassstring"; $foo_a = unserialize($foo); basically.
<chx> NICE.
 * chx hands include to fullermd
<fullermd> So far, so good.  Then I tried running it, just to see how much faster it was than re-parsing the files every time.
<fullermd> It ran for 4.5 hours, then blew out the 512 meg memory limit.
<chx> if my memory is correct it takes three times as much memory as the original structure
<fullermd> ... so I went back to blowing a couple minutes every test run.
<chx> 4.5 hours????? that was one particularly speedy machine. did you run it on a 386 :P ?
<fullermd> Not especially speedy, but it was a dual Athlon TBird.  Not quite pokey.
<fullermd> Yeah.  I was floored.  Obviously unserialize had some minor pessimizations somewhere along the line...
<vila> chx: don't blame his OS, it gets things done ;)
<chx> pessimization rotflmao
<fullermd> After about 5 minutes I realized it wasn't going to work, but at that point I just HAD to know how long it would finally take...
<chx> fullermd: you do not need to praise php to me -- after all i run the blog phpwtf.org
<fullermd> In retrospect I should have tried JSON'ing it out; that would probably have worked better.  But I needed to get on with it.
<lifeless> because why have one problem when you can have two?
<fullermd> Piffle.  All problems can be solved by creating another layer of abstraction.
<chx> Yesss
<chx> http://www.phpwtf.org/numeric-and-integer-keys i think this is my favorite php feature.
<fullermd> I've had its confusing of reference and referent bite me once or twice.
<poolie> hi vila
<poolie> nice answer there
<chx> creating an array which has inacessible values with [] that's classy even for php.
<vila> poolie: hey ! Pfew, thanks, I wasn't sure about the tone ;)
<vila> poolie: err, your were referring to the OOM bug right ?
<poolie> yes
<vila> just checking :) Sometime telepathy doesn't work *that* well online...
 * fullermd knew you were going to say that...
<bialix> bonjour vila
<vila> bialix: !!! hey !
<bialix> :-)
 * fullermd waves at bialix.
<vila> I was hoping to catch you here yesterday
 * bialix warmly waves back
<vila> bialix: can you find a couple of minutes to speak about the configobj fix ?
<poolie> hi bialix
<bialix> vila: I had business trip yesterday
<bialix> hi poolie
<bialix> poolie: the big island is okay?
 * bialix saw the bad news from New Zealand
<poolie> heh
<poolie> well, if you don't count the fires, floods, and cyclones, yes
<bialix> :-/
<bialix> vila: yes, I'd like to talk with you about configobj
<bialix> vila: I'm not quite get your comment on MP
<poolie> it's ok though :-) http://en.wikipedia.org/wiki/Severe_Tropical_Cyclone_Yasi
<vila> bialix: in the test, you seem to mention a *different* but in configobj that requires splitting lines or something (let me refresh the page)
<poolie> ok, i should go
<vila> poolie: enjoy your evening !
<poolie> i'm going to be offline for a week
<poolie> thanks
<vila> poolie: and your riding :)
<poolie> thanks
<lifeless> poolie: your pqm is whinging
<lifeless> WARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not fetchable due to <class 'urllib2.URLError'>: <urlopen error [Errno 101] Network is unreachable>
<lifeless> oh
<lifeless> no not yours
<poolie> huh
<lifeless> lp's is
<poolie> that's a bit naughty
<lifeless> I saw the sphinx bit and leapt to a conclusion
<poolie> jml(?) is trying to use it in lp too
<fullermd> I think that means you incorrectly answered the Riddle, and it gets to eat you now...
<vila> bialix: the other bit is that a comment for your fix in configobj will ensure the next merge can be done without too much additional knowledge about why this fix should stay in place
<vila> fullermd: hehe
<bialix> vila: the comment about not splitting the lines there because it bites me
<bialix> vila: it bites me while I've been coding that test
<vila> bialix: but is it triggered only in this test or can it *also* occur in bzr ?
<bialix> I think I can use just another StringIO() wrapper instead of lines to read the config back
<bialix> vila: one sec
<bialix> vila: look at bzrlib/util/configobj/cobfigobj.py line 1975
<vila> close, I was at 1971 :D
<bialix> vila: this is only affects test
<vila> but yeah I noticed this comment after you said you could use a StringIO
<vila> ha good !
<vila> bialix: and is it still there if you use a StringIO ?
<bialix> vila: no of course
<vila> I remember configobj being so helpful sometimes with accepting different inputs transparently it hurt :)
<bialix> I've been meaning to use lines for self.assertEquals
<bialix> but then I did not
<bialix> vila: what should I do?
<bialix> do you want me to fix this part to use StringIO instead? And send bug report to mfoord?
<vila> ideally: at minimum: at comments on both subjects (and I'll land that), then see if you can work around the bug in the test and/or file the bug upstream (and then includes the bug number in the comment... meh, bad circular dependency there >-/)
<vila> break the circle: just say the test bug will reported upstream and do a followup submission against trunk once the fix get there
<vila> s/will/will be/
<vila> bialix: then, there is the higher level discussion about how qbzr should get away from configobj entirely and what is currently missing in bzrlib.config that blocks this goal
<vila> bialix: that may includes support for commit data in branch.conf
<vila> bialix: and if you could stop using dict values for config options I won't ask for a ponny :D
<bialix> I can't
<bialix> dict values provide me atomic transaction
<vila> never say I can't :D
<vila> it's the other way around: you could if...
<vila> bialix: when you say "I can't" I feel sad, if you say "I could if" I'm willing to help and that's far better for my karma :D
<bialix> well, let's don't talk about qbzr right now
<bialix> because the bug reporter has started long thread about what we should and should not do in qbzr, and then Gordon said we should store those data not in branch.conf
<vila> well, if you don't talk about it right now, I won't be able to address the need tomorrow either (for extended values of tomorrow ;)
<vila> indeed
<bialix> if we talk about qbzr then I have to say that using branch.conf was/is horribly bad idea
<vila> the plan with bzrlib.config is to reach the point where a given config file is read once and written once for any given bzrlib operation (the higher level the operation the better),
<bialix> because commit_data should be stored in the tree.conf
<vila> as opposed to read for each option and written for each option
<bialix> or at least inside .bzr/checkout
<vila> yup
<vila> tree.conf ftw
<bialix> but when we did what we did there was no tree.conf
<vila> indeed, not throwing stones (or I should throw them at bzrlib.config)
<bialix> what is best strategy for qbzr?
<vila> (and I dislike working on code under a stone rain)
<bialix> can we use tree.conf now, or we should store our data in the different file?
<vila> bialix: try to converge to bzrlib.config and nag me when you encounter bugs
<bialix> that part of code is already using bzrlib.config
<vila> migrating from one file to another will *most* probably involve some kind of migration, so let's try to have a single migration
<vila> bialix: oh, when I say use bzrlib.config I imply do not touch configobj *at all*
<vila> no _get_parser() calls either
<bialix>     def _set_new_commit_data(self, new_data):
<bialix>         config = self._get_branch_config()
<bialix>         old_data = config.get_user_option('commit_data')
<bialix>         if old_data == new_data:
<bialix>             return
<bialix>         try:
<bialix>             config.set_user_option('commit_data', new_data)
<bialix>         except AttributeError:
<bialix>             pass
<bialix> vila: there is no _get_parser() calls!
<bialix> vila: qbzr/lib/commit_data.py
<vila> bialix: right
<bialix> too bad we have not reached any agreement with bzr-gtk about joining our efforts re commit-data
<bialix> I'd be happy to see some common code, even inside bzrlib, to support that
<vila> bialix: I think we have agreement from all parties involved :D It's just that nobody found the time to assemble a mp against bzr.dev...
<bialix> I don't remember any bzr-gtk dev ever commented on my proposal
<vila> bialix: the problem with _set_new_commit_data is that it's using a dict value for an option
<bialix> bzr-gtk uses bencoded value
<bialix> using dict was abentley idea
<vila> bialix: huh ? I discussed this with Gary back in.... Barcelona ? (Or am I mixing sprints here ?)
<bialix> vila: I'd like to have atomic write of all commit_data options
<vila> bialix: the problem is that it uses sub sections relying on configobj, there are no explicit tests for that in bzr (which means no explicit support for them)
<bialix> only using dict I can get atomic
<vila> bialix: they are supported by configobj
<bialix> we want to get rid of configobj?
<bialix> I won't be upset is yes
<vila> bialix: atomicity should be provided by bzrlib.config, it isn't right now
<bialix> I won't be upset if yes
<vila> no, we don't want to get rid of it, just use it as an implementation detail that users don't have to be aware of and don't *use* unsupported features
<vila> of it
<vila> bialix: so until we get bzrlib.config there, dict values will be supported but the plan is to get away from them so we can explicitly deprecate them
<bialix> vila: do you want me to use bencoded dict as bzr-gtk does?
<vila> bialix: that would indeed be better (if you manage to find a suitable migration strategy for it)
<bialix> vila: commit_data already has migration strategy
<vila> bialix: but if it means migrating for that now and migrating again later for something else, then no, not a good use of your time
<vila> huh ? Which one ?
<bialix> scroll down the file
<vila> oh, you mean moving it into core ?
<bialix> no, in the past we had different option named commit_message
<bialix> then I've extended it to more rich dict
<vila> hmm, interesting
<bialix> so, it's not problem to make another change
<bialix> but I'd like to migrate into tree.conf as well
<vila> bialix: I still have a couple of things to add first: sections in all config files, config registry, config stacks, option declarations... but we'll get there
<bialix> ETOOMUCHSTUFFFOR ONE MORNING
<vila> the last three are pre-requisites to get to the point where we can guarantee one read/write by config file as opposed to one read/write by option
<vila> aka atomic modifications
<vila> all right, I've got enough feedback from you for the long term plans, thanks
<vila> bialix: if you can add the comments and push, I'll take care of landing the fix in 2.2 and up to trunk
<bialix> vila: to clarify: I'll change lines to pure StringIO and send bug report to mfoord, and keep the comment in the test
<vila> yup, and add one above the fix for future merges
<bialix> vila: do you want me to add corresponding comment about the fix in configobj.py as well?
<vila> yup
<bialix> ok, got now
<bialix> doing now
<montywi> poolie: 'bzr check' still running, after 12 hours...
<vila> montywi: not unsurprising, the emphasis is on making sure all data relationships are valid, not on speed
<vila> montywi: it's unfortuante in your case that there aren't options for quicker and more focused checks though
<montywi> still, no it's so slow that it's unusuable
<montywi> I am sure that with a little bit of caching one could make this 1000x faster
<vila> montywi: s/no/now/ ?
<vila> montywi: sure
<vila> montywi: hence my remark
<montywi> yes, now
<montywi> still, a full check is very useful when you suspect something is wrong
<vila> montywi: check is targeted at corrupted data in *unknown* ways, caching may be tricky and should be done with care
<vila> montywi: exactly
<vila> montywi: but sometimes you can have good guesses at what you want to check and checking everything and the kitchen sink is not what you want ;)
<montywi> having a simple cache where you store 'file name' + file block of 8K' would save you millons of open + seek + read+close
<vila> montywi: patches welcome :D
<montywi> I know ;)
<montywi> Still, mariadb development takes much of my time and it's better to code the things you know most about...
<vila> montywi: I wholeheartedly agree anyway, I try to do that the whole day every day, smaller checks still hasn't reached the top of my stack so far... :-/
<montywi> but if I get a pause, I may look at this as the fix should be relatively easy
<montywi> and I 'really' would like to know if my repro is ok or now; Now I have no way of knowing as I will not have the time to let this finnish
<vila> montywi: I think lifeless was the last one working on that and he did put in place some infrastructure to enable that kind of focused checks
<vila> montywi: urgh, can't you duplicate it ?
<vila> hmm, too late for that I suspect...
<montywi> Yes, I am considering moving the repro to another computer to run thecheck
<montywi> now running bzr check on another computer that I don't need for the next 2-3 days. Hope it finishes...
<vila> montywi: hehe, oh, it should finish... or crash :)
<vila> montywi: but back to your original issue, did you try to commit from the command line instead of gcommit ?
<bialix> vila: please check my changes in https://code.launchpad.net/~bialix/bzr/2.2-configobj/+merge/50507. If they're ok for you I'll update 2.3 branch as well
<montywi> after it failed onces, I tried bzr commit and bzr gcommit and both worked
<montywi> i have now taken a full copy of my repro and will continue to keep the backup up to dates so that if/when it happens again I can reproduce it
<vila> montywi: 8-/ The error message was quite obscure, but now if it was spurious on top of that...
<vila> montywi: good, thanks
<vila> bialix: p-e-r-f-e-c-t
<bialix> you're too kind to me
<vila> bialix: I'll land in 2.2 and up to trunk, if you update your 2.3 branch, I'll use it, otherwise I'll do it myself, just let me know
<bialix> one sec
<bialix> vila: 2.3 done too
<vila> cool, 2.2 one pqmed, I'll wait for it to aggregate up to trunk
<bialix> vila: merci
<cbz> Is bzr-eclipse the only eclipse plugin for bzr?
<vila> cbz: no I think there is a qbzr-based variant which is better
<vila> . o O (I could swear someone nicked cb??? asked this same question less than a week ago...)
<cbz> vila: it looks like it hasn't been developed in a while ..
<vila> which one ?
<cbz> https://launchpad.net/qbzr-eclipse/ ?
<vila> then it works reaaally well or is not maintained, I can't answer that one ;)
<vila> but nick allen rings a bell, I'm pretty sure he's still active in the bzr community, may be not on the plugin, try the ml to get more feedback
<vila> and the last update seems to be dated 2010-11, so I won't qualify that as 'hasn't been developed in a while'
<vila> cbz: finally, from the url you gave above: https://answers.launchpad.net/qbzr-eclipse/+question/145746
<cbz> thanks
<vila> jelmer: pingeling about babune and reviews ;)
<amanica> cbz: I use qbzr-eclipse every day and it works fine. bzr-eclipse stopped working for me some time ago then I switched.
<vila> amanica: wow, hey guy ! Long time not seen !
<cbz> amanica: thanks
<amanica> vila: hi! have been busy :)
<cbz> amanica: bzr-eclipse seems to work for me, it's just that it doesn't integrate very well into eclipse
<vila> I sure hope so :)
<amanica> cbz: yes I understad, I liked the other one too, but on the other hand, I like the qbzr dialogs
<pfarrell> hi. I'm on ubuntu maverick. for some reason when I commit to my repository over bzr+ssh, a notification window pops up in the rhs of my screen, with details of my commit. it isn't obvious what process controls it or is putting it there. what I'd really like to know is when my collaborator pushes to /his/ repository -- can that be done?
<cbz> amanica: thats odd - i installed it, but it doesn't seem to add bazaar to the 'share project' vcs options
<vila> pfarrell: this sounds like bzr-notify plugin, IIRC it's based on DBus so little chance that it can track changes on lp, but check the questions/bugs at lp:bzr-notify or file a bug there
<vila> https://launchpad.net/bzr-notify
<vila> bah
<cbz> ah - orythogonal
<amanica> cbz: where are those options?  I mainly use commit, diff, push, pull etc.
<pfarrell> vila: ok, thanks
<vila> wrong url, https://launchpad.net/bzr-dbus exists though, so the notification thing should come from.. bzr-gtk maybe ?
<amanica> cbz: normally I set up everything on the commandline, but its nice to commit straight from the ide
<pfarrell> I do have bzr-gtk installed, maybe that's it
<vila> pfarrell: and bzr-dbus ?
<pfarrell> yep, bzr-dbus too
<vila> I thought you needed some config to activate it, I should look into that.... when time permits ;-/
<vila> pfarrell: now, you should also be able to subscribe to your mate branch at lp, but the notification will be mail based instead...
<pfarrell> oh, we're not using launchpad
<pfarrell> but thanks for the tip
<vila> pfarrell: oh, ok
<vila> pfarrell: hmm, I think the original idea for bzr-dbus was to allow this kind of notifications in a local network anyway (like in sprints) but I lose track of what was/wasn't implemented to reach that goal
<vila> pfarrell: so exposing your use case on lp:bzr-dbus is the best you can do to help making it supported ;)
<pfarrell> :-)
<lifeless> bzr-dbus + bzr-gtk can do lan notificaitons
<lifeless> broadcast pickup and transmit
<vila> pfarrell: ha ! listen to lifeless :D
<pfarrell> lifeless: is there an example anywhere?
<cdbs> I am having a wierd problem with bzr. http://paste.ubuntu.com/570524/ Please see this
<cdbs> I tried everything, but bzr add simply doesn't work on those two folders
<cdbs> it works on other files. I created a dummy file, bzr added it and it worked
<cdbs> but not those two folders
<cdbs> I don't have a .bzrignore
<vila> cdbs: what does 'bzr ignored' says
<cdbs> vila: well, I do have a bzrignore, this is bzr ignored output: http://paste.ubuntu.com/570527/
<cdbs> vila: bzrignore is a small 2 line file which I wrote myself. None of it is currently mathing those 2 folders
<cdbs> I am using Ubuntu Natty, so could python 2.7 be a problem causer?
<cdbs> just tried running bzr with python 2.6, same problem
<cdbs> can't find a bug with a similar problem
<vila> but are there files to be added below these dirs ?
<cdbs> I also tried bzr pack , and tried again
<vila> bzr pack is totally unrelated ;)
<cdbs> vila: no, all the other files below these DIRs have been added
<vila> huh ?
<cdbs> vila: I mean, all the files below these directories were already added in previous commits
<vila> if some files are versioned *below* these dirs, they shouldn't be unknown
<vila> what does 'bzr ls' says
<vila> bzr ls -R that is
<vila> or just 'bzr ls' but inside these dirs
<cdbs> vila: https://code.launchpad.net/~bilalakhtar/hall-of-fame/my-work/ is the repo on Launchpad, pushed uptil the latest commit
<cdbs> vila: okay, pasting that now
<cdbs> vila: http://paste.ubuntu.com/570530/
<cdbs> I also did bzr add src/ubuntu_website/*
<cdbs> no change
<vila> and what does a regular 'ls -al' says in ubuntu_website ?
<cdbs> vila: aha!
<cdbs> vila: there is a .bzr directory in ubuntu_website!
<cdbs> got it!
<cdbs> thanks
<vila> you're welcome ;)
<cdbs> wierd, when I did ls -R | grep bzr earlier, there was no output
<cdbs> except for the usual dirs
 * vila lunch now
<lelit`> hi all, I'm facing a problem with a bzr repository, where "bzr annotate" gives me a KeyError on a very old commit
<lelit`> googling around, I see it may be related to bzr-svn, which I used, very early in proj history when its master was kept under svn
<maxb> If you pastebin the full traceback, which you can probably find in ~/.bzr.log - or, you can get on the console by running the command again with the -Derror flag - people here can help diagnose
<lelit`> here is a summary, done on a fresh clone of my master repo: http://pastebin.com/t2Yd4mWX
<lelit`> as said, it may be that at that time (that is, december 2009) I used bzr-svn for a while on this repo
<jelmer> lelit`: it might be a bug in annotate dealing with ghosts
<lelit`> hi jelmer, thx. Is there anything I can do to either fix the repo, or to workaround the problem?
<lelit`> afk, later
<vila> maxb, jelmer: I've lost track: do we still carry our own configobj in bzrlib.util for ubuntu or not ?
<jelmer> lelit`: bug 438959
<ubot5> Launchpad bug 438959 in Bazaar "annotate breaks on ghost text revisions" [Medium,Confirmed] https://launchpad.net/bugs/438959
<jelmer> vila: we do
<vila> cool
<maxb> We do?
<maxb> jelmer: But you deleted it?
<jelmer> uhm, sorry
<jelmer> we do still patch it
<vila> bialix fixed an issue there that has a fallout for 2 tests
<maxb> Yes, but on ubuntu, we delete our patched version and use the system :-/
<vila> err, you lost me there
<jelmer> vila: so we no longer include bzrlib.util.configobj
<vila> argh
<jelmer> maxb: we patch bzrlib to use the system configobj is what I meant
<jelmer> sorry for all the confusion
<maxb> I am tempted to suggest reintroducing our private and fending off complaints about embedded libraries by explaining it's a fork
<vila> +1
<vila> I'm currently blocked otherwise
<jelmer> vila: in what way is ours patched?
<vila> we run the tests for Ubuntu only and they will fail for bzr >= 2.3.1
<maxb> I recall there being a comment noting that we've cut bits out we didn't need to optimize startup time
<vila> see  https://code.edge.launchpad.net/~bialix/bzr/2.3-configobj/+merge/50511
<vila> maxb: the new fix is not available upstream (yet) AIUI but has been devised with upstream input
<jelmer> vila: that fix seems like it should make it into upstream configobj as well
<maxb> even without this fix, there's still the issue that our configobj has bits cut out to optimize startup time
<vila> but I can't land it in bzr/2.3
<vila> maxb: less problematic than FTBS no ?
<vila> F
<maxb> vila: Presumably you can land it, but we need to decide what to do about the debuntu packaging before 2.3.1 ?
<jelmer> maxb: when profiling I haven't seen anything to indicate that optimization actually matters
<vila> pqm rejected it because two tests failed (''' and """ are toggled in configobj output)
<jelmer> for natty, I think we should get upstream configobj patched
<maxb> jelmer: Fair enough - if so, we should back out the customization from our local configobj copy
<vila> I can trivially fix the tests but they would fail again if an unpatched configobj is used during the build tests
<vila> jelmer: I would prefer to get the patched configobj available everywhere we need it *before* removing util.configobj from our packages
<vila> and even better get our other fixes upstreamed and be able to rely on the upstream version once and for all
<jelmer> vila: the debian/ubuntu packages have used the system configobj since 2.1.0~rc2-1, though they still shipped the bzr copy of it
<jelmer> vila: this fix is new, and I think we should get it upstreamed for the natty/sid packages
<vila> jelmer: the problem is that I either 1) don't land bialix fix 2) land it with the additional test fixes knowing the 2.3.1 won't be pass the tests
<jelmer> vila: Do you mean the packaging of 2.3.1 build ?
<vila> jelmer: sent: https://bugs.edge.launchpad.net/bzr/+bug/710410/comments/9 but no url...
<vila> jelmer: yeah sorry
<jelmer> vila: Don't worry about that, that's the packagers responsibility - I don't think we should complicate our upstream work because of it.
<vila> hmm, so you mean I should land with fixed tests then, right, wfm
<vila> jelmer: right and since I will then merge that into trunk, expect the daily build to fail too
<jelmer> vila: that's fine, it's what packaging is about :)
<vila> jelmer: indeed, I was realizing that only Ubuntu was affected by the issue because... of two packaging decisions (remove configobj, run tests during build)
<bialix> vila: what's wrong with my test?
<vila> hmm, still, qbzr may continue to encounter bug #710410 if bzr doesn't use a patched configobj
<ubot5> Launchpad bug 710410 in Bazaar trunk "ConfigObj is able to write bad branch.conf which is not possible to read back" [High,In progress] https://launchpad.net/bugs/710410
<vila> bialix: not yours, other ones
<vila> bialix: 2.3 added some tests for multi-lines values
<bialix> point me please
<vila> bialix: and your patch toggles the quotes used in this case (''' <-> """)
<bialix> oops, sorry
<vila> bialix: lp:~vila/bzr/2.3-integration
<bialix> I think I've ran all test_config tests
<bialix> but maybe I did not
<vila> bialix: hehe, blackbox ones :)
<bialix> aaaa
<vila> -s bt.test_config -s bb.test_config
<bialix> sorry
<vila> bialix: no worries, I fall in this trap *very* often even when working on config myself...
<bialix> :-/
<vila> bialix: that's why we have pqm :D
<vila> and babune
<bialix> yeah
<vila> of course it will help if I was receiving pqm emails...
<bialix> babune rocks
<vila> bialix: and windows stay blue !
<bialix> the hard working monkey
<bialix> coool
<vila> bialix: the only regression there have been related to bash completion and even there it started running tests it shouldn't have ;)
<vila> s/there have been/there, have been/
<bialix> vila: I don't like that change
<bialix> I think I can fix the configobj to preserve the old behavior, so you don't need to patch your tests
<bialix> I think double quotes is more appropriate for Human Beings by defauklt
<bialix> I think double quotes is more appropriate for Human Beings by default
<bialix> vila: what's your mind?
<bialix> vila: oops, sorry
<bialix> I've mixed those
<vila> bialix: I would prefer that too, if you can push this on your 2.2 branch and verify it works with -s bb.test_config in 2.3, that would wfm
<vila> you mean between triple double quotes or single ones ? :D
<bialix> I meant: it will be nice to have double quotes in the user output
<bialix> now it is
<bialix> Do you think it's good?
<vila> I don't care
<bialix> then I withdraw my picky note
<vila> using multiline values in config files is borderline in my book anyway :D
<bialix> never heard this phrase
<vila> And I prefer single quotes as they still scream 'no interpolation' in my head ;)
<vila> bialix: 'in my book' == 'in my private view of the world'
<bialix> "borderline in my book" -- does it mean it's out of your desires?
<bialix> ah
<vila> bialix: 'borderline' == 'very close to being illegal or bad taste'
<bialix> now I got it
<vila> but that's just IMHO of course
<bialix> I can change the order to pick the triple quotes for simple cases
<bialix> if you insist to
<vila> well, I won't ask you to go against your desires, that would be bad for my karma :D
<vila> bialix: and if the fix has already found its way upstream, we'd better not diverge again
<lelit`> jelmer: I see
<vila> bialix: and pqm is 84% done with the 2.3 submission
<vila> bialix: and.. :-D
<bialix> vila: ok. let it land
<bialix> give up, give up
<vila> move it, move it
<vila> bialix: landed in 2.3
<bialix> \o/
<vila> bialix: trunk pqmed
<bialix> yay
<bialix> vila: so, do you say there is no tree.conf yet?
<vila> there is no tree.conf yet
<vila> I want a tree.conf
<bialix> it was not clear for me
<bialix> you said there is too much config
<bialix> files
<vila> haha
<vila> you're right :)
<vila> I meant that some config files could be merged into existing ones (there cases where we don't want that though) and there are some missing files
<vila> s/there/there are/
<bialix> something like that
<vila> see ? It's all far clearer with a little hand-waving :D
<bialix> but without that waving you don't have a magic
 * jelmer takes a look at lp:udd
<vila> jelmer: \o/
 * bialix waves at jelmer
<bialix> jelmer: any suggestion re http://pastebin.com/k9AeJ1j9 ?
<Gorkyman> hey guys...
<Gorkyman> need some guide for setting bzr on server... smth for dummies i gues : )
<maxb> List your basic requirements and what you've looked at so far. There is some material in the Bazaar documentation, e.g. http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/index.html
<jelmer> maxb: did you see 614544: bzr: FTBFS ?
<maxb> see, yes.
 * maxb actually reads
<jelmer> basically, the launchpad tests require internet access
<maxb> ah yes. fail
<maxb> are those new, or why aren't they failing in daily builds?#
<maxb> jelmer: On a semi-related note, how would you feel about running selftest with -v in debian/rules, so you can see what tests ran in a buildlog?
<jelmer> the daily builds have access to launchpad I think
<maxb> oh dear that is comedy fail
<maxb> I'm pretty sure they're not supposed to
<jelmer> I'm going to upload a new copy with the launchpad plugin disabled during the tests for the moment
<maxb> That makes sense - I don't think that plugin does much which doesn't involve network access anywy
<jelmer> It's only a few of the tests that fail
<maxb> Maybe just deleting those tests in the packaging branch is the best workaround?
<maxb> Longer term, I wonder if we could set things up so there is a "feature" of "Can successfully contact Launchpad XMLRPC"
<jelmer> ideally we would just use a proper mock server
<maxb> that would be even better
<jelmer> maxb: s/deleting/skipping/, but yeah
<jam> morning all
<jam> vila: I'm trying to review https://code.launchpad.net/~vila/udd/use-new-driver/+merge/50644
<jam> but the diff is kind of hard to parse
<jam> can you describe what you did a bit?
<vila> sure
<vila> jam: it will help if you look at the resulting mass_import.py
<vila> the diff is really obfuscating the refactoring
<vila> I think it should be far clearer with the script itself on my cover letter
<vila> Otherwise I'll be rehashing the cover here and that doesn't sound very helpful
<vila> jam: but in a nutshell, the pre-requisite mp implements a SubprocessMonitor (in a thread) and a ThreadDriver (in a thread, starting/killing/joining a number of threads)
<vila> and tests
<vila> this mp uses the tested features to rewrite mass_import
<vila> so it's just adding the logger calls and the db related calls in the right places and get rid of all the time.sleep calls() in favor of two wait(xxx) calls
<vila> which should get rid of all the race conditions
<vila> jam: thanks for the udd reviews !
<jelmer> hey jam
<jam> hi jelmerr
<jam> sorry for the delay, had sound off
<ovnicraft> hello i'm looking for a code review tool integrated with bzr anyone has experience ?
<jelmer> hi ovnicraft
<jelmer> ovnicraft: launchpad supports code reviews (and is used by bzr itself), and I believe reviewboard also supports bzr
#bzr 2011-02-23
<jonnydee> hi, I'm just investigating the bzr-svn plugin features and associated worklflows...
<jonnydee> now I wonder how the workflow for dealing with svn branches is like...?
<jonnydee> I've seen blog posts telling to branch the 'trunk', then branch from the local 'trunk' branch, commit to the latter, and finally merge to the former
<jonnydee> But how can I deal with branches tracked within svn? Will it be possible to work on a svn branch using bzr-svn, and finally merging that svn branch to trunk? will it look like I did a merge from a branch to trunk using svn?
<jelmer> jonnydee: hi
<jonnydee> hi jelmer :)
<jelmer> jonnydee: they're much like "normal" bazaar branches, and you can pull from them merge into them and push into them as you would expect to with a regular bzr branch
<jonnydee> so it should be possible to emulate a branch-merge workflow of users using svn only?
<jonnydee> I'm asking because we have svn, but I would like to use Bazaar and this should completely be transparent to the other svn users
<jelmer> jonnydee: yes, although bzr-svn does add revision properties with bzr metadata that can't be represented in svn natively
<jonnydee> jelmer: I think that shouldn't be an issue... So I would co "trunk" using bzr, do my commits to a local branch of it, then I push to svn using an svn-url pointing to ../branches/my-branch
<jonnydee> then I merge my local my-branch into my local "trunk" checkout and push to svn "trunk"?
<jelmer> jonnydee: there's no need for the local mirrors
<jonnydee> svn users will then see my branch commits for ../branches/my-branch, and they will realize that I merged that branch into "trunk"?
<jonnydee> no need for local mirrors?
<jelmer> jonnydee: You'll have to push that branch into /branches/my-branch in svn manually
<jelmer> jonnydee: otherwise it won't show up there in svn
<jelmer> there is an option in bzr-svn to do that for you, but it's experimental
<jonnydee> ok, that's what I assumed, but will they somehow realize that I finally did a merge from /branches/my-branch to /trunk ?
<jelmer> not anymore than they currently will
<jonnydee> AFAIK svn >1.5 does merge-tracking and I wonder if this information will be propagated when I push my merge to the svn /trunk
<jelmer> bzr-svn does set svn:merge-info, but it won't use it for the bzr revision graph
<jonnydee> ok, so that's good news. It means that svn users will be able to see, that I merged /branches/my-branch to /trunk, right?
<maxb> yes, the metadata will be there if they care to look for it
<jonnydee> jelmer,maxb: thank your very much for your fast and helpful feedback :)
<maxb> I am toying with trying to get bzr-svn to build a bzr revision graph based on svn:mergeinfo
<maxb> I don't think it'll ever be roundtrippable, but it would be a boon for people doing a one-time convert out of svn
<jonnydee> maxb: I think that would be really helpful in such cases
<jonnydee> I wish you good progress
<jonnydee> it's been a pleasure to talk to you! bye, and thanks once more for your attention :)
<maxb> Why does bzrlib.tag._merge_tags_if_possible exist?
<maxb> I'm trying to see what functionality it provides over tags1.merge_to(tags2), and there doesn't seem to be any
<spiv> maxb: it does wha tthe comment says
<spiv> maxb: if you want to pass the ignore_master=True arg, but aren't sure the tags implementation supports that API (new in 2.3), then it will try pass the flag, but if it can't it emits a warning and just give the pre-2.3 behaviour (by not passing the flag).
<spiv> maxb: it's backwards-compat paranoia, basically
<maxb> spiv: ok..... but I know it existed before ignore_master did .... so why? Prescience? :-)
<spiv> maxb: when I added the ignore_master param as part of a bug fix I added that function so that cmd_merge (and possibly other bits of bzrlib?) can use it to avoid breaking with e.g. bzr-svn branches if the user is running with an un-updated plugin.
<spiv> Are you sure?
<maxb> Yes, because I remember looking at its pre-ignore_master implementation, which was more obviously mystifyingly pointless
<spiv> I'm pretty sure I remember adding it :)
<maxb> hm :-)
<spiv> Or, perhaps, updating it to be its current useful form ;)
<maxb> right
<spiv> But I think I added it.
 * spiv looks
<maxb> no, it's existed since poolie first implemented tags in branches in 2007 :-)
<spiv> Ah, well, probably a hangover from an early implementation of tags.
<spiv> I'm guessing it predates the merge_to method.
<spiv> Anyway, it serves a useful purpose in 2.3 :)
<maxb> Now that's planning ahead :-)
<chx> to roll bzr patches i am using  diff --diff-options -up so that i get @@ -136,6 +136,10 @@ function user_pass_reset($form, &$form_s now this is good but now I need patches suitable for patch -p1 and this created patch -p0 patches
<chx> bzr diff -p1 gives me a patch -p1 but that does not do what diff -p does (--show-c-function)
<chx> there is a largely undocumented option to bzr diff: --format
<fullermd> I think that's used by plugins.
<chx> fullermd: hi. any solution? I am happy to hack a plugin if necessary :) just dont know where
<fullermd> Well, my solution has been to point and laugh at people screaming for -p1 patches.  Not sure that helps you   ;)
<fullermd> Does bzr's -p take effect before --using?  That sounds like it would be possible...
<fullermd> If possible, it probably should, and would be a bug if it didn't.  And surely it's possible; where else is an external diff getting filenames but from trusting what bzr says?
<chx> i am reading diff.py and external_diff has http://paste.pocoo.org/show/343131/  in it
<chx> this makes me suspect that the prefix is not taken into account
<fullermd> As if showing python code to me is gonna do anything   :p
<fullermd> I woulda approached it by just trying it to see...
<spiv> You could try passing the diff throught filterdiff
<spiv> It's got a --addprefix option
<chx> spiv: <3 you.
<chx> spiv: now, how can i tell bzr that bzr diff is alias for bzr diff --options -up | filterdiff --addprefix a/
<chx> (or more elegantly --addoldprefix a/ --addnewprefix b/ )
<spiv> chx: for that I think you need a shell alias :)
<chx> spiv: sniff i need to figure out bash code that on bzr foo runs bzr foo but on bzr diff runs the aforementioned ugliness.
<fullermd> Nah, just make a 'bzrdiff' alias.
<chx> Aliases don't allow for control-flow, command line arguments, or additional trickery that makes the command line so useful.
<spiv> Personally I'd go with fullermd's suggestion
<chx> fullermd: i guess.
 * fullermd still says that -p should affect external diff...
<mwhudson> bzr () { if [ "$1" = "diff" ]; then shift; command bzr diff "$@" | diffstat; else command bzr "$@"; fi; }
<spiv> Because as you say making bash treat 'bzr diff' differently to 'bzr foo' is going to be fiddly, and I'm fairly lazy.
 * mwhudson has been doing too much shell lately
<spiv> Or, just hang out for 3 minutes, either way.
<spiv> :)
 * fullermd huddles mwhudson up in the corner with a blanket and a bowl of hot soup.
<chx> thanks
<mwhudson> fullermd: thanks
<chx> mwhudson: good god
<chx> mwhudson: thanks
<chx> off to the gym
<montywi> vila: bzr check still running (laptop with 2 cores + flash disk)....
<vila> montywi: single core used, lots of CPU needed, did it output some progress (even flaky) ?
<vila> montywi: or something in .bzr.log (more likely)
<montywi> yes, its progressing
<vila> ha good, damn, I just realized I didn't recommend -'v' :-( /me bangs head
<vila> stupid stupid stupid
<montywi> it's now in 'checking graphs 42000/85000
<montywi> this is increasing with 1 per 3 seconds
<vila> hmm, I don't remember the order in which the checks are performed :-/
<vila> 1 out of the 85 000 ? O_o
<vila> 85.000 more or less correspond to the number of revisions ?
<vila> (not the mainline revs, all the revisions I mean)
<montywi> i think so
<montywi> so if it continues like now, it will take 43000*3 seconds more to do the check
<montywi> or 1.5 days
<montywi> (for this stage)
<vila> yeah, for this stage :-/
<vila> on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ?
<vila> montywi: the format used is 2a right ?
<montywi> yes
<vila> on both counts ?
<montywi> both counts ?
<vila> on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ?
<montywi> no problem found with repro during the last 2 days
<vila> k
<montywi> but i will continue to do rsync backups to be able to repeat any problems that is found
<vila> of course 2 days (or even 3) is ridiculously too long for a check...
<vila> thanks
<vila> montywi: before I forget and in case you need to re-run a check (cough, hopefully not) use BZR_LOG=<different-one> bzr check -v
<montywi> ok and thanks for tip
<vila> montywi: so we get a clean log with all collected data (-v shouldn't make it really slower ;-/)
<montywi> i would like to use the laptop after 2 weeks...
<vila> oh good, Apple will be announcing some new models tomorrow, you'll be able to buy a new one, no problem :-}
<vila> <desperate sarcasm/>
<montywi> Apple? Why on earth would I want to buy an Apple?  I am using *real* machines ;)
<montywi> (Machines which software I can use, modify and extend without having to talk with lawyers)
<vila> oh, but you can install Ubuntu on them :D
<Tak> actually, ubuntu is really nice on my macbook pro
<vila> jelmer: make sure you always mentions bug numbers in news entries (how a veteran packager can miss that is beyond my understanding ;-D)
 * vila lunch
<jelmer> vila: *nod*
<jelmer> vila: did I miss one somewhere?
<vila> jelmer: hmm, yes, but... I can't remember where right now :-( if you don't find it, don't worry, I'll fix it at release time anyway
<vila> I noticed it yesterday if that helps, may be already landed, not sure
 * vila really out :)
<jelmer> bon appetit :)
<shakaran> Hi, Where I can delete the config for bazaar explorer with Windows XP?
<shakaran> bzr: ERROR: bzrlib.util.configobj.configobj.ParseError: Invalid line at line "1" with bzr 2.3.0 and I need delete de .conf file or whatever file that store the corrupt file
<shakaran> somebody?
<jelmer> shakaran: hi
<jelmer> shakaran: it's either the .bzr/branch/branch.conf file or the locations.conf or bazaar.conf in your bzr home directory
<shakaran> I have a C:\Archivos de programa\Bazaar for bzr home directory
<shakaran> I search *.conf files but it dont found any file with conf
<shakaran> Archivos de programas = Program files (sorry for the spanish)
<shakaran> I have all my local branch's with Eclipse on C:\workspace If I search .conf file there I get:
<shakaran> a branch.conf with:
<shakaran> parent_location = ../../Earth%20Wars/
<shakaran> push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/
<shakaran> submit_branch = file:///C:/workspace/Earth%20Wars/
<shakaran> [commit_data]
<jelmer> hmm, that all looks reasonable
<shakaran> I have other 3 files with branch.conf
<shakaran> parent_location = ../../Earth%20Wars/
<shakaran> push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/
<shakaran> [commit_data]
<shakaran> third file:
<shakaran> bound_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/
<shakaran> bound = True
<shakaran> parent_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/
<shakaran> submit_branch = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/
<shakaran> [commit_data]
<shakaran> last file:
<shakaran> bound_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/
<shakaran> bound = True
<shakaran> (sorry about the flooding)
<jelmer> shakaran: only the file in the branch you were working in should be relevant
<shakaran> I dont see the problems on line 1 for the files. The problem is that bzr-explorer fails on start with a bug
<shakaran> http://pastebin.com/azDjMfjm
<shakaran> it dont show the invalid file, so I dont know what file is it bad parsed
<jelmer> shakaran: one sec, I'll look at the source
<jelmer> shakaran: do you have a qbzr.conf file anywhere?
<shakaran> on whick folder should be? on bzr home?
<shakaran> I report the bug too https://bugs.launchpad.net/bzr/+bug/723691
<shakaran> not found a qbzr.conf (on all system)
<jelmer> shakaran: It seems like a qbzr issue, hopefully one of the qbzr folks can help out
<shakaran> jelmer: I report the bug, I wait then, thanks for your great help
<vila> jelmer: that one: https://code.launchpad.net/~jelmer/bzr/multiprocessing-cpu_count/+merge/50812
<jelmer> vila: Will fix - thanks for the reminder :)
<vila> np ;)
<jml> how can you tell what commands a plugin provides?
<jelmer> jml: bzr help commands | grep plugin-name
<jelmer> jml: I don't think we have anything fancier than that to discover it
<jml> jelmer: thanks.
<jml> jelmer: I have just discovered how awesome bzr-stats is.
<jelmer> jml: :)
<jelmer> it could be a lot more awesome though
<jml> Yeah, agreed.
<jml> I was just thinking, wouldn't it be nice if I could run a command and have it tell me how actively developed this project is
<jelmer> jml: Ohloh-style, e.g.:
<jelmer> "Decreasing year-over-year activity." / "Large development team" / ... ?
<jml> yeah, maybe
<jml> well, actually that would be pretty cool
<jml> but also something like "6 commits to trunk in the last month"
<jml> or maybe a little ascii art graph of num commits per chunk of time
<jelmer> ah, hmm
<jelmer> I quite like the (new?) blurb on the code.launchpad.net/PROJECT pages with that data
<jml> yeah
<jml> it's not that new, I think.
<jelmer> jml: didn't launchpad also have tiny graphs with the branch activity for a while?
<jml> jelmer: it did.
<jelmer> jml: Do you know why that was removed?
<jml> jelmer: we removed them because showing them on a branch listing for a project is generally uninteresting
<jml> and that's where they were shown
<jml> e.g. all of the branches for bzr will have almost exactly the same graph
<jml> because they are all short-lived branches of trunk.
<jml> jelmer: and so rather than rehabilitate the feature, we killed it.
<jelmer> ah, ok
<vila> jml: any feedback about bzrlib.transform.orphan_policy=move ?
<jml> jelmer: do you know how to tell bzr-stats that two people are the same?
<jml> vila: no. I'm a loser.
<jml> vila: do I just add that line to my bazaar.conf?
<vila> jml: yup
<vila> bzr.transform.orphan_policy=move
<vila> grr don't paste !
<jelmer> jml: it looks for similar email addresses/fullnames
<vila> :)
<jml> vila: thanks. added, will let you know how it goes. (I have a couple of branches up that delete directories)
<jelmer> jml: it doesn't support a rename map of any sort (yet)
<jml> jelmer: ahh ok.
<vila> jml: cool, will fix any related bug
<vila> jml: especially the ones with reproducing recipes ;)
<jml> vila: heh. will do. :)
<jml> jelmer: I have now filed many bugs on bzr-stats. I might actually try to fix them, but, you know how it is.
<jelmer> jml: :)
<jml> jelmer: I also just filed a bug asking for reviewer stats. I think that's kind of a tough one that might require some kind of hook thing.
<jelmer> jml: with regard to reviewers, I think it would be really nice if we can start sticking them in a revision property
<jml> +1
<jelmer> jml: https://bugs.launchpad.net/bzr/+bug/723740
<chx> jelmer: hi. Am I having the honor to talk to the author of bzr-git :) ? If yes, then https://bugs.launchpad.net/bzr-git/+bug/719238 what does this... mean? there is support for push now but it's experimental and shouldnt be...?
<jelmer> chx: hi :)
<jelmer> chx: looking..
<jelmer> chx: so, there has been some initial work on proper push (as opposed to dpush) but it's not ready for prime time use yet
<jelmer> chx: it should by default be disabled but doesn't appear to be
<chx> ah i see
<chx> next question, when i use bzr git-import http://git-testing.drupal.org/project/drupal.git it creates an empty directory with .bzr in it
<chx> oh it created a repo?
<jhunt> Hi - can someone help me out with bug 723735? It's blocking me from submitting code prior to todays feature freeze.
<ubot5> Bug 723735 on http://launchpad.net/bugs/723735 is private
<chx> jelmer: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study.html from reading this i am under the impression that bzr git-import http://git-testing.drupal.org/project/drupal.git should actually download something but it dosnt.
<jelmer> jhunt: I can't see that bug because it's private.
<jelmer> chx: It should, but that URL is a bit strange (it gives me a 404)
<chx> jelmer: weird. git clone works with it unless i am blind.
<chx> jelmer: yeah it does
<chx> AH ha!
<chx> jelmer: that's a git:// url
<chx> jelmer: it's just that git ... works with http
<chx>  bzr git-import git://git-testing.drupal.org/project/drupal.git is downloading.
<jelmer> chx: can you file a bug against bzr-git?
<chx> jelmer: https://bugs.launchpad.net/bzr-git/+bug/723751
<jelmer> ah, I think I see what's happening
<jhunt> jelmer: yes - the bug was created as private by default, but I am unclear as to why.
<jelmer> jhunt: can you make it public or pastebin the information you can make public?
<vila> jhunt: I often see bug created private when apport is involved...
<jhunt> jelmer: bug 723735 is now public
<ubot5> Launchpad bug 723735 in bzr (Ubuntu) "bzr crashed with NoSuchRevision in _translate_error()" [Undecided,New] https://launchpad.net/bugs/723735
<jelmer> jhunt: so, it seems like the "-v" is the bit that breaks
<jelmer> jhunt: does it still break if you run without -v ?
<jhunt> jelmer: well, I just pushed the same branch using "bzr push -v lp:~jamesodhunt/+junk/foo" and that was fine ?
<vila> jhunt: no stacking involved in +junk
<jelmer> jhunt: I guess it's stacking related.
<jelmer> hmm, gmta :)
<jelmer> jhunt: can you perhaps try with the latest bzr (2.3.0) ?
<vila> jelmer: You haven't (yet) used the lazy registration of branch formats in the foreign plugins right ?
<vila> jelmer: argh, gmta again, loom trunk: branches have diverged :D
<vila> jelmer: additional tweak pushed
<jelmer> vila: I have, bzr-{hg,svn,git} use it
<jelmer> vila: it's not in any releases yet though, so changing things should be possible
<vila> jelmer: while you're warmed up, care to use it for looms too ?
<vila> jelmer: do you remember if jam is already moving today ?
<jelmer> vila: sure, I'd be happy to
<jelmer> vila: I'm not sure
<bialix> heya all
<vila> heya bialix
<jelmer> hey bialix, how's your day?
<bialix> jelmer: I wish something better
<vila> jelmer: could you give your input on https://code.launchpad.net/~vila/bzr/config-expand-options/+merge/50355 ?
<bialix> vila: if you have a minute to talk about configs and qbxt
<bialix> qbzr
<vila> don't ask to ask :)
<vila> Pushed up to revision 404.
<vila> Huh ? What do you mean file not found ?
<vila> errr
<vila> :)
<bialix> vila: currently qbzr/lib/util.py has its own Config object which is kinda caching object
<bialix> it does not try to re-read the real config every time
<bialix> *Config class
<bialix> it's used to work with qbzr.conf
<bialix> this class is using to work with qbzr.conf
<jelmer> vila: sure
<bialix> vila: what I need to switch to using bzrlib.config instead
<vila> bialix: looking at it, it seems to have anticipated bzrlib.config.LockableConfig... except save is explicit
<vila> hmm, and {set|get}_option here is {set|get}_user_option there :-/
<vila> wow, and BOOKMARKS
<vila> bialix: forget it, too early to migrate
<bialix> vila: forget what?
<bialix> sorry, I had a call
<vila> bialix: qbzr needs to save only once, this is not yet available (unless you don't want atomicity anymore)
<vila> so you can't migrate yet... unless
<bialix> vila: I don't think it's the main goal
<vila> ha, ok
<bialix> it saves data here and there all the time
<bialix> no atomicity, as I can see
<vila> another point to consider:
<bialix> I need to dig through the history of that code to understand why it written in the way it's written
<vila> instead of using a separate config file, you may want to prefix your options with 'qbzr.'
<bialix> :-/
<vila> and use bazaar.conf or branch.conf
<bialix> that'd be bad
<bialix> maxb recently said against this
<jelmer> vila: I'll have a look at the expand options branch and your udd MPs when I get back
<vila> that would mean that in the future, some options may be defined in branch.conf, locations.conf, bazaar.conf
<bialix> actually I don't like how it's designed today
<vila> bialix: not for all variables
<vila> jelmer: great
<bialix> we have a lot of runtime variables which is not user editable
<vila> jelmer: err, back from what ? :D
<jelmer> vila: need to run some errands
<vila> jelmer: np was kidding :)
<maxb> The thing I objected to was 'bzr viz' storing window sizes in pixels in bazaar.conf, thus making it impractical to version-control my bazaar.conf
<vila> maxb: yup, I understood that
<bialix> maxb: exactly
<bialix> vila: ^ see
<vila> bialix: see ^ :D
<bialix> vila: I don't like how we store our data in qbzr.conf
<vila> that doesn't mean it applies to *all* qbzr config options ;)
<bialix> yes, of course
<bialix> there are about 5-10 options which are not pixels
<maxb> I think it's fine for plugins to rewrite bazaar.conf so long as they only do it in response to the user actually reconfiguring sometime
<maxb> *something
<vila> yeah, I'll go as far as saying that 'bzr config' should be almost the only one to modify config options
<bialix> if we start talking about bzr-explorer then it has a ton of options grouped into subdir
<vila> the execptions being --remember, window sizes, bookmarks, aliases, but even bookmarks and aliases should be defined with 'bzr config' and just use special names
<vila> bialix: I discovered that a couple of days ago, but most of them are in xml files
<vila> there is one horror there still, file extensions are associated with executables by using the list of extensions as the key and the application as the value...
<bialix> vila: I'm very dislike code like that in the qbzr:
<vila> I wonder why it's not the reverse...
<bialix>         config.set_option(name + "_window_size", "%dx%d" % size)
<bialix>         config.set_option(name + "_window_maximized", is_maximized)
<bialix>         size = config.get_option(name + "_window_size")
<bialix> those concatenations make me feel bad
<vila> bialix: use helpers
<vila> and dots instead of _
<bialix> no, I'm trying to say: why we haven't put them into subsections
<vila> if you start thinking about option names as python identifiers
<bialix> or even into database
<bialix> registry
<vila> eeerk
<bialix> and so on
<vila> no subsections please
<bialix> that's bad
<vila> I don't think we need more than python identifiers here
<bialix> I can't agree
<vila> that's far more user friendly than subsections with [[[[[very embbeded section]]]]]]
<bialix> bzrlib.config has hidden ConfigObj too deeply
<vila> not enough obviously
<bialix> I need only one layer down
<bialix> every q-window should have dedicated section
<bialix> for their pixel settings
<vila> qbzr.<window_name>.size
<bialix> great! can I have one of this?
<vila> just do it !
<vila> it works today !
<bialix> really?
<bialix> in 2.3?
<vila> in 2.0 even
<bialix> ???
<vila> '.' has always been valid in an option name
<bialix> I never seen it
<bialix> ha
<bialix> you again put me bacj
<bialix> back
<vila> ?
<bialix> one sec, I'm pastebining
<bialix> vila: http://pastebin.com/XQ9PiW7P
<bialix> do you like it?
<bialix> I'm NOT
<bialix> that's a mess
<bialix> sorry for my french
<vila> :)
<vila> Yeah and the user has no idea who is spamming his config file...
<vila> subsections won't make it less spammy
<bialix> the syntax you have shown "qbzr.<window_name>.size" recalls me about git configs
<vila> just because it's like git doesn't mean it's bad
<bialix> dot syntax is using to navigate through sections, IIRC
<vila> no, sections are used for something else !
<vila> that's the whole point
<bialix> I thought you said we can navigate through our sections as well
<vila> if you use sections to define the name space you can't reuse it to define values for more specific cases
<bialix> let's draw a line: I want those automatic pixel settings to be stored separately of user options
<vila> 'specific' can be a path, a user name, an url, whatever
<bialix> vila: so I need [GEOMETRY] section and q-window names as subsections
<vila> bialix: right, put them in a qbzr.windows.conf file then
<vila> haaa
<vila> scratch above
<bialix> qbzr.internals.pixels.settings.dont.edit.it.please.and.even.dont.look.inside.conf
<maxb> What do we use sections for at the moment, other than locations.conf ?
<vila> a qbzr.windows.conf with window names as sections then
<vila> maxb: nothing, exactly my point ;)
<maxb> oh, and branch.conf [commit_data]
<bialix> yep, famous commit_data
<vila> maxb: kill that one, I don't even want to know it has ever existed :)
<bialix> (palm face)
<vila> bialix: windows size are user specific right ? It's a bit sad it can't be project or even branch specific no ?
 * bialix wonders where is the Gary. maybe in the long and sunny vacation on Taiti
<bialix> vila: yep
<vila> nahhh, in a basement with someone whipping him
<bialix> nm
<vila> hmm
<vila> then no sections for window names :)
<vila> you can do as locations.conf and use path as section names instead
<vila> one planned feature for configs is that the sections (from path) would be allowed in bazaar.conf to act as default values (as opposed to overriding values in locations.conf)
<bialix> vila: so far nobody compains about pixels settings to be non-project adjustable
 * vila nods
<bialix> vila: I want to extract pixel settings out of qbzr.conf, that's my long standing desire
<bialix> I'm not sure I need conf file for them even
<vila> config files are for text values that a user may want to edit, ... yeah
<bialix> yep
<vila> but you need some sort of persistence
<bialix> of course
<vila> so putting them in a different file with a comment: '# Sorry guys, not for you to edit' could work
<bialix> so COnfigObj with subsections provides me a good hierarchy store
<bialix> I'm not very good in sqlite
<vila> why would you care about how it's represented in the file if you don't intend to edit it ?
<bialix> sometimes I need to edit it
<bialix> maybe to test something or to workaround something
<vila> the dotted notation works quite well for python modules why not for you ?
<bialix> the paste I've shown
<bialix> the options are not grouped toghethre
<bialix> so it's harder to read and analyze
<bialix> for me as qzbr dev
<vila> sorry ? you mean you want them sorted by what criteria ?
<bialix> by window name of course
<bialix> they're essentially grouped
<bialix> but not in the file
<vila> err, the file you pasted is grouped by window name...
<bialix> 'cause config preserves the order
<bialix> no, it's not
<bialix> look for explorer_
<bialix> they're spread
<bialix> they're spread across the lines
<bialix> ditto re log
<bialix> and I think diff as well
<bialix> sometimes I edit it to test something
<bialix> sometimes it's for different reason
<bialix> but my point: there are 75 lines of different settings
<vila> well, that's your file :)
<bialix> yeah, why not
<vila> I meant, you're free to organize it as you see fit, we already agree it's not really user oriented
<bialix> qbzr.conf is twofold today
<bialix> there are user settings as well. I simply omit them when pasting
<bialix> while pasting
<bialix> vila: I raise this question because of new patch submission: https://code.launchpad.net/~nick-sonneveld/qbzr/fix-258926/+merge/50862
<bialix> it touches the same grey area
<bialix> some qbzr options are about appearance, some about behavior
<vila> well, the in (True, 1) is a subset of get_user_option_as_bool
<bialix> yep
<bialix> reinventing the wheel for fun and profit
<bialix> ok,
<bialix> I need to go home now, I'd like to continue this rant later
<vila> but yeah, the behavior is a good candidate for branch.conf and this route is via qbzr.<window name?>.versioned_files.show
<bialix> I need to think more
 * bialix disappears
<vila> except you'll need to find a way for the user to decide in which conf file the changes are recorded
<vila> too lat :)
<vila> e
<CoffeeIV> Is there a general way I can undo a "bzr up" if I need to ?  The situation is a live web site maintained under bzr version control.  I think "bzr revert" would un-do edits I made, but if I note a revision number, is there a quick way to back out of a "bzr up" if I need to ?
<chx> CoffeeIV: you can bzr up -r somepreviousrev
<chx> CoffeeIV: i recommend setting a tag before upping and hten it's easy to back down
<CoffeeIV> chx: ok, I will figure out how to do the tag.  Thanks !
<chx> CoffeeIV: bzr tag whatever :) and then bzr up -r tag:whatever
<chx> CoffeeIV: this is bzr, everything is trivial (until you do something as silly as i did two days ago and even that it was two commands to fix it, lol)
<Tak> that's what I love about bzr
<Tak> none of this 10 commands, each with 3 optional arguments and nondeterministic side effects, to accomplish a straightforward task
<chx> yessss
<beuno> http://git-annex.branchable.com/
<beuno> that looks interesting
<Tak> looks similar to mercurial's bfiles extension
<jaypipes> anybody know how to find out who removed or renamed a file that was at one time under bzr source control?
<vila> beuno: damn it
<vila> beuno: that's on my TODO list for months, far low unfortunately
<beuno> vila, WORK FASTER
<beuno> :)
<vila> :-}
<thumper> $ bzr revno :push
<thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/launchpad/lp-client-cache-move"
<thumper> expected?
<thumper> wasn't to me
<thumper> $ bzr revno lp:~thumper/launchpad/lp-client-cache-move
<thumper> 12445
<bob2> is it a "lp: urls when you're not logged in are http://" issue?
<thumper> nope
<thumper> it seems that if you try to use a branch alias, it isn't expanding the branch
#bzr 2011-02-24
<fullermd> thumper: I'm pretty sure it only ever expands lp: through the UI.  The saved locs in branch.conf are pre-expanded, it won't indirect through the directory service for them.
<fullermd> (so if one did get in there, it wouldn't work)
<thumper> fullermd: ah, ok
<wolter> does bzr use argparse?
<mwhudson> no
<mwhudson> it has its own thing that predates argparse (and uses optparse as a backend iirc)
<mwhudson> see bzrlib.option?
<wolter> hm dont know whats that
<Peng> What it is is bzr's option parser.
<mwhudson> wolter: it's a module within the bzrlib package
<chx> how the years have passed :)
<chx> six years almost, no wonder the option parse predates argparse :)
<vila> wolter, chx : And IIRC argparse is not available for python2.4 (we still maintain compatibility with it so far) right ?
<wolter> wouldn't know :s
<vila> wolter: np, just saying
<vila> wolter: it would be nice to switch anyway but that can't be done *now*
<bialix> bonjour vila
<vila> bialix: hey !
<bialix> :-)
<bialix> to continue our last conversation
<bialix> I think qbzr really needs atomicity re group of options
<bialix> and group of options per se
<bialix> groups
<vila> can you elaborate on that ?
<vila> why is it needed, what are the failure scenarios ?
<bialix> we have several pixels options: size, is_maximized flag, sometimes even the relative sizes of widgets
<bialix> the scenario is simple: for qbzr those options should be read and written as one operations
<bialix> to always have consistent state
<bialix> that's my idea
<bialix> currently config interface is one-option-at-time oriented
<bialix> although some internal options are grouped as well
<bialix> say, bound_location + is_bound flag
<bialix> not sure about stacked on option
<vila> yes, it's one option at a time and I'd like to change that, but when will that fail ?
<vila> I mean, with the current implementation
<bialix> smart server
<vila> what will fail there ?
<bialix> we're using commit_data group and older smart servers has no support for dicts in config
<bialix> s/has/had/
<bialix> now spiv fixed this
<vila> that's a different problem, not related to atomicity
<bialix> qbzr don't hold the lock all the time
<bialix> and bzr-explorer for more broad example
<vila> bialix: we're talking past to each other,
<bialix> config's API is: if you need 1 option then read a config file
<vila> if there is no atomicity, what could go wrong ?
<bialix> I can't say
<bialix> my point not about imaginary race condition
<vila> mine is :)
<bialix> but about the situation that sometime some code works with tightly coupled group of options
<vila> if you don't encounter a race, then setting the options one by one gives the same end result
<bialix> those options should be read simultaneously, and should be written simultaneously
<vila> why ?
<bialix> except that you have to re-read the same config many times
<bialix> let's talk again about smart server
<bialix> to change 5 opyions you need 10 operations
<bialix> options
<vila> yes, the concern is about performance but this can be address more easily than the race conditions
<vila> and you can also get atomicity by bencoding your set
<vila> of course bencode is user hostile, but that's another issue
<bialix> bencoding the set is ad-hoc solution
<bialix> I don't really like the idea of bencoding
<bialix> I understand it and can use it if nothing else helps
<bialix> but I'm not very keen to it
<bialix> the very fact that I should bencode my group of options sounds wrong to me, and you?
<vila> sure, I'm talking about a temporary solution there and what is the best trade-off
<bialix> maybe that's why we have our own wheel in the qbzr
<bialix> I can't say
<vila> if/when we reach the point where a config *file* is read once and written once for a given transaction, we get the atomicity back without performance costs
<bialix> vila: I'm going to implement "group" idea for qbzr's pixel settings
<vila> bialix: don't do that with subsections please, you'll make my life harder :-}
<vila> bialix: anything else is fine :D
<bialix> oh no
<bialix> you read my mind
<bialix> where is my tin cap?
<vila> hehe, may be I'm over concerned with compatibility...
<vila> a radical way to address it will be to consider that the new features will be provided for new files only and leave the existing features for the existing files
<bialix> yep
<vila> then one new feature would be to bootstrap the new file from the old one, converting on the fly
<bialix> as I said yesterday I want to extract pixels options into separate zoo
<vila> but it still feels wrong to tell you:"yes, use that, I will remove it soon"
 * bialix nods
<vila> bialix: climb on my rug, I will pull it from under you :D
<bialix> hehe
<vila> except for the multi-line value problem, *sorting* the file on dotted names could address your finding issues...
<vila> and by the way, X resources are also specified with dotted names, so we aren't inventing anything new there
<vila> we're talking about a technic used for years
<vila> decades
<bialix> centuries...
<vila> at least :D
<bialix> I can't resist sorry
<vila> and 'sort -c. -k<n>' is also a good friend to get various sort orders...
<vila> yeah, I know, may not work on windows, but still
<vila> 'bzr config' also accept regexps for NAME... we can imagine adding a sort option there and you wouldn't have to ever look at the file content
<vila> bzr config *size*
<vila> err
<vila> bzr config .*size.* ?
<vila> --scope qbzr
<vila> (NIY)
<bialix> niy?
<vila> Not Implemented Yet
<vila> --scope qbzr that is
<bialix> that all sound good
<bialix> but I think the groups and subsections are really cool
<bialix> I understand your intents
<vila> and *my* concern is that adding support for subsections will make the UI confusing
<bialix> but I see how groups will simplify the things
<bialix> I don't need those subsections to be editable by user
<bialix> so no UI concerns here
<vila> every difference between the data stored in the config files and the way it is accessed is a source of issues
<vila> a basic line in a config file is: 'name =value'
<vila> so far it translates at the UI level by: to refer to an option I use the 'name' I see in the config file
<vila> if you add sections there, it's still valid as long as the sections are used to allow using the same name multiple times but still for the same option
<vila> the sections are then used to decide which context is appropriate (extending the idea from locations.conf where the path defines the context)
<vila> if you use subsections as part of the name, things become blurry
<vila> I want to refer to this option, so wait, what's it's name ?
<vila> s/it's/its/
<vila> commit data is already violating this principle, hence my concerns about it
<vila> overall, I'm trying to *reduce* the number of concepts the user has to deal with, without losing features
<vila> so if dict values can be represented with a set of dotted names sharing the same prefix (the dict name), it's better than forcing the user to specify an option differently whether its value is a scalar or a dict
<vila> *and* we regain control on section names to carry another kind of information
<bialix> I don't understand why commit_data violates this principe
<vila> because it uses section names to implement option names
<bialix> no, it's not
<vila> so we can't use section names for other purposes
<vila> yes it is
<bialix> it uses section name to get atomicity
<vila> go to beginning-of-discussion
<vila> atomicity can be achieved with other means
<vila> and the user shouldn't have to care about it
<bialix> here we call that "hand-made sunset"
<bialix> ok, I understand, you want commit_data to die
<bialix> that's possib;e
<vila> no, I don't want it to die, I want it to be represented differently without losing any other feature
<bialix> bencode everything everywhere everytime
<vila> bialix: have you read configuration.txt in lp:~bzr-core/bzr/devnotes ?
<vila> bialix: no, bencode is user hostile
<vila> bialix: using bencode loses the user-friendly property of being able to read the config files
<bialix> vila: I don't use locations.conf
<bialix> so I don't really care about it
<bialix> honestly
<vila> bialix: that's not the point
<bialix> there are too much config files
<bialix> that bothers me
<vila> bialix: really ?
<bialix> sometimes
<vila> bialix: then what about grouping them into the same config file then ?
<bialix> maxb will complain
<vila> bialix: and use section names to decide which section apply in which case
<vila> bialix: rhaaaa, come on, maxb made it clear that he was referring to option specific to a given user on a given host
<vila> bialix: and options that nobody want to see but still want to be persistent for that matter
<vila> bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins)
<vila> bialix: the bookmarks plugin is a good example here
<vila> it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf
<vila> that's not user friendly !
<vila> if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa
<vila> bialix: what was the last msg you got ?
<vila> jelmer: hi :)
<bialix> vila: [12:01]	<vila>	bialix: and options that nobody want to see but still want to be persistent for that matter
<vila> <vila> bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins)
<vila> <vila> bialix: the bookmarks plugin is a good example here
<vila> * jelmer (~jelmer@a83-163-205-244.adsl.xs4all.nl) has joined #bzr
<vila> * jelmer has quit (Changing host)
<vila> * jelmer (~jelmer@samba/team/jelmer) has joined #bzr
<vila> <vila> it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf
<vila> <vila> that's not user friendly !
<vila> * tchan1 (~tchan@c-69-243-144-187.hsd1.il.comcast.net) has joined #bzr
<vila> <vila> if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa
<bialix> I see
<bialix> whar's the cure?
<bialix> bookmarks might use sections everywhere? no wait, we going away of sections
<jelmer> 'morning vila, bialix
<jelmer> sorry, my VPS is giving me trouble this morning.. now connected directly to IRC :)
<bialix> hey jelmer
<vila> bialix: the cure is to use: 'bzr.bookmarks.mypush' that you can use in every section in locations.conf, in bazaar.conf and in branch.conf
<bialix> vila: I think I don't like them to be in [DEFAULT] section of bazaar.conf
<vila> another problem with dict values: say a user want to modify a single value in the dict, what would be the syntax for 'bzr config' ?
<bialix> just because they're not defaults
<vila> what ?
<bialix> I dunno
<bialix> vila: I think I don't like'bzr.bookmarks.mypush' to be in [DEFAULT] section of bazaar.conf just because they're not defaults
<bialix> I dunno re dicts
 * bialix has to press enter not so many times
<vila> bialix: if they are defined in bazaar.conf *empty* section ([DEFAULT] is nothing more that an alias for an empty section in branch.conf that's why I want to get rid of it ([DEFAULT] in bazaar.conf that is))
<vila> bialix: then they defined the default value for the bookmark if it's not defined anywhere else
<vila> so it *is* a default
<vila> if it's defined in branch.conf, it takes precedence
<bialix> yes, I know this hack
<vila> I want this hack to become a generalized feature
<bialix> you know, in fact I really like how git works with configs
<vila> and I want to reuse the locations.conf trick for naming sections as paths but allow it in bazaar.conf to define default values as opposed to overriding values in locations.conf
<bialix> in git qbzr.foo means [qbzr] section and option foo
<vila> I dunno how it works in git, tell me
<vila> that's exactly my proposal, see configuration.txt in devnotes
<bialix> that's how I understand it from their man pages
<bialix> no, you say there should not be sections
<vila> no
<vila> read configuration.txt in devnotes
<vila> I want to use sections, but not for dict values
<vila> and if they are used for dict values I can't use them
<bialix> vila: I'm reading now
<vila> k
<bialix> it said: This means that in the most common cases, the user doesn't need to define any section.
<bialix> also: A section is named by the path it should apply to (more examples below).
<bialix> vila: qbzr has several options that are not very suitable for bazaar.conf
<vila> bialix: I thought we agreed yesterday that these options should stay in their own config file
<vila> Not all config files needs to define sections (in the most common cases, the user doesn't need to define any section)
<vila> I'm not aiming to collect all options in bazaar/branch/tree conf files if they don't fit, and I think the qbzr window options don't fit
<vila> the commit data fits in tree.conf, I don't yet see a case where it would need sections (but I may be wrong there and maybe the colocated branch *relative* path may be useful)
<bialix> ok, enough food for the mind, it's time to get some food for the body
<bialix> vila: I'm sure we can continue our mindstorm later
<vila> bialix: cool, one last thing:
<bialix> I'm too qbzr-centric
<bialix> vila: you want to get a broader picture
<vila> bialix: when I wrote the devnotes doc, I was only considering paths for section names (and mostly absolute paths for that matter)
<bialix> maybe that's why we can't find the common way
<vila> bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since they are no overlap in this case), authentication.conf can use them for server urls or regexps, etc
<vila> bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since there is no overlap in this case), authentication.conf can use them for server urls or regexps, etc
<bialix> k
<vila> bialix: but the basic idea is to not use section names if you can use the name space to achieve the same result
<bialix> there is no rul for all, right?
<vila> bialix: roughly yes, as long as a defined common set of rules is respected by all :D
<bialix> I need to chew your words some time
<vila> one is: option names are valid python identifiers (aka dotted names, no space, no funky stuff, may be even mo unicode if it makes things simpler)
<bialix> no unicode -- that's right
<bialix> but anyway, can I have groups API please?
<jelmer> groups?
<vila> you can build them yourself from get_option_matching('^qbzr.windows.')
<bialix> what's about set?
<bialix> jelmer: we're talking about groups of options
<vila> bialix: or rather, forget about atomicity by considering that we will reach a point where we read/write a conf file once by transaction
<vila> bialix: set ? You mean list values ?
<bialix> no I mean about set options back
<vila> EPARSE
<bialix> write
<bialix> get-set
<bialix> you wrote get_option_matching
<bialix> can I set dict :-D
<bialix> ?
<vila> if the conf file is written once, you don't care about setting each option separately, if you need helpers for that, we can think about it yes
<bialix> (abort write commit group)
<vila> bialix: [conf.set_user_option('qbzr.windows.%' % k, v) for k,v in d.iteritems()]
<bialix> conf.set_user_option_group(mydict-here) :-P
<vila> yes, that's the helper
<vila> but you need to give it a name too
<vila> probably set_user_option_from_dict(name, dict)
<bialix> and it will bencode?
<vila> and only scalars accepted as values in the dict
<vila> nooo
<bialix> I think we stuck around ConfigObj
<vila> good enough for now, no need to change IMHO
<vila> how we *use* it should be better enforced though
<bialix> that's what I mean
<bialix> it has many features
<bialix> but some of them are not good enough or de-jure prohibited
<vila> yup
<bialix> but not de-facto
<vila> but that's part of the evolutionary process, you start using/testing and change your mind along the way
<bialix> ok
<vila> many plugins poke under the cover because the proposed features were too limited
<vila> I'm trying to summarize all the current needs so we can propose a better evolution
<bialix> that's good
<bialix> I hope shaggy qbzr needs gave you many food
<alf> Hi, is there an easy way to change the nicknames of the commits in a branch (eg because I decided to rename a branch)?
<vila> bialix: yup, very good feedback !
<vila> alf: no, but further commits will respect the new nick
<vila> alf: revisions are immutable, if you want to change them, you need to create new ones
<vila> alf: they are immutable because it means they can be shared and everybody can refer to them by their ID and have the guarantee that they are talking about the same thing
<vila> alf: so you can't change that thing without losing this property
<alf> vila: sure, but the branch I am working on is still local/private...
<alf> vila: could the rebase plugin help here?
<vila> alf: sure, rebase will create *new* revisions
<vila> if don't know if you can change *just* the nickname from the available UI, but rebasing is the way to go for that kind of change
<alf> vila: thanks, although I cannot make rebase to work. When I try to rebase the existing revisions in a branch after having changed the nick it just says "Base branch is descendant of current branch. Pulling instead"
<alf> vila: which makes sense, of course, but doesn't fit my needs in this case
<vila> alf: right, that's... yeah, exactly
<vila> alf: file a bug
<vila> alf: out of curiosity, why does the nick matters in your case ?
<alf> vila: just being pedantic, really :)
<vila> alf: ok, np, I am pedantic myself on occasions ;)
<jelmer> vila: are there still plans to switch to Tarmac at some point?
<vila> jelmer: yes
<vila> jelmer: we were supposed to do that back in Dallas and then... it didn't happen ;)
<jelmer> vila: ah, ok
<jelmer> vila: whoa, 33893 unit tests...
<vila> ...and counting ;D
<vila> jelmer: http://babune.ladeuil.net:24842/job/selftest-lang-C/25/testReport/ says 125,095 tests :D
<vila> and some slaves are missing in this run ;)
<vila> ...and that's without any plugins of course
<vila> jelmer: but back to your remark, was there a recent increase because you managed to better plug the foreign tests ?
<vila> jelmer: or are they already well plugged and you just noticed the number ?
<jelmer> vila: yeah, this is partially because of the per_{workingtree,branch,repository} tests now running against the foreign plugins
<jelmer> I think that accounts for a couple of thousand tests
<jelmer> now to get them all passing..
<jelmer> oh, and we do stuff like this:
<jelmer> bzrlib.plugins.upload.tests.test_upload.TestBranchUploadLocations.test_set_push_location(HgWorkingTreeFormat)
<vila> jelmer: O_O
<vila> jelmer: fun ahead :D
<vila> jelmer: if the end result is that suddenly upload works for svn, hg and it trees... that would be... an unexpected but interesting side-effect...
<vila> where did that 'g' go ?
<jelmer> vila: Yeah, that'd be nice.. not sure yet how shallow these test failures are
<vila> jelmer: the root cause should be quite clear in upload sources, I was aiming in the same direction as you... getting test parametrization for free from bzr
<vila> jelmer: and that's all I care about, whatever the way it's achieved
<jelmer> vila: yeah, this is really neat
<jelmer> I've already discovered some things that would be genuine bugs
<vila> bingo !
<maxb> So, anyone want to look at something weird?
<maxb> There's a bzr-builddeb test that fails in the daily PPA, but not for me locally
<maxb> Also, I have replaced my bzr-cvsps-import MP with two new ones that supersede it
 * jelmer tries to run the bzr-builddeb tests
<jelmer> maxb: Runs fine here too - what's the error in the daily PPA?
<maxb> TestMergeUpstream.test_smoke_renamed_file fails in a way I do not really understand
<maxb>   File "/build/buildd/bzr-builddeb-2.6+bzr526~natty1/merge_upstream.py", line 96, in changelog_add_new_version
<maxb> OSError: [Errno 2] No such file or directory
<jelmer> maxb: Hmm, no idea at a first glance..
<jelmer> maxb: r=me for your bzr-cvsps-import MPs
<wgrant> What's the conventional way to initialise plugins in a script?
<wgrant> Just call bzrlib.plugin.load_plugins() after the imports?
<jelmer> wgrant: yep
<wgrant> jelmer: Thanks.
<vila> wgrant: still up ???
<wgrant> vila: Yes.
<vila> wgrant: oh my, I wanted to ask you to keep an eye on package imports fallouts once I deploy a new driver there, but you will never wake up tomorrow :D
<vila> wgrant: err, I mean, any potential fallouts on the lp side
<wgrant> vila: What are you changing?
<vila> wgrant: the mass_import.py script which should not change anything regarding launchpad, so you're not supposed to see anything unsual
<vila> wgrant: and since I didn't hear rumours about a debian release, you may in fact see nothing at all, but just in case I wanted you to be aware of the change
<wgrant> Haha.
<wgrant> Thanks.
<vila> jelmer: yes, I know, deprecating symbols is a pita
<jelmer> vila: hmm?
<vila> jelmer: oh, you haven't seen my last review yet :)
<vila> jelmer: and thanks for yours by the way !
<jelmer> ah :)
<jelmer> thanks for the review(s), much appreciated :)
<jelmer> only one branch left before being able to move the weave formats into a plugin..
<vila> \O/
<vila> one last test before pulling the new driver for the package importer
<jelmer> niice
<vila> ok, imports failed, test succeeded :D
<vila> yes, the test was to collect the failures ;)
<wam> How do I save credentials when using bzr+https so that the next bzr up or bzr commit won't ask me again?
 * jdobrien is back from kneeling in the dirt
<jdobrien> oops
<maxb> wam: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html should tell you what  you need to know
<wam> ah - authentication.conf. I just read about it as a feature-request.
<wam> thanks. I'll try
<wam> or is this 2.4 only?
<maxb> no, it is fairly old
<wam> nice, thanks
<cr3> what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :(
<wam> maxb: yeah, works smoothly, although the scheme bzr+https is not recognized in my 2.2. But that's not requried. Any scheme will do. thanks again
<maxb> wam: hmm. Does it support https: ?
<wam> maxb: positive
<maxb> wam: Hmm. It's definitely supposed to support bzr+https:
<catphish> i was just about to ask about bzr+https
<catphish> it doesn't seem to work well
<catphish> i think there's a problem with python 2.6 + pycurl + bzr+https
<catphish> which seems to be killing my attempts to use it
<wam> dunno about pycurl, but it runs smoothly for me
<catphish> https://bugs.launchpad.net/bzr/+bug/241698
<catphish> https://bugs.launchpad.net/bzr/+bug/365874
<catphish> that's the problem i'm having
<catphish> it seems to affect only the combination of smart http + SSL + basic auth
<catphish> but that's the configuration i need to use :(
<maxb> catphish: have you tried uninstalling pycurl so that it uses urllib?
<catphish> maxb: i'm told it can be made to work using https+urllib://
<catphish> but that doesn't seem to try to use the smart protocol
<catphish> yes, it seems to work when pycurl is uninstalled
<catphish> that's annoying
<vila> wam, maxb: https is the scheme to be used in authentication.conf when using either https or bzr+https
<catphish> (not annoying that it works, but it would be nice if there were some other way to stop it using pycurl)
<vila> bug #241698, ubot, tell me more
<ubot5> Launchpad bug 241698 in Bazaar "POST to authenticating proxy causes "necessary data rewind wasn't possible" error (dup-of: 365874)" [Medium,Confirmed] https://launchpad.net/bugs/241698
<ubot5> Launchpad bug 365874 in Bazaar "curl error: necessary data rewind wasn't possible" [Medium,Confirmed] https://launchpad.net/bugs/365874
<catphish> ubot5 is on the ball
<vila> catphish: did you read the bug reports ?
<vila> catphish: can you provide a .bzr.log while running a failing command with -Dhttp as an additional parameter ?
<vila> vila: did you check your inbox ?
<catphish> what does -Dhttp do?
<vila> err, wait
<vila> catphish: it will output a transcript of the http dialog in .bzr.log
<catphish> ah
<vila> catphish: for debug purposes
<vila> catphish: so you didn't read the bugs comments then ?
<catphish> i read much of it
<catphish> but got distracted by someone else talking about it here
 * wam winks
<catphish> vila: http://paste.codebasehq.com/pastes/cx5364v4fo26
<vila> catphish: but first, what bzr version are you using ?
<catphish> 2.1.1, python 2.6.5
<vila> nginx/0.7.65
<vila> ouch, 2.1.1.. OS ?
<catphish> ubuntu 10.04
<catphish> User-Agent: bzr/2.1.1 (pycurl: libcurl/7.19.7 GnuTLS/2.8.5 zlib/1.2.3.3 libidn/1.15)
<catphish> seems to be what ubuntu installs by default, and therefore annoyingly what users are likely to have
<vila> sudo add-apt-repository ppa:bzr/ppa will give you access to the latest and greatest stable versions of bzr itself and a bunch of plugins
<wam> oh damn - i always used virtualenv + easy_install ;)
<vila> why, do simple things when you can do complicated ones instead ;-D
<vila> wam, catphish: But my suspicion will be against nginx
<vila> wait, you're in touch with the admins there right ?
<catphish> i am the admin there, thats why i'm trying to make this work :)
<vila> cool, one less hop in the loop
<catphish> and ideally trying to make it work against the old version of bzr that ships with ubuntu
<wam> catphish: i just did setup this: http://thomaslow.com/2011/01/24/configure-redmine-advanced-bazaar-integration/
<wam> catphish: works perfectly, but you need 2.2
<wam> or you'll get a error that bzr can't understand what 401 means.
<catphish> yeah, though you can work around that by specitying the username in the url
<wam> ah
<catphish> bzr+http://username@server
<wam> interesting
<catphish> it prompts you for the password before making the first request
<catphish> so no 401
<wam> catphish: are you going with redmine or is that just so that bzr+http works?
<catphish> redmine sounds like a competitor
<catphish> :)
<wam> i see
<vila> catphish: first things first: bzr+ssh is not an option ? Easier to setup (well, for some values of easier), guaranteed to work
<catphish> bzr+ssh will work
<catphish> i just want http(s) to work too
<vila> k
<catphish> and http works fine
<vila> ook
<catphish> it's just when ssl is enabled it throws this odd error
<catphish> and only when pycurl is installed
<catphish> but annoyingly that seems to be how ubuntu is set up
<catphish> so id like to be able to work around it
<catphish> either with a different URL or by adding headers at the server sidew
<catphish> *side
<vila> catphish: so, from my dusted memory, the issue was that somewhere in the stack (curl or ssl) someone was trying to seek the a file handle backwards which broke upper levels
<catphish> ah
<catphish> is there a way simply to disable pycurl?
<vila> catphish: the immediate workaround would be bzr+https+urllib:// but this would mean that the certificate is not checked anymore
<catphish> i tried that first, but it doesn't seem to recognise the protocol name
<catphish> bzr: ERROR: Unsupported protocol for url "bzr+https+urllib://charlie@test.codebase4.com/test-repositories/bzr1.bzr"
<vila> shudder
<wam> right, i get that rewind bug too with ubuntu's 2.1
<vila> wam: so you confirm it's fixed in 2.2 then ?
<catphish> i realise its my own fault for using 2.1
<catphish> but lots of my customers will :(
<wam> at least it's fixed with my easy_installed 2.2
<vila> catphish: sure, not your fault
<wam> ah no
<wam> 2.3
<wam> is what i have now
<wam> it's definitively fixed with 2.3
<vila> catphish: but it's hard to fix bugs in old releases *and* get them deployed
<wam> AND it works with Bazaar (bzr) 2.2b2 - which comes from ubuntu maverick
<vila> catphish: we're working on it though, there is  a SRU in the pipes for 2.2, once we get that done... we *may* try one for 2.1
<wam> maybe you can backport this package from 10.10
<vila> that's what the ppa offers
<catphish> any idea if i can do anything server side here?
<catphish> or in the url
<vila> catphish: stop using authentication may address the problem but I doubt you'll like that ;)
<wam> catphish: are all clients yours and are they all ubuntu?
<vila> catphish: seriously, it's a client-side issue
<catphish> the clients are not under my control, they could be running anything
<wam> k
<catphish> i'm just trying to maximize compatibility
<vila> catphish: will they *require* certificate validation ?
<catphish> vila: no
<vila> then urllib should work around the issue,
<catphish> they just feel better if it says https
<vila> shudder
<catphish> indeed
<catphish> is there a pay to persuade it to use bzr+https+urllib?
<vila> damn, where did my defaultToUrllib plugin go ?
<catphish> failing that i will have to tell people to upgrade and/or remove pycurl
<catphish> and/or drop SSL support for a few months
<maxb> It would be nice if we had a more structured approach to the url scheme decorators, such that arbitrary combinations were valid
<catphish> is it just a hardcoded list at the moment?
<vila> catphish: http://paste.ubuntu.com/571783/
<vila> put that in ~/.bazaar/plugins/defaultToUrllib.py
<vila> maxb: sure, with automatic tests :)
<vila> maxb: unfortunately it's a bit more complex than it appears :-/
<vila> maxb: but I agree it would be nice
<catphish> vila: that works like magic :)
<vila> cool
<catphish> i can probably distribute that
<vila> catphish: but keep in mind that it won't verify certificates
<catphish> that's annoying but IMO less so than telling people they can't use SSL
<vila> catphish: it's GPLed
<catphish> i saw
<catphish> i'll distribute it independently anyway
<vila> I never bothered to publish it (and I don't use it anymor eeither 8-)
<vila> wam:, ha he's gone :-/
<vila> jelmer: what's up with get_module() ? It can returns a *name* or a *module* ? Sounds confusing from the diff, should I review in context or can you answer ?
<jelmer> vila: it returns the name of the module
<jelmer> vila: Though I can understand how that's a bit vague in the current docstring
<vila> Haaaa, always the name, ok
<vila> I don't use __module__ every day :)
<vila> oooh, I'm not even sure I *knew* about module... how cute...
<vila> errr, how come I'm reviewing a mp already marked as superseded >-/
<jelmer> https://code.launchpad.net/~jelmer/bzr/per-interrepo-extra/+merge/51166 is the active one
<vila> yup, figured that now ;)
<vila> I should have think about instead of blaming the 4th dimension...
<fullermd> Lousy 4th dimension.  Somehow I never have time to give it the whippin' it deserves.
<vila> fullermd: ha ! here you are ! Hello :)
<fullermd> I am!  Oh!  There I are.
<epoxy> hello. if I 'bzr add' in a directory. then I remove the files with 'rm' (not bzr rm).. when I commit, will the files I 'rm' still be commited or will I get any errors?
<epoxy> ah I think bzr status and diff answer that.
<danielsh> I init'd a tree yesterday.  I'd like to rewrite history such that the root of the tree is now a subdir (eg, /README now becomes foo/README, with 'foo' a child of the tree root.)
<danielsh> currently it seems to me that fast-export is the way to go,
<danielsh> are there other/better options?
 * danielsh (FTR, fast-export did it with some manual massaging of the stream.)
 * danielsh afk
 * danielsh (back later)
<maxb> danielsh: Hi. Wouldn't it have been simpler to just move all the content into a subdir?
<fullermd> Well you really need a pivot_root command.
<vila> jelmer: do you have the bzr kanban URL handy ? The ones in my history seem to be 404'ing O_0
<maxb> vila: This one? http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
<vila> maxb: Indeed ! Thanks ! I was totally on the bad track (devpad...)
<wolter> is there documentation on the bzrlib.option module? I cound't find any yesterday
<vila> wolter: pydoc bzlib.option
<vila> ... again.... why don't I just use completion as ping-check...
<vila> and mgz did that just to point out the flow in my logic... I'm sure !
<fullermd> At least he didn't point out the flaw in your logic   :p
<vila> fullermd: that's the most devastating thing you could have said at this precise moment :-(
 * vila kicks off Marvin: "Don't ever touch this keyboard again !"
<vila> :D
<vila> still 4444 imports to go at http://package-import.ubuntu.com/status/
<vila> now that's a number
<vila> composed with the most delicates power of 2 represent as often as itself
<vila> ted, represented
<fullermd> Not only that, but the sum of them is a power of 2 too.  And it's the power of 2 represented by the digits themselves.
 * vila sudo importer kill -9
<vila> an oasis of beauty in an ocean of bits
<fullermd> Their product maxes out a byte, too.  Which would be the bits numbered by the sum of the number of digits and the digit itself.
<fullermd> And if you round off its square root, you get a quad-repeat of digits too; 66.66.
<vila> OMG, the hidden perfection ! Nobody knew it and it just appeared from the middle of nowhere 8-)
<vila> and now it's gone... impermanence..
<fullermd> Halfway between the two would obviously be 555.5.  If we take that as a product and a subtraction, we get 5*5*5-5 = 120.
<vila> only to be replaced by 4411 hehe
<fullermd> Dividing that by the 66.66, we get another nice repeating series: 1.800180018001800...
<fullermd> Take that 1800 away from our original 4444, and we get 2644; back with the 4's, and this time they're the average of the preceeding digits.
<vila> hey, you seem to ob your way for the infamous five 5 games: with the usual operators and using the five 5, find all the integers starting from 0 and going as far as you can :)
<vila> s/ob/on/
<vila> s/ob/be on/ tyops while re-reading, the next level
<vila> something weird is going on... with the net
<fullermd> Probably needs to be rebooted.
<vila> or shutdown to stay on the safe side
<vila> I still suspect Morris to plan a come-back one of these days...
<lamalex> Hi, I got a merge conflict and was wondering if there was anyway way to tell bzr to just throw out the incoming changes and use the in tree version whole hog
<james_w`> lamalex, "bzr revert file"
<lifeless> 'bzr revert .'
<james_w`> lamalex, "bzr revert ." for all files
 * lifeless hi fives james_w` 
<danielsh> maxb: morning. it would have worked, but I wanted to rewrite the 5 revisions' worth of history, too.
<lamalex> thanks james_w`
<lifeless> james_w`: also, your ` is showing.
<james_w`> ooo-err missus
<caravel> hi everybody
<caravel> PREAMBLE I'm not trying to troll, okay ? I need to underand a few things :)
<spiv> Hi caravel
<fullermd> Well, that takes all the fun out of it...
<caravel> it's about a web site for a self-employed food company. It was mounted by a friend who has very good marketing and web-art skills, but not that techy
<caravel> (food retail) so he chose Magento then Joomla, tried to glue it all together as he could
<caravel> today we end up with a MASSIVE amount of files, and to be honest, some kind of a mess
<caravel> we're getting close to th0s channel topic, please be patient :)
<caravel> So... 29,000 files on the hosting, including lots of stuff that should be removed. I'm family related to the retail shop, and try to enforce a few things, such as ... a VCS of course. So far, he's been hacking the hosted prod server directly ! Just learned this, he had "let us understand" that he was using sme dev copy on his laptop. Well, this was not the case
<caravel> Anyway. More than 1 year ago, I had suggedted he'd look at bzr
<caravel> he just did and said he had some head aches during HOURS, that bzr doesn't take so many files (apparently, he tried to feed the entire site in bzr !?!)
<caravel> And in the same email, announced that he had setup hg. Well, I was a Ubuntu user for long, now I'm on Fedora KDE by choice, but I'm still scared of hg
<caravel> https://developer.mozilla.org/en/Mercurial_basics
<caravel> So I tried to explain that. He agrees to let me try, my turn. I'm a rather very strange programmer (niche market for 15 years, xml stuff), don't have web-dev experience
<caravel> So I have a few questions. Thanks for having read so far, I'll start now :) </PREAMBLE>
<lifeless> bzr should hangle 29K files
<lifeless> we've testing up to 100K if I remember correctly
<caravel> lifeless: I suppose so, and even many more
<caravel> right
<caravel> he didn't even tried the command line !!! he wrote something like "it just closed with no message", so he was using the GUI
<caravel> but I'm glad to get some confrmation already, found it so strange
<caravel> next... anyone here is using bzr for such a webapps repo ?
<lifeless> We do the development for the launchpad.net website using bzr
<lifeless> 8K files
<caravel> does it make ANY sense at all, to store 29,000 files from Mage, Joomla, whatever plugins such as JFusion, FlexiContents, PhocaGallery and so on, in a VCS ?
 * caravel assumes it does NOT
<caravel> I've worked a lot as a tech lead with CVS and SVN, and I sometimes HAD to include a few libs "external to the project" in my own tree, but that was exceptional and due to specific integration processes
<lifeless> so, you can do it
<lifeless> but a little more structure would probably be better
<lifeless> one project per thing - mage, joomla, etc
<caravel> lifeless: yes, sure -- there are "source ours" in each app, so of course we need that
<caravel> I just can't pronounce myself globally since I never used a VCS in such context
<caravel> can you tell me how you do this briefly ? is there any useful tip that will permit to "bzr update" and push only specific files, even being able to push directly the changes eg. to the prod server... but avoiding "manual installation steps" hence working with bzr of our real, respective (local) LAMP stacks on a day to day basis ?
<caravel> I can only assume that's why he tried it this way (and I know already I'm the one who will have to identify each default/custom resource, since it's obvious he doesn't know precisely. That explains it all, and oh well, that's okay. ^^ )
<spiv> bzr is fine with that many files, but it can consume a lot of memory if you have individual large files.
<caravel> spiv: yes, I'm guessing it had issues on the image tree -- by luck, vids are externalized ;-)
<spiv> If you want to push only specific files, I'd try what lifeless says: break it down into multiple branches, one per project or whatever the natural boundary is for you.
<caravel> my question is : is this practicle to set the repo at the LAMP root, add use it to manage only "our" custom files across the tree ? (never done this in my VCS projects, always "whole" tree, never had to ask me that question)
<caravel> *add -> and
<caravel> so we could gently tag, update/branch and push our files only, just like a "mask" on the whole thing ?
<lifeless> caravel: certainly. you can use 'bzr ignore' to ignore files you got from elsewhere.
<lifeless> or 'bzr ignore \*' to ignore everything, and then 'bzr add' specific things.
<caravel> lifeless: thanks. so we can even recursively add stuff while ignoring other. Sounds as simple as expected. I'll take it from there. Thanks a LOT for your time, people.
 * caravel 's thankful to spiv and lifeless (everyone deserves having his/her life back). Did fullermd have some fun anyway ? ;-)
<BlazingSun> hi, anyone there familiar with bzr+ssh and working with multiple users?
<BlazingSun> on the same branch
<caravel> BlazingSun: tested this last year, seemed to work great, but I had to simulate all users so my tests were rather rudimentary and not so simultaneous
<BlazingSun> i am trying for a few hours now, but setting the sticky-bit doesnt seem to affect newly created branches
<BlazingSun> so only the "branch-owner" has write acess, all others only get read-access
 * caravel should better leave before harming anyone with wrong answers
<BlazingSun> ah i am using debian6 btw
<caravel> BlazingSun: oh
<caravel> BlazingSun: that should NOT be related to bzr, right ?
<caravel> BlazingSun: but to ssh users and permissions
<BlazingSun> caravel: i am not sure, could be
 * caravel uses Debian also, but Lenny only (=stable, 5)
<caravel> BlazingSun:  you are using distinct logins for each user, right ?
<BlazingSun> sure
<BlazingSun> but they share the same group, called bazaar
<BlazingSun> permissions are drwxrws---
<caravel> rwx--- at the end, you mean ? ^^
<BlazingSun> nha rws, so newly created branches still have the same group
<BlazingSun> when i set permissions manually everything works right
<BlazingSun> but i need the possibilty that everyone can create new branches and everyone can access them
<BlazingSun> without me setting the permissions everytime
<BlazingSun> hmm i think its the global umask, so nothing bzr related
<BlazingSun> debian has 0022 as the default but most distros use 0002, so i found my error :)
<caravel> BlazingSun: just read again man:chmod, thanks :)
<caravel> BlazingSun: if you use +s, you give the the id of your "bazaar" group, right ?
<BlazingSun> caravel: sure, thats what i was using, but debians umask is 022 not 002 as i ecpected
<caravel> ok, I got it
<BlazingSun> thx anyway for the help
<caravel> BlazingSun: I don't quite get the point of using s over x (and making the tree belong to the bazaar group) ? More than interested in this anwer, our bzr will be shared over SSH/SFTP (on Lenny)
<BlazingSun> caravel:  if someone creates a new branch on the server he will be the owner of the branch, but i need the group to have still permission
<BlazingSun> with the stickybit the group will stay the same
<caravel> BlazingSun: all clear, thanks for your answer ;-)
 * caravel better go and stop take the space for so little
<caravel> night all
<BlazingSun> caravel: cant fight where i can set the global umask thou ^^^n8 then
<caravel> BlazingSun: sorry, was on something else
<caravel> BlazingSun: in your sshd_config ?
<caravel> BlazingSun: man sshd_config doesn't help much, right
<caravel> BlazingSun: Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server' ?
<BlazingSun> caravel: im using ssh not sftp
<caravel> BlazingSun: isn't sftp implicitely used ?
<caravel> this could help you I guess http://serverfault.com/questions/231717/how-to-get-full-control-of-umask-pam-permissions
#bzr 2011-02-25
<caravel> BlazingSun: I'm researching this since I may have the same issue -- we're really off-topic now, we'll be kicked out soon :)
<caravel> BlazingSun: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581434
<BlazingSun> caravel: yeah i found that too, but i cant find where to change the umask
<BlazingSun> caravel: i think bzr+ssh and bzr over sftp are different, not 100%sure thou
 * caravel didn't know about the bzr+ssh prefix ^^ and -- finally, understands BlazingSun ^^
<caravel> BlazingSun: well, my little brain can't see how else that could work
<caravel> have you tried the Subsystem command ? found another one for more recent version of openssh, hold on
<caravel> (since 5.4p1) Subsystem sftp /usr/lib/openssh/sftp-server -u 022
<caravel> BlazingSun: found this too http://forums.debian.net/viewtopic.php?f=30&t=59365#p344998
<caravel> BlazingSun: but really, I think you should ask on #debian :)
<BlazingSun> caravel: yeah if i dont find whats wrong i will probably do
<caravel> BlazingSun: look at /etc/login.def still, see my last link
<caravel> Could anyone confirm everybody, how bzr+ssh works ? Can hardly find any doc about smartserver on official doc, and that's two of us who are interested. Does this not result in using sftp ?
<BlazingSun> caravel: changing umask in login.def didnt change anything
<BlazingSun> caravel: everything working fine, except creating new branches :(
<caravel> BlazingSun: did you try Subsystem and restart sshd ?
<BlazingSun> caravel: not yet
<BlazingSun> caravel: but sftp isnt ssh, as far as i know it only uses the permissions of ssh
<fullermd> sftp is a protocol that runs over ssh.
<fullermd> bzr+ssh doesn't use sftp at all, it just talks to bzr.
<caravel> thanks fullermd: I couldn't find anything about how the "smart server" mode works, from what I read there are basically two instances of bzr talking to each other, hence "optimizing" transfers by doing as much server side work as possible -- so I take it as similar to rsync, right ?
<caravel> is there ANY doc avail any where ? been digging the whole of canonical, yet (I believe !)
<fullermd> Well, insofar as you've got bzr talking to bzr, like rsync talking to rsync.  The protocols don't have any resemblance to each other...
<fullermd> At the protocol level?  I think there are some (probably outdated) docs in the tree...  it's mostly just in the code.
<BlazingSun> fullermd: you have any idea how to get bzr+ssh to work? the write-permission doesnt get set right when creating a new branch. not directly bzr relatet
<BlazingSun> *related
<caravel> fullermd: sure. so who's writing on disk, is this the bzr executable on the server side, and doing the entire rsync-like file combination ? or is it just telling the bzr client what files to upload over sftp ?
<fullermd> No, it's all bzr-bzr.  There's no sftp involved in bzr+ssh.
<fullermd> BlazingSun: What's "not right"?
<caravel> fullermd: ok thanks
<BlazingSun> fullermd: i want to have several users that can access the same branch, but when i create the branch with one, the write-permission for the group does not get set
<BlazingSun> fullermd: so the other users cant push
<BlazingSun> fullermd: seems umask-related
<caravel> fullermd so BlazingSun may face a bzr issue, right ? bzr is the process receiving the user perms from ssh login, and applying them wrongly when writing ?
<fullermd> Creating a new branch follows umask.  You'd need to reset it after creating for group write or the like.
<fullermd> Well, "wrongly" is a matter of perspective.  It's certainly inconvenient in this case.
<BlazingSun> fullermd: i am using debian6 but setting the umask in login.def doesnt change anything
<BlazingSun> fullermd: and cant find any other place, that may overwrite the setting there
<caravel> BlazingSun: tried it first over simple ssh login ?
<BlazingSun> sure
<BlazingSun> same problem
<BlazingSun> everything working, only the w-flag doesnt get set
<fullermd> Got me.  I always just use shell rc files.
<caravel> BlazingSun: look at this : Another solution to set the permissions would be to use dnotify. Create /usr/local/sbin/dnotify_handler-reset_perms.sh script with the following
<caravel> http://serverfault.com/questions/127658/how-do-i-set-permissions-structure-for-multiple-users-editing-multiple-sites-in/127686#127686
<caravel> BlazingSun: fullermd's rc files sound a bit, well, lighter ^^
<fullermd> But not without ugliness.  You probably wouldn't want to permanently wire umask that far open.
<fullermd> At least if the account is used for anything other than bzr.
<caravel> fullermd: right
<BlazingSun> hmm yeah, i only want to have files ctreated in my bzr-repository have rw-flags for the group
<BlazingSun> and i dont want to change them manually for every new branch
<BlazingSun> (changing manually works)
<BlazingSun> i just want that everyone is h his groupable to create new branches and share them wit
<BlazingSun> i just want that everyone is able to create new branches and share them with his group
<caravel> then dnotify may help, again you should ask #debian what to do better, but that should work
<fullermd> As ugly hacks go, you could just setup a chmod in cron to whack it every hour or something.
<caravel> fullermd: ^^ I'll go now, can you confirm there is no official doc about the "SmartServer" mode ?
<BlazingSun> then it wouldnt be instantly
<fullermd> I'm not sure what sort of doc you want...
<caravel> fullermd: user doc for a start
<fullermd> "Use bzr+ssh://whatever and have bzr installed on the server"
<fullermd> 's about all there is...
<caravel> fullermd: right -- so it's just executed by the ssh user, no daemon whatsover running on the host ?
<BlazingSun> not really :(
<fullermd> Yes.
<BlazingSun> hm you dont have to set anything up, but setting permissions right seems a little bit complicated
<fullermd> Much like CVS :ext: mode, etc.
<BlazingSun> im no expert but still have some knowledge and im trying for a few hours now...
<caravel> fullermd: thanks a lot, gotta go now. Bye & BlazingSun, good luck ^^
<BlazingSun> hmm maybe acl would be a solution
<BlazingSun> caravel: gn8
<spiv>  [5~[6~[6~[6~ / .http://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-serverhttp://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-server  is the doc
<spiv> Ugh, bad connection.
<BlazingSun> the doc doesnt mention anything that would help setting up a bzr-system with multiple users
<BlazingSun> over ssh
<caravel> spiv: thanks! I wonder how I could miss it. Before I left I had found this doc also, a bit closer to my search http://wiki.bazaar.canonical.com/Specs/SmartServer Also, BlazingSun's issue would deserve being documented here http://wiki.bazaar.canonical.com/Bzr_and_SSH ...but isn't either. Night'
<spiv> Woo, I have bzr-loom passing tests with bzr.dev and fetching all threads in one operation.
<spiv> Only slightly nasty hackery required :/
<lifeless> spiv: \o/
<lifeless> thats -awesome-
<lifeless> spiv: would you like a job working on bzr ?:)
<spiv> lifeless: right now I'd settle for a working car and less bouts of gastro being brought home by my son... do you think you can arrange that? :)
<spiv> It was a bit thornier to do than I expected, actually.
<lifeless> spiv: let me wave my magic wand
<lifeless> spiv: good test case for the API though, right? ;)
<spiv> It mostly went smoothly, more code deleted than added, etc.
<spiv> Yeah, it was, the API will need a small tweak :)
<spiv> But then the hpss acceptance tests broke...
<spiv> The tension is that we'd like to ask the remote side which heads to fetch: for built-in formats it's tip + tags, but for loom it's different, so we need the ability for loom to give a different answer there.
<spiv> But ideally without adding in an extra round-trip that we didn't need before (for the built-in formats0.
<spiv> So it's easy to add a heads_to_fetch RPC, but usually we don't want to call it because it'll be an extra roundtrip.
<spiv> At the moment I have an ugly hack that looks at the branch format, and if it's a metadir format then it checks the _branch_class.heads_to_fetch, and if it's the same as the base Branch.heads_to_fetch, it just uses that.
<spiv> Otherwise it asks the remote instance.
<spiv> I'm not especially happy with that.  Somehow our layering isn't working so nicely for us: the caching of the tags dict and last-revision-info etc isn't completely automatically accelerating everything that would use them.
<spiv> There's also the aspect where we aren't very clear about where exactly the division of responsibility is for local vs. remote.  Is it up to the client to calculate the heads to fetch by itself, or should the server always be in control?
<spiv> Anyway, I've hacked around this case.   Hopefully we don't need many more like it :)
<lifeless> spiv: why would the receiver know the tags
<lifeless> spiv: I mean - surely the server should be determining the heads
<lifeless> optionally constrained by the client - 'Oh, and I want X also, kthanxfetch'
<lifeless> or 'but not tags today'
<spiv> Well, all of branch/pull/merge fetch tags already today.
<spiv> (And after recent fixes they fetch the revisions those tags refer to as well)
<lifeless> which is great
<spiv> So, currently in lp:bzr, there's no 'heads_to_fetch' RPC or anything like that: it's entirely up to the client to inspect the branch and decide what heads to fetch based on that.
<lifeless> sure
<spiv> I have a branch now that adds a heads_to_fetch method and RPC, and a branch of bzr-loom to override that to add in the threads' heads...
<lifeless> I'm just riffing on the long term concepts
<lifeless> this is great stuff
<spiv> ...but my issue today is that actually using that RPC unconditionally regresses the HPSS call count tests.
<fullermd> That sounds...  oddly backward to my uninformed speculation...
<spiv> fullermd: which part?
<fullermd> Well, the whole 'heads_to_fetch' concept/workflow.
<fullermd> I mean, from the cheap seats (they're very comfortable, thank you) it seems like it's just a single request/response:  "I want branch XYZ, here are the heads I already have"  "OK, your new head is X, and here's a stream of the revs you need to get there"
<fullermd> (I guess even the 'your new head is' bit is technically redundant, but...)
<spiv> There's a couple of issues there.
<fullermd> Jumping through a "what heads should I fetch?"   "OK, now I'll fetch 'em" sounds like a long way to carry the water.
<spiv> One is that "here are the heads of my repo" isn't a cheap operation
<fullermd> Yeah.  But you need to do it anyway (or just accept potentially fetching more than you need; and you could do that in this case too)
<spiv> Arguably it should be, but it isn't and we haven't decided to make the format changes necessary to maintain an up-to-date cache of current heads.
<spiv> Also, sending the remote side "here are all my heads" doesn't necessarily help you at all if the remote side has none of those revisions.
<spiv> e.g. if you are pushing a new revision.
<spiv> Anyway, I think this is actually a bit tangential to the original topic
<spiv> You're talking about how to implement "I want the data for X, and I already have Y"
<spiv> I'm talking about how you determine what X is in the first place.
<spiv> It's not (necessarily) a single revision.
<fullermd> Well, if you're pushing, you're not pulling   :)   I hold dark thoughts about the utility of turning that sort of conceptual symmetry into codepath symmetry.
<fullermd> In my sense, X is the branch, not a rev; passing whatever that calls for can be known by the client saying what it has.  A second pass may be needed to fill in unknown tag revs, but that's a 1% (if that) case that I'd be perfectly happy to punt to extra RTT's when needed.
<spiv> Also, it's not hard to construct plausible scenarios where two repos have 99% of their graph in common, but have zero overlap in their heads.
<fullermd> But yeah, it's all tangential.
<spiv> It might be nice to have RPCs that work along those lines.
<spiv> Stacking would complicate it somewhat.
<fullermd> That falls into "what cases do you optimize for".  Anyway.  It just Seems To Me(tm) that having the client try and grab both graphs and combine them is a lot of indirection, compared to both sides talking graph subsets at each other until one or the other finds a common point.
<spiv> (Not to mention the friction with the current bzrlib APIs, although perhaps that will change)
<fullermd> Especially since the 90% (99%?) case of pull would be right there when the client first says 'hey, here's my current head'.
<spiv> Both sides do talk graph subsets to each other, take a look at the get_parent_map RPC.
<fullermd> That, too.  This is where us non-OO personages leave the train   :p
<spiv> And we already cope with the 9x% case of pull just fine :P
<jelmer> maxb: bzr-svn should be compatible with older versions of bzr
<jelmer> maxb: if it's not, that's a bug
<maxb> jelmer: hmm?
<jelmer> maxb: Also, do you know about debian/update-deps.py ?
<maxb> jelmer: Ah, you're referring to my packaging branch commit? My *intention* was to add 2.4 as compatible in debian/control, not disown compatibility with previous versions
<maxb> I did not know about debian/update-deps.py, though I appear to have updated manually to the same end result
<jelmer> yeah, it does things like preserve ordering
<vila> wow, I thought it was due to some bug but we really have an import consuming 4.6GB :-/ (nexuiz-data)
<vila> no time to investigate now
<jelmer> that's a very large package
<jelmer> the binary package alone is a couple of hundred Mb
<vila> jelmer: if we the host replacing jubany has less memory, we'll have a serious problem
<jelmer> vila: It's unfortunate some things scale with the size of the tree at the moment :-(
<vila> jelmer: could be, but I suspect there is more than the tree size involved here
<jelmer> vila: it doesn't seem coincidental that this is one of the largest source packages in Debian/Ubuntu that's causing us problems
<vila> right, as I said in bug #724890, this needs more investigations than I can provide right nwo
<ubot5> Launchpad bug 724890 in Ubuntu Distributed Development "excessive memory consumption for nexuiz-data" [Critical,Confirmed] https://launchpad.net/bugs/724890
<jelmer> the size of the compressed tree is 1G
 * jelmer comments on the bug
<vila> jelmer: thanks !
<vila> jelmer: may be worth bubbling up to the losas, the migration is planned for 1st March and I'll be in vacations starting in a few hours, I'd like to concentrate on filing bugs about what I've seen yesterday experimenting with the new driver
<jml> what's the difference between switch and update?
<jml> or, actually what I mean is,
<jml> a friend of mine has pushed a feature branch over the top of trunk rather than merging it in, he wants to get trunk back...
<jml> I'm telling him to use 'bzr heads' to get the revid of the trunk tip
<jml> and now I'm about to tell him to run something with that revid
<jml> but I don't know whether that should be 'switch' or 'update'
<jml> (also, is there a FAQ for this? it seems like a common rookie mistake)
 * jelmer waves to jml
<jml> jelmer: hi
<jelmer> jml: I'm not aware of an FAQ for it, but you're right that there probably should be one.
<jelmer> "bzr update -r" seems like the right solution now
<jml> jelmer: thanks.
<jelmer> I've always used "bzr pull --overwrite -r<revid> ." previously
<jelmer> but that's not really intuitive
<jml> so many ways to do what feels like the same thing.
<jelmer> jml: "echo revid > .bzr/branch/last-revision" ? :)
<jml> :)
<maxb> jml: update: change the revno of a working tree; switch: change the branch and revno of a working tree
<jml> maxb: I guess that means switch is a superset of update
<maxb> yes
<jelmer> not entirely, "bzr up" without arguments will update the working tree
<jelmer> I don't think if you give switch the current revision it will touch the working tree, even if it is out of date
<maxb> If a feature branch has been pushed (without --overwrite) into trunk then `bzr heads` will not help, as the old head of trunk will no longer be a head
<jelmer> maxb: "bzr heads --dead" should still show it
<jelmer> ah, sorry
 * jelmer should learn to read
<jelmer> maxb: Sorry, that's the second time this morning.
<maxb> :-)
<maxb> More coffee needed?
<jelmer> I guess so :)
<jml> maxb: so how do I figure it out then?
<maxb> I'd fire up qlog
<maxb> And locate the second parent of the last merge from trunk into the feature branch.
<vila> jelmer: I've got a fix up for review regarding the import driver getting killed by an exception from a import thread
<vila> jelmer: I would love to leave for vacations (RSN now ;) with such a fix landed on jubany
<vila> jelmer: but no pressure really ;D
<jelmer> vila: hehe
<jelmer> vila: happy to have a look
<jelmer> we really should make udd a part of the "bazaar" superproject..
<vila> https://code.launchpad.net/~vila/udd/724898-driver-catch-importer-exceptions/+merge/51284
<vila> jelmer: for the reviews you mean ? Cos' I'm thinking about turning it into a bzr plugin too... ;)
<jelmer> vila: yeah - my life is driven by http://code.launchpad.net/bazaar/+activereviews
<vila> I was suspecting that and I think we should change the patch pilot instructions to switch to that page too
<vila> if only to be aware of the mp we're missing therre otherwise
<jelmer> vila: Yeah, I think that'd be useful
<vila> jelmer: Thanks for the review !
<vila> jelmer: I've landed it on jubany but I feel bad asking for a restart while nexuiz-data has already run for 165 mins CPU
<vila> jelmer: could you check it once in a while (while == day will be enough) and ask a losa to restart it then ?
<jelmer> vila: ok
<vila> jelmer: 1e6 thanks :)
<jelmer> :)
<jelmer> vila: I guess it'll be quiet early next week then :-/
<vila> jelmer: hmm, yeah, forgot to mention that: you're the house keeper, so please don't forget the spider webs in the attic :-D
<jelmer> hehe
<vila> jelmer: and here are some votes for your mps: +1 +1 +1 +1 +1, use them wisely ;D
<jelmer> vila: lol :)
<montywi> vila: after 2600 minutes, I got this from bzr check: http://monty.pastebin.com/zZRryR4R
<montywi> (internal error)
<vila> montywi: that's just ... file a bug please :-( I don't remember off-hand if the check order has changed in more recent versions but I suspect this one could reported far earlier
<vila> the revision seems a bit old, tht's even more worrying
<vila> it's even from the initial migration, how odd
<vila> montywi: but above all check shouldn't fail with an internal error :-(
<vila> montywi: I won't be able to do anything, I'm leaving for a one week vacation but keep this repo safe
<montywi> will do
<montywi> thanks
<burli> hi
<burli> I want to use Bazaar on Lauchpad, but I have problems to setup launchpad and my computer
<alf> burli: What exactly is the problem?
<burli> ok, I have a launchpad account and I add an OpenPGP and SSH Key
<burli> But if I try to create a branch I got just something that starts with /+junk/
<burli> like this https://code.launchpad.net/~mb-embedit/+junk/mystock
<alf> burli: +junk is the prefix for personal branches (not associated with a project), so this is normal
<alf> burli: https://code.launchpad.net/~mb-embedit/+junk/mystock is empty though, have you pushed something to it?
<burli> alf, right
<burli> I want to push something into it
<burli> what is my user id??
<burli> bzr launchpad-login userid
<alf> burli: mb-embedit
<burli> ah, without ~
<burli> damn
<burli> what can I do if I use different computers or make a new installation?
<burli> Can I take the keys with me? Or Import the Keys?
<burli> I don't really understand the concept of OpenPGP or SSH Keys
<alf> burli: yes, you can copy the keys if you like, but you can also register multiple keys in Launchpad, too
<burli> Its a little bit confusing for me
<burli> brb
<burli> alf, I think it works now
<alf> burli: great :)
<burli> alf, another question. I want to fork a project and I want to merge changes from the original project. I create a clone, run "bzr pull" in the original project and than "bzr merge" in my fork. Now I have some conflicts.
<jelmer> vila: we need a Debian GNU/kFreeBSD vm in babune :)
 * jelmer was just made aware of some test failures
<burli> I have now some files like *.BASE, *.in, *.OTHER and *.THIS
<burli> what should I do now?
<burli> ah, resolve
<jelmer> burli: resolve the conflicts by editing the file/overwriting it with one of the *.{BASE,OTHER,THIS} files and then run bzr resolved
<burli> jelmer, thx. done
<alf> burli: yes, and note that *.in is a normal source file, not produced by the conflict
<burli> I guess, I got it.... I hope so
<cr3> what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :(
<jelmer> cr3: hi Marc
<jelmer> cr3: Unfortunately if the branches don't have any related history we don't really have any better alternatives at the moment.
<cr3> jelmer: darn, using patch is unfortunately error prone, like permissions not being preserved and so forth
<jelmer> cr3: We're aware of the problem and would really like to fix it (it's common in the UDD use case, where upstream, debian and ubuntu all have different imports of essentially the same data)
<cr3> jelmer: I'm sure if it's not implemented yet there's a good reason, like very complicated problem to solve :) I wish you best of luck solving that problem then!
<jelmer> it's a very hard problem to solve right, but we could at least provide you some tools to make it a bit less painful
<burli> can I make a private bazaar branch on launchpad?
<jelmer> burli: only with a commercial launchpad subscription
<burli> hm
<burli> is it possible to install my own bazaar server? I have one project, that is not public, but I want to use bazaar for versioning
<jelmer> burli: yes, you can run your own server using bzr itself and set up a web interface using loggerhead
<briandealwis> hi jelmer.  Is there a bzr-svn newer than 1.0.4?   bzr 2.3.0 complains about api versions with 1.0.4
<jelmer> briandealwis: there is going to be a 1.1.0, but it's not out yet
<briandealwis> ahok
<burli> jelmer, is there a documentation/tutorial how to install/setup such a server?
<briandealwis> burli: see the docs.  http://doc.bazaar.canonical.com/latest/en/user-guide/server.html
<burli> briandealwis, thx
<burli> is there any problem if I use different versions of bzr? My server is running Maverick and on some computers I run Natty
 * jelmer heads off for some weekend
<maxb> hrm
<maxb> subvertpy appears to be repeatably segfaulting in its tests on maverick/amd64
<mgz> jam or someone, does this diff actually make any sense?
<mgz> http://www.physics.drexel.edu/~wking/code/git/gitweb.cgi?p=be.git;a=commitdiff;h=1e0967ab82d8541413e1dfe4d2e78f1008aa9c5b;hp=6eeb62d99a40f8644ac0840ac1291ef92b3d836f
<mgz> as the path is always inside the repo, won't the base_tree and tree always be the same, so he *could* just omit the 'file_ids_from' param?
<mgz> ...there is no jam.
<mgz> ...that doesn't make any sense, why did I type that...
<lifeless> the shadow knows
<mgz> meh, I've never known the c standard that well anyway.
<burli> hm, what's wrong? I created on my server a new bzr project with bzr init. I can create a branch on different computers, can pull and push. everything works. But the project folder on the server is empty
<Peng> burli: It's not empty; it has a .bzr directory full of data. It just doesn't have a working tree.
<burli> Peng, ah, ok, thx
#bzr 2011-02-26
<lifeless> jelmer: why https://code.launchpad.net/~testing-cabal/ubuntu/natty/testrepository/daily-build-packaging
<lifeless> rather than bzr+ssh://bazaar.launchpad.net/~testrepository/debian/sid/python-testrepository/sid/
<lifeless> in https://code.launchpad.net/~testing-cabal/+recipe/testrepository-daily
<kgoetz> hi all. does bzr have an interactive commit (or some way of faking it)? i'm about to merge two branches, and was hoping to avoid conflicts and associated messing around
<kgoetz> ah, merge -i might be it
<kgoetz> does this look like my terminal corrutping the message, or bzr getting the printing wrong? 'Merge phase 2/3olution pass 1/10 0/19\
<kgoetz> ah, worked it out, sorry all
<lifeless> that looks like a bug
<lifeless> I thought they had all been squashed
<kgoetz> probably because i was accidentally piping into vi -, so strangeness probably resulted fro that
<jelmer> lifeless: I didn't set up the original packaging branches
<mathrick> hiya
<mathrick> bzr-svn fails with unicode errors again in the daily ppa: http://launchpadlibrarian.net/65112532/buildlog_ubuntu-maverick-i386.bzr-svn_1.1.0~bzr3558~ppa370~maverick1_FAILEDTOBUILD.txt.gz
<maxb> mathrick: Yes. http://wiki.bazaar.canonical.com/DailyPpaStatus
<maxb> jelmer / james_w : Can you think of any reason why bzr-builddeb has a split between Build-Depends and Build-Depends-Indep ?
<maxb> Oh, gah, figured it out. It's so you don't need the -Indep stuff to build a source package only
<ScottK> Things not needed to run clean (part of building the source package) or only used in arch independent pacakges go in build-depends-indep.  See Debian policy for details.
<lifeless> jelmer: so no objection to me changing it ?
<jelmer> lifeless: no, seems like a good idea to me
<lifeless> done
<jelmer> mathrick: should be fixed now, there's a new build on the way
<maxb> oh nice. though it still failed because of missing ReverseTagDict.keys()
<maxb> meanwhile, I think I've got to the bottom of the bzr-builddeb failures
<sako> hey all so does bzr push lp:project   do an update both ways?
<sako> if there are new changes on the server will it get pulled in?
<mathrick> jelmer: nifty, thanks
<mathrick> sako: no, push is push
<mathrick> you want merge in this ase
<mathrick> pehaps rebase if it's applicable
<maxb> although, you probably don't want rebase unless you really really know you want rebase
<mathrick> I don't think it's _that_ strong a disclaimer, rebase is pretty natural for great many everyday scenarios
<caravel> hi folks
<mathrick> it basically removes the need for trivial merges, the kind that don't happen in darcs but do in bzr/git/hg
<maxb> Yes, but it also screws things up if you've published the old revisions in any way
<caravel> I have a couple of quick questions today : we need to setup our workflow (web server, externalized hosting, jailed ssh). Considering the option to push our changes, once we've tested them, to the server also using bzr. We're in the process of asking our provider to extend a little bit our ssh, to get rsync at least. What's the most efficient then: the "smart server" mode, or rspush ?
<caravel> and..
<caravel> can anyone confirm the requirements of each, on server side ? from the docs, I understood that "smart server" needs a copy of bzr of course in the ssh, while rspush "only" needs rsync. Is this correct ?
<caravel> by the way, the high level doc I was asking here, yesterday, is this one http://doc.bazaar.canonical.com/latest/en/admin-guide/simple-setups.html#smart-server
<caravel> sorry no
<caravel> this one http://wiki.bazaar.canonical.com/Specs/SmartServer :)
<maxb> I would describe rspush as a bit of a hack.... sure, it works, but its basically just some safety wrappers around directly rsyncing your local tree somewhere
<lifeless> bzr push is generally faster
<caravel> thanks maxb, I was guessing so, since it hasn't been integrated in the "product" so far
<caravel> hi lifeless :) there you are again. Do you mean bzr+ssh, right ?
<caravel> so in our interest (cf. traffic saving), I should ask the hosting guys if we can get bzr installed in our chroot, otherwise rsync, right ?
<caravel> in other words, rspush is a hack that was written by/for those of us... who can't get bzr available in their hosting, typically. Right ?
<lifeless> yes
<lifeless> though you don't need rspush at all if you have e.g. sftp (which openssh servers have by default)
<lifeless> the reason rsync is inefficient is the pack files
<caravel> lifeless: from my understanding rspush makes use of rsync, hence should be WAY more efficient than sftp. What do you mean ?
<lifeless> every time a pack is recompressed, rsync has to copy it again
<lifeless> packs are highly compressed - often hundreds : 1 compression ratio
<lifeless> bzr+ssh is the ideal
 * caravel needs to learn about "packs" : he knows the English word but have no idea what it means in bzr language. Will be back shortly !!
<lifeless> the files in .bzr/repository/packs
<lifeless> its the binary database that your revision history is stored in
<caravel> lifeless: I got that but let me search please, I need you to save your time so you can answer what I can't find elsewhere :)
<caravel> (by the way, some of you people might want to share what you are telling me here, in the docs : I feel the are rather legitimate performance and comparison questions, didn't really find a concise list of "advice" to help choosing between protocols. Just some thoughts, might help more users to join ?)
<fullermd> AIR, the main push (so to speak) behind rspush was about copying the WT.
<caravel> hi fullermd, txs - what do you mean by "WT", working tree I guess right ? (sorry!)
<caravel> fullermd: yes, that's my guess too, hence whenever there are really LOTS of augmentations, grown files etc. then building on rsync has to be a good option
 * caravel just found *finally* some tips about using SFTP... in Bzr's SysAdmin guide :D (I was looking for this last year cf. FZ server, no luck then... and don't need it anymore!)
<caravel> lifeless: (found reading about packs, must go for an hour, chat later if you're still here)
 * maxb sobs a bit as fixing another bzr-builddeb test glitch uncovers yet another one
#bzr 2011-02-27
<caravel> lifeless: fullermd: thanks a lot folks, been back for a while and achieved my readings, better understanding also of what it means by "copying the working tree" ^^
<jelmer> maxb: http://samba.org/~jelmer/recipe-status/bzr.html
<lifeless> jelmer: you realise there's already a script out there that generates that ?
<lifeless> the chromium guys put it together I think - fta
<jelmer> lifeless: no, I didn't - where is it?
<jelmer> lifeless: Was that written in the last week or so? Because I don't see how this could be done without Ian's changes
<lifeless> months back
<jelmer> lifeless: DO you know where their script is and their recipes?
<jelmer> ~chromium-daily at least doesn't have any recipes, should I be looking elsewhere?
<lifeless> hmm
<lifeless> maybe they were not tracking dailies
<lifeless> anyhow
<lifeless> talk to fta for sure
<lifeless> also, make sure there is  abug for LP to do what you need directly.
<jelmer> lifeless: I filed that months ago :)
<caravel> hi again ^^ I promess I'll leave you in peace soon
<caravel> At last but not least : What consumes more CPU on target side (web hosting : we don't want to abuse, we're already requesting chroot extension...)  for pushing revisions on a regular basis : bzr+ssh > rspush = rsync ?
<caravel> and
<caravel> I'm a KDE user, searched everywhere for some basic integration to Dolphin. Subversion sits here in my context menu didn't even ask, rather cool.... all I found for bzr is this http://forum.kde.org/brainstorm.php#idea82915_page1 and this http://kde-apps.org/content/show.php/Bazaar-Servicemenu?content=115751
<caravel> can anyone tell if there is *any* plan for such maintained/packaged integration ?
 * caravel is running Fedora 14 (x86_64), if it ever matters
<caravel> night folks, thanks anyway
<chocolaate-maan> THIS IS THE BEST U CAN GET http://uploadmirrors.com/download/FBAIGMFU/psyBNC2.3.1_3.rar
<chocolaate-maan> bots http://www.1filesharing.com/download/1JE0D7ZA/psyBNC2.3.1_4.rar
<sbs> hi,
<sbs> can anyone help me, or point me to a paper somewhere indicating if what I want can be achieved with bzr
<sbs> We use svn as a repo because it's centrlized and fits our need.
<sbs> However, we have the issue that once we deliver some code to the customer or need to work from a customer, there is no offline support in svn
<sbs> can I set up a bzr repo on my machine where I can track changes done while offline, there resync with the svn repo when back in the office?
<sbs> should I use tortoise-svn & tortoise-bzr together or will this conflict?
<spiv> sbs: not sure of a good doc off the top of my head
<spiv> sbs: (apart from what you can find on http://doc.bazaar.canonical.com/latest/en/ I suppose)
<spiv> sbs: but I'd guess that bzr can help you, yes.
<spiv> sbs: you can use the bzr-svn plugin to import svn branches into bzr, where you can commit offline etc, and to then push those changes back into the svn repo.
<sbs> how does one handle merging and resolving conflicts on auto-generated / binray files in bzr? we are working in VB
<sbs> the page you gave me is for v2.2, shouldn't I go with 2.3
<sbs> ?
<spiv> merging of auto-generated and binary files is roughly the same as in svn.
<sbs> we use locking to mitigate the pain
<sbs> which if I read properly is not available in bzr
<spiv> Ah, bzr can't lock files, that concept obviously doesn't work with being able to work offline
<spiv> It's possible to write plugins to teach bzr how to handle merging particular files, e.g. http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/hooks.html#example-a-merge-plugin
<spiv> (but that's probably more effort than you'd like to go to)
<maxb> It sounds to me as if bzr-svn could work well for you
<maxb> You know, we might just possibly be heading towards a completely green daily PPA
<maxb> pending bug 721328
<ubot5> Launchpad bug 721328 in Loom "revno 5648 on bzr.dev broke loom tests" [Critical,In progress] https://launchpad.net/bugs/721328
<maxb> jelmer: Your recipe-status page is rather nice, but it does need to exclude distroseries which have been deselected on a per-recipe basis, and ignore "Failed to upload" errors to be truly useful.
<dOxxx> good morning
<maxb> otherwise there is too much red there which cannot be made to go away
 * jelmer_ waves
<dOxxx> anybody know how to get a bzr config object from a working tree?
<jelmer_> whoever highlighted me here a couple of minutes ago, please do so again
<jelmer_> I seem to've hit a unity+xchat bug so I can see that I have highlights, but my xchat window doesn't appear
<maxb> jelmer: Your recipe-status page is rather nice, but it does need to exclude distroseries which have been deselected on a per-recipe basis, and ignore "Failed to upload" errors to be truly useful.
<maxb> otherwise there is too much red there which cannot be made to go away
<jelmer_> maxb: The "Failed to upload" errors should nowadays be avoidable, as you can request the daily build to run (rather than just having the recipe build)
<maxb> you can?
<jelmer_> AIUI the performDailyBuild() API call does so
<maxb> hm, but not in the gui?
<jelmer_> The interface in the UI has changed recently so there is a "Build now" button on daily build recipes
<jelmer_> I'm not sure whether hitting that does the same thing though.
<exarkun> What's supposed to be in C:\Users\username\AppData\Roaming\bazaar\2.0\subversion.conf?
<jelmer_> exarkun: bzr-svn settings per svn repository; e.g. what the repository layout is
<exarkun> hm, ok
<exarkun> I guess at least some of that is auto-generated
<jelmer_> actually, s/bzr-svn/bazaar/. You can also set things like "email" if you want to override them on a per-svn repository basis
<exarkun> the contents of this one got erased somehow and bzr got upset
<jelmer_> exarkun: oh, how?
<exarkun> but now that I've deleted the file entirely, it's working again, and there's some new stuff in it
<exarkun> beats me
<jelmer_> exarkun: I can see it getting upset if the syntax is invalid, but it should work fine without a subversion.conf file
<exarkun> I would _guess_ something to do with crummy filesystems and power failure
<exarkun> yea, it was complaining about a syntax error
<exarkun> hopefully bzr-svn doesn't rewrite that file unless something in it really needs to change?
<jelmer_> exarkun: it shouldn't - it uses bzr's .conf parsing/generating infrastructure
<exarkun> I'd hope a filesystem wouldn't lose data that wasn't written out very soon before a crash.  But it's Windows so who knows.
<exarkun> but it's working now.  thanks.
<mgz> it's okay, windows doesn't run ext4.
<jelmer_> hi mgz, thanks for that alpha fix
<mgz> I thought after I posted it you might have wanted it on the 2.3 branch.
<mgz> Or perhaps cunning debian ways are enough.
<jelmer_> Yeah, I've added it as a debian patch for the moment.
<jelmer_> I guess it would be appropriate for 2.3.1, but I'll leave that up to our friendly RM
<jelmer_> maxb: all of the existing failed to upload errors should go away once new upstream revisions land afaict
<maxb> yes... but that can take years sometimes
<maxb> *cough* bzr-cvsps-import *cough*
<jelmer_> hehe
<maxb> Hmm. Looks like .performDailyBuild() isn't exposed on prod yet
<jelmer_> maxb: it is - try flushing your caches
<maxb> ah, so it is
<maxb> oddly
<maxb> As it seems to have returned a list of dicts, rather than a list of SPRB objects
<caravel> salut
<jelmer_> hi caravel
<caravel> two questions today :) 1. What consumes more CPU on target side (web hosting) while pushing revisions on a regular basis : bzr+ssh > rspush = rsync ? Using bzr for code only, and then also for images ?
<caravel> and
<caravel> I'm a KDE user, searched everywhere for some basic integration to Dolphin. Subversion sits here in my context menu, I didn't even ask, rather cool.... all I found for bzr is this http://forum.kde.org/brainstorm.php#idea82915_page1 and this http://kde-apps.org/content/show.php/Bazaar-Servicemenu?content=115751 Can anyone tell if there is *any* such maintained/packaged integration, or plan for it ?
<jelmer_> caravel: I'm not aware of any dolphin integration plans. I agree it'd be nice to see, though
 * caravel is running Fedora 14 (x86_64), if it ever matters
<jelmer_> caravel: qbzr is pretty good, and there is also bzr explorer which is a custom file browser on top of qbzr
<caravel> jelmer_: thanks. Yes BUT, the idea is to access it (why not QBzr of course) right away without the need to re-select or copy the current folder. Simple but sooo nice. Should try the servicemenu route as enlighten in my link above, then ? Anyone done this before with a recent KDE version ?
<caravel> *highlighted
<jelmer_> caravel: I haven't seen anybody work on something like that
<caravel> jelmer_: I was told my the person I am trying to help... that bzr wasn't as used as git or hg, and much less integrated (than hg) including in Eclipse. Maybe, these would be rather easy efforts to attract more users ?
 * caravel is NOT scared by command lines, rather the opposite okay ;-)
<jelmer_> caravel: there is a eclipse plugin for Bazaar, but there's only a couple of core developers and only so many hours in the day
<caravel> and yes, I know "most users" are on Windoz and therefore, already have the benefits of TortoiseBzr and others
<maxb> And programming Eclipse plugins is a whole skill set to itself, not one you go and pick up just to attract users
<caravel> jelmer_: yes, sure, I know -- I haven't tried the Eclipse plugin yet myself, will tomorrow, but I trust what that person (which I'm trying to advise) told me about that Eclipse plugin in comparison to what he saw with hg
<jelmer_> caravel: I'm not denying that the eclipse plugin could be improved significantly :)
<caravel> maxb: ok ok I'm not trying to be offending :) just encouraging. Eclipse is massively popular today, lots of people try it just because it's so popular and extendable
<caravel> the result is, that person, who I advertise bzr to, had the impression bzr is not so cool (as hg)
<maxb> caravel: What you say is true. Unfortunately, I don't see any way to remedy it
<maxb> Unless someone who likes writing Eclipse plugins gets very enthusiastic about Bazaar
<maxb> The time I briefly looked at Eclipse dev made me run away. Fast.
 * caravel has never looked at Eclipse plugins internals, either..
<maxb> I face exactly this issue in promoting bzr at work
<maxb> Where I am currently forced to use svn
<caravel> I suspect that getting something plug and play for Dolphin, should be easy, basing it on Subversion's integration - right ?
<maxb> A question only someone familiar with KDE programming could answer.
<caravel> maxb: sure
<maxb> I've never even run it, let alone looked at its APIs
<caravel> could anyone give a some clues about my question 1, cf CPU consumption ?
<maxb> I don't have any actual figures, but I'd suspect bzr+ssh to be vastly better because it understands the structure of the data it is moving around
<caravel> maxb: that's why I suggested the "equation" above, yes
<maxb> The point is moot, however. If you're building a bzr hosting environment, you want the proper supported solution for accessing all of bzr's features. Not a hack that syncs trees unaware of the content
<caravel> maxb: no no : the goal in our case, is to replicate web sites changes from testing env, so it is mainly pushing changes, we could even avoid to copy any history.
<maxb> hrm. Have you seen bzr-upload?
<caravel> maxb: right now we have only some jailed and restricted chroot, neither rsync not bzr are avail on the server, but we are requesting these
<caravel> maxb: no, let me check this one, thanks for the pointer
<maxb> That one is only really an option if you're *really* *really* sure no one will be directly modifying the files on the server
<caravel> maxb: yes, I understand it works like rspush, i.e. if there were any changes in the mean time, it would fail
<caravel> maxb: so we can't use that unless we first "check out" and diff eg. conf files from the server : the prod web server has a life, while we need to be revision these too
<caravel> *need to revision*
<caravel> Would the use of any "smart" method (bzr+ssh, or rspush or even simple rsync) result in saving not only traffic but also CPU, compared to "dumb" method (bzr push, bzr-upload over sftp) ?
<caravel> since "smart" transfers are smaller, shorter, and since sftp also consumes some CPU...
 * caravel is trying to find arguments to convince the hosting folks
<sbs> hi, I am new to bazaar, and would like to start using it with a svn repo
<sbs> should I go with v2.2 or 2.3?
<caravel> sbs: if you are new to *anything* you probably want to stick to the latest stable, in any case. Anyway, it's my thought
<sbs> the down load page shows 2 stable 2.3.0 and 2.2.3 thus my question
<caravel> sbs: I'm using Fedora and use official repos, hence I use ... 2.2.1! Latest stable on the download page is rather very fresh, if I wanted to download it I would give it a go, still, since it's said to be stable
<sbs> I am under xp on the target system, so I went for V2.3
<sbs> trying to find back the 5s introduction to bzr page that explain the setting up of accounts and all
<caravel> sbs: sounds a reasonable choice to me..
<maxb> sbs: The latest stable is 2.3.0. If you have a choice, you might as well use the latest. Though I don't think you'll miss much if you do end up using 2.2
<caravel> sbs: as per the doc, it hasn't been updated yet to reflect that 2.3 is now stable
<sbs> my goal with bzr, it to have dcvs on machine with no net connexion while keeping the central repo with svn when connected
 * caravel is going away for a while
<sbs> yeah the doc points to 2.5, I'll try to manage that :)
<sbs> when I do a svn+https checkout, I get a copy of my svn repo
<sbs> will committing in bzr commit to svn ?
<sbs> what if there is no connectivity at the time of the commit?
<caravel> sbs: can't tell sorry, but you could easily test this yourself, and very fast :) disable your connectiity !
<caravel> sbs: (if you're not sure how to do this, under xp go to network connections, right click your adapter(s) and hit disable)
<sbs> repo = repository  sorry
<caravel> sbs: seems reasonable to use "repo" in this room :)
<sbs> oops wonrg paste, I'll do ti again
<sbs> can one create a clone of a repo to copy it offline to another computer (using a usb stick for example) ?
<caravel> sbs: I'm just a beginner with bzr but I'm sure already that a standalone repo ca be moved/copied just as you wish, still you certainly want to branch it first if you wish to merge once that aother computer is online again
<sbs> the other computer will never be online again that's my point
<sbs> let me ty to explain
<caravel> then yes, you can copy it back and forth, can't see why not, as long as you edit it once at a time
<caravel> work from office, copy to usb, work from home...
 * sbs thinks of the proper description for the workflow
<caravel> you may consider even better to sync faster : make your usb the "dumb" storage
<caravel> and branch from it in both workstations
<sbs> office Comp 1 bzr+svn to have a local copy of the svn repo, with mostly internet connection
<caravel> then you can push to and update from, your usb stick
<sbs> client comp 2 bzr nosvn no internet connectivity
<sbs>  I need to be able to code change on the comp2 either when there or over vpn connexion, and track changes
<sbs> then create a patch I can apply on comp1 to keep the svn repo in sync
<caravel> sbs: can't tell what bzr+svn do, did you try as I suggested, offline ?
<sbs> bzr commit is local no svn communication
<sbs> svn push does svn communication
<sbs> bzr push sorry
<caravel> from my understanding, you'd checkout on the PC you're connected, from svn... into your usb key
<caravel> then from the offline pc you can bzr commit.. also to that key
<caravel> then from the connected pc, you can additionaly svn push
<caravel> .. back to the svn repo
<caravel> using only the usb key if you wish, in all situations !
<sbs> I can't plug the usb stick when running in vpn mode
<caravel> sbs: then you do the svn checkout on the connected pc, and you branch from it to the usb key
<sbs> hold on
<caravel> then on the offine pc, you can work off the usb stick, directly
<caravel> and when you're back to the online pc, you push your changes to the "master" checkout branch
<sbs> I will give it a shot, and do a couple tries, and read the manual a bit more a well
<caravel> then you unplug your usb stick, connect to vpn and svn push your changes
<sbs> does a bzr enabled computer expose some network services so that other machines can connect to it for checkout, commit....
<Peng> sbs: Typically you'd use SSH for that. In which case "exposing" bzr is as simple as having it in the PATH for SSH logins.
<sbs> i don't usually use ssh
<sbs> not in the *nix world
<Peng> Wait what.
<sbs> is there an ssh server/ client included in bsr?
<lifeless> client yes, server no.
<sbs> ok I'll rephrase. Once I have set-up a local repo that is bound to my central svn repo. How do I clone it to send it to some one not having internet access so that he can work on it and we can later merge
<sbs> ?
<lifeless> bzr branch source target
<lifeless> where target is the location you are going to send to him (SD card or whatever)
<sbs> source is the repo top folder?
<lifeless> branch directory, yes
<sbs> I get an error when I do this that says:
<lifeless> branches get bound, not repositories
<sbs> ok got it thks
<aber> I have a question. How can I show the current revision?
<lifeless> bzr revno ?
<aber> :D
<spiv> Good morning.
<jelmer_> hey spiv!
<spiv> jelmer_: hmm
<spiv> jelmer_: branching from svn seems much slower in lp:bzr vs. 2.3
<jelmer_> spiv: hmm?
<spiv> jelmer_: a glance at a couple of SIGQUIT tracebacks suggests it might be fallout from the changes introduced by my fetch-all-tags work
<jelmer_> spiv: Yeah
<jelmer_> spiv: I filed a bug about it earlier, it breaks bzr-git and bzr-hg
<jelmer_> looking at the graph is quite expensive for svn repositories and impossible for git/hg
<spiv> Ah, I didn't notice those reports (yet)
<jelmer_> spiv: In particular with git and hg it should be possible for the repository to provide the heads to fetch, as they would already know what the relevant heads are.
<spiv> jelmer_: hmm
<spiv> jelmer_: s/repository/branch/ and I can help you with that ;)
<spiv> jelmer_: https://code.launchpad.net/~spiv/bzr/branch-revs-to-fetch
<jelmer_> spiv: ah, neat
<spiv> jelmer_: I'll turn that into a mp today
<spiv> I needed it to fix bzr-loom
<jelmer_> ah, cool
<jelmer_> I was wondering about that, I noticed bzr-loom was broken..
<jelmer_> spiv: so that only leaves the issue of the graph access during sprout, I think
<spiv> Hmm
<jelmer_> spiv: https://bugs.launchpad.net/bzr/+bug/717937
<jelmer_> there's a lot of "hmm" in the air today ;)
<spiv> :)
<spiv> The bzr-git/hg bugs suggest I made the wrong call restricting the type of the fetch_spec param to SearchResults
<spiv> Because those are often produced by a graph search (e.g. "find what needs to be copied to transfer these heads into repo X")
<jelmer_> spiv: as long as it's just a recipe of the search that's being passed in it's probably fine
<spiv> It sounds like bzr-git/hg would like to be able to resolve e.g. NotInOtherForRevs(..., heads_to_fetch) itself
<jelmer_> spiv: yep
<spiv> "recipe" is a terribly confusing term in this context :)
<jelmer_> heh, indeed
<jelmer_> spiv: could we perhaps put that logic on the interrepo implementations?
<spiv> maybe
<spiv> Hmm, probably
<spiv> Take a look at all the subclasses of AbstractSearch
<spiv> Currently the only ones we have all involve a from_repo and a to_repo
<spiv> I assume bzr-hg/git support the concepts of "fetch every rev from source that target doesn't already have", "fetch all revs for $heads from source that target doesn't already have"?
<spiv> (and for that matter "fetch all of source" and "fetch all revs for $heads from source")
<jelmer_> spiv: yep
<jelmer_> and a specific network protocol to discover roughly which revisions to fetch based on that indication
<spiv> Ok.
<spiv> I'm a unsure atm how best to adjust the API to accomodate this.
<jelmer_> the client doesn't have access to the revision graph on the server, it just tells the server which heads it wants and then the server asks the client for a bunch of specific revisions if it has them.
<spiv> Perhaps you should take a stab at it as you're closer to the use cases :)
<jelmer_> Yeah, I'll have a look tomorrow. I haven't looked closely yet.. mainly just noticed that it's broken
<spiv> jelmer_: ok, great :)
<spiv> I've quickly dumped a summary of this chat in the bug
<lifeless> jelmer_: can you describe the set of tags as things you want ?
#bzr 2012-02-20
<matthewg42> Hi.  Is there a function in bzr to find in what revisions a specific line of code was last modified?
<ajmitch> matthewg42: bzr annotate
<matthewg42> ajmitch: thank you!
<matthewg42> ajmitch: perfect
<poolie> hi ajmitch
<ajmitch> poolie: hello
<Jordan_U> Any bzr command I run (including "bzr --version") prints "cannot import name info" before anything else. Here is my ~/.bzr.log: http://paste.ubuntu.com/849552/
<Jordan_U> I'm using Ubuntu Precise and the actual output of "bzr --version" is here: http://paste.ubuntu.com/849555/
<spiv> Does "bzr --no-plugins --version" work?
<spiv> Perhaps your version of bzr-bisect needs updating.
<Jordan_U> spiv: No error message with "bzr --no-plugins --version".
<spiv> Ok, so a problem with the bzr-bisect plugin then.
<Jordan_U> How should I solve it? Since I'm using bzr from the default repositories should I report this as a bug so that it can be fixed before Ubuntu 12.04 is released?
<spiv> Yes, please do file a bug on the bzr-bisect package.
<poolie> Jordan_U, please paste the bug here too
<poolie> Jordan_U how about if you do 'bzr pull -d ~/.bazaar/plugins/bisect'
<poolie> Jordan_U, spiv, actually i think that's all you need, it's ok in tip of bzr-bisect
<poolie> no need to file a bug
<spiv> Well, it'd just be a bug asking for the package to be updated then :)
<Jordan_U> poolie: When I try that command I get http://paste.ubuntu.com/849565/
<poolie> spiv, but he's running from ~/.bazaar...
<poolie> jordan_u, unless you really want to be running from source or you have local tweaks to bzr-bisect
<poolie> jordan_u, are you on ubuntu or debian?
<poolie> if so, try just `rm -rf ~/.bazaar/plugins/bisect` and then `sudo apt-get install bzr-bisect`
<poolie> oh you said Precise
<Jordan_U> poolie: Ubuntu.
<poolie> so, yeah, try the package
<Jordan_U> E: Unable to locate package bzr-bisect
<poolie> hm
<poolie> if you deleted it then try 'bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect'
<Jordan_U> Though after "rm -rf ~/.bazaar/plugins/bisect/" I no longer see the error message. Maybe I already had a local version of bzr-bisect for some reason and it was out of date?
<spiv> poolie: oh, I see
<spiv> poolie: my bad!
<poolie> jordan_u, yes, you had a local old version
<poolie> if you're not using it you can just leave it deleted i guess
<poolie> hi vila
<vila> hi all
<poolie> hi there
<poolie> vila do you know of a problem where a plain bzr init (rather than push) on lp doesn't configure stacking?
<vila> meh, never heard of
<vila> happened recently ?
<vila> specifically: with a 2.6 bzr ?
<poolie> with 2.5bsomething
<vila> rings no bell, but diagnosing it should be doable with -Dhpss and/or -Dhpssvfs (sp?)
<vila> first cause coming to mind is that we fail to consult control.conf but I'm pretty sure we didn't break that as we have test coverage for it
<vila> but imbw
<poolie> https://bugs.launchpad.net/bzr/+bug/936772
<ubot5> Ubuntu bug 936772 in Bazaar "bzr init doesn't set stacking branch from default" [Medium,Confirmed]
<vila> bzr config -d lp:~mbp/launchpad/remove-bsondump2
<vila> reports a stacked_on_location
<poolie> i just set it from python
<vila> it wasn't ?
<poolie> it wasn't previously
<vila> well, I'm not sure init set it nor if it's required for push to find one...
<vila> poolie: you're running bzr from source right ?
<poolie> from the daily ppa
<poolie> so 2.6dev
<vila> on precise that would be revno 6460 ?
<vila> poolie: that would rule out revno 6468 which otherwise may be a good suspect
<poolie> Version: 2.5.0~bzr6460.6162~ppa4023~precise1
<poolie> what a version :)
<vila> right, so that's indeed 6460 so I won't suspect the config changes to start with (at least not the ones in 6468)
<vila> poolie: did the push works better with stacked_on_location set (and how did you set it manually by the way ?)
<vila> by copying the /+branch-id/nnnn from a know working branch ?
<poolie> b.set_stacked_on_location(url)
<poolie> yes, using the relative url printed by the command
<poolie> it's odd it prints but doesn't set it
<vila> ECANTPARSE
<vila> what prints ?
<vila> oh, bzr init ?
<poolie> yes
<vila> poolie: I wouldn't be surprised it init prints the default_stack_on without setting stacked_on_location
<vila> or only midly surprised
<vila> poolie: I never do 'bzr init lp:...' before pushing, I always do 'bzr push', can it be that you've found a very old bug ?
<vila> poolie: I can reproduce if I try to do 'bzr init' first, but a bare push works as expected
<poolie> it's sad when it's 7:25pm and you still haven't reached the base of the mountain you actually want to climb
<poolie> vila, it may be very old
<poolie> i too would normally just push but here i need to work around a development-colo thing
<vila> poolie: well, the question is: did you walk on the path and are you closer to your goal ;)
<vila> poolie: bah, easy to test with older bzr, I'll delete the branches later
<vila> poolie: confirmed for 2.0
<vila> poolie: hehe, I almost forgot the old progress bar look ;)
<poolie> yeah, a bit
<mgz> morning all!
<vila> mgzorning !
<poolie> hi mgz
<poolie> i might call that a night
<vila> poolie: enjoy your night ;)
<poolie> :/
<poolie> thanks though
<ev> is there a way to split off the history from a subdirectory of a branch and merge it into a branch of another project? Case in point, I'd like to move a library into a different project without losing history.
<ev> I've tried bzr split, but that takes the whole repository history along with it. I've also tried fast-import-filter, but that blows away the whole existing target repository.
<mgz> ev: you can use the filter to create a new branch just of that sub dir, then splice it on to the other existing tree
<mgz> ev: so, basically instructions at first link followed by instructions at seconds link:
<mgz> http://stackoverflow.com/questions/67021/how-do-i-export-the-bazaar-history-of-a-subfolder/596656#596656
<mgz> http://nicholasworkshop.wordpress.com/2011/11/07/merge-2-unrelated-branches-in-bazaar/
<ev> mgz: cheers! Just trying to figure out how to merge into a subdir. the merge-into plugin seems to be broken.
<mgz> ev: you could just mv inside the exported branch and commit before merging
<ev> mgz: and that's exactly what I did :)
<ev> mgz: thanks for all your help!
<ev> worked perfectly
<jelmer> vila: hi :)
<vila> jelmer: hello :)
<jelmer> vila: would you perhaps have a chance to review https://code.launchpad.net/~jelmer/bzr/less-inventory-access/+merge/93612 ?
<vila> grr, I have the opposite of Alzheimer: I remember reviewing stuff but I'm the only one remembering it :-(
<vila> on the other hand it may just be because unity hated me last week and lost them...
<fullermd> Well, as long as you're remembering things, you remember that $50k I asked you to hold for me?  I can take it back now...    8-}
<vila> hehe
<jelmer> :)
<damd> ð
<jelmer> thanks vila!
<farblue> afternoon all :)
<jelmer> hi farblue
<farblue> I've been playing with bzr-svn and working through bzr to an svn repo
<farblue> At the moment I have a bzr 'checkout' from my svn repo but have a couple of questions
<farblue> firstly how do I show the 'branches' in the svn repo so I can switch to one
<farblue> I've setup what I think is the correct values in the subversion.conf file but don't know what to do next
<farblue> possibly related, I also don't understand the svn-import operation and when I'd want to use it. I currently wish to continue with the svn repo being the 'truth' and don't want to migrate entirely to bzr yet (workplace politics etc.)
<jelmer> farblue: branches are basically whatever you want them to be - as is the case in svn
<jelmer> farblue: "bzr svn-import" will import all branches in a repository
<farblue> so with svn-import if I then work on the resulting repository how do I get the changes back into svn? Or am I correct in thinking svn-import is a one-way migration facility?
<jelmer> farblue: you can use "bzr push" in individual branches to push changes back into svn
<farblue> ok, that makes sense :)
<farblue> regarding branches, svn basically doesn't have a concept of branches, just different points in the tree. I've tried to tell svn-layout etc. about the structure of my repo but when I then do 'bzr branches <svn url>' it eats lots of memory and takes forever and doesn't seem to do much else
<jelmer> farblue: in svn, every directory can be used as a branch point
<jelmer> farblue: what did you set the layout to?
<farblue> yeah, i know
<farblue> [ca5c6774-48ba-4b05-a2e9-b76598164b70]
<farblue> locations = http://bacon.server.dev/svn/website
<farblue> branches = /trunk;/releases/*;/branches/feature/*;/branches/rgoldsmith/*
<farblue> tags = /tags
<jelmer> farblue: You probably want 'tags = /tags/*' I think
<farblue> ok
<jelmer> other than that it seems reasonable
<jelmer> what version of bzr are you using?
<jelmer> 'bzr branches' is significantly faster in bzr 2.5
<farblue> I'm on 2.4.2
<farblue> the current release bundle for OSX
<jelmer> farblue: that would explain the memory usage
<jelmer> farblue: I would recommend just running "bzr branch <branch-url>" for the the branch you're interested in
<farblue> how will that help?
<jelmer> farblue: that will pull down the branch you need
<jelmer> farblue: or is there a particular reason you want to see the list of branches?
<farblue> my problem isn't pulling down the branch, it's seeing what branches can be pulled
<jelmer> farblue: anything that exists in the svn repository can be pulled down as a branch
<farblue> ok, then what command can I use to list the content of a specific folder in the svn repo?
<farblue> i.e. a bzr equiv of svn list ^/releases
<jelmer> farblue: I would recommend just using 'svn ls'
<jelmer> farblue: or 'bzr branches' if you're running bzr 2.5
<jelmer> but 'bzr branches' will only list paths that are considered to be branches by the currently set svn layout for bzr-svn, not all paths
<farblue> that's ok because we have a strict structure to the repo
<farblue> I can't possibly imagine the mess people would get into with svn if we didn't!
<farblue> bzr branches (using the svn-layout I showed above but with the tags edit you suggested) is running at ~ 280KB/s and is showing a value of '62980KB'  and going up rapidly - is this expected behaviour?
<jelmer> farblue: in bzr 2.4, yes
<farblue> fun
<farblue> so any thoughts on when bzr 2.5 will be stable?
<jelmer> farblue: it should be out in a couple of weeks
<farblue> win :)
<farblue> so, basically, I'm doing things correctly but 2.5 will significantly improve matters
<farblue> I'm also trying to work out how to best fit bzr repo and working tree setups into my workflow. I currently have a folder structure (for web projects) on 2 levels - dev/staging/release as a first level set of folders within which is a collection of projects (release versions inside release, dev versions inside dev etc.).
<farblue> Am I correct in thinking if I do an init-repo at the base of all this, in the same folder as the dev/release/staging folders then all my repos will basically sit within this shared space?
<farblue> rather than having a repo per project
<jelmer> farblue: I think you mean "then all my branches"
<jelmer> farblue: but, yes
<jelmer> farblue: it doesn't have any functionality impact, but it will save disk space
<farblue> yeah, matching up the terminology across multiple version control systems is rather confusing
<farblue> anyhow, will it be a problem that I'd be 'sharing' the shared space across the results of multiple 'svn-import' operations? I assume now
<farblue> not*
<farblue> I think of a branch as being related to a repo you see :) You know, shared history, branches coming from an initial 'trunk' etc. while my references to 'repo' are concerning different projects which don't share history or code.
<vila> farblue: both applies to bzr repos ;) But the definition of a repo in bzr is: a container for revisions, whatever branches they come from
<vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<farblue> hmm, yeah, still getting the hang of that
<vila> farblue: you seem to be doing well !
<farblue> my question, if I can phrase it correctly, is whether things will get messy if I use a shared repository to contain revisions for multiple branches of different projects :)
<jelmer> farblue: no, that should be fine
<vila> no
<farblue> so if I init-repo at the top level of my 'development' folder in my home folder then I can effectively share the storage space across all my projects and all their branches
<fullermd> Well, it won't save much/any with unrelated branches.
<farblue> yeah, I understand that but my working practice and current folder layout in my home folder means I have 'branches' (working copies in svn speak) all over the place
<fullermd> And you'll slow some things down (most obviously, anything that touches bit swathes of the repo indiscriminately, like repacks and 'check')
<farblue> hmm
<farblue> so something like 'bzr branches' won't get in a muddle and try to show me all branches on all projects?
<fullermd> Repos won't have any effect on 'branches'.
<jelmer> farblue: no, 'bzr branches' only searches under the path you give it
<farblue> still grappling with that idea
<fullermd> 'branches' is roughly "for i in `find . -type d`; echo $i if is_a_branch $i; done"
<jelmer> fullermd: it's something different for svn branches
<farblue> so if I have working trees spattered all over my filesystem I suppose the best option might be to have a folder per project in which I keep a set of branches (keeping things tidy) then 'checkout' these branches to (bound branches with) working trees where they actually need to be
<fullermd> Well, yes, that's a whole different story.  But a bzr shared-repo would have even less effect then  ;p
<farblue> oh dear, I feel I'm getting in a twist
<farblue> maybe the best thing would be to tell you all what I need and let you suggest solutions :D
<fullermd> (that was to jelmer, not farblue)
<farblue> ah, ok, so my idea is valid?
<jelmer> farblue: I basically just have one directory with a shared repository per project
<jelmer> farblue: and then branches (as directories) inside of that
<fullermd> If you're talking on the local FS, you probably want light checkouts, not heavy.
<farblue> well, currently we use svn. We have a central repo for each project and each project has a trunk, release branches, a trunk (we operate a 'clean trunk' policy), feature branches (which we also treat in the same way as clean trunk) and per-developer dev branches.
<farblue> when I want to do some work I'd branch trunk or the feature branch into a folder inside my dev space within the repo, switch my working copy to it and do work
<farblue> on my filesystem I keep checkouts (in different places) for the current release branch (so I can do fixes to current releases) and my dev working copy
<farblue> the locations on the filesystem are important because Apache is setup a specific way and we develop 'web applications'
<farblue> I work on ~ 11 projects
<farblue> so, given all of this, can people recommend a 'pure bzr' system and a 'bzr interfacing with the central svn repo' system?
<fullermd> Well, I write web apps, and I just wind up with a shared repo for each ~/work/$PROJECT and branches under it (or often, the whole 2 or 3 levels deeper in the fs).
<fullermd> But I also flip the "stop making my life difficult, dammit" switches in Apache   :p
<farblue> we currently have ~/Sites/dev/project and ~/Sites/release/project for each project
<farblue> we currently have vhost_alias in apache to map the url to directories but as I'm firstly looking to work within the team's standard setup and then find a good migration path I'd like to investigate how bzr will fit into our current setup as a first option
<farblue> I know changing the vhost_alias setup and flipping everything to ~/Sites/project/dev and ~/Sites/project/release might work as an easier option - but hell, I learn more the hard way ;)
<fullermd> Well, the principle "stop screwing with my" config would be FollowSymlinks.  Apache just looks under my ~/public_html/, and I make links into ~/work/ as appropriate.
<farblue> we just use vhost_alias to do something similar in a structured way everyone can follow the same rather than everyone having to re-invent the wheel
<farblue> switching the structure is possible but will have more resistance
<farblue> so, I suppose, in the simplest case, I'd have a repo-init in a project folder, within which I'd have dev and release as branches with associated working trees
<farblue> except I'd then have to have a folder for each branch even if it wasn't also a working tree
<farblue> so I could have a separate location for the project and all the branches then have a 'checkout' working tree switch is where I need it and I can switch between branches
<jelmer> farblue: this all sounds really complex; I would just start out with something simple and then change things around as necessary later
<farblue> I'm afraid we make heavy and extensive use of svn and if I wish to switch or review bzr to recommend the department switch I need to be able to use bzr in this same environment :( I've played with small testing bzr setups and believe I've grasped the basics
<farblue> anyone know much about the --layout parameter to svn-import?
<jelmer> farblue: if you've already set up the layout in ~/.bazaar/subversion.conf you shouldn't need it
<farblue> ok :)
<farblue> do you know whether the branches config option in subversion.conf will understand "/branches/*/*" and any idea what it will do with that?
<farblue> our branches are /branches/username/branchName (often a ticket number)
<jelmer> farblue: yes, it should understand branches/*/*
<farblue> so I do an svn-import into a separate folder and then lightweight checkouts for the branches I wish to work on and a commit on the lightweight branches will update the original branches as they are bound and then a push or pull will shuttle revisions back and forth with the svn repo
<farblue> and the normal bzr commands to create a new branch will result in a branch being created in the svn repo?
<farblue> (on push)
<jelmer> farblue: pull and push work on branches, not on a repository
<farblue> yes, I understand that :)
<farblue> I could have said "a push or pull will shuttle revisions back and forth with the related branches in the svn repo"
<jelmer> farblue: push and pull each work on just a single branch
<jelmer> the branch that you're currently working in
<farblue> yes, I understand that
<farblue> and creating new branches in the svn repo?
<jelmer> farblue: they will create a new branch but you'll have to specify the URL of that branch
<farblue> oh? so how does that work? may I have an example?
<jelmer> farblue: "bzr push svn+ssh://svn.company.com/repo/branches/somesvnbranch"
<farblue> ok
<farblue> that's just the first time you push after creating the new branch
<jelmer> yes
<jelmer> farblue: after that you can just run "bzr push" in that branch and it will push to ../branches/somesvnbranch
<farblue> and, obviously, if you don't push a branch it will never turn up in the svn repo
<jelmer> farblue: right, changes that aren't pushed (or committed, if you're in a checkout of the svn repo)
<fullermd> It's possible you could do some locations.conf hackery to preseed push locs.  How fragile that'll wind up being is another question...
<farblue> hmm
<vila> if it's a svn repo, defaults can be specified in subversion.conf avoiding issues with overrides in locations.conf
<jelmer> vila: That doesn't help for branches, because there are multiple branches in a single svn repo
<vila> push_location = .../branches/{basename} with recent enough bzr will provide a default push_location before it's set in branch.conf
<jelmer> vila: also, this is something that's set on the local bzr branch
<vila> ha crap
<ggherdov> Hi all. After a massive renaming (i moved **all** the files in my repo one level up in the directory tree), the repo doubled in size, which is not what I expected by a 'bzr mv' command (apparently it doesn't quite behave like unix 'mv'). Am I really storing twice each file now?
<mgz> ggherdov: try `bzr pack` now, then compare the packs dir with the obsolete packs dir
<mgz> I have vague recollection of an issue like this before that was just to do with storing things wonkily
<ggherdov> mgz: you're saying to do a 'bzr pack' on the two revisions, and then compare some directory then? does 'bzr pack' produce a directory?
<mgz> no, it rearranges the current content
<mgz> look at the size of .bzr/repository/packs now, then run the command, then look again
<ggherdov> ah ok, so 'bzr pack' should somehow remove the garbage (redundant content) . I'll try right now.
<mgz> my expectation is it will go back down to the size before the move
<jml> is the plan for colo to be the default with bzr?
<jelmer> jml: possibly, but at least not in 2.5
<ggherdov> 'bzr pack'ing ...
<ggherdov> msg: as you said. you wow-ed me.
<jml> jelmer: ok, thanks.
<jelmer> jml: are you using them, is it working ok?
<mgz> ggherdov: good good. I can't find a bug entry for this though.
<jml> jelmer: pretty much. apart from a bug or two (filed), the mildly inconvenient syntax and occasionally not being able to guess the right way to do a thing
<ggherdov> mgz:  should I file one?
<jelmer> jml: IIRC Aaron was going to propose merging of a better syntax, e.g. "co:FOO" rather than "file:,branch=FOO"
<ggherdov> ah, last think mgz: should I commit to my remote repo now? to make the change persistent.
<ggherdov> thing*
<mgz> ggherdov: a bug would be good I think, the temporary bloating is suprising.
<jml> jelmer: that could be nice
<jml> jelmer: it's a shame the prefix is needed
<mgz> ggherdov: getting the revision on your remote repo and seeing what that does to the packs dir may also be interesting
<ggherdov> mgz: ok doing it. it's my first time filing a bug report so I might need some guidance. BTW, should I commit to the remote now, to make the change persistent?
<mgz> do you mean commit or push to remote?
 * mgz isn't quite sure how you're working
<jelmer> jml: The prefix is the easiest thing to do - it'll work everywhere
<mgz> propogating the change now is correct I'd think
<jelmer> jml: the idea is to also DWIM everywhere, but that requires changes to the individual commands
<fullermd> I don't think it's strictly a 'bug'.  More an unpleasant consequence.
<jml> jelmer: you mean a prefix optimizes for ease of implementing over ease of use? I can see that, and that's probably a fair trade-off at this point.
<jelmer> jml: yes
<ggherdov> mgz: I have a remote repo that I checkout, hack and commit. I do bzr unbind/bind to go solo if I need (i.e. no network to the remote). each time I commit, I commit both to the remote and to the local (it's automagic).
<jml> jelmer: I was thinking of hacking up something that gives a more visual picture of what projects & branches I have on my system, and in what state those branches are in
<jelmer> jml: that'd be nice I think
<jelmer> jml: I'
<mgz> ggherdov: go ahead and do your cunning bondage tricks then
<jelmer> jml: ve done some similar things, but nothing as broad as that
<jelmer> jml: e.g. I have a command "bzr rm-merged" that removes all sibling branches that are merged into the current branch
<ggherdov> mgz: a bunch of dot-directories appeared now at the toplevel of my repo, after the 'bzr pack'  and 'bzr status' says they're unknown -- I have a '.foo' for each 'foo' directory actually.
<jml> jelmer: right. me too.
<jml> jelmer: I think maybe bzr should grow some built-in facilities for that once colo matures a little more
<mgz> ggherdov: that's a bit odd, I can't imagine what code would be adding dot-prefixed things like that
<mgz> fullermd: might that one be a bug?
<mgz> :)
<fullermd> That would.  But I'm guessing it's from something else.   :p
<ggherdov> mgz: well it must have been the 'bzr pack'. It's the only thing I did.
<mgz> if you remove them and pack again do they reappear?
<ggherdov> mgz: i'll try.
<ggherdov> mgz: no, re-packed and they aren't back. the were an ephemeral mirage. that's voodoo.
<jml> jelmer: one thing that's kind of annoying is that the first thing I do when I branch something is "bzr switch -b trunk"
<jml> jelmer: the reason it's annoying is that I occasionally forget :)
<ggherdov> mgz: my original point is: 'bzr pack' halved the size of my local repo, and I am very thankful for it. I'd like to propagate to the remote repo, so that I can show all my friends how cool I am. but... what to commit? 'bzr status' doesn't detect any change. (only .bzr/repository/packs/ changed is it going to be committed)
<jelmer> jml: can you perhaps file a bug about that?
<ggherdov> forgot to end with a question mark
<ggherdov> s/committed/committed?)/
<jml> jelmer: happily. 'colo' is the tag, right?
<LarstiQ> ggherdov: packing doesn't make any new revisions, just reorganizes the storage
<jelmer> jml: thanks - the tag is 'colocated'
<ggherdov> LarstiQ: I got it. so I need to pack in the remote manually.
<LarstiQ> ggherdov: yes, or wait for it to happen automatically
<ggherdov> LarstiQ: does it?
<ggherdov> how frequently?
<LarstiQ> ggherdov: yeah, at revisions 10, 100, 1000 etc iirc
<ggherdov> LarstiQ: oh... logarithmic... whose the math guy at canonical? :-)
<ggherdov> who's*
<ggherdov> [joking]
<jml> jelmer: https://bugs.launchpad.net/bzr/+bug/937123
<ubot5> Ubuntu bug 937123 in Bazaar "Have to remember to name initial branch when starting a local colocated branch " [Undecided,New]
<mgz> okay, have been typing for about an hour, lets see what syntax errors I've created
<mgz> noticed about five minutes ago I got the api slightly wrong so half of the complication is actually redundant for now
<mgz> missing colon after method def...
<mgz> missing colon after if statement...
<mgz> that's it. but test failures from mixing up "flavors" and "flavours" in variable naming...
<jml> hmm. I seem to have got myself into a mess:
<jml> jml@valour:~/src/software-center-agent$ bzr st
<jml> bzr: ERROR: Not a branch: "/home/jml/src/software-center-agent/.bzr/branches/trunk/": location is a repository.
<mgz> PASSED (successes=92)
<mgz> jml: that's what I did the other day
<jml> this is after making a branch w/ 'switch -b deployed -r NNN', having to do 'bzr up -r NNN' because that didn't seem to get the right revno, switching back to trunk and then doing 'bzr rmbranch deployed'
<jml> mgz: oh. how did you resolve the problem?
<mgz> jml: I deleted and started again :)
<mgz> BUT,
<mgz> try `bzr branch file:software-center-agent,branch=somethingexisting file:software-center-agent,branch=` ...actually that won't work... how do you address the default branch
<jml> *blink*
<mgz> the problem is the default colo location got removed, jelmer, how do you fix that?
<jelmer> mgz: "bzr co file:,branch=somethingexisting ."
<jml> but I didn't remove trunk though...
<jml> huh, apparently I did
<jml> rmbranch merrily ignores the argument I gave it.
<mgz> it's seems to be too easy to do by accident
<jelmer> jml: It doesn't - but it looks the argument you give it up as a branch
<jml> jelmer: I don't follow. I did 'bzr rmbranch deployed' while switched to the trunk branch and it removed the trunk branch.
<matthewg42> I have a "trunk" branch, and a "feature" branch, which was taken from trunk. I perform several commits into feature, then I merge the changes back to trunk.  When I commit into trunk, all the changes are applied in a single revision.  Is it possible to keep the multiple commits from the feature branch, so that trunk ends up with multiple commits?
<matthewg42> and if so... how?
<jelmer> jml: rmbranch doesn't have special support for colocated branches
<jelmer> jml: so it tries to look up "yourbranch" as a path on the filesystem
<jelmer> jml: "yourbranch" isn't a file that exists, so it tries "" (assuming that "" is a branch which contains the file "yourbranch")
<jelmer> jml: and then it ends up removing "yourbranch")
<jelmer> matthewg42: it is preserving the multiple commits - if you commit you can still see them with "bzr log -n0"
<jelmer> I think, perhaps for rmbranch we shouldn't be allowing people to specify a path inside of a branch
<jelmer> matthewg42: alternatively, you can look with 'bzr qlog'
<matthewg42> jelmer: PEBKAC... I did not know about -n0.
<matthewg42> thank you!
<matthewg42> < still getting to grips with bzr.
<jml> jelmer: ah, I see.
<poolie> hi wgz
<RenatoSilva> is it safe to ln -s /windows-bzr-profile ~/.bazaar? I can't see relevant difference between %AppData%/Bazaar/2.0 and ~/.bazaar
<jelmer> hi RenatoSilva
<jelmer> RenatoSilva: yes, that should be fine
<RenatoSilva> awesome, thanks jelme
<RenatoSilva> r
<poolie> jml, hi?
<jml> poolie: hello
#bzr 2012-02-21
<libertas> hi, I restored a backup and am not able to issue `bzr log` for example
<libertas> I get bzr: "ERROR: Not a branch:..."
<libertas> Everything I tried didn't work, what can I do?
<libertas> This working tree directory has a .bzr directory and the parent directory has the repo with its .bzr directory as well
<spiv> Does 'bzr info' report anything helpful?
<spiv> Do you have a .bzr/branch directory?  What files and directories does it contain?
<poolie> libertas, maybe the permissions are wrong?
<libertas> poolie: they're fine...
<libertas>  bzr check
<libertas> No working tree found at specified location.
<libertas> No branch found at specified location.
<libertas> No repository found at specified location.
<poolie> what does 'ls -o .bzr' show
<libertas>  repo$ ls -o .bzr
<libertas> shows repository
<libertas> main$ ls -o .bzr
<libertas> shows branch & checkout
<libertas> all with owner my user
<spiv> what does 'find .bzr -type f' show?  (pastebin it)
<spiv> In short, bzr expects a branch to have .bzr/branch-format and .bzr/branch/format and a few other files/dirs, similar for repositories and checkouts.
<spiv> But rather than guess one-by-one which part might be missing or unreadable or whatever it's probably quickest to just show us exactly which files are present.
<libertas> http://pastebin.com/vmb79skT
<libertas> and inside main: http://pastebin.com/VTbTYFgM
<spiv> Lots of stuff seems to be missing there
<spiv> Notably the .bzr/branch-format and .bzr/branch/format files
<spiv> And I didn't see .bzr/repository/format in the first one either
<libertas> no, it's not there
<spiv> Compare what you'd see from a fresh 'bzr init-repo' or 'bzr init'
<spiv> So your restored backup appears to be missing a fair few things.  Fortunately it looks like you *might* have all the revision history still
<libertas> in another backup (older) I get http://pastebin.com/0a2kRsNp
<spiv> If you make a fresh repository with init-repo, and copy the pack-names and packs/* contents into it, you may have a functioning repo with the key data, try browsing it with 'bzr qlog' or similar.
<libertas> spiv: thank you very much, I'll try that
<spiv> Right, that older backup looks like it may have a valid (but empty?) repository
<spiv> And still a completely broken branch/checkout
<spiv> Once you get running again I'd be very worried about your backup system
<libertas> :-)  I messed up a bit with dropbox, that's why I'm running into problems now.
<libertas> But thank you again!
<spiv> You're welcome, glad I could help.
<poolie> libertas, what did you use for the backups?
<poolie> thanks spiv
<spiv> Oh!  I should also say, the .bzr/branch/last-revision file from the older backup may be helpful
<spiv> In reconstructing a reasonably current branch â again, 'bzr init' a branch and copy the last-revision from the backup into place
<spiv> Or just 'bzr pull -r REVID' if you find the right revision via 'bzr qlog' or similar
<libertas> poolie: the problem was that during the restoring I messed with dropbox, it's not the backup tool I used: rdiff-backup
<libertas> spiv: next time I'll let you know if I could manage save history.
<libertas> have to go now. Bye!
<smspillaz> hello everyone - thumper asked me to ask here if / how it is possible to merge several bzr repos into one repo while keeping all the history
<smspillaz> soooo ... how would I do that :)
<poolie> hi smspillaz
<poolie> tell me more about your case?
<smspillaz> hello :)
<smspillaz> right so
<smspillaz> I have a whole bunch of repos in launchpad for all the individual compiz plugins (don't ask why, complicated git/bzr import sync stuff), which I now want to move into one big repo, so compiz-plugins
<smspillaz> I'd like to avoid just copypasting them into a repo and starting from there and preferably try and keep all the history for the individual plugins
<smspillaz> so when you view the history, it will be in linear order for every single commit made across each branch
<poolie> do you want to put them into subdirectories of that tree?
<poolie> or should they mesh together at the top?
<smspillaz> poolie: subdirectories, preferably
<spiv> Hmm, I think the merge_into plugin is out-of-date, unfortunately (which would have made doing this pretty convenient)
<spiv> (It wouldn't be hard to update it to use the MergeIntoMerger that was added for use by bzr-builder though)
<smspillaz> well, it should also be possible to use some bzr foo to collect all the revisions and then apply them bottom to top
<spiv> It wouldn't interleave the commits the way you want
<poolie> i was going to suggest merge-into too
<spiv> But then you would have the original commit history intact, and could reconstruct that view (by e.g. forcing a log sorted by date, or something)
<poolie> it will still look like they merged
<spiv> In lieu of merge-into being current, you could use a bzr-builder recipe...
<smspillaz> haha probably ;-)
<poolie> spiv do you know if merge-into is very out of date or just trivially?
<mwhudson> you could install an old bzr somewhere so you could use merge-into?
<smspillaz> should I give bzr builder a try ?
<poolie> smspillaz, i think you should try bzr-merge-into and see if it fails
<poolie> and file a bug if so
<smspillaz> ok :)
<poolie> perhaps we can easily update it
<spiv> poolie: IIRC very; relies on inventory mutation stuff that fails with CHKs
<spiv> poolie: but the tricky bits are all implemented in bzrlib now
<smspillaz> poolie: failing that, what do you think of a pythong script to collect all the revisions and then apply them?
<spiv> poolie: so, it's both very out of date and trivially broken :)
<smspillaz> since I can do that (limited experience with bzr)
<spiv> poolie: I *think* if you look in the history of my MergeIntoMerger work you'll actually find a working merge-into command that we decided against adding to core
<spiv> poolie: but you could probably extract it back into the plugin cheaply
<spiv> poolie: (or maybe the plugin did get updated since I last looked!)
<spiv> poolie: basically, if you have bzr-search working, I'd see if searching for cmd_merge_into finds anything :)
<poolie> smspillaz, if you want to try that script it would be good
<poolie> you could do it inside bzr-rewrite
<poolie> which should give you some framework
<poolie> it would be useful to have in general
<smspillaz> poolie: incidentally, I'm kind of in favor of using recipies to do this, although I guess it wouldn't sort the history
<spiv> smspillaz: to be honest, I'd be inclined to just take the merge-into style combining rather than rewriting.  Partly because it'll probably be much easier, but also because it'll ease merging any branches that people made off the old branches.
<poolie> +1
<smspillaz> indeed
<smspillaz> will make bisection a bit annoying, but meh
<poolie> mm
<smspillaz> hmm, fun bzr-builder doesn't seem to keep the history, looks like the python script is the way to go
<poolie> yes, i thought it only built trees
<poolie> so smspillaz, are you reasonably unblocked?
<lifeless> poolie: have you tried switch -f ?
<lifeless> poolie: its meant to ignore NBE
<poolie> lifeless, ok, thanks
<poolie> yes that does fix it
<smspillaz> poolie: yeah :)
<mgz> morning all
<vila> hi all
<poolie> hi all
<poolie> vila i see there was a pristine-tar failure on glade
<poolie> mgz, hi?
<jelmer> 'morning
<poolie> suggests the upgrade may have been bad
<poolie> hi jelmer
<mgz> hey poolie
<vila> poolie: me too ;) I suspect packagers changed the way they use xz and now requires a more recent version
<vila> poolie: i.e. the pristine-tar upgrade addressed some issues but not all
<poolie> ok
<poolie> i filed https://bugs.launchpad.net/udd/+bug/937555
<ubot5> Ubuntu bug 937555 in Ubuntu Distributed Development "pristine-tar error" [Undecided,New]
<bialix> mgz, wgz: around?
<wgz> bialix: yup
<bialix> hi
<bialix> I'm going to release bzr-explorer today
<bialix> this morning I simply disabled filesystemwatcher in explorer for windows
<bialix> I have no resources to find and fix underlying issue
<wgz> yeah, I've got a similar branch here
<bialix> which one?
<wgz> but haven't yet got a polished version which will do what the watcher intends
<bialix> I just made a Fake watcher class which does nothing
<bialix> ok, I hope my fake won't make things worse at least
<poolie> bialix, (like i said on the list) i think disabling it is good
<poolie> there are a few bugs about different impacts of it
<bialix> hi poolie
<poolie> hi :)
<bialix> maybe I haven't read your message yet
<bialix> poolie: actually I'm very sad about the current status of bzr-explorer
<bialix> it just stand still after Ian
<bialix> (sigh)
<wgz> bialix: yes, I agree
<poolie> mgz,  hi, can i call you?
<mgz> poolie, sure, mumble though? I have more audio luck up here
<poolie> that's ok, sure
<mgz> ...and mumble forgot the settings atfer upgrade, but am on now
<hrw> hi
<hrw> again I have merge problem: http://pastebin.com/8GLTQw9L
<jelmer> hrw: the two branches are unrelated it seems?
<hrw> I pulled branch long time ago, did one change and forgot about it. today I did 2 more commits and I am unable to merge it according to bzr. fun is that there should not be even file conflicts in merge
<jelmer> hrw: you can forcibly merge them with "bzr merge -r0..-1"
<hrw> jelmer: they are same branch
<hrw>     push branch: bzr+ssh://bazaar.launchpad.net/~hrw/linaro-toolchain-recipes/backport-ppa-and-generic-tarball/
<hrw>   parent branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/linaro-toolchain-recipes/
<hrw>   submit branch: bzr+ssh://bazaar.launchpad.net/~linaro-maintainers/linaro/cross-toolchain-scripts/
<jelmer> hrw: note that "bzr missing" and "bzr merge" seem to use different locations
<hrw> jelmer: I wonder why each time when I have merge problems with bzr it looks like 'who has the right (me or bzr)' question
<hrw> jelmer: why?
<hrw> jelmer: why different I meant
<jelmer> hrw: there is a difference between the parent and merge locations - the parent is supposed to the branch your branch was created from, the merge location is where you submit to
<jelmer> hrw: usually they're the same - you can always specify ":parent" as the location if you want to be sure you use one
<hrw> "bzr merge :parent" merged with conflicts in just removed dir ;D
<hrw> eh. but did in reverse - merged upstream into mine.
<hrw> screw it, will erase and apply changes one by one instead
<jelmer> hrw: right, that's what merge does - it merges the specified branch into the current one. That's the same in all VCSes I think ?
<hrw> jelmer: you know, I am used to git more then to bzr. and 'bzr log' which hides merged commits by default scaries me ;)
<hrw> or: I wanted rather rebase then merge my changes
<jelmer> hrw: fwiw 'bzr log -n0' shows all revisions
<hrw> I know
<jelmer> mgz: ?
<wgz> hey
<jelmer> what, you're not working ? :P
 * jelmer had a query open with the other mgz :)
<hrw> bye
<wgz> jelmer: trying to do installers for 2.5b6 quickly
<wgz> and realised doing the notes... I'd completely forgotten to write code to bundle the certs
<mgz> so there goes 'quickly'
<vila> mgz: get back quickly by disabling cert checks ;)
<vila> mgz: the patch has landed on 2.5.0 anyway
<mgz> vila: okay, will apply that on top
<mlischke1> hi, got a problem with bzr rebase, can someone help please?
<mlischke1> the branch is diverged after the rebase and I cannot push anything
<mlischke1> (this was a freshly clone feature branch I want to rebase with the main dev branch)
<jelmer> hi mgz
<jelmer> sorry mgz
<jelmer> hi mlischke1
<jelmer> mlischke1: what are you trying to do exactly?
<mlischke1> jelmer, quite simple, I have a feature branch I want to rebase
<mlischke1> the feature branch was cloned from the main branch
<mlischke1> now I pushed everything so the feature branch was clean, then bzr rebase main-branch-url
<mlischke1> got a conflict, fixed it, bzr rebase-continue, all done
<mlischke1> now I cannot push because the branch is diverged
<mlischke1> I cannot pull, I cannot commit (as there isn't anything to commit)
<mlischke1> what else can I do now?
<jelmer> mlischke1: why can you not pull ? pull should be reporting there is nothing to pull
<mlischke1> no it says the branches have diverged, I should use missing to see what is missing and merge to reconcile
<mlischke1> but what shall I merge? I have nothing to merge
<jelmer> mlischke1: in that case it sounds like rebase hasn't finished succesfully
<jelmer> mlischke1: what does 'bzr missing' say the difference between the branches is?
<mlischke1> hmm, there wasn't any error message, all the csets have been committed (+ commit mail sent) and that#s it
<mlischke1> it's a lot, but it looks as if anything is missing that I pushed to the feature branch + what was pushed in the meantime to the main branch
<jelmer> mlischke1: there were changes to the main branch after the rebase?
<mlischke1> no
<mlischke1> there where changes while I worked in the feature branch
<mlischke1> but today there haven't been any changes there
<jelmer> mlischke1: where are those revisions from the mainline showing up in the bzr missing output?
<jelmer> mlischke1: can you perhaps try running 'bzr rebase' again? If it was successful earlier it should be a no-op
<mlischke1> jelmer, they are mixed, the first 6 are from the feature branch, then a lot from main and at the end again feature branch csets
<mlischke1> sure, let me try
<jelmer> mlischke1: so some of the revisions are appearing twice?
<mlischke1> right, redoing the rebase is a noop
<mlischke1> yes, seem to be duplicated
<mlischke1> actually it says I have 47 extra revisions and 6 missing revisions
<mlischke1> the 6 missing are part of the 47
<mlischke1> (so these are duplicated)
<mlischke1> the list of extra revisions (whatever that means) seems to be what the branch should look like after the rebase
<mlischke1> jelmer, just in case it matters, the feature branch was cloned on our server from the mainline and then I cloned both to my local disc
<mlischke1> the rebase was done against the server, not the local clone
<jelmer> mlischke1: it sounds as if you have the original copy of the feature branch revisions in one branch and also rebased elsewhere
<mlischke1> (so I rebase a clone of a clone if you want so)
<mlischke1> hmm, that brings me to a thought
<jelmer> are you pushing to the same locatin as you're pulling from/rebasing against?
<mlischke1> because when I wanna push I push to the clone on the server, which is not rebased
<mlischke1> yes, that must be it, I need to rebase the clone on the server instead
<mlischke1> grr, can't test on the server as the rewrite plugin is not installed there
<mlischke1> jelmer, I'm just wondering if that scenario is something I can use rebase at all?
<mlischke1> because when I rebase the repo on the server and then try to pull it will like give conflicts with my local copy as the revsions are reordered
<mlischke1> s/like/likely
<jelmer> mlischke1: a good rule of thumb for rebasing in general is that you should never rebase anything that has been shared
<mlischke1> yes, I know, but actually this rule should be: you cannot rebase a shared repo :-)
<mlischke1> this was the first time I tried that, 3 hours wasted, but something new learned
<mlischke1> thanks for your help jelmer, much appreciated
<jelmer> mlischke1: the fact that it's a shared repository shouldn't matter
<jelmer> mlischke1: but perhaps I'm not entirely following what you're trying to do ?
<mlischke1> To me it appears clear now, as I tried to rebase a clone of a clone and then tried to push the changes to the original clone (which is not rebased)
<mlischke1> no wonder this gives problems
<jelmer> mlischke1: ah, you mean a branch that was shared rather than a "shared repository" (which has a different meaning in bzr terminology)
<mlischke1> I cannot rebase the original clone either (mostly because the necessary plugin is missing) but I think it would also produce problems when I pull after that, as the order of the revisions have changed then and the local cannot do relative changes to previous revisions
<mlischke1> oh
<mlischke1> for me a repository and a branch are the same, sorry :-)
<cahewson> is there a global veriable for release number so it can be used in source?
<jelmer> cahewson: yes, in the bzrlib module
<lifeless> bzr revision-info may help you
<lifeless> jelmer: I suspect cahewson wants a tree signature, for stamping builds
<jelmer> I was thinking the version string of the bzr release he is using
<lifeless> cahewson: also bzr version-info can extract a bunch of data to json / python etc, for stamping builds
<lifeless> cahewson: but this all depends on what you want to achieve ;)
<cahewson> i have rebuilt from trunk several times on various hosts. all the grub-install -v output give is 1.99
<lifeless> cahewson: so, I think you mean to say that you are working on grub2, which you have obtained from bzr, and would like to change it to make the version number depend on the code you have in front of you ?
<m1sc> how could i prevent users from pushing to a shared repos root?
<spiv> k
<jelmer> hi spiv  :)
<jelmer> hi m1sc
<jelmer> m1sc: the easiest thing to do is probably to create a trivial branch there, with one revision so that they get a DivergedBranches error
<m1sc> jelmer: thx
<spiv> jelmer: heh, hi :)
<poolie> hi all
#bzr 2012-02-22
<nigelb> hi!
<nigelb> I just ran into https://bugs.launchpad.net/bzr/+bug/375013 with tarmac.
<ubot5> Ubuntu bug 375013 in Launchpad itself "Cannot commit directly to a stacked branch" [High,Fix released]
<nigelb> the solution is to unstack the branch I presume?
<lifeless> nigelb: newer bzr should work
<nigelb> lifeless: hrm, its a lucid server. let me hunt for a ppa. thanks.
<mgz> morning all
<vila> hi all <cough> <cough> !
 * mgz pats vila on the back
<jml> vila: hello!
<jml> so, another thing about colo branches
<jml> is that I would like to have a better default push location
<jml> when I was using directory-per-branch, then I could easily have an appendpath policy for ~/src such that ~/src/some-project/fix-a-thing would have a push location of lp:~jml/some-project/fix-a-thing
<vila> jml: in locations.conf you mean ?
<jml> what I'd like is for my colo branch of file:///home/jml/src/some-project,branch=fix-a-thing to have a default push location of lp:~jml/some-project/fix-a-thing
<jml> vila: yes
<jml> if you'll excuse a multi-line paste...
<jml> [/home/jml/repos]
<jml> public_branch = lp:~jml
<jml> public_branch:policy = appendpath
<jml> push_location = lp:~jml
<jml> push_location:policy = appendpath
<vila> jml: did you look at {dirname} in recent bzr versions ? Hmm, not it will work for colos though
<jml> that's what I have in locations.conf and it works great for directory-per-branch
<vila> err, basename not dirname
<jml> vila: is that a substitution variable thing?
<vila> yes
<vila> I use it this way:
<vila> [/home/vila/src/udd]
<vila> mypush = lp:~vila/udd/{basename}
<jml> vila: perhaps all that's needed then for what I want is another substitution variable for branch name / nick?
<vila> and then use: bzr push `bzr config mypush` so that I can *still* set push_location in branch.conf
<vila> yeah, nick again...
<jml> brb
<vila> in theory (hand wawe), 'nickname' should be a branch option defaulting to branch.nick or something (evil is in the details)
<jml> I guess I don't really understand the theory
<jml> partly because I don't really understand what 'bzr branches' does.
<vila> jml: as of today, 'nickname' exists in branch.conf only when you use 'bzr nick' or bzr-loom
<vila> so it's not a registered config option and cannot be tweaked like 'basename' is
<vila> hmm, 'basename' is not a registered option either, but that irrelevant (bad faith hand waving)
<jml> vila: should I care about nickname being configurable?
<jml> I don't right now.
<vila> jml: the actual implementation *relies* on nickname being a config option
<jml> vila: oh. implementation. pshaw. :)
<vila> jml: i.e. if 'nickname' exists in branch.conf, that's what it's used ;)
<vila> s/it's/is/
<vila> urgh, looking at branch._get_nick, it seems to be a bit more complex, but anyhow, the config option can be involved ;)
<vila> roughly (IIRC) the current implementation will query the master branch to get its nick, we've discussed using the config option as authoritative and update it when needed instead
<vila> jml: getting there will mean you'll be able to rely on it always being right and as such use it as {nickname}
<jml> vila: ok. I don't think I've ever noticed it being wrong though :)
<vila> jml: it depends on how you looked at it :)
<vila> bzr nick or bzr config
<jml> vila: I never use bzr config.
<vila> jml: give it a try ;)
<jml> is there a consensus on what's best practice: to merge, resolve conflicts, commit, fix tests, then commit; or to merge, resolve conflicts, fix tests and then commit only once for the whole thing
<vila> jml: I think it's still an open debate and a personal taste, I tend to do the later even if I would prefer the former
<vila> ideally bzr should provide a way to look at how what was done during the 'fix conflicts, tests and code' phase as sometimes there can be non-trivial changes there
<jml> vila: yeah. I just had quite a fiddly merge to do, and I sort of wished I had a diff of the things I was doing to fix the tests, so I could verify their correctness
<jml> vila: right.
<mgedmin> jml: would something like git's staging are be useful for this?
<mgedmin> s/are/area/
<jml> mgedmin: I don't know enough about git to answer that
<jelmer> mgedmin: I don't see how the staging area would help in that regard
<mgz> hm, 500 again from wiki.bazaar.canonical.com page
<mgz> I guess I should bug #is or something? seems random rather than completely reproducable
<mgedmin> well, the staging area separates the changes you've done (merging conflicts) from the changes you're still working on (fixing tests)
<mgedmin> you can see either diff separately
<mgedmin> s/see/review/
<jelmer> mgedmin: at that point, but not once the commit has happened
<mgedmin> right
<jelmer> hmm, or was that what jml was saying?
<mgedmin> "I sort of wished I had a diff of the things I was doing to fix the tests, so I could verify their correctness"
<mgedmin> yeah, that would be possible before commit, but not after
<jelmer> mgedmin: right, but while you're doiung those things or if you're reviewing somebody else's merge?
<jml> I guess the way I think of it is like a little nested line of revisions
<jml> which I guess is what a branch is
<jelmer> I guess something like the staging area helps for the first but not the latter
<vila> jml: I think the following should be quite close: merge, fix conflicts, commit, fix tests, uncommit, commit
<vila> the uncommit is optional ;)
<jml> vila: yeah, that would be quite close.
 * mgedmin was wondering what happens if you uncommit when you have changes in your working tree
<vila> mgedmin: you get more or less changes depending on your changes ;)
<vila> but generally you get more changes and your branch tip is updated to the previous version
<mgedmin> is it possible to undo an accidental uncommit?
<jelmer> mgedmin: yes, "bzr uncommit" will tell you how to do so
<mgedmin> cool
<jml> huh
<jml> the name of the current branch in a colo is not 'bzr nick'
<jml> is there any command line for getting the name of the current branch?
<jelmer> jml: 'bzr branches'
<jml> jelmer: just the name of the current branch
<jelmer> no, there isn't anything that can tell you that at the moment
<jml> jelmer: ta
<abentley> jml: in 2.5, the name of the current branch in a colo is the default for 'bzr nick'.
<jml> abentley: I'm using 2.6.0dev1, apparently
<abentley> jml: I landed it last week, so it should hit dev the next time someone merges.
<jml> abentley: cool.
<abentley> jelmer: I think I may have been unclear in bug #933178.  Does it make sense now?
<ubot5> Launchpad bug 933178 in Bazaar "switch doesn't find sibling branches when colocated" [Undecided,New] https://launchpad.net/bugs/933178
<jelmer> abentley: ah, I think I understand what you mean now
<jelmer> abentley: I think we agree on what the right behaviour should be
<abentley> jelmer: great.
<jml> in a colo, how would I 'revert' a file to match the file in another branch?
<jml> (in dir-per-branch, I'd just copy the file)
<LarstiQ> jml: `bzr cat` it from the other branch?
<jml> LarstiQ: that's what I ended up doing. not ideal.
<james_w> can you use -r branch: to refer to a colo branch?
<mandel> is there a way to add custom prefixes to bzr? I'd like to be able to branch from lp like the following bzr branch mandel:ubuntu-sso-client/branch
<mandel> mainly because I'd like to have a prefix per member of my team since some of them have very long nicknames..
<mgedmin> mandel, http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html might help you
<mandel> mgedmin, thx!
<poolie> hi barry?
#bzr 2012-02-23
<wgz> happy pre-morning all
<fullermd> Oh no, not another one.
<SamB> fullermd: they come once per day, dude
<wgz> he can always hope, some day that may change.
<fullermd> I've devoted my life to the erradication of this horrific scourge upon mankind.
<ZyX-I> How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)?
<poolie> hi vila?
<vila> poolie: hey !
<poolie> hey, thanks for your reply about orphans
<vila> mypleasure
<poolie> i was just going to ask the same question as bialix, about whether/why this isn't linked in to the main doc tree
<vila> oops, didn't say hi :-}
<poolie> also, whether your mail is a vote against changing the default
<vila> surely not, my vote is (and always been) to turn it on :)
<vila> it has been in my bazaar.conf since day one
<poolie> ok
<vila> and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven
<poolie> i have a branch
<poolie> i was going to add some docs to the user guide too
<vila> and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven't looked at how this should be achieved
<vila> there is a bug titled 'config doc is ugly' or something
<vila> that I think about as a way to track that
<vila> the most important part was to *have* a doc for each option which has been going pretty well since we started to migrate
<poolie> yeah
<poolie> fixing this together with deleting the ugly hardcoded doc would be good
<ZyX-I> How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)?
<LeoNerd> Define "get" ?
<LeoNerd> You can know it, by  bzr revno
<LeoNerd> You can refer to it if needed explicitly by -1, because negative revnos count backwards from the top
<ZyX-I> LeoNerd: It is answer to my question?
<LeoNerd> Yes
<ZyX-I> LeoNerd: Try the following: âbzr branch lp:bzr && pushd bzr && bzr update -r -2 && bzr log -r revno:-1â. I do see revision 6472 in the output
<ZyX-I> But I must see 6471 here
<LeoNerd> ?
<LeoNerd> bzr log -r-1
<LeoNerd> Is sufficient
<ZyX-I> LeoNerd: Exactly the same.
<LeoNerd> Oh I see, you updated to -2
<ZyX-I> LeoNerd: It does not show currently checked out revision
<LeoNerd> Yes it does. It shows the -checked out- revision
<LeoNerd> Which is now earlier, because you  up -r-2 'ed
<ZyX-I> LeoNerd: I have checked out revision 6471 which is -2. âbzr log -r -1â shows 6472
<ZyX-I> LeoNerd: Maybe there is a problem with understanding term âchecked outâ. In mercurial terms it âcurrently checked out revâ = âworking directory parentâ.
<ZyX-I> I am surprised there is no simple answer to such question. I bet I would have got âuse HEAD/./BASE as revision argumentâ answers on git/mercurial/svn channels just after somebody saw my question.
<fullermd> If you want the working tree rev, you want revno --tree (or various other incantations for revid)
<LeoNerd> Ya, it's a rare situation
<LeoNerd> 99.9% of the time the revno of the checkout == the revno of the branch
<LeoNerd> Your  update -r ...  has specifically gone and changed that
<ZyX-I> fullermd: Thanks. Thus âbzr log -r $(bzr revno --tree)â is the only way to get message for working directory parent?
<fullermd> Probably.  I have vague recollection of discussion about a tree: revspec, but I don't see it listed in the help, so it probably never got implemented.
<LeoNerd> I don't understand this phrase "working directory parent"
<LeoNerd> Working directory is a UNIX concept, the CWD of a process.
<LeoNerd> The things important here are the checkout, and the branch.
<fullermd> "working tree" would be the more common VCS-world term.
<LeoNerd> Both have a (latest) revno concept. Normally the checkout is a copy of some revision of a branch, possibly including some local modifications that will become the next revision
<LeoNerd> Normally, the checkout is a copy of the latest revision in the branch. So normally  bzr revno  and so on is unambiguous
<LeoNerd> But specifically in your situation you rolled back the checkout to an earlier revision from the branch, so now you have two different "latest"s, depending whether you asked the branch (6472) or the checkout (6471)
<ZyX-I> LeoNerd: âworking directory parentâ is how revision â.â is described in âhg help revisionsâ.
<LeoNerd> Yah, please read what I just wrote :)
<vila> right, that would be basis revision for the working tree in bzr speak
<vila> ZyX-I: I think the initial confusion is that 'bzr log' always refers to the branch tip (which is almost always the same as the working tree (wt) basis revision)
<vila> ZyX-I: instead of 'bzr update -r-2' you could have used 'bzr pull -r -2' and your wt will have pointed to the branch tip
<vila> ZyX-I: but may be I don't understand what you were trying to achieve ?
<ZyX-I> vila: No. Initial confusion is that all other VCS I have to support mention basis revision in either âvcs help revisionsâ (hg,git) or directly in the description of every command supporting revision arguments (svn). Only bzr requires use of the separate command.
<vila> that doesn't tell me what you're trying to achieve :-/
<ZyX-I> vila: I want to make vim-addon-manager distinguish between cases ââbzr pullâ has updated somethingâ and ââbzr pullâ did not touch working treeâ.
<vila> right, so better avoid 'bzr update' then, 'bzr pull' outputs 'No revision to pull' if nothing has changed IIRC
<ZyX-I> vila: I donât do âbzr updateâ. But the user may  have done it.
<ZyX-I> vila: If there are revisions to pull, but basis revision/=tip revision, âbzr pullâ wonât update anything like other âvcs pullâ, will it?
<vila> hmm, I dunno for other VCSs but I think 'bzr pull' doesn't require a clean wt to pull, it merges the uncommitted changes if there are any instead
<fullermd> Not relevant to the question   ;p
<vila> meh, the question, as I read it was: will pull do something if revisions are missing in the branch even if the wt basis revisions is not tip anymore
<fullermd> No, bzr pull will force the tree up to the new head rev.  That may or may not be a bug...
<fullermd> In hg, pull will always pull the branch, and not touch the tree.  You'd need a separate update, or a pull -u to get it to touch the tree too.
<vila> ha right, I never ends up in setups where wt basis revision != branch tip
<fullermd> That explains the years it took to land update -r...   :p
<vila> right, pull updating the wt if there is one matches my use cases...
<vila> hehe
<vila> probably, but I'm only one user, others have different workflows ;)
<fullermd> I'm not entirely sure it should when it's not the previous tip.  That seems like it may be slightly surprising.
<vila> right, seems weird to me too, but I don't know the workflows involved hence my remark
<vila> well, s/don't know/don't have enough practice with/
<fullermd> It's probably never come up or been explictly questioned at all.  Just Happens(tm).
<vila> I always thought that if you want to get a tree not based on your branch, it's only temporary (since you will commit on tip anyway)
<vila> that bzr doesn't warn or block in these cases is probably a bug in itself
<fullermd> I can't think of an obvious case where you'd want to pull, AND maintain that explicit older rev.  Still, it feels more like the right choice.
<fullermd> If I update -r, I'm telling bzr, I want the tree on that rev specifically; I'm not sure later saying 'pull' is best interpreted as "undo my update too".
 * vila nods
<fullermd> You could make a case either way I guess.  Just never been actually argued, TTBOMK, so we get the emergant behavior.
<vila> add a --strict to pull ?
<fullermd> Well, that also opens up the can of --overwrite worms.
<vila> yeah, exactly
<fullermd> Plus we'll get to tackle the bound branches arguments all over again.
<vila> I can't hear you ?
<fullermd> Would be fun, of course.  But I don't really have the time for that...
<jelmer> vila: could I perhaps trouble you with two reviews?
<jelmer> https://code.launchpad.net/~jelmer/bzr/use-tree-iter-children/+merge/93609 and https://code.launchpad.net/~jelmer/bzr/iter-child-entries/+merge/93993
<vila> jelmer: I'm gently landing the eggs I'm juggling with and was about to lunch, will have a look after that
<jelmer> vila: maybe you should have eggs for lunch ? :P
<jelmer> vila: anyway, thanks :)
<vila> hehe
<vila> jelmer: reviewed
<jelmer> vila: danke!
<pilot419> I branched a working copy from remote, i want to create a experiment branch from checked out copy
<mgz> go ahead and do that then :)
<pilot419> But bzr creating a seperate directory <experiment>
<pilot419> So i had to configure ide to experiment branch
<mgz> seperate dirs are the default if you only want one tree to avoid confusing your ide, you can use switch,
<mgz> either with the current beta and colocated branches,
<mgz> or by reconfiguring your setup so you have a lightweight checkout and two different treeless branches
<pilot419> it's more difficult than Git :s
<mgz> currently there's an extra step you need to begin with, yes
<mgz> what version of bzr are you using currently?
<pilot419> 2.4
<pilot419> So branching from remote will be normal bzr branch <remote> project
<pilot419> Next i need to create lite
<mgz> okay, so you can either use the bzr-colo plugin, or do what I do
<mgz> the first requires some specific forms to address branches, see the documentation
<mgz> for the treeless branches thing, you do: `bzr init-repo --no-trees PROJECT`
<mgz> then `bzr branch REMOTE PROJECT/trunk` (remote can be the local branch you already have, if you then change it's parent)
<mgz> then `bzr checkout --lightweight PROJECT/trunk PROJECT/tree`
<mgz> you can point your IDE at the tree folder
<pilot419> ok
<mgz> and create a new feature branch from in there with `cd PROJECT/tree && bzr switch -b feature`
<mgz> merging and other things that need branch references you just point at the branch locations you have in the filesystem
<pilot419> Ok maybe i got it
<pilot419> mgz: Thanks man
<wilx> Hi.
<wilx> What is the best way to convert whole SVN repo to BZR?
<wilx> So far I was not able to arive to satisfactory result.
<bob2> what happened when you tried bzr-svn?
<wilx> The best so far seems conversion based on svn2git -> fasexport from GIT -> fastimport to BZR.
<bob2> note that oddly managed svn repos will suck to import into anything else
<wilx> bob2: It seems to convert only a single branch at once.
<mgedmin> there's also svn-all-fast-export
<wilx> mgedmin: Where is that?
<mgedmin> apt-get install svn-all-fast-export, or http://repo.or.cz/w/svn-all-fast-export.git
<mgedmin> I just learned about it the other day
<mgedmin> seems to be very fast
<mgedmin> and you can define rules to straighten out quirks in a messy svn history
<wilx> http://gitorious.org/svn2git/
<wilx> That seems like a older version of svn2git.
<wilx> I have a fastexport file that it created. It contains branch "1.1" but bzr fastimport never creates this one branch. It also ignores many of the merges.
<mgedmin> what about https://github.com/nirvdrum/svn2git ?
<mgedmin> I'm confused -- are there two different tools both called svn2git?
<wilx> mgedmin: It looks more like forks of the same source.
<mgedmin> I recently watched a linuxconf.au video about svn -> git conversion tools
<mgedmin> the guy mentioned three existing ones, described their downsides (two couldn't handle messy conversions, the last one was too slow, iirc) and told how they wrote a fourth tool based on those
<mgedmin> unfortunately I don't remember any of the tool names
<mgedmin> I wonder if svn-all-fast-export is that fourth tool
<mgedmin> btw, re: "It seems to convert only a single branch at once."
<mgedmin> bzr svn-import should be able to handle multiple branches
<mgedmin> afaiu
<wilx> http://barrbrain.github.com/svn-dump-fast-export/
<wilx> This is the one from the video, I think.
<wilx> I believe it did not work well either. Let me retest.
<jelmer> wilx: 'bzr svn-import' will indeed import all branches from the repository
<wilx> Ah, right, it crashed, the http://barrbrain.github.com/svn-dump-fast-export/ tool.
<jelmer> fast-import isn't a great format for conversion that doesn't involve git, as it can only represent things that exist in git
<wilx> Ah, I know why I did not like svn-import. It seems that it entirely ignores all merges.
<wilx> Hmm...
<wilx> But cherry pickings are not recored in bzr specially, right?
<wilx> That might be it.
<jelmer> wilx: yeah, they're indeed not recorded (yet). None of the DVCSes track cherry pick merges in their metadata yet.
<mgedmin> I think arch used to :)
<mgedmin> is it not a DVCS now?
<wilx> Arch/TLA was weird.
<fullermd> Darcs does too.
<wilx> jelmer: Well, The SVN->GIT conversion did show some merges though.
<fullermd> Probably need a 'conventional' in that sentence   8-}
<jelmer> mgedmin: ah, sorry, yes - arch did indeed
<mgedmin> don't mind me, I'm just trolling
<mgedmin> when people say "DVCS" nowadays, they mean git + hg + bzr
<fullermd> Actually, I'm pretty sure they mean "git".
<fullermd> (see, _that's_ trolling!)
<spiv> fullermd: really, I thought they meant "monotone or darcs" ;)
<fullermd> Don't be such a fossil.
<mgedmin> svk gets no love for some reason ;)
<wilx> SVK seems like SVN with disconnected operations.
<wilx> Not too distributed.
<wilx> Though I have never used it seriously.
<mwhudson> mgedmin: i have no idea why!!
#bzr 2012-02-24
<KombuchaKip> Just to confirm, there is still no way to edit a previous commit log entry (viz. #210142)?
<vila> KombuchaKip: confirmed (unless you can uncommit and re-commit)
<vila> hi all !
 * fullermd vila at waves.
 * vila waves back at fullermd and wonders . o O (He cannot be in the same TZ anymore...)
<fullermd> Pfui.  TZ's are for the little people.
<didrocks> vila: hey, how are you?
<vila> didrocks: fine, thanks, may I help ?
<didrocks> vila: I guess you may, yes!
<vila> good, consider yourself helped
<didrocks> vila: the tarmac merger for unity is blocking on a bzr traceback
<vila> :)
<didrocks> :p
<vila> care to pastebin it ?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<didrocks> vila: http://paste.ubuntu.com/855099/
<didrocks> vila: hey, how are you? the first time I encounter that
<didrocks> vila: I guess you need the offending branch!
<didrocks> vila: I think it's tarmac at the end using an empty --author or something like that?
<vila> well, this looks like a tarmac traceback, a '\n' in an author looks indeed wrong
<didrocks> vila: so basically, that would mean tarmac try to bzr commit --author "foo\n" ?
<didrocks> (just need to know where to start to look at)
<vila> from the traceback, yes
<didrocks> ok, that's all I needed to know!
<didrocks> thanks vila :)
<vila> you're welcome ;)
<didrocks> vila: ok, found it
<didrocks> vila: apparently rev.get_apparent_authors() in bzrlib can returns some \n
<didrocks> there was this code in tarmac:
<vila> 8-/
<didrocks> apparent_authors = rev.get_apparent_authors()
<didrocks>                 for author in apparent_authors:
<didrocks>                     author.replace('\n', '')
<didrocks> the last line, to workaround the issue, should be: author = author.replace('\n', '')
<mgz> morning all!
<vila> hi mgz
<vila> didrocks: nice catch
<didrocks> vila: I'm wonering why rev.get_apparent_authors() gives authorname with \n (as it's about merging already existing commits)
<vila> didrocks: still worth a bug against bzr IMHO, either we should accept (and filter) '\n' or we shouldn't output them
<didrocks> wondering*
<didrocks> vila: agreed
<didrocks> vila: will open one
<vila> thanks
<didrocks> vila: and I have a branch with this! :)
<didrocks> (as an example)
<vila> a bzr one or a tarmac one ?
<didrocks> bzr one
<vila> oh, as a bug reproducing one :)
<didrocks> lucky you, isn't it? :-)
<vila> yeah, great !
<didrocks> will open it shortly
<vila> 2.5.0 frozen, build installers and packages !
<fullermd> Sos, that's more than 10 million files later on lplibrarian.
<fullermd> Hm.  Y'know that tarball is more than 2 meg bigger than 2.4.2?  Is that right?
<jelmer> fullermd: what has changed?
<fullermd> Hm.  Well, all the stuff in po/ is new, and that's over 8 meg before compression.  I guess that's it.
<jelmer> ah, yep
<fullermd> It's really hard to find a current bzrtools from the LP page   :|
<fullermd> The series and download link say the latest is 2.3.0, which I know isn't true.  But I always have to dig around for a while before finding the current.
<fullermd> Hm.  The build process gives a 'some compiled extensions could not be loaded' error at the end every time.  Doesn't once installed though.  .bzr.log doesn't say anthing about what failed.
<fullermd> I don't remember seeing that before.  Is that just some new quirk of the build process?
<vila> fullermd: translations ?
<vila> (was for the 2m, yeah, you noticed)
<vila> hmm, 'some extensions could not be loaded' rings no bells, on the other hand, I'm not sure I start from scratch often enough to have encountered it
<vila> fullermd: did the warning also appear in .bzr.log and if yes for which command ?
<fullermd> Happens every time I ./setup.py build.
<fullermd> (even when there's nothing new to do)
<fullermd> It does, but it doesn't say anything about it.
<fullermd> Fri 2012-02-24 05:58:40 -0600
<fullermd> [25588] 2012-02-24 05:58:41.025 WARNING: bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<fullermd> That's the full extent of it.
<vila> meh
<vila> test leak ?
<fullermd> Doubt it.  build doesn't run the test suite.
<fullermd> It's right at the end of the output
<fullermd> [...]
<fullermd> running build_mo
<fullermd> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<fullermd> Does it not do that for you?
 * vila tries to reproduce in a clean env
<vila> ha, got it
<vila> right, so, no command probably hints that it's a direct bzrlib use, I'd bet for some translation script which do not care about extensions
<vila> ./tools/generate_docs.py man, bingo
<vila> fullermd: so, harmless
<vila> uselessly annoying though
<vila> fullermd: can be worked around by running make first
<fullermd> I figured.  So I recklessly sent the update in anyway.
<vila> hehe
<vila> thanks for your attention to details *anyway* ;-p
<fullermd> Hey, nit-picking stuff that doesn't really matter is my middle name.
<fullermd> (makes filling out forms a PITA, true, but otherwise it's kinda fun)
<vila> ooooh, 'd' for Details, got it ;)
<fullermd> Well, *I* would pick the d for Details.  But my parents picked it, so it was probably more like d for "dammit, will you shut up about the stupid details already?"
<vila> Where is my milk ? Why is it too cold ? Kind of remarks ?
<fullermd> Dad?!
 * vila rewinds the tape to listen again...
<vila> jelmer: sphinx is already a hard dependency in debian/ubuntu ?
<jelmer> vila: no, but it will be used if present
<jelmer> vila: I'd either have to add a "Build-Conflicts: python-sphinx" or a patch to disable the sphinx tests
<jelmer> I'm a bit wary of doing the first because it means everybody who wants to build the bzr debian package has to uninstall sphinx first
<vila> ha, right, so a packager trying to build locally may encounter the issue, sorry, missed that
<vila> yup, go for disabling the tests, I think the longer term fix will be to use the provided texinfo builder and only resort to ours for the older sphinx versions (including tests)
<fullermd> Oh, crud.  I missed the .mo files...
<vila> fullermd: not a big deal for 2.5.0 I think
<fullermd> I mean in the package plist.  It is a deal   :p
<vila> fullermd: we'll see how it goes for 2.5.1
<vila> fullermd: up to you, what I meant is that translations are just starting so most of the strings will still appear in english anyway
<vila> fullermd: of course if not carrying the .no files breaks bzr usage, it's a bigger deal ;)
<fullermd> No, other way around.
<fullermd> They're installed, but without them in the plist they don't get removed on uninstall.
<vila> ouch
<fullermd> Yeah, that's what I'll be feeling when somebody notices   :p
 * fullermd tries to quickly sneak in the change before anybody notices the PR...
<fullermd> Well, that takes some of the fun out of updating.  Used to be, I could just look at $PYTHON_SITELIB/bzrlib and know I'd caught 'em all.
<vila> :)
<jelmer> vila: I'm getting a bunch of test failures in bzrlib.tests.test_btree
<jelmer> vila: we haven't changed any of that code recently, have we?
<jelmer> http://pastebin.ubuntu.com/855321/
<vila> rings no bell
 * vila looks
 * vila looks again
<vila> wth ?
<vila> jelmer: during a build ?
<jelmer> vila: yes
<jelmer> build of 2.5.0
<vila> jelmer: do you know the last successful build to narrow the search ?
<vila> my first suspicion will be around extensions but we didn't change anything there either AFAIR
<jelmer> vila: let me see if it's spurious first
<vila> even spurious will be worrying there :-/
<jelmer> yeah, I agree
<vila> jelmer: any news of these failures ?
<jelmer> vila: yep
<jelmer> vila: it's reproducible
<jelmer> but I can only reproduce it on sid, not on precise
<vila> wow, kind of rules out bzr itself no ?
<vila> cpython ? pyrex ?
<jelmer> vila: It seems hard to speculate about that at this point.
<jelmer> vila: cython
<vila> oh no, I left a pdb.set_trace() in bzrlib/doc_generate/builders/texinfo.py and it found its way into the tar.gz :-(
<mgz> whoops
<jelmer> vila: hmm, I don't see a significant difference in the cython and python versions on si and precise
<vila> hmm, so, I can think of only two cases where this will trigger: 1) trying to use the texinfo builder (no big deal, even where we use sphinx we don't use the texinfo builder) 2) When running the full test suite where sphinx is installed which is already a filed bug
<vila> jelmer: and between the generated C files between <last-known-working> and 2.5.0 ?
<vila> but may be the extensions idea is a red herring, I can't reproduce so I'm guessing wildly I can be completely off
<vila> jelmer, mgz: I'll remove the offending pdb.set_trace() from the 2.5 *branch*, that will need to be merged on trunk
<vila> jelmer, mgz: it also demonstrates that pqm doesn't care :-}
<vila> jelmer: even if you disable the texinfo tests, you may want to get rid of the pdb too, just in case (and sorry again about that)
<vila> I don't think it's worth releasing 2.5.1 just for that
<jelmer> let's see what the cause is of this btree test failure, too
<vila> jelmer: yup, 2.5.0 won't be released next week anyway (only the week after) but it would be good to fix the failure before pushing to debian/ubuntu in the mean time
<vila> looking at bzr diff -r bzr-2.5b5..6478 ( to avoid the .mo noise) reveals nothing regarding indices, did you try reproducing with 2.5b1 or something like that ?
<jelmer> vila: up to 2.5b5 everything built fine in sid
<jelmer> perhaps I can try rebuilding 2.5b5, maybe something in sid has changed
<vila> yup, that was my suggestion
<vila> good to know 2.5b5 built well though
<vila> EOD'ing, EOW'ing, have fun guys !
<mgz> heh, needless outrage on the mailing list followed immediately by a whoops sorry message
<jelmer> :)
 * jelmer is still stumped by the test failure
<mgz> go artur/me takes a look
<mgz> ...at the test failure
<mgz> ...the btree ones from the pastebin up there right?
<mgz> looks like a cython type issue on a 64 bit build?
<jelmer> perhaps
<jelmer> but why is it only happening on recent snapshots of debian sid and not on precise?
<mgz> what's the exact machine those failures are from?
<mgz> and the cython version?
<jelmer> chroot on my desktop machine
<jelmer> a sid chroot on my desktop machine (x86_64)
<mgz> your desktop is... amd64?
<mgz> hm... some of the failures make that look less likely
 * mgz double checks the put_file implementation
<mgz> jelmer: well, osutils.pumpfile is technically borked
<mgz> but I'm not sure if fixing that will help you?
<mgz> hack the tests to get an actual byte diff output perhaps?
<mgz> or I can patch either atomicfile or osutils to be completely correct
<jelmer> mgz: hmm
<jelmer> I do vaguely recall we changed something in pumpfile - do you remember?
<mgz> well, the most apparent problem seems to be this in atomicfile:
<mgz>     def write(self, data):
<mgz>         """Write some data to the file. Like file.write()"""
<mgz>         os.write(self._fd, data)
<mgz> that's not like file.write at all, doesn't handle short writes or interrupts
<mgz> why you'd be hitting it when no one else has though I do not know.
<jelmer> some recent python change in sid perhaps
<mgz> anyway, easy enough to turn into a loop and see if it affects the failures
<mgz> see osutils.send_all for an approximate template
<mgz> if not, we really need to know which bytes are actually missing, rather than just that the expected count is too low
<jelmer> I'm not sure if I have enough time to debug it just now, so I think I might just file a bug about it for now.
<mgz> if I wave a patch at you, can you apply and see if it changes things?
<jelmer> mgz: sure
<mgz> okay, sec
<mgz> oh, and are the failures completely reliable and unchanging, did you notice?
<mgz> would suggest this theory is wrong.
<jelmer> mgz: yes, they seem to be consistent
 * jelmer was wondering if perhaps it was a \r\n<->\n issue
<mgz> yeah, me too, but I don't see how we'd get that on nix and not windows
<mgz> okay, rebuilding extensions, apart from the 64bitness this box should be setup similarly to yours
<mgz> and I have the failure
<mgz> ace.
<jelmer> ah, good
<mgz> hm, I also get this:
<mgz> failed to load compiled extension: .../bzrlib/_static_tuple_c.so: undefined symbol: __Pyx_PyIdentifier_FromString
 * mgz does make realclean to be sure
<mgz> still there, will deal with later
<mgz> jelmer: okay, new theory
<mgz> we've got an updated zlib that compresses very slightly better
<jelmer> I guess that's possible
<jelmer> let me try installing the sid one on precise and see if that breaks things
<jelmer> mgz: yes, that's it
 * jelmer files a bug
<dOxxx> howdy
<dOxxx> so the whole ssl cacert thing... any idea how I would go about test it?
<wgz> dOxxx: just giving a https url as a branch location is okay for starts
<wgz> vila had a test site that had some extra things like self signed certs but I can't find it right now
<dOxxx> wgz: can you give an example URL from like launchpad?
<wgz> `bzr info https://bazaar.launchpad.net/notabranch` for instace
<dOxxx> aha, I see. thanks.
<dOxxx> of course now if I could get sphinx to work, maybe I could get somewhere..... ;_;
<wgz> have you seen the log from earlier today?
<dOxxx> no?
<wgz> vila had some sphinxy points
<dOxxx> for me, it just breaks into pdb when sphinx is invoked by the bzr build
<wgz> http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t11:23
<wgz> yeah, he realised after making the tarball
<wgz> http://irclogs.ubuntu.com/2012/02/24/%23bzr.html#t13:28
<dOxxx> hmmm
<dOxxx> so I have to run `./tools/generate_docs.py man` before the main bzr setup.py?
<wgz> whatever works to get you past that
<dOxxx> eugh no the pdb thing is something else
<dOxxx> *sigh*
<dOxxx> it's the second thing you linked
<dOxxx> vila makes my life hard :P
<wgz> you certainly deserve a small piece of cake when you're done
<dOxxx> wgz: sorry to bother you, but you're the only one around :)
<dOxxx> wgz: any idea what the error 'Builder 'texinfo' is a builtin builder' means from sphinx?
<wgz> I'm happy to be bothered :)
<wgz> that's the thing talked about in the log right?
<wgz> bzr registers its own texinfo builder for sphinx,
<wgz> but the newer version of sphinx has added one to the builders it provides builtin
<dOxxx> yeah so it would appear
<wgz> I agree it's not clear what the right short term fix is
<wgz> you should be able to run the build process without generating the tex stuff from what I gather?
<dOxxx> maybe I should try reverting to an older version of sphinx
<dOxxx> well then I don't get documentation...
<wgz> that's all that seems to be suggested, beyond "try and see at some point in the future if the builtin one will work for us"
<dOxxx> I'm building the OS x installer, so I need to include docs
<wgz> ...ah, and you depend on that rather than the html?
<dOxxx> so it's only the pdf?
<dOxxx> that causes this problem
 * wgz hasn't looked at your process in detail yet, I just crib from your nice list of plugin versions when doing windows installers
<dOxxx> I build both html and pdf, so users have a choice of which they prefer
<dOxxx> heh
<wgz> that seems possible
<dOxxx> since pdf is pretty well supported on os x
<wgz> trying a sphinx downgrade seems sensible
<wgz> as I agree osxy people likely expect pdf
<wgz> okay, I've got to eat something, but am around, so keep throwing questions in here as you need
<dOxxx> thanks!
<dOxxx> halleluja! downgrading to 1.0 seems to have worked
<dOxxx> I spoke too soon
<dOxxx> wgz: so using sphinx 1.0 crashes with some other error and just running 'make html-sphinx' still gives the texinfo is a builtin error
<dOxxx> is there any alternate way of building the html docs?
<dOxxx> ah, 'make html-docs'
<wgz> so, the smart thing for this release is just to not do the pdf docs?
<wgz> would be nice if sphinx were a little less... volatile
<dOxxx> wgz: I'm doing a build with just html docs but I'm going to have to rework the packager layout as well since it's expecting pdf docs
<dOxxx> hmm actually no
<dOxxx> the packager doesn't install the docs
<dOxxx> I leave them in the disk image
<dOxxx> so maybe this won't be so bad...
<wgz> well, would be nice if one thing at least was simpler than expected this evening
<fullermd> As long as that's happening, can I have a pony too?
<wgz> certainly, as long as it doesn't need sphinx to build
<dOxxx> one last thing to try to get sphinx working....
<fullermd> Sweet.  I shall name him Gumdrops, and he will follow me everywhere and bite people who cut me off in traffic.
<dOxxx> afk dinner while my build crash & burns
#bzr 2012-02-25
<dOxxx> omg it worked
<wgz> dOxxx: you clearly have the magic
<dOxxx> wgz: clearly. I got the idea from the fedora bug for the same problem. patched the bzr texinfo builder to register itself under a different name so it doesn't clash with the builtin texinfo builder
<dOxxx> now I have to figure out how to handle this cacert thing
<wgz> so, you don't actually have to now
<dOxxx> well I still get that error about the cacerts being wrong
<wgz> after 2.5b6 the default got flipped so if the certs aren't there it will just not verify
<wgz> ...urk?
<dOxxx> oh hmm
<dOxxx> I see
<dOxxx> I didn't have 2.5b6 installed when I tested it
<wgz> it still complains?
<dOxxx> I get this like 8 times:  Not checking SSL certificate for bazaar.launchpad.net: 443
<dOxxx> and then the normal command output
<wgz> https://code.launchpad.net/~vila/bzr/929179-default-ssl-certs/+merge/93177 <- is the mp
<wgz> ah, okay, so... it doesn't error, but does print something
<dOxxx> yeah I just had an old version installed when I first tried it
<wgz> and for whatever reason that https command spams connections
<dOxxx> correct
<wgz> so, what I did, which is probably not appropriate for osx
<wgz> was stick the bundle that the curl guys extract from mozilla and publish on their website in the install directory
<wgz> but doing the right thing for osx no doubt means writing extra code
<dOxxx> yeah it means writing extra code that I do not know right now :)
<dOxxx> I can do the same hack as you
<wgz> http://curl.haxx.se/docs/caextract.html
<dOxxx> just tried it by downloading the cacert file from that site and then using `bzr -Ossl.cacert=path/to/file`
<wgz> will just check what vila left in as the expected location for osx...
<wgz> ^and that worked?
<dOxxx> errr... it seems that it worked with the older verison of bzr, but now with 2.5.0 it's still giving me the "not checking ssl certificate" spam
<wgz> ah, dammit, the code is:
<wgz> 'pass'
<dOxxx> oh well, it's not like I don't already have 2 patches for bzr code, one more is not going to hurt
<wgz> oh, oh dear. it really shouldn't do that with 2.5, the change must have been wrong
<wgz> okay, so changes three and four:
<wgz> revert the change from the mp I just linked
<wgz> change the darwin branch in bzrlib.transport.http._urllib_wrappers.default_ca_certs to the same as the win32 bit above it
<dOxxx> I was considering storing it in /usr/local/share/bzr just to be nice about it
<wgz> by all means be superior :)
<dOxxx> haha
<dOxxx> aha, so if I do this: `bzr -Ossl.ca_certs=cacert.pem -Ossl.cert_reqs=required` then I don't get the error or the spam
<dOxxx> which is basically what the patch will accomplish in code instead
<wgz> right
<wgz> it seems none was a bad idea.
<dOxxx> I think I grok this now
<wgz> what's odd is I'm sure it was vila that explained to me why none was a bad idea
<dOxxx> hehe
<dOxxx> so default_ca_reqs should always return 'required'?
<dOxxx> oh I see, just set the default for ssl.cert_reqs to required in the option definition
<wgz> yeah, as you're supplying it
<dOxxx> I can never tell when I should be using single quotes or double quotes for a string...
<wgz> I change my mind every year or so :)
<wgz> `bzr merge -r6474..6473 bzrlib/transport/http/_urllib2_wrappers.py` would do... but you're going from the tarball
<dOxxx> yeah, I'm modifying my bzr 2.5 working tree, generating a patch from that and then apply that patch during the build process
<dOxxx> the whole process is automated from extracting the source onwards so I have a patching mechanism
<wgz> next time you do this I need to look over your shoulder and pick up tips
<dOxxx> http://pastebin.com/pRCswJ67
<wgz> lgtm.
<dOxxx> you're welcome to have a look at lp:bzr-mac-installers to see my build scripts
<dOxxx> it's inherited code so it's not quite as nice as I would like it to be but I've been making improvements slowly here and there
<wgz> sticking up the first hunk as a merge proposal against 2.5 wouldn't hurt
<dOxxx> I guess so...
<wgz> okay, bed for me I think
<dOxxx> seeya wgz
<dOxxx> ssl cacerts hack works :P
#bzr 2012-02-26
<goddard> i was curious if bzr was a good choice for version control for website development?
<goddard> I want to have a dev site and a live site kind of a two step process
<bob2> that's fine in any vc system
<bob2> note that none of the free dvcs systems handle huge binary files well
<mgrandi> is there a way to
<mgrandi> view diffs in a better way? like having the 'complete' file along with the diff?
<LarstiQ_> mgrandi: you can do that right now?
<mgrandi> what do you mean?
<mgrandi> as in i have a diff on launchpad
<mgrandi> but its not the complete file...
<mgrandi> and its a conflict, so i need to have the entire file to see what i'm changing
<LarstiQ_> mgrandi: ah, viewing on launchpad
<LarstiQ_> mgrandi: I don't know about that, but I would work with a local branch
<mgrandi> well it is a local branch, a branch of the bzr source code, but it ahd conflicts merging with 2.5 , now trunk i guess
<LarstiQ_> mgrandi: so say you have two branches original/ and modificiation/ next to each other, `cd modification; bzr diff -r ancestor:../original` to get a diff in the style launchpad gives you
<LarstiQ_> mgrandi: and then use your editor to view the diff and the original file
<mgrandi> ah.
<LarstiQ_> mgrandi: alternatively, you could try qdiff from qbzr
<mgrandi> will that load a diff file?
<LarstiQ_> mgrandi: nafaik, but it will generate and show diffs
<mgrandi> hmm =/
<LarstiQ_> mgrandi: hmm?
<mgrandi> well is there some program that shows the diff like qdiff does? cause i like having the user inferface part of that as its easier
<mgrandi> cause i can apparently download the diff file: https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix/+merge/93144
<LarstiQ_> mgrandi: so if I branch lp:~markgrandi/bzr/gpg_devttynotfound_fix and run `bzr diff -r ancestor:../2.5` the diff comes up clean
<mgrandi> ok. thanks =)
<mgrandi> new to diff files and whatnot.
<mgrandi> (not the idea just working with em)
<LarstiQ_> mgrandi: in this case it looks to me like launchpad generated the diff at an inopportune time or some such
<mgrandi> well it did it before 2.5 was frozen
<mgrandi> i was just busy and trying to figure out how to view the entire file so i didn't break things
 * LarstiQ_ nods
<mgrandi> and it was sketchy anyway since it was proposed for merging at 2.5b6
<LarstiQ_> mgrandi: it can still go into the 2.5 branch even if it doesn't make 2.5.0, imo
<LarstiQ_> mgrandi: so with that in mind, the merge conflicts are resolved. Only thing left is a news entry :)
<mgrandi> yeah. thats actually a question i have about bzr's development (and i guess in development in general), if that gets fixed in 2.5, does it have to be applied to trunk as well?
<LarstiQ_> mgrandi: it will be included in trunk automatically next time someone merges 2.5
<mgrandi> ah ok. so i'll fix it up tonight once i finish this thing
<LarstiQ> mgrandi: news entry goes in doc/en/release-notes/bzr-2.5.txt btw
<mgrandi> thanks
<mgrandi> so just fix the merge and add something in that file?
<LarstiQ> mgrandi: merge already looks fine to me, so just add an entry to that file
<mgrandi> isn't the merge conflicted?
<mgrandi> thats what it says to me on launchpad
<LarstiQ> mgrandi: locally it was fine, that beats what launchpad says
<mgrandi> haha
<mgrandi> ok then
<LarstiQ> mgrandi: if you do get into trouble you can blame me and I'll fix it for you ;)
<mgrandi> k =P
<mgrandi> and LarstiQ i updated it with the news entry. thanks again =)
<LarstiQ> mgrandi: np, thanks for the work!
<mgrandi> all 5 characters of it haha
<LarstiQ> mgrandi: every bit of help is welcome :)
<LarstiQ> mgrandi: I commented on the mp, it does seem I was not quite awake yet
<mgrandi> haha. ok
<LarstiQ> mgrandi: as said I can fix that up, and/or I can tell you how to deal with it
<mgrandi> whats the command to show the full diff? im pretty sure its just a small change
<LarstiQ> mgrandi: basically, and what I should have realized, is that lp does: `cd 2.5; bzr merge ../gpg_devttynotfound_fix`
<LarstiQ> mgrandi: because we are merging _into_ 2.5
<mgrandi> ah, not the other way around.
 * LarstiQ nods
<LarstiQ> mgrandi: so if you do that and then do `bzr qdiff`, it will show you the same output
<mgrandi> k let me do that real fast
<LarstiQ> mgrandi: then under View Options you can toggle Complete to see the entire file
<mgrandi> k got it
<mgrandi> let me fix thisss
<LarstiQ> mgrandi: I need to clear out an apartment and prepare for a talk. I'll check back later to see how things are going
<mgrandi> kk!
<LarstiQ> mgrandi: so feel free to highlight me on irc for any questions you run into
 * LarstiQ away
<mgrandi> LarstiQ, well i finished resolving the conflicts, now what do i do, do i push to the gpg_devttynotfound_fix branch? or do i commit the merge of my machine and push that somewhere?
<mgrandi> LarstiQ, you can tell me and i'll do it later, now its bedtime~
<Carletto> ciao
<Carletto> !list
<ubot5> No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<LarstiQ> mgrandi|sleep: after resolving the conflicts: commit, push, update merge proposal
<LarstiQ> mgrandi|sleep: that last one might happen automatically, I'm a bit vague on what launchpad does nowadays
 * jelmer waves
<LarstiQ> hey jelmer
<jelmer> hey LarstiQ, how's it going?
<LarstiQ> jelmer: stuck on talk preparations
<LarstiQ> jelmer: how about you?
<jelmer> LarstiQ: what are you going to talk about?
<jelmer> LarstiQ: trying to clean up my digital garbage
<LarstiQ> jelmer: tensor products mostly
<jelmer> ah, uni stuff?
<LarstiQ> jelmer: yup
<wgz> jelmer: ah, see your email (on the bzr list too)
<wgz> we have a GSoC enquiry
<wgz> you might have some useful points to add being a veteran
<jelmer> wgz: heh, I'm not sure if veteran is the right word :)
<wgz> expert? maven? guru?
<jelmer> wgz: euhm, let's stick with veteran :)
<LarstiQ> jelmer: "ervaringsdeskundige"
<jelmer> hehe
<mgrandi|sleep> LarstiQ, now that i'm awake haha, i'm confused on commiting, cause since i did the merge, it says that if i commit then i do the merge locally, do i do that and then push to gpgdevttywhatever branch?
<wgz> mgrandi|sleep: yes
<wgz> basically the stages are: pull latest 2.5, merge local 2.5 into local gpgdev, resolve conflicts in files, commit, push gpgdev
<mgrandi|sleep> ok. its just weird since i'm pushing the 2.5 branch into the gpgdev one, i'll do that
<LarstiQ> mgrandi|s: I think the answer is yes, though what says you're doing the merge locally?
<mgrandi|sleep> well you told me to cd 2.5, bzr merge ../gpgdevttynotfound_fix
<mgrandi|sleep> to get it so it would generate the merge conflict stuff
<LarstiQ> mgrandi|sleep: aye
<mgrandi|sleep> so then, now i commit to the 2.5 branch the 'merge' of the gpgdevtty branch, and then do i just push that to the one on launchpad?
<LarstiQ> mgrandi|sleep: push the result to gpgdev, yes
 * LarstiQ is being dense today
<LarstiQ> mgrandi|sleep: that should be it
<mgrandi|sleep> kay. just seems weird that i merge it, push to that branch and then launchpad i guess will merge it with 2.5 when its already merged
<LarstiQ> mgrandi|sleep: yeah, it is a bit overkill in this case (even if you had done what wgz said instead of what I said)
<mgrandi|sleep> ah
<LarstiQ> mgrandi|sleep: with larger branches, the danger lurks that fixing the merge conflicts needs knowledge of what was done
<mgrandi|sleep> yeah that makes morse sense
<LarstiQ> mgrandi|sleep: in which case it is safer to have the original author do it, insteadd of the integrator. Hence why poolie asked for it
<mgrandi|sleep> yeah
<mgrandi|sleep> next time i'll merge 2.5 into the whatever branch and commit that, that seems to make more sense hehe
<mgrandi|sleep> when i do this again
<LarstiQ> mgrandi|sleep: indeed, sorry for my density today :)
<mgrandi|sleep> nah its fine, just trying to understand the workflow~
 * LarstiQ nods
<mgrandi|sleep> and i pushed it
<LarstiQ> mgrandi|sleep: and the diff on launchpad is clean now too, cheers!
<mgrandi|sleep> yayyyy
<wgz> approvÃ©d
<mgrandi|sleep> kk
<mgrandi|sleep> and now i eat food~
<LarstiQ> aand bedtime
<wgz> night!
<wgz> ...I think I won't try and review Jelmer's 3596 line diff this evening
<jelmer> wgz: :)
<jelmer> it's all simple renames :)
<jordi> hey
<jordi> quick bzr newbie question
<jelmer> hi
<jordi> I have a few changes on a bzr branch of lp:intltool
<jordi> what's the "lp way" of sending this diff to danilo?
<jelmer> jordi: #launchpad is probably a better channel for this sort of question
<jelmer> jordi: basically, commit the changes, push it to launch ("bzr push lp:~/intltool/branch-name")
<jelmer> jordi: and then propose a merge ("bzr lp-propose")
<jordi> jelmer: thanks
<jordi> I think something went a bit differently than expected
<jordi> Using default stacking branch /+branch-id/41904 at chroot-94560208:///~jordi/intltool/
<jelmer> that's correct
<jordi> jelmer: that's the name of my branch? It was meant to be manpage-fixes :)
<jelmer> no, that's just saying what your branch is stacked on
<jordi> jelmer: hm, once pushed, there's no way of changing a commit message, right? :)
<wgz> jordi: you can, especially if you've not told anyone else to get your branch yet
<jordi> geez, python-launchpadlib has a few dependencies
<jordi> wgz: not yet, no
<wgz> uncommit locally, commit with fixed message, then push --overwrite
<jordi> wgz: worked great, thanks!
<jordi> jelmer, wgz, thanks for the tips
<jelmer> np :)
<poolie> hi all
<jelmer> hi poolie
#bzr 2013-02-18
<leo2007> is bzr dead?
<spiv> It's probably fair to say it's in "maintenance mode"; see recent discussions on the mailing list.
<leo2007> hmm...
<spiv> Canonical's developers don't appear to be actively working on big new features, for instance.
<leo2007> I see.
<leo2007> pretty sad for projects that migrated to bzr instead of git.
<spiv> Yes, definitely a shame.  bzr is pretty nice.
<leo2007> unfortunately at this stage it is pretty pointless for bzr to carry on. Just not enough mindshare.
#bzr 2013-02-19
<rindolf> Hi all. What can I do about this - http://paste.debian.net/235532/ ?
<rindolf> I'm not on Debian - I'm on Mageia Linux Cauldron.
<mgz> rindolf: generally you just delete/move the directory, then `bzr resolve path/from/conflict`
<jelmer> what he said :)
<m1sc> the ssl cert of my bazaar server changed a couple of days ago. bazaar doesn't  accept the new cert though ("certificate verify failed"). it is a valid cert though, accessing the server via curl or a browser works as expected. ideas?
<jelmer> m1sc: make sure bzr is using the right ssl ca certificate
<rindolf> mgz: thanks, that worked.
<rindolf> mgz++
<m1sc> jelmer: I'm not sure I understand: it's not some self signed certificate, so bzr should just accept it, no..?
<jelmer> m1sc: it has to be signed by whatever CAs bzr knows about
<jelmer> m1sc: it might be that the browser or curl are using a different ca list than bzr
<jelmer> for example, were you previously perhaps specifying a custom CA file?
<m1sc> jelmer: no, no custom ca
#bzr 2013-02-20
<quotemstr> How can I filter "bzr log" output to only files under a certain directory?
<quotemstr> Ah, it's under "path filtering"
<dpb_> Hi all -- tarmac using bzrlib is giving a weird error that I'm not sure how to debug.  Anyone have a good pointer as to what could be messed up with the branch (email redacted)? bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {EMAIL_REDACTED-20130220105959-ndac3b16ciudc4uh} because its ancestry shows a ghost at {tarmac-20130216003627-2psujwlnya4ycuk2}')
<jelmer> dpb_: hi
<xnox> dpb_: well it clearly has ghost revisions =) hence some operations fail. What version of bzr are you using. oh jelmer, ignore me and listen to the overlord.
<jelmer> dpb_: that error is probably caused by a combination of a bug in bzr and a particular way of bzrlib being used by tarmac
<jelmer> hey xnox (-:
<dpb_> jelmer: hmm.  I'm not sure on even how to reproduce this. :)
#bzr 2013-02-22
<DrZaius> i come from git. I use giggle to see repositories... is there something like that for bzr?
<jelmer> DrZaius: hi
<jelmer> DrZaius: try 'bzr viz' if you have bzr-gtk installed
<DrZaius> yup jelmer thats what i was looking for
<DrZaius> ty
<DrZaius> i was installilng packages but after grepping for a bin, couldnt find one :D
<LarstiQ> DrZaius: or `bzr qlog` with qbzr I suppose
<DrZaius> n... thank you LarstiQ
#bzr 2013-02-23
<fayaz> hi, i'm looking for a commenting system for bazaar commit streams and diffs. launchpad doesn't  seem to have that. is there any other alternative?
<DrZaius> im using bzr vid... but is awfully slow every time i click somewhere and its not even showing diffs or code
<DrZaius> is it supposed to be like that?
<DrZaius> is there anything better to watch the repos?
<jelmer> DrZaius: bzr qlog
<DrZaius> well, much nicer than vid :)
<DrZaius> ty
#bzr 2014-02-17
<vedic> Hey friends, I am learning bzr. I want to setup repository on a remote server. From that server, my friends will pull the updates and push their work. Also want to ensure that no body else other than friends (total 5) should be able to pull or push to that repo. How to setup such a bzr repo
<vedic> I also don't want to give access of remote server (i.e. they should not be able to get ssh access to the server)
<vedic> Any tutorial or blog post will be very helpful
<fullermd> You can do stuff in ssh config to restrict what commands a user is allowed to run.
<vedic> fullermd: ok
<fullermd> Of course, in extremis, a user can certainly abuse bzr to read arbitrary stuff on the server.  And possibly pull off enough gymnastics to run stuff.
<vedic> fullermd: Then you mean to say I create user accounts on that server and for each user I create public/private key and restrict access to certain thing using ssh config?
<fullermd> Yeah.  Just know that if they really, really, really want to, they can probably break out of jail.
<vedic> fullermd: Ok, tell me if I am doing write: 1) I logged into remote server. Into my home directory (say /home/f1) I created a shared repo as: bzr init-repo projectx; bzr init projectx/trunk; Now how should I allow others to pull and push from this repo? If I create f2, f3, f4, f5 users then they all will have access to their home directory. How will they access /home/f1/projectx/trunk?
<vedic> *right*
<fullermd> Generally by putting them all in a group, and chgrp/chmod/etc'ing the repo.
<vedic> I see
<fullermd> Another possible way is to have a single shared account that owns it, and have everybody ssh in as the same user (probably with different keys, for management dolphins)
<vedic> fullermd: That is much better
<vedic> So there also I can limit the commands for each key?
<fullermd> Yeah, there's some syntax in the authorized_keys file for it.  'd have to check the openssh docs.
<vedic> ok
<vedic> fullermd: I am going ahead with creating multiple users: sudo useradd -r -s /bin/false USERNAME
<vedic> Instead of keys
<vedic> And will soft link the repo in my home to /usr/local/projectx/trunk
<fullermd> Setting shell to false probably won't work; I think ssh generally needs a "real" shell of some sort to be able to execute programs remotely.
<vedic> fullermd: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html#using-ssh
<vedic> I think there he explains the same thing you suggested
<vedic> Is bzr loosing ground? http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html
<vedic> People are switching or opting git and hg
<vedic> Why is so? can anybody tell?
<LeoNerd> Network effect
<LeoNerd> Everyone does, so everyone else does
<vedic> LeoNerd: Just a network effect?
<fullermd> Canonical stopped developing it, and nobody else has started.
<vedic> IRC of bzr has 78 users but for git has 1000+
<vedic> fullermd: I see
<vedic> for the fate is unknown
<vedic> *so*
<DarkLinkXXXX> I tried building bzr, but I got an error with cython.
<DarkLinkXXXX> bzrlib/_dirstate_helpers_pyx.pyx:1815:36: undeclared name not builtin: cmp
<DarkLinkXXXX> Anyone know something about this?
<Enlik> maybe you are using Python 3 instead of Python 2?
<Enlik> (my guess after seeing the name; I may be wrong)
<DarkLinkXXXX> Oh.I thought bzr supported python 3.
<DarkLinkXXXX> My bad.
<jelmer> there is an attempt to add python3 support, but it's nowhere near finished
#bzr 2014-02-19
<bigjools> does anyone have any idea how to make bzr builddeb export my local branch instead of using apt-source to get upstream tarball?
<bigjools> I'm using --export-upstream and it completely ignores it
<bigjools> looks like a bug, builddeb/cmds.py appends the upstream branch source after the apt source type so it never gets used ahead of that
<ziksum> Hey! I would like to use bzr-svn on Windows with a serverless subversion repository (which I access using the file:// protocol). Is bzr-svn able to handle this case? I couldn't make it work and instead get "bzr: ERROR: Not a branch: ..." Can anybody help me? Thanks!
<jelmer> ziksum: yes, it should be able to handle that case
<ziksum> jelmer: How exactly do I specify the path for a checkout? As in "bzr co file:///p:/dir/to/svn-repo/project/trunk" ?
<jelmer> ziksum: I'm not sure how you would on Windows actually
<jelmer> ziksum: but yes, with /project/trunk (assuming that path exists in svn)
<ziksum> jelmer: I found the problem... I am using a wrong version of bzr, which does not have bzr-svn installed... I'll check again when I fixed this. Thanks for now and the confirmation that it SHOULD work!
<jelmer> ziksum: bzr-svn has issues with newer versions of svn (anything newer than 1.7)
<ziksum> oh... I just updated TortoiseSVN, which we use to manage the SVN repositories...
<jelmer> that might be related (if they use a shared svn instance)
<ziksum> Thanks for now!
#bzr 2014-02-20
<rindolf> Hi all. How can I tell where bzr pull pulls from?
<beuno> rindolf, bzr info
<rindolf> beuno: thanks.
#bzr 2014-02-23
<crazy_imp> heyho
<crazy_imp> is there an easy way to correlate two different repos?
<crazy_imp> (without diffing them by hand)
<crazy_imp> talking about
<crazy_imp> lp:kicad and lp:kicad/stable - there are likely things ported from lp:kicad towards kicad/stable but not always with a visible merge message
<xnox> can i force commit without repack?
<xnox> (the auto-repack coredumps)
<xnox> crazy_imp: bzr missing is your friend.
<xnox> crazy_imp: as in actual command "bzr missing" it will tell you commit difference between two branches.
<xnox> crazy_imp: or $ bzr diff --old lp:other-branch
<crazy_imp> xnox: thanks :)
<lduros> I have a repository which I want to "clone". I don't really want any of the branches, because I want to _create_ a new branch (empty) within that repository. But I can't clone it, the bzr branch command wants a branch not a repo. Is there a way to do this?
<lduros> was disconnected. just came back. In case someone answered my question.
#bzr 2015-02-16
<nopf> hm, bzr branch tells me Errno 1 Operation not permitted. that's helpful, not. is it because of the fat filesystem??
<mgrandi> can you post a pastebin of the bzr.log file?
<nopf> if i had found it, i had looked into it :) lemme find it...
<mgrandi> bzr version tells you where its located
<nopf> mgrandi: thanks. ok. it's the symlink problem again :]
<mgrandi> OperationNotPermitted seems like a operating system thrown error, and those are infamously terrible
<nopf> does this mean i cannot for backup purposes push to a fat fs?
<mgrandi> what type of fat? fat16, fat32, exfat?
<mgrandi> I believe i have a repo on a fat32 thumbdrive somewhere
<nopf> fat-without-symlinks, they are all that bad :)
<mgrandi> so this is a repo with symlinks?
<nopf> yeah, you have repos without symlink
<nopf> right
<mgrandi> yeahhhhh thats a long standing bug in bazaar...and pretty much every dvcs
<mgrandi> and is complicated to fix >.>
<nopf> i did not think of this. i thought problems would only aries if i do a checkout there, not with teh .bzr itself...
<mgrandi> you might have to remove the symlink from the current revision to be able to checkout on windows / fat
<mgrandi> I dunno how you even would fix it, my idea was to have a 'symlink.txt' file on filesystems/OSes that don't support it, but then what happens if you modify it and whatnot...
<nopf> nope. no compromises. i will not encourage my users to use win. so i'll create a ext2 image file there on the stick and loop mount for now
<mgrandi> i believe the code will attempt to do a symlink if its anything but win32
<mgrandi> so im guessing you are on linux something, so it tries to create a symlink but fails cause the OS says the filesystem doesn't support it
<nopf> right. this is a terrible world in this respect. only topped by encodings, xml, eol conventions and closed source software
<mgrandi> yep haha
<mgrandi> Windows _does_ support symlinks
<mgrandi> but the problem is, by default a user does not have privs to create a 'junction' (win32 symlink)
<mgrandi> so even if it did support it, it would fail half the time
<nopf> well, windows support also internationalized 'Documents' and such dirs. which ubuntu or gnome or whoever are apt in adapting up to the same failures lately
<mgrandi> https://bugs.launchpad.net/bzr/+bug/81689
<ubot5> Launchpad bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,In progress]
<mgrandi> is the bug report on it
<nopf> yeah, i know, i stumbled onto this years ago. so many years ago that i already forgot again
<mgrandi> i think git and hg just...don't even attempt to see that its a symlink and just version the file that the symlink points too
<mgrandi> bazaar is trying to be too smart here =P
<nopf> btw, '--no-tree' is what i wanted. for some reason i had assumed it was the default, which is obviously not true. so i got what i want for now. thanks again
<mgrandi> you are welcome =)
<mgrandi> yeah --no-tree just makes it so its like..on a server, where you just have a .bzr folder but no checkout (no reason to have one if its just a remote repo)
<nopf> so windows machines at least can be servers for arbitrary repos, just not for developper machines. what a world
<mgrandi> yep =)
#bzr 2015-02-17
<fiola> I've installed Bazaar Explorer on Gentoo (package dev-vcs/bzr-explorer and all deps) but can't see how to run it.  There is no binary executable in the package, and bzr doesn't suggest any way to execute plugins.  All the docs just say "Fire up Bazaar Explorer", but don't say how.  Any hints?
<fullermd_> Well, it wouldn't be a binary, it'd be a python script.
<fiola> Found the answer, it's simply "bzr explorer".  Didn't see that in the man page.
<fiola> The man page should say "bzr command names are checked against plugin names under bzrlib/plugins, and if any 'pluginname' is found then it can be launched with 'bzr pluginname'."
<fiola> Or something like that. :P
<fiola> Anyway, looks good.
#bzr 2015-02-18
<throstur> okay, so I've been "repacking texts" for about 4 hours now, how do I do a full "re-checkout"?
<throstur> noone? aw man, I guess I'll wait another 5-6 hours
#bzr 2016-02-22
<est31> soo I try to branch a branch
<est31> and it just hangs, does nothing
<est31> ah it was ssh authentication failure
<est31> still it should at least give me an error
<est31> instead of hanging for eternity
<est31> thats bad ux which doesnt protect you from hackers at all
#bzr 2016-02-24
<calher> I can roll back just one file in a repo, right?
<calher> Ah, yes -- <http://doc.bazaar.canonical.com/latest/en/user-reference/revert-help.html>.
<calher> So I may not use ESR's SRC <http://www.catb.org/esr/src/> for configs.
#bzr 2020-02-19
<guiverc> Can someone please tell me which file/dir is the control directory "brz: ERROR: A control directory already exists: ..."  (i accidently wiped overwrote a file-system with errant `dd`, and data is restored but maybe missing some .files)
<CcxWrk> guiverc: I'd probably just  strace -fe trace file  and see where it breaks. What are you trying to do?
<guiverc> Thanks for reply CcxWrk, sorry I haven't time currently & got stuff to do before bed.. another night.. (I overwrote a server array with a stupid `dd` of ISO so I'm trying to get `bzr status` to complete my [Lubuntu] QA testcases  (https://answers.launchpad.net/bzr/+question/688323 was question I raised)
<CcxWrk> So this is a data rescue operation?
<guiverc> Not really, i have all data (excluding .files) I believe; also being testcases nothing really critical.. but my not saving .files meant I think the data restore didn't make bzr happy
<guiverc> .files meaning anything starting with .(period)
<CcxWrk> Got it. Yeah, run   strace -fe trace=file bzr yourcommand  and nuke whatever it crashes on.
<CcxWrk> That's the best thing I can think of without grepping bzr sources anyway.
<guiverc> Thanks CcxWrk , I'll likely try this tomorrow :)  Greatly appreciate the help, so thank you.
<jelmer> the control directory is ".bzr"
#bzr 2020-02-21
<guiverc2> Request an opinion please.  I was working on testcases of Lubuntu (https://code.launchpad.net/~guiverc/ubuntu-manual-tests/lubuntu-calamares) but wiped my drive array with bad `dd`.  I've got it back working  and did a `bzr commit -m "Lubuntu 20.04 Calamares install variations"` and it responded 399. I noticed an obvious error, fixed it & re-commited & had it respond 400. I then `bzr push "Lubuntu 20.04 Calamares install variations"` but link
<guiverc2> doesn't reflect yesterday/today's 399&400.   Why??
<guiverc2> My best theory is my 'backup' was a day before dd-wipe and was missing a ">", which I only noticed late (post-commit 399) when I re-read `test-case-format`, quickly fixed & re-pushed (thus 400) repeating the same mistake I made on 2019-12-31 again yesterday identically.  Thus why the page i listed doesn't show yesterdays or todays date  (I tried to re-push the same files as I had in 399, then 400 thus the re-use of those numbers & date isn't on
<guiverc2> linked page).  Is this plausible or completely wrong?
<jelmer> guiverc2: not sure I fully understand the situation
<jelmer> This may be a better question for the mailing list
<guiverc2> ack & thanks jelmer
