| mgz | morning! | 08:01 |
|---|---|---|
| === zyga is now known as zyga-afk | ||
| === zyga-afk is now known as zyga | ||
| m1sc | hi. remove-branch seems to work for local locations only. how do I remove a remote branch? | 10:11 |
| bob2 | don't think bzr has that built in | 10:19 |
| mgz | m1sc: that works over a smart server in recent versions, but deletes the branch only, any repository is left existing | 10:23 |
| m1sc | mgz: smart http? I use bzr 2.5.1 on client side -- when trying "bzr remove-branch https+urllib://example.com/my/branch", it's doing http authentication but then tries to delete the branch locally.? (bzr: ERROR: Not a branch: "/home/user/foo/https+urllib://example.com/my/branch".) | 10:40 |
| mgz | that's not smart. | 10:42 |
| mgz | m1sc: this is what works <http://pastebin.ubuntu.com/1084259/> | 10:43 |
| jelmer | it tries the remove branch first then falls back to locally | 10:43 |
| mgz | (progress leakage there incidentially) | 10:44 |
| mgz | falling back to treating it like a filename when it has a scheme seems like a bad idea | 10:45 |
| mgz | m1sc: what you can do is just remove the directory via any other means | 10:46 |
| jelmer | mgz: yeah | 10:48 |
| m1sc | bob2, mgz, jelmer: thanks, will stick with ssh | 10:49 |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga | ||
| ggherdov | hello. I know I can ask bazaar for all commits involving file FOOBAR.txt. Can I show all commit made by a specific developer, too ? | 15:11 |
| mgz | yup, see `bzr help log` | 15:19 |
| mgz | note the author(s)/committer distinction | 15:20 |
| mgz | but generally `bzr log -n0 -m "Your Name"` will be fine | 15:22 |
| ggherdov | mgz thanks | 15:27 |
| james_w | vila, hi, you around? | 15:57 |
| vila | james_w: yup | 15:57 |
| james_w | great | 15:58 |
| james_w | hi :-) | 15:58 |
| james_w | vila, what would be the best way of injecting the db configuration values in to the config stack during the tests? | 15:58 |
| james_w | currently I believe it uses the standard dbs, which isn't great for test isolation | 15:58 |
| james_w | I'm adding support for postgres to the test suite, so now we need to run against both | 15:58 |
| vila | err, no, I think it uses ones under self.test_dir | 15:58 |
| james_w | I don't want to be adding pkgimport.conf on the fly | 15:59 |
| james_w | aha! | 15:59 |
| * james_w tries to find that | 15:59 | |
| vila | TestCaseWithConfig does that for you, at least it sets pi.base_dir | 15:59 |
| vila | now, I don't know postgres, but given the config you added for it it seems to be using a host:port to reach the db so I you can set that in the config and initialize the db itself | 16:00 |
| james_w | vila, what's "_set_store_content" | 16:00 |
| james_w | I mean, what's "store" in that context? | 16:01 |
| vila | a trick to add additional content in the config, there are examples... | 16:01 |
| vila | let me check | 16:01 |
| vila | store as in config store, a physical container, here, a file :) | 16:01 |
| james_w | ah, I see | 16:01 |
| james_w | but it's a "set all" interface, rather than an "append" interface? | 16:01 |
| vila | look into test_mass_import for how to add stuff | 16:02 |
| vila | just calling super() then | 16:02 |
| vila | so each subclass can add what it needs | 16:03 |
| james_w | oh, hmm | 16:03 |
| james_w | ok | 16:03 |
| james_w | thanks | 16:03 |
| * james_w ponders moving this to fixtures | 16:04 | |
| === iBasic is now known as BasicOSX | ||
| Wiz_KeeD | hey guys | 17:49 |
| lduros | hello, I have a bzr branch which I initialized with the source files from Firefox 12. Now, I made some changes to these files, and now there is a Firefox 13 with many many differences with both Firefox 12 or my own fork. My question is, what is the best way to merge all the changes from the files in Firefox 13, while keeping the changes in my own fork. I can see many ways to do that more or less efficiently with diff and bzr diff. But I'd like to know if the | 17:52 |
| lduros | so what I did is use bzr diff -r1 > diff.txt | 18:07 |
| lduros | which outputs all the difference with the current version with the first version in which the initial files were present | 18:07 |
| lduros | and now I'll try to apply it as a patch to the new set of files | 18:08 |
| lduros | does it make sense or is there a better way to do this with bzr and a special merge | 18:08 |
| lduros | hello, I asked a question earlier, got no answer, and thought maybe i'd ask it again | 23:13 |
| lduros | if you have upstream files, you create a branch with them | 23:14 |
| lduros | make changes to them, | 23:14 |
| lduros | and then the upstream releases a new version | 23:14 |
| lduros | what's the best way to merge those new changes from upstream while keeping your own changes | 23:14 |
| lduros | upstream does not use bzr by the way, i'm just using the tar | 23:14 |
| lduros | using bzr diff and then patch does the trick, but is there a more elegant way? :-) | 23:16 |
| lduros | or some documentation worth reading? :-) | 23:16 |
| lifeless | lduros: bzr import can import the tar | 23:21 |
| lifeless | lduros: have one branch representing upstream and one your work, import upstream onto the upstream branch, then merge that to your branch. | 23:21 |
| lduros | ah | 23:28 |
| lduros | ok, I see, I'll try this, thanks | 23:29 |
| lduros | looking into bzr import at the moment | 23:29 |
| lduros | lifeless: what you are describing is basically what's described in this page, minus the bzr import for the tar >> http://wiki.bazaar.canonical.com/TrackingUpstream -- correct? | 23:31 |
| lifeless | yes | 23:32 |
| lduros | ok cool | 23:32 |
| lduros | :-) | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!