| matthewg42 | Hi. Is there a function in bzr to find in what revisions a specific line of code was last modified? | 00:57 |
|---|---|---|
| ajmitch | matthewg42: bzr annotate | 00:58 |
| matthewg42 | ajmitch: thank you! | 00:59 |
| matthewg42 | ajmitch: perfect | 01:00 |
| poolie | hi ajmitch | 01:15 |
| ajmitch | poolie: hello | 01:39 |
| 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/ | 04:58 |
| Jordan_U | I'm using Ubuntu Precise and the actual output of "bzr --version" is here: http://paste.ubuntu.com/849555/ | 05:02 |
| spiv | Does "bzr --no-plugins --version" work? | 05:04 |
| spiv | Perhaps your version of bzr-bisect needs updating. | 05:04 |
| Jordan_U | spiv: No error message with "bzr --no-plugins --version". | 05:07 |
| spiv | Ok, so a problem with the bzr-bisect plugin then. | 05:09 |
| 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:11 |
| spiv | Yes, please do file a bug on the bzr-bisect package. | 05:13 |
| poolie | Jordan_U, please paste the bug here too | 05:17 |
| 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:19 |
| spiv | Well, it'd just be a bug asking for the package to be updated then :) | 05:20 |
| Jordan_U | poolie: When I try that command I get http://paste.ubuntu.com/849565/ | 05:25 |
| poolie | spiv, but he's running from ~/.bazaar... | 05:32 |
| 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:33 |
| poolie | oh you said Precise | 05:34 |
| Jordan_U | poolie: Ubuntu. | 05:34 |
| poolie | so, yeah, try the package | 05:34 |
| Jordan_U | E: Unable to locate package bzr-bisect | 05:35 |
| 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:37 |
| spiv | poolie: oh, I see | 05:47 |
| spiv | poolie: my bad! | 05:47 |
| 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 | 06:09 |
| poolie | hi vila | 07:00 |
| vila | hi all | 07:08 |
| poolie | hi there | 07:15 |
| poolie | vila do you know of a problem where a plain bzr init (rather than push) on lp doesn't configure stacking? | 07:32 |
| vila | meh, never heard of | 07:33 |
| vila | happened recently ? | 07:33 |
| vila | specifically: with a 2.6 bzr ? | 07:33 |
| poolie | with 2.5bsomething | 07:34 |
| vila | rings no bell, but diagnosing it should be doable with -Dhpss and/or -Dhpssvfs (sp?) | 07:35 |
| 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:36 |
| vila | bzr config -d lp:~mbp/launchpad/remove-bsondump2 | 07:42 |
| vila | reports a stacked_on_location | 07:42 |
| poolie | i just set it from python | 07:44 |
| vila | it wasn't ? | 07:44 |
| 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:45 |
| vila | poolie: you're running bzr from source right ? | 07:47 |
| poolie | from the daily ppa | 07:47 |
| poolie | so 2.6dev | 07:47 |
| vila | on precise that would be revno 6460 ? | 07:51 |
| vila | poolie: that would rule out revno 6468 which otherwise may be a good suspect | 07:53 |
| poolie | Version: 2.5.0~bzr6460.6162~ppa4023~precise1 | 07:58 |
| poolie | what a version :) | 07:58 |
| 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:03 |
| vila | by copying the /+branch-id/nnnn from a know working branch ? | 08:04 |
| 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:13 |
| vila | ECANTPARSE | 08:17 |
| vila | what prints ? | 08:17 |
| vila | oh, bzr init ? | 08:17 |
| poolie | yes | 08:18 |
| 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:19 |
| 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:23 |
| vila | poolie: I can reproduce if I try to do 'bzr init' first, but a bare push works as expected | 08:24 |
| 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:25 |
| 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:26 |
| vila | poolie: bah, easy to test with older bzr, I'll delete the branches later | 08:27 |
| vila | poolie: confirmed for 2.0 | 08:30 |
| vila | poolie: hehe, I almost forgot the old progress bar look ;) | 08:32 |
| poolie | yeah, a bit | 08:32 |
| mgz | morning all! | 09:01 |
| vila | mgzorning ! | 09:02 |
| poolie | hi mgz | 09:09 |
| poolie | i might call that a night | 09:09 |
| vila | poolie: enjoy your night ;) | 09:14 |
| poolie | :/ | 09:15 |
| poolie | thanks though | 09:15 |
| 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:25 |
| 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:37 |
| 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:43 |
| ev | mgz: cheers! Just trying to figure out how to merge into a subdir. the merge-into plugin seems to be broken. | 09:44 |
| mgz | ev: you could just mv inside the exported branch and commit before merging | 09:53 |
| ev | mgz: and that's exactly what I did :) | 09:54 |
| ev | mgz: thanks for all your help! | 09:54 |
| ev | worked perfectly | 09:54 |
| 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:47 |
| vila | grr, I have the opposite of Alzheimer: I remember reviewing stuff but I'm the only one remembering it :-( | 11:49 |
| vila | on the other hand it may just be because unity hated me last week and lost them... | 11:51 |
| 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:55 |
| vila | hehe | 11:56 |
| jelmer | :) | 11:56 |
| damd | 😍 | 12:01 |
| jelmer | thanks vila! | 12:02 |
| === yofel_ is now known as yofel | ||
| farblue | afternoon all :) | 15:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| jelmer | farblue: branches are basically whatever you want them to be - as is the case in svn | 15:06 |
| 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:08 |
| jelmer | farblue: you can use "bzr push" in individual branches to push changes back into svn | 15:10 |
| farblue | ok, that makes sense :) | 15:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:27 |
| farblue | rather than having a repo per project | 15:28 |
| 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:33 |
| 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:39 |
| 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:40 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| fullermd | 'branches' is roughly "for i in `find . -type d`; echo $i if is_a_branch $i; done" | 15:48 |
| jelmer | fullermd: it's something different for svn branches | 15:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| farblue | so, given all of this, can people recommend a 'pure bzr' system and a 'bzr interfacing with the central svn repo' system? | 15:55 |
| 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:56 |
| farblue | we currently have ~/Sites/dev/project and ~/Sites/release/project for each project | 15:57 |
| 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:58 |
| 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. | 15:59 |
| 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:00 |
| 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:02 |
| farblue | except I'd then have to have a folder for each branch even if it wasn't also a working tree | 16:03 |
| 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:08 |
| jelmer | farblue: this all sounds really complex; I would just start out with something simple and then change things around as necessary later | 16:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| farblue | our branches are /branches/username/branchName (often a ticket number) | 16:18 |
| jelmer | farblue: yes, it should understand branches/*/* | 16:18 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| farblue | oh? so how does that work? may I have an example? | 16:27 |
| 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:28 |
| 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:29 |
| farblue | hmm | 16:30 |
| vila | if it's a svn repo, defaults can be specified in subversion.conf avoiding issues with overrides in locations.conf | 16:32 |
| jelmer | vila: That doesn't help for branches, because there are multiple branches in a single svn repo | 16:33 |
| 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 | 16:34 |
| 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:22 |
| 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:26 |
| 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:28 |
| 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:29 |
| jml | is the plan for colo to be the default with bzr? | 17:31 |
| jelmer | jml: possibly, but at least not in 2.5 | 17:32 |
| ggherdov | 'bzr pack'ing ... | 17:32 |
| ggherdov | msg: as you said. you wow-ed me. | 17:36 |
| jml | jelmer: ok, thanks. | 17:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| mgz | ggherdov: a bug would be good I think, the temporary bloating is suprising. | 17:41 |
| 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:42 | |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| mgz | if you remove them and pack again do they reappear? | 17:50 |
| ggherdov | mgz: i'll try. | 17:50 |
| ggherdov | mgz: no, re-packed and they aren't back. the were an ephemeral mirage. that's voodoo. | 17:55 |
| 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:57 |
| 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:58 |
| 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? | 17:59 |
| 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:00 |
| 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:04 |
| 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:07 |
| mgz | missing colon after method def... | 18:08 |
| mgz | missing colon after if statement... | 18:08 |
| mgz | that's it. but test failures from mixing up "flavors" and "flavours" in variable naming... | 18:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| jml | *blink* | 18:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:24 |
| 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:26 |
| 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:27 |
| 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:29 |
| matthewg42 | thank you! | 18:30 |
| matthewg42 | < still getting to grips with bzr. | 18:30 |
| jml | jelmer: ah, I see. | 18:42 |
| === Quintasan_ is now known as Quintasan | ||
| poolie | hi wgz | 21:08 |
| 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:33 |
| jelmer | hi RenatoSilva | 21:34 |
| jelmer | RenatoSilva: yes, that should be fine | 21:34 |
| RenatoSilva | awesome, thanks jelme | 21:49 |
| RenatoSilva | r | 21:49 |
| poolie | jml, hi? | 22:07 |
| === jvargas_ is now known as jvargas | ||
| jml | poolie: hello | 22:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!