matthewg42Hi.  Is there a function in bzr to find in what revisions a specific line of code was last modified?00:57
ajmitchmatthewg42: bzr annotate00:58
matthewg42ajmitch: thank you!00:59
matthewg42ajmitch: perfect01:00
pooliehi ajmitch01:15
ajmitchpoolie: hello01:39
Jordan_UAny 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/04:58
Jordan_UI'm using Ubuntu Precise and the actual output of "bzr --version" is here: http://paste.ubuntu.com/849555/05:02
spivDoes "bzr --no-plugins --version" work?05:04
spivPerhaps your version of bzr-bisect needs updating.05:04
Jordan_Uspiv: No error message with "bzr --no-plugins --version".05:07
spivOk, so a problem with the bzr-bisect plugin then.05:09
Jordan_UHow 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:11
spivYes, please do file a bug on the bzr-bisect package.05:13
poolieJordan_U, please paste the bug here too05:17
poolieJordan_U how about if you do 'bzr pull -d ~/.bazaar/plugins/bisect'05:19
poolieJordan_U, spiv, actually i think that's all you need, it's ok in tip of bzr-bisect05:19
poolieno need to file a bug05:19
spivWell, it'd just be a bug asking for the package to be updated then :)05:20
Jordan_Upoolie: When I try that command I get http://paste.ubuntu.com/849565/05:25
pooliespiv, but he's running from ~/.bazaar...05:32
pooliejordan_u, unless you really want to be running from source or you have local tweaks to bzr-bisect05:33
pooliejordan_u, are you on ubuntu or debian?05:33
poolieif so, try just `rm -rf ~/.bazaar/plugins/bisect` and then `sudo apt-get install bzr-bisect`05:33
poolieoh you said Precise05:34
Jordan_Upoolie: Ubuntu.05:34
poolieso, yeah, try the package05:34
Jordan_UE: Unable to locate package bzr-bisect05:35
poolieif you deleted it then try 'bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect'05:37
Jordan_UThough 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:37
spivpoolie: oh, I see05:47
spivpoolie: my bad!05:47
pooliejordan_u, yes, you had a local old version06:09
poolieif you're not using it you can just leave it deleted i guess06:09
pooliehi vila07:00
vilahi all07:08
pooliehi there07:15
poolievila do you know of a problem where a plain bzr init (rather than push) on lp doesn't configure stacking?07:32
vilameh, never heard of07:33
vilahappened recently ?07:33
vilaspecifically: with a 2.6 bzr ?07:33
pooliewith 2.5bsomething07:34
vilarings no bell, but diagnosing it should be doable with -Dhpss and/or -Dhpssvfs (sp?)07:35
vilafirst 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 it07:36
vilabut imbw07:36
ubot5Ubuntu bug 936772 in Bazaar "bzr init doesn't set stacking branch from default" [Medium,Confirmed]07:36
vilabzr config -d lp:~mbp/launchpad/remove-bsondump207:42
vilareports a stacked_on_location07:42
pooliei just set it from python07:44
vilait wasn't ?07:44
poolieit wasn't previously07:45
vilawell, I'm not sure init set it nor if it's required for push to find one...07:45
vilapoolie: you're running bzr from source right ?07:47
pooliefrom the daily ppa07:47
poolieso 2.6dev07:47
vilaon precise that would be revno 6460 ?07:51
vilapoolie: that would rule out revno 6468 which otherwise may be a good suspect07:53
poolieVersion: 2.5.0~bzr6460.6162~ppa4023~precise107:58
pooliewhat a version :)07:58
vilaright, 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
vilapoolie: did the push works better with stacked_on_location set (and how did you set it manually by the way ?)08:03
vilaby copying the /+branch-id/nnnn from a know working branch ?08:04
poolieyes, using the relative url printed by the command08:13
poolieit's odd it prints but doesn't set it08:13
vilawhat prints ?08:17
vilaoh, bzr init ?08:17
vilapoolie: I wouldn't be surprised it init prints the default_stack_on without setting stacked_on_location08:19
vilaor only midly surprised08:19
vilapoolie: 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:23
vilapoolie: I can reproduce if I try to do 'bzr init' first, but a bare push works as expected08:24
poolieit's sad when it's 7:25pm and you still haven't reached the base of the mountain you actually want to climb08:25
poolievila, it may be very old08:26
pooliei too would normally just push but here i need to work around a development-colo thing08:26
vilapoolie: well, the question is: did you walk on the path and are you closer to your goal ;)08:26
vilapoolie: bah, easy to test with older bzr, I'll delete the branches later08:27
vilapoolie: confirmed for 2.008:30
vilapoolie: hehe, I almost forgot the old progress bar look ;)08:32
poolieyeah, a bit08:32
mgzmorning all!09:01
vilamgzorning !09:02
pooliehi mgz09:09
pooliei might call that a night09:09
vilapoolie: enjoy your night ;)09:14
pooliethanks though09:15
evis 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
evI'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:25
mgzev: you can use the filter to create a new branch just of that sub dir, then splice it on to the other existing tree09:37
mgzev: so, basically instructions at first link followed by instructions at seconds link:09:43
evmgz: cheers! Just trying to figure out how to merge into a subdir. the merge-into plugin seems to be broken.09:44
mgzev: you could just mv inside the exported branch and commit before merging09:53
evmgz: and that's exactly what I did :)09:54
evmgz: thanks for all your help!09:54
evworked perfectly09:54
jelmervila: hi :)11:47
vilajelmer: hello :)11:47
jelmervila: would you perhaps have a chance to review https://code.launchpad.net/~jelmer/bzr/less-inventory-access/+merge/93612 ?11:47
vilagrr, I have the opposite of Alzheimer: I remember reviewing stuff but I'm the only one remembering it :-(11:49
vilaon the other hand it may just be because unity hated me last week and lost them...11:51
fullermdWell, 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:55
jelmerthanks vila!12:02
=== yofel_ is now known as yofel
farblueafternoon all :)15:00
jelmerhi farblue15:01
farblueI've been playing with bzr-svn and working through bzr to an svn repo15:01
farblueAt the moment I have a bzr 'checkout' from my svn repo but have a couple of questions15:01
farbluefirstly how do I show the 'branches' in the svn repo so I can switch to one15:02
farblueI've setup what I think is the correct values in the subversion.conf file but don't know what to do next15:02
farbluepossibly 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:04
jelmerfarblue: branches are basically whatever you want them to be - as is the case in svn15:06
jelmerfarblue: "bzr svn-import" will import all branches in a repository15:08
farblueso 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:08
jelmerfarblue: you can use "bzr push" in individual branches to push changes back into svn15:10
farblueok, that makes sense :)15:11
farblueregarding 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 else15:13
jelmerfarblue: in svn, every directory can be used as a branch point15:14
jelmerfarblue: what did you set the layout to?15:14
farblueyeah, i know15:14
farbluelocations = http://bacon.server.dev/svn/website15:14
farbluebranches = /trunk;/releases/*;/branches/feature/*;/branches/rgoldsmith/*15:14
farbluetags = /tags15:14
jelmerfarblue: You probably want 'tags = /tags/*' I think15:15
jelmerother than that it seems reasonable15:15
jelmerwhat version of bzr are you using?15:15
jelmer'bzr branches' is significantly faster in bzr 2.515:15
farblueI'm on 2.4.215:16
farbluethe current release bundle for OSX15:16
jelmerfarblue: that would explain the memory usage15:16
jelmerfarblue: I would recommend just running "bzr branch <branch-url>" for the the branch you're interested in15:16
farbluehow will that help?15:17
jelmerfarblue: that will pull down the branch you need15:17
jelmerfarblue: or is there a particular reason you want to see the list of branches?15:17
farbluemy problem isn't pulling down the branch, it's seeing what branches can be pulled15:18
jelmerfarblue: anything that exists in the svn repository can be pulled down as a branch15:18
farblueok, then what command can I use to list the content of a specific folder in the svn repo?15:18
farbluei.e. a bzr equiv of svn list ^/releases15:19
jelmerfarblue: I would recommend just using 'svn ls'15:19
jelmerfarblue: or 'bzr branches' if you're running bzr 2.515:19
jelmerbut 'bzr branches' will only list paths that are considered to be branches by the currently set svn layout for bzr-svn, not all paths15:19
farbluethat's ok because we have a strict structure to the repo15:20
farblueI can't possibly imagine the mess people would get into with svn if we didn't!15:20
farbluebzr 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
jelmerfarblue: in bzr 2.4, yes15:22
farblueso any thoughts on when bzr 2.5 will be stable?15:23
jelmerfarblue: it should be out in a couple of weeks15:23
farbluewin :)15:23
farblueso, basically, I'm doing things correctly but 2.5 will significantly improve matters15:23
farblueI'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
farblueAm 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:27
farbluerather than having a repo per project15:28
jelmerfarblue: I think you mean "then all my branches"15:33
jelmerfarblue: but, yes15:33
jelmerfarblue: it doesn't have any functionality impact, but it will save disk space15:33
farblueyeah, matching up the terminology across multiple version control systems is rather confusing15:39
farblueanyhow, will it be a problem that I'd be 'sharing' the shared space across the results of multiple 'svn-import' operations? I assume now15:39
farblueI 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:40
vilafarblue: both applies to bzr repos ;) But the definition of a repo in bzr is: a container for revisions, whatever branches they come from15:43
farbluehmm, yeah, still getting the hang of that15:43
vilafarblue: you seem to be doing well !15:44
farbluemy 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
jelmerfarblue: no, that should be fine15:44
farblueso 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 branches15:45
fullermdWell, it won't save much/any with unrelated branches.15:45
farblueyeah, 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 place15:46
fullermdAnd you'll slow some things down (most obviously, anything that touches bit swathes of the repo indiscriminately, like repacks and 'check')15:46
farblueso something like 'bzr branches' won't get in a muddle and try to show me all branches on all projects?15:46
fullermdRepos won't have any effect on 'branches'.15:47
jelmerfarblue: no, 'bzr branches' only searches under the path you give it15:47
farbluestill grappling with that idea15:47
fullermd'branches' is roughly "for i in `find . -type d`; echo $i if is_a_branch $i; done"15:48
jelmerfullermd: it's something different for svn branches15:49
farblueso 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 be15:50
fullermdWell, yes, that's a whole different story.  But a bzr shared-repo would have even less effect then  ;p15:50
farblueoh dear, I feel I'm getting in a twist15:50
farbluemaybe the best thing would be to tell you all what I need and let you suggest solutions :D15:51
fullermd(that was to jelmer, not farblue)15:51
farblueah, ok, so my idea is valid?15:51
jelmerfarblue: I basically just have one directory with a shared repository per project15:51
jelmerfarblue: and then branches (as directories) inside of that15:51
fullermdIf you're talking on the local FS, you probably want light checkouts, not heavy.15:51
farbluewell, 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
farbluewhen 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 work15:53
farblueon 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 copy15:54
farbluethe locations on the filesystem are important because Apache is setup a specific way and we develop 'web applications'15:54
farblueI work on ~ 11 projects15:54
farblueso, given all of this, can people recommend a 'pure bzr' system and a 'bzr interfacing with the central svn repo' system?15:55
fullermdWell, 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
fullermdBut I also flip the "stop making my life difficult, dammit" switches in Apache   :p15:56
farbluewe currently have ~/Sites/dev/project and ~/Sites/release/project for each project15:57
farbluewe 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 option15:58
farblueI 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:58
fullermdWell, 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.15:59
farbluewe 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 wheel16:00
farblueswitching the structure is possible but will have more resistance16:00
farblueso, 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 trees16:02
farblueexcept I'd then have to have a folder for each branch even if it wasn't also a working tree16:03
farblueso 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 branches16:08
jelmerfarblue: this all sounds really complex; I would just start out with something simple and then change things around as necessary later16:14
farblueI'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 basics16:15
farblueanyone know much about the --layout parameter to svn-import?16:16
jelmerfarblue: if you've already set up the layout in ~/.bazaar/subversion.conf you shouldn't need it16:16
farblueok :)16:16
farbluedo you know whether the branches config option in subversion.conf will understand "/branches/*/*" and any idea what it will do with that?16:17
farblueour branches are /branches/username/branchName (often a ticket number)16:18
jelmerfarblue: yes, it should understand branches/*/*16:18
farblueso 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 repo16:23
farblueand 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
jelmerfarblue: pull and push work on branches, not on a repository16:24
farblueyes, I understand that :)16:25
farblueI could have said "a push or pull will shuttle revisions back and forth with the related branches in the svn repo"16:25
jelmerfarblue: push and pull each work on just a single branch16:25
jelmerthe branch that you're currently working in16:26
farblueyes, I understand that16:26
farblueand creating new branches in the svn repo?16:26
jelmerfarblue: they will create a new branch but you'll have to specify the URL of that branch16:26
farblueoh? so how does that work? may I have an example?16:27
jelmerfarblue: "bzr push svn+ssh://svn.company.com/repo/branches/somesvnbranch"16:28
farbluethat's just the first time you push after creating the new branch16:28
jelmerfarblue: after that you can just run "bzr push" in that branch and it will push to ../branches/somesvnbranch16:29
farblueand, obviously, if you don't push a branch it will never turn up in the svn repo16:29
jelmerfarblue: right, changes that aren't pushed (or committed, if you're in a checkout of the svn repo)16:29
fullermdIt's possible you could do some locations.conf hackery to preseed push locs.  How fragile that'll wind up being is another question...16:29
vilaif it's a svn repo, defaults can be specified in subversion.conf avoiding issues with overrides in locations.conf16:32
jelmervila: That doesn't help for branches, because there are multiple branches in a single svn repo16:33
vilapush_location = .../branches/{basename} with recent enough bzr will provide a default push_location before it's set in branch.conf16:34
jelmervila: also, this is something that's set on the local bzr branch16:34
vilaha crap16:34
ggherdovHi 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:22
mgzggherdov: try `bzr pack` now, then compare the packs dir with the obsolete packs dir17:26
mgzI have vague recollection of an issue like this before that was just to do with storing things wonkily17:26
ggherdovmgz: 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
mgzno, it rearranges the current content17:28
mgzlook at the size of .bzr/repository/packs now, then run the command, then look again17:29
ggherdovah ok, so 'bzr pack' should somehow remove the garbage (redundant content) . I'll try right now.17:29
mgzmy expectation is it will go back down to the size before the move17:29
jmlis the plan for colo to be the default with bzr?17:31
jelmerjml: possibly, but at least not in 2.517:32
ggherdov'bzr pack'ing ...17:32
ggherdovmsg: as you said. you wow-ed me.17:36
jmljelmer: ok, thanks.17:36
jelmerjml: are you using them, is it working ok?17:37
mgzggherdov: good good. I can't find a bug entry for this though.17:37
jmljelmer: 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 thing17:38
ggherdovmgz:  should I file one?17:38
jelmerjml: IIRC Aaron was going to propose merging of a better syntax, e.g. "co:FOO" rather than "file:,branch=FOO"17:39
ggherdovah, last think mgz: should I commit to my remote repo now? to make the change persistent.17:39
mgzggherdov: a bug would be good I think, the temporary bloating is suprising.17:41
jmljelmer: that could be nice17:42
jmljelmer: it's a shame the prefix is needed17:42
mgzggherdov: getting the revision on your remote repo and seeing what that does to the packs dir may also be interesting17:42
ggherdovmgz: 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
mgzdo you mean commit or push to remote?17:42
* mgz isn't quite sure how you're working17:42
jelmerjml: The prefix is the easiest thing to do - it'll work everywhere17:43
mgzpropogating the change now is correct I'd think17:43
jelmerjml: the idea is to also DWIM everywhere, but that requires changes to the individual commands17:43
fullermdI don't think it's strictly a 'bug'.  More an unpleasant consequence.17:43
jmljelmer: 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
jelmerjml: yes17:44
ggherdovmgz: 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
jmljelmer: 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 in17:45
jelmerjml: that'd be nice I think17:46
jelmerjml: I'17:46
mgzggherdov: go ahead and do your cunning bondage tricks then17:46
jelmerjml: ve done some similar things, but nothing as broad as that17:46
jelmerjml: e.g. I have a command "bzr rm-merged" that removes all sibling branches that are merged into the current branch17:47
ggherdovmgz: 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
jmljelmer: right. me too.17:47
jmljelmer: I think maybe bzr should grow some built-in facilities for that once colo matures a little more17:47
mgzggherdov: that's a bit odd, I can't imagine what code would be adding dot-prefixed things like that17:48
mgzfullermd: might that one be a bug?17:48
fullermdThat would.  But I'm guessing it's from something else.   :p17:49
ggherdovmgz: well it must have been the 'bzr pack'. It's the only thing I did.17:49
mgzif you remove them and pack again do they reappear?17:50
ggherdovmgz: i'll try.17:50
ggherdovmgz: no, re-packed and they aren't back. the were an ephemeral mirage. that's voodoo.17:55
jmljelmer: 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
jmljelmer: the reason it's annoying is that I occasionally forget :)17:57
ggherdovmgz: 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
jelmerjml: can you perhaps file a bug about that?17:58
ggherdovforgot to end with a question mark17:58
jmljelmer: happily. 'colo' is the tag, right?17:58
LarstiQggherdov: packing doesn't make any new revisions, just reorganizes the storage17:59
jelmerjml: thanks - the tag is 'colocated'17:59
ggherdovLarstiQ: I got it. so I need to pack in the remote manually.17:59
LarstiQggherdov: yes, or wait for it to happen automatically17:59
ggherdovLarstiQ: does it?17:59
ggherdovhow frequently?18:00
LarstiQggherdov: yeah, at revisions 10, 100, 1000 etc iirc18:00
ggherdovLarstiQ: oh... logarithmic... whose the math guy at canonical? :-)18:00
jmljelmer: https://bugs.launchpad.net/bzr/+bug/93712318:04
ubot5Ubuntu bug 937123 in Bazaar "Have to remember to name initial branch when starting a local colocated branch " [Undecided,New]18:04
mgzokay, have been typing for about an hour, lets see what syntax errors I've created18:07
mgznoticed about five minutes ago I got the api slightly wrong so half of the complication is actually redundant for now18:07
mgzmissing colon after method def...18:08
mgzmissing colon after if statement...18:08
mgzthat's it. but test failures from mixing up "flavors" and "flavours" in variable naming...18:09
jmlhmm. I seem to have got myself into a mess:18:10
jmljml@valour:~/src/software-center-agent$ bzr st18:10
jmlbzr: ERROR: Not a branch: "/home/jml/src/software-center-agent/.bzr/branches/trunk/": location is a repository.18:10
mgzPASSED (successes=92)18:10
mgzjml: that's what I did the other day18:11
jmlthis 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
jmlmgz: oh. how did you resolve the problem?18:11
mgzjml: I deleted and started again :)18:11
mgztry `bzr branch file:software-center-agent,branch=somethingexisting file:software-center-agent,branch=` ...actually that won't work... how do you address the default branch18:12
mgzthe problem is the default colo location got removed, jelmer, how do you fix that?18:14
jelmermgz: "bzr co file:,branch=somethingexisting ."18:14
jmlbut I didn't remove trunk though...18:15
jmlhuh, apparently I did18:15
jmlrmbranch merrily ignores the argument I gave it.18:15
mgzit's seems to be too easy to do by accident18:15
jelmerjml: It doesn't - but it looks the argument you give it up as a branch18:16
jmljelmer: I don't follow. I did 'bzr rmbranch deployed' while switched to the trunk branch and it removed the trunk branch.18:16
matthewg42I 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
matthewg42and if so... how?18:24
jelmerjml: rmbranch doesn't have special support for colocated branches18:26
jelmerjml: so it tries to look up "yourbranch" as a path on the filesystem18:26
jelmerjml: "yourbranch" isn't a file that exists, so it tries "" (assuming that "" is a branch which contains the file "yourbranch")18:27
jelmerjml: and then it ends up removing "yourbranch")18:27
jelmermatthewg42: it is preserving the multiple commits - if you commit you can still see them with "bzr log -n0"18:27
jelmerI think, perhaps for rmbranch we shouldn't be allowing people to specify a path inside of a branch18:29
jelmermatthewg42: alternatively, you can look with 'bzr qlog'18:29
matthewg42jelmer: PEBKAC... I did not know about -n0.18:29
matthewg42thank you!18:30
matthewg42< still getting to grips with bzr.18:30
jmljelmer: ah, I see.18:42
=== Quintasan_ is now known as Quintasan
pooliehi wgz21:08
RenatoSilvais it safe to ln -s /windows-bzr-profile ~/.bazaar? I can't see relevant difference between %AppData%/Bazaar/2.0 and ~/.bazaar21:33
jelmerhi RenatoSilva21:34
jelmerRenatoSilva: yes, that should be fine21:34
RenatoSilvaawesome, thanks jelme21:49
pooliejml, hi?22:07
=== jvargas_ is now known as jvargas
jmlpoolie: hello22:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!