[00:57] <matthewg42> Hi.  Is there a function in bzr to find in what revisions a specific line of code was last modified?
[00:58] <ajmitch> matthewg42: bzr annotate
[00:59] <matthewg42> ajmitch: thank you!
[01:00] <matthewg42> ajmitch: perfect
[01:15] <poolie> hi ajmitch
[01:39] <ajmitch> poolie: hello
[04:58] <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/
[05:02] <Jordan_U> I'm using Ubuntu Precise and the actual output of "bzr --version" is here: http://paste.ubuntu.com/849555/
[05:04] <spiv> Does "bzr --no-plugins --version" work?
[05:04] <spiv> Perhaps your version of bzr-bisect needs updating.
[05:07] <Jordan_U> spiv: No error message with "bzr --no-plugins --version".
[05:09] <spiv> Ok, so a problem with the bzr-bisect plugin then.
[05:11] <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?
[05:13] <spiv> Yes, please do file a bug on the bzr-bisect package.
[05:17] <poolie> Jordan_U, please paste the bug here too
[05:19] <poolie> Jordan_U how about if you do 'bzr pull -d ~/.bazaar/plugins/bisect'
[05:19] <poolie> Jordan_U, spiv, actually i think that's all you need, it's ok in tip of bzr-bisect
[05:19] <poolie> no need to file a bug
[05:20] <spiv> Well, it'd just be a bug asking for the package to be updated then :)
[05:25] <Jordan_U> poolie: When I try that command I get http://paste.ubuntu.com/849565/
[05:32] <poolie> spiv, but he's running from ~/.bazaar...
[05:33] <poolie> jordan_u, unless you really want to be running from source or you have local tweaks to bzr-bisect
[05:33] <poolie> jordan_u, are you on ubuntu or debian?
[05:33] <poolie> if so, try just `rm -rf ~/.bazaar/plugins/bisect` and then `sudo apt-get install bzr-bisect`
[05:34] <poolie> oh you said Precise
[05:34] <Jordan_U> poolie: Ubuntu.
[05:34] <poolie> so, yeah, try the package
[05:35] <Jordan_U> E: Unable to locate package bzr-bisect
[05:37] <poolie> hm
[05:37] <poolie> if you deleted it then try 'bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect'
[05:37] <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?
[05:47] <spiv> poolie: oh, I see
[05:47] <spiv> poolie: my bad!
[06:09] <poolie> jordan_u, yes, you had a local old version
[06:09] <poolie> if you're not using it you can just leave it deleted i guess
[07:00] <poolie> hi vila
[07:08] <vila> hi all
[07:15] <poolie> hi there
[07:32] <poolie> vila do you know of a problem where a plain bzr init (rather than push) on lp doesn't configure stacking?
[07:33] <vila> meh, never heard of
[07:33] <vila> happened recently ?
[07:33] <vila> specifically: with a 2.6 bzr ?
[07:34] <poolie> with 2.5bsomething
[07:35] <vila> rings no bell, but diagnosing it should be doable with -Dhpss and/or -Dhpssvfs (sp?)
[07:36] <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
[07:36] <vila> but imbw
[07:36] <poolie> https://bugs.launchpad.net/bzr/+bug/936772
[07:36] <ubot5> Ubuntu bug 936772 in Bazaar "bzr init doesn't set stacking branch from default" [Medium,Confirmed]
[07:42] <vila> bzr config -d lp:~mbp/launchpad/remove-bsondump2
[07:42] <vila> reports a stacked_on_location
[07:44] <poolie> i just set it from python
[07:44] <vila> it wasn't ?
[07:45] <poolie> it wasn't previously
[07:45] <vila> well, I'm not sure init set it nor if it's required for push to find one...
[07:47] <vila> poolie: you're running bzr from source right ?
[07:47] <poolie> from the daily ppa
[07:47] <poolie> so 2.6dev
[07:51] <vila> on precise that would be revno 6460 ?
[07:53] <vila> poolie: that would rule out revno 6468 which otherwise may be a good suspect
[07:58] <poolie> Version: 2.5.0~bzr6460.6162~ppa4023~precise1
[07:58] <poolie> what a version :)
[08:03] <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)
[08:03] <vila> poolie: did the push works better with stacked_on_location set (and how did you set it manually by the way ?)
[08:04] <vila> by copying the /+branch-id/nnnn from a know working branch ?
[08:13] <poolie> b.set_stacked_on_location(url)
[08:13] <poolie> yes, using the relative url printed by the command
[08:13] <poolie> it's odd it prints but doesn't set it
[08:17] <vila> ECANTPARSE
[08:17] <vila> what prints ?
[08:17] <vila> oh, bzr init ?
[08:18] <poolie> yes
[08:19] <vila> poolie: I wouldn't be surprised it init prints the default_stack_on without setting stacked_on_location
[08:19] <vila> or only midly surprised
[08:23] <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 ?
[08:24] <vila> poolie: I can reproduce if I try to do 'bzr init' first, but a bare push works as expected
[08:25] <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
[08:26] <poolie> vila, it may be very old
[08:26] <poolie> i too would normally just push but here i need to work around a development-colo thing
[08:26] <vila> poolie: well, the question is: did you walk on the path and are you closer to your goal ;)
[08:27] <vila> poolie: bah, easy to test with older bzr, I'll delete the branches later
[08:30] <vila> poolie: confirmed for 2.0
[08:32] <vila> poolie: hehe, I almost forgot the old progress bar look ;)
[08:32] <poolie> yeah, a bit
[09:01] <mgz> morning all!
[09:02] <vila> mgzorning !
[09:09] <poolie> hi mgz
[09:09] <poolie> i might call that a night
[09:14] <vila> poolie: enjoy your night ;)
[09:15] <poolie> :/
[09:15] <poolie> thanks though
[09:25] <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.
[09:25] <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.
[09:37] <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
[09:43] <mgz> ev: so, basically instructions at first link followed by instructions at seconds link:
[09:43] <mgz> http://stackoverflow.com/questions/67021/how-do-i-export-the-bazaar-history-of-a-subfolder/596656#596656
[09:43] <mgz> http://nicholasworkshop.wordpress.com/2011/11/07/merge-2-unrelated-branches-in-bazaar/
[09:44] <ev> mgz: cheers! Just trying to figure out how to merge into a subdir. the merge-into plugin seems to be broken.
[09:53] <mgz> ev: you could just mv inside the exported branch and commit before merging
[09:54] <ev> mgz: and that's exactly what I did :)
[09:54] <ev> mgz: thanks for all your help!
[09:54] <ev> worked perfectly
[11:47] <jelmer> vila: hi :)
[11:47] <vila> jelmer: hello :)
[11:47] <jelmer> vila: would you perhaps have a chance to review https://code.launchpad.net/~jelmer/bzr/less-inventory-access/+merge/93612 ?
[11:49] <vila> grr, I have the opposite of Alzheimer: I remember reviewing stuff but I'm the only one remembering it :-(
[11:51] <vila> on the other hand it may just be because unity hated me last week and lost them...
[11:55] <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-}
[11:56] <vila> hehe
[11:56] <jelmer> :)
[12:01] <damd> 😍
[12:02] <jelmer> thanks vila!
=== yofel_ is now known as yofel
[15:00] <farblue> afternoon all :)
[15:01] <jelmer> hi farblue
[15:01] <farblue> I've been playing with bzr-svn and working through bzr to an svn repo
[15:01] <farblue> At the moment I have a bzr 'checkout' from my svn repo but have a couple of questions
[15:02] <farblue> firstly how do I show the 'branches' in the svn repo so I can switch to one
[15:02] <farblue> I've setup what I think is the correct values in the subversion.conf file but don't know what to do next
[15:04] <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.)
[15:06] <jelmer> farblue: branches are basically whatever you want them to be - as is the case in svn
[15:08] <jelmer> farblue: "bzr svn-import" will import all branches in a repository
[15:08] <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?
[15:10] <jelmer> farblue: you can use "bzr push" in individual branches to push changes back into svn
[15:11] <farblue> ok, that makes sense :)
[15:13] <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
[15:14] <jelmer> farblue: in svn, every directory can be used as a branch point
[15:14] <jelmer> farblue: what did you set the layout to?
[15:14] <farblue> yeah, i know
[15:14] <farblue> [ca5c6774-48ba-4b05-a2e9-b76598164b70]
[15:14] <farblue> locations = http://bacon.server.dev/svn/website
[15:14] <farblue> branches = /trunk;/releases/*;/branches/feature/*;/branches/rgoldsmith/*
[15:14] <farblue> tags = /tags
[15:15] <jelmer> farblue: You probably want 'tags = /tags/*' I think
[15:15] <farblue> ok
[15:15] <jelmer> other than that it seems reasonable
[15:15] <jelmer> what version of bzr are you using?
[15:15] <jelmer> 'bzr branches' is significantly faster in bzr 2.5
[15:16] <farblue> I'm on 2.4.2
[15:16] <farblue> the current release bundle for OSX
[15:16] <jelmer> farblue: that would explain the memory usage
[15:16] <jelmer> farblue: I would recommend just running "bzr branch <branch-url>" for the the branch you're interested in
[15:17] <farblue> how will that help?
[15:17] <jelmer> farblue: that will pull down the branch you need
[15:17] <jelmer> farblue: or is there a particular reason you want to see the list of branches?
[15:18] <farblue> my problem isn't pulling down the branch, it's seeing what branches can be pulled
[15:18] <jelmer> farblue: anything that exists in the svn repository can be pulled down as a branch
[15:18] <farblue> ok, then what command can I use to list the content of a specific folder in the svn repo?
[15:19] <farblue> i.e. a bzr equiv of svn list ^/releases
[15:19] <jelmer> farblue: I would recommend just using 'svn ls'
[15:19] <jelmer> farblue: or 'bzr branches' if you're running bzr 2.5
[15:19] <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
[15:20] <farblue> that's ok because we have a strict structure to the repo
[15:20] <farblue> I can't possibly imagine the mess people would get into with svn if we didn't!
[15:22] <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?
[15:22] <jelmer> farblue: in bzr 2.4, yes
[15:22] <farblue> fun
[15:23] <farblue> so any thoughts on when bzr 2.5 will be stable?
[15:23] <jelmer> farblue: it should be out in a couple of weeks
[15:23] <farblue> win :)
[15:23] <farblue> so, basically, I'm doing things correctly but 2.5 will significantly improve matters
[15:27] <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.).
[15:27] <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?
[15:28] <farblue> rather than having a repo per project
[15:33] <jelmer> farblue: I think you mean "then all my branches"
[15:33] <jelmer> farblue: but, yes
[15:33] <jelmer> farblue: it doesn't have any functionality impact, but it will save disk space
[15:39] <farblue> yeah, matching up the terminology across multiple version control systems is rather confusing
[15:39] <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
[15:39] <farblue> not*
[15:40] <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.
[15:43] <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
[15:43] <vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
[15:43] <farblue> hmm, yeah, still getting the hang of that
[15:44] <vila> farblue: you seem to be doing well !
[15:44] <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 :)
[15:44] <jelmer> farblue: no, that should be fine
[15:44] <vila> no
[15:45] <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
[15:45] <fullermd> Well, it won't save much/any with unrelated branches.
[15:46] <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
[15:46] <fullermd> And you'll slow some things down (most obviously, anything that touches bit swathes of the repo indiscriminately, like repacks and 'check')
[15:46] <farblue> hmm
[15:46] <farblue> so something like 'bzr branches' won't get in a muddle and try to show me all branches on all projects?
[15:47] <fullermd> Repos won't have any effect on 'branches'.
[15:47] <jelmer> farblue: no, 'bzr branches' only searches under the path you give it
[15:47] <farblue> still grappling with that idea
[15:48] <fullermd> 'branches' is roughly "for i in `find . -type d`; echo $i if is_a_branch $i; done"
[15:49] <jelmer> fullermd: it's something different for svn branches
[15:50] <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
[15:50] <fullermd> Well, yes, that's a whole different story.  But a bzr shared-repo would have even less effect then  ;p
[15:50] <farblue> oh dear, I feel I'm getting in a twist
[15:51] <farblue> maybe the best thing would be to tell you all what I need and let you suggest solutions :D
[15:51] <fullermd> (that was to jelmer, not farblue)
[15:51] <farblue> ah, ok, so my idea is valid?
[15:51] <jelmer> farblue: I basically just have one directory with a shared repository per project
[15:51] <jelmer> farblue: and then branches (as directories) inside of that
[15:51] <fullermd> If you're talking on the local FS, you probably want light checkouts, not heavy.
[15:53] <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.
[15:53] <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
[15:54] <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
[15:54] <farblue> the locations on the filesystem are important because Apache is setup a specific way and we develop 'web applications'
[15:54] <farblue> I work on ~ 11 projects
[15:55] <farblue> so, given all of this, can people recommend a 'pure bzr' system and a 'bzr interfacing with the central svn repo' system?
[15:56] <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).
[15:56] <fullermd> But I also flip the "stop making my life difficult, dammit" switches in Apache   :p
[15:57] <farblue> we currently have ~/Sites/dev/project and ~/Sites/release/project for each project
[15:58] <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
[15:58] <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 ;)
[15:59] <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.
[16:00] <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
[16:00] <farblue> switching the structure is possible but will have more resistance
[16:02] <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
[16:03] <farblue> except I'd then have to have a folder for each branch even if it wasn't also a working tree
[16:08] <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
[16:14] <jelmer> farblue: this all sounds really complex; I would just start out with something simple and then change things around as necessary later
[16:15] <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
[16:16] <farblue> anyone know much about the --layout parameter to svn-import?
[16:16] <jelmer> farblue: if you've already set up the layout in ~/.bazaar/subversion.conf you shouldn't need it
[16:16] <farblue> ok :)
[16:17] <farblue> do you know whether the branches config option in subversion.conf will understand "/branches/*/*" and any idea what it will do with that?
[16:18] <farblue> our branches are /branches/username/branchName (often a ticket number)
[16:18] <jelmer> farblue: yes, it should understand branches/*/*
[16:23] <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
[16:24] <farblue> and the normal bzr commands to create a new branch will result in a branch being created in the svn repo?
[16:24] <farblue> (on push)
[16:24] <jelmer> farblue: pull and push work on branches, not on a repository
[16:25] <farblue> yes, I understand that :)
[16:25] <farblue> I could have said "a push or pull will shuttle revisions back and forth with the related branches in the svn repo"
[16:25] <jelmer> farblue: push and pull each work on just a single branch
[16:26] <jelmer> the branch that you're currently working in
[16:26] <farblue> yes, I understand that
[16:26] <farblue> and creating new branches in the svn repo?
[16:26] <jelmer> farblue: they will create a new branch but you'll have to specify the URL of that branch
[16:27] <farblue> oh? so how does that work? may I have an example?
[16:28] <jelmer> farblue: "bzr push svn+ssh://svn.company.com/repo/branches/somesvnbranch"
[16:28] <farblue> ok
[16:28] <farblue> that's just the first time you push after creating the new branch
[16:28] <jelmer> yes
[16:29] <jelmer> farblue: after that you can just run "bzr push" in that branch and it will push to ../branches/somesvnbranch
[16:29] <farblue> and, obviously, if you don't push a branch it will never turn up in the svn repo
[16:29] <jelmer> farblue: right, changes that aren't pushed (or committed, if you're in a checkout of the svn repo)
[16:29] <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...
[16:30] <farblue> hmm
[16:32] <vila> if it's a svn repo, defaults can be specified in subversion.conf avoiding issues with overrides in locations.conf
[16:33] <jelmer> vila: That doesn't help for branches, because there are multiple branches in a single svn repo
[16:34] <vila> push_location = .../branches/{basename} with recent enough bzr will provide a default push_location before it's set in branch.conf
[16:34] <jelmer> vila: also, this is something that's set on the local bzr branch
[16:34] <vila> ha crap
[17:22] <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?
[17:26] <mgz> ggherdov: try `bzr pack` now, then compare the packs dir with the obsolete packs dir
[17:26] <mgz> I have vague recollection of an issue like this before that was just to do with storing things wonkily
[17:28] <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?
[17:28] <mgz> no, it rearranges the current content
[17:29] <mgz> look at the size of .bzr/repository/packs now, then run the command, then look again
[17:29] <ggherdov> ah ok, so 'bzr pack' should somehow remove the garbage (redundant content) . I'll try right now.
[17:29] <mgz> my expectation is it will go back down to the size before the move
[17:31] <jml> is the plan for colo to be the default with bzr?
[17:32] <jelmer> jml: possibly, but at least not in 2.5
[17:32] <ggherdov> 'bzr pack'ing ...
[17:36] <ggherdov> msg: as you said. you wow-ed me.
[17:36] <jml> jelmer: ok, thanks.
[17:37] <jelmer> jml: are you using them, is it working ok?
[17:37] <mgz> ggherdov: good good. I can't find a bug entry for this though.
[17:38] <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
[17:38] <ggherdov> mgz:  should I file one?
[17:39] <jelmer> jml: IIRC Aaron was going to propose merging of a better syntax, e.g. "co:FOO" rather than "file:,branch=FOO"
[17:39] <ggherdov> ah, last think mgz: should I commit to my remote repo now? to make the change persistent.
[17:39] <ggherdov> thing*
[17:41] <mgz> ggherdov: a bug would be good I think, the temporary bloating is suprising.
[17:42] <jml> jelmer: that could be nice
[17:42] <jml> jelmer: it's a shame the prefix is needed
[17:42] <mgz> ggherdov: getting the revision on your remote repo and seeing what that does to the packs dir may also be interesting
[17:42] <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?
[17:42] <mgz> do you mean commit or push to remote?
[17:42]  * mgz isn't quite sure how you're working
[17:43] <jelmer> jml: The prefix is the easiest thing to do - it'll work everywhere
[17:43] <mgz> propogating the change now is correct I'd think
[17:43] <jelmer> jml: the idea is to also DWIM everywhere, but that requires changes to the individual commands
[17:43] <fullermd> I don't think it's strictly a 'bug'.  More an unpleasant consequence.
[17:44] <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.
[17:44] <jelmer> jml: yes
[17:45] <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).
[17:45] <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
[17:46] <jelmer> jml: that'd be nice I think
[17:46] <jelmer> jml: I'
[17:46] <mgz> ggherdov: go ahead and do your cunning bondage tricks then
[17:46] <jelmer> jml: ve done some similar things, but nothing as broad as that
[17:47] <jelmer> jml: e.g. I have a command "bzr rm-merged" that removes all sibling branches that are merged into the current branch
[17:47] <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.
[17:47] <jml> jelmer: right. me too.
[17:47] <jml> jelmer: I think maybe bzr should grow some built-in facilities for that once colo matures a little more
[17:48] <mgz> ggherdov: that's a bit odd, I can't imagine what code would be adding dot-prefixed things like that
[17:48] <mgz> fullermd: might that one be a bug?
[17:48] <mgz> :)
[17:49] <fullermd> That would.  But I'm guessing it's from something else.   :p
[17:49] <ggherdov> mgz: well it must have been the 'bzr pack'. It's the only thing I did.
[17:50] <mgz> if you remove them and pack again do they reappear?
[17:50] <ggherdov> mgz: i'll try.
[17:55] <ggherdov> mgz: no, re-packed and they aren't back. the were an ephemeral mirage. that's voodoo.
[17:57] <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"
[17:57] <jml> jelmer: the reason it's annoying is that I occasionally forget :)
[17:58] <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)
[17:58] <jelmer> jml: can you perhaps file a bug about that?
[17:58] <ggherdov> forgot to end with a question mark
[17:58] <ggherdov> s/committed/committed?)/
[17:58] <jml> jelmer: happily. 'colo' is the tag, right?
[17:59] <LarstiQ> ggherdov: packing doesn't make any new revisions, just reorganizes the storage
[17:59] <jelmer> jml: thanks - the tag is 'colocated'
[17:59] <ggherdov> LarstiQ: I got it. so I need to pack in the remote manually.
[17:59] <LarstiQ> ggherdov: yes, or wait for it to happen automatically
[17:59] <ggherdov> LarstiQ: does it?
[18:00] <ggherdov> how frequently?
[18:00] <LarstiQ> ggherdov: yeah, at revisions 10, 100, 1000 etc iirc
[18:00] <ggherdov> LarstiQ: oh... logarithmic... whose the math guy at canonical? :-)
[18:00] <ggherdov> who's*
[18:00] <ggherdov> [joking]
[18:04] <jml> jelmer: https://bugs.launchpad.net/bzr/+bug/937123
[18:04] <ubot5> Ubuntu bug 937123 in Bazaar "Have to remember to name initial branch when starting a local colocated branch " [Undecided,New]
[18:07] <mgz> okay, have been typing for about an hour, lets see what syntax errors I've created
[18:07] <mgz> noticed about five minutes ago I got the api slightly wrong so half of the complication is actually redundant for now
[18:08] <mgz> missing colon after method def...
[18:08] <mgz> missing colon after if statement...
[18:09] <mgz> that's it. but test failures from mixing up "flavors" and "flavours" in variable naming...
[18:10] <jml> hmm. I seem to have got myself into a mess:
[18:10] <jml> jml@valour:~/src/software-center-agent$ bzr st
[18:10] <jml> bzr: ERROR: Not a branch: "/home/jml/src/software-center-agent/.bzr/branches/trunk/": location is a repository.
[18:10] <mgz> PASSED (successes=92)
[18:11] <mgz> jml: that's what I did the other day
[18:11] <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'
[18:11] <jml> mgz: oh. how did you resolve the problem?
[18:11] <mgz> jml: I deleted and started again :)
[18:11] <mgz> BUT,
[18:12] <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
[18:13] <jml> *blink*
[18:14] <mgz> the problem is the default colo location got removed, jelmer, how do you fix that?
[18:14] <jelmer> mgz: "bzr co file:,branch=somethingexisting ."
[18:15] <jml> but I didn't remove trunk though...
[18:15] <jml> huh, apparently I did
[18:15] <jml> rmbranch merrily ignores the argument I gave it.
[18:15] <mgz> it's seems to be too easy to do by accident
[18:16] <jelmer> jml: It doesn't - but it looks the argument you give it up as a branch
[18:16] <jml> jelmer: I don't follow. I did 'bzr rmbranch deployed' while switched to the trunk branch and it removed the trunk branch.
[18:24] <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?
[18:24] <matthewg42> and if so... how?
[18:26] <jelmer> jml: rmbranch doesn't have special support for colocated branches
[18:26] <jelmer> jml: so it tries to look up "yourbranch" as a path on the filesystem
[18:27] <jelmer> jml: "yourbranch" isn't a file that exists, so it tries "" (assuming that "" is a branch which contains the file "yourbranch")
[18:27] <jelmer> jml: and then it ends up removing "yourbranch")
[18:27] <jelmer> matthewg42: it is preserving the multiple commits - if you commit you can still see them with "bzr log -n0"
[18:29] <jelmer> I think, perhaps for rmbranch we shouldn't be allowing people to specify a path inside of a branch
[18:29] <jelmer> matthewg42: alternatively, you can look with 'bzr qlog'
[18:29] <matthewg42> jelmer: PEBKAC... I did not know about -n0.
[18:30] <matthewg42> thank you!
[18:30] <matthewg42> < still getting to grips with bzr.
[18:42] <jml> jelmer: ah, I see.
=== Quintasan_ is now known as Quintasan
[21:08] <poolie> hi wgz
[21:33] <RenatoSilva> is it safe to ln -s /windows-bzr-profile ~/.bazaar? I can't see relevant difference between %AppData%/Bazaar/2.0 and ~/.bazaar
[21:34] <jelmer> hi RenatoSilva
[21:34] <jelmer> RenatoSilva: yes, that should be fine
[21:49] <RenatoSilva> awesome, thanks jelme
[21:49] <RenatoSilva> r
[22:07] <poolie> jml, hi?
=== jvargas_ is now known as jvargas
[22:51] <jml> poolie: hello