| mlischke | Hi, I have a bzr repository on a server without working tree and when I run "bzr status" (or "bzr merge.." what is my original intent) I get the error "bzr: ERROR: No WorkingTree exists for..". | 07:51 |
|---|---|---|
| mlischke | Shouldn't that work also for tree-less branches? | 07:51 |
| lifeless | no | 07:52 |
| lifeless | status reports on the tree status | 07:52 |
| lifeless | it has no meaning for tree-less branches | 07:52 |
| lifeless | bzr info will work | 07:52 |
| mlischke | hmm, forget bzr status then, it was just a test, actually I want to merge another branch into this one | 07:53 |
| mlischke | (bzr info works as expected) | 07:53 |
| lifeless | well you'll need a tree :) | 07:53 |
| mlischke | sounds a bit … weird, I can create a branch without working tree, shoudn't I be able to merge from the parent tree to the copy also without a tree? | 07:58 |
| lifeless | no, because merge's job is to prepare an updated tree. | 07:59 |
| lifeless | when you commit the merge you can push the commit to a treeless branch | 07:59 |
| mlischke | Ok, so what can I do to to make the copy take all changes from another branch? Create a tree in the copy, merge, remove tree? | 08:02 |
| lifeless | mlischke: either do the merge elsewhere and push the result of the merge to the branch, or checkout the branch and do the merge in the checkout. | 08:04 |
| mlischke | hmm, actually, this was my first approach, I have a checkout of both branches, but that gives me a criss-cross | 08:05 |
| lifeless | mlischke: for instance; if you want to do this directly on the server; bzr checkout --lightweight $(branchpath) /tmp/foo; cd /tmp/foo; bzr merge $(otherbranch); bzr commit -m "Merged otherbranch";cd ..; rm -rf foo. | 08:05 |
| mlischke | ok, let me try this on the server... | 08:06 |
| mlischke | Previously I only tried locally | 08:06 |
| lifeless | mlischke: criss-cross merges are a result of having an ambiguous history, not of the trees | 08:06 |
| lifeless | you'll get that everywhere until it's resolved. | 08:07 |
| mlischke | hmm, so it wouldn't help to merge on the server? | 08:07 |
| mlischke | I always have to resolve criss-cross issues? | 08:07 |
| mlischke | My hope was it would be simpler to solve when doing it on the server, but if that wouldn't help I can as well go through the hassle and clean it up locally | 08:08 |
| mlischke | lifeless: thanks, I see the same criss-cross merge problem on the server... | 08:14 |
| lifeless | mlischke: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/criss-cross-help.html | 08:14 |
| mlischke | yes, thanks, have read this already | 08:15 |
| mlischke | and use weave, but got +50 conflicts, so I was looking for an easier approach | 08:15 |
| lifeless | so yes, you will see it everywhere until its been resolved (by merging into one or the other side) | 08:15 |
| mlischke | seems I have to bite the bullet | 08:15 |
| lifeless | sorry yeah | 08:15 |
| lifeless | this tends to happen if you merge branch A to branch B and B to A without picking up the prior merge of A to B | 08:16 |
| mlischke | It was a chain like this: A -> B, A -> C, now C -> B (as preparation for a later merge back to C) | 08:17 |
| lifeless | that can do it | 08:18 |
| lifeless | one way you might be able to fix it | 08:18 |
| mlischke | C -> B is rather C merge to B, not a branch | 08:18 |
| lifeless | merge C->B with -r - and choose the revision of C right before the merge of A->C | 08:18 |
| lifeless | commit that | 08:18 |
| lifeless | then merge C->B without -r | 08:19 |
| mlischke | thanks, will try that | 08:21 |
| === r0bby is now known as robbyoconnor | ||
| icebrain | Hi! I'm thinking of setting up a readonly bzr server. Is it safe to give access using bzr_ssh_path_limiter? | 11:34 |
| icebrain | safe enough to, say, publish the access information publicly? | 11:35 |
| mgz | should be, you can just expose over http, which is reasonable performance for smaller repos | 12:25 |
| === stub` is now known as stub | ||
| wedgwood | anyone know of good examples of how to do the bzrlib equivalents of status (minimally checking for changes), revert, and clean-tree? | 17:03 |
| beuno | wedgwood, I can help after lunch | 17:11 |
| wedgwood | beuno: much appreciated | 17:11 |
| wedgwood | I was just about to grab the bazaar source, but I'm nearly certain there's a more concise way | 17:12 |
| beuno | wedgwood, have you seen this? http://wiki.bazaar.canonical.com/Integrating_with_Bazaar | 17:12 |
| beuno | it won't have exactly what you're looking for, but it may tp you in the right direction | 17:12 |
| beuno | IIRC, what you want to operate on is the working tree | 17:12 |
| wedgwood | no, I hadn't seen that. It does cover the status/diff bits. I'll see if I can find the rest. | 17:14 |
| * beuno goes eat | 17:14 | |
| wedgwood | I see WorkingTree.revert (undocumented). Looks promising. | 17:15 |
| wedgwood | beuno: I found everything I need. thanks for the pointer | 18:01 |
| beuno | wedgwood, w00t, np | 18:19 |
| === vednis is now known as mars | ||
| === iBasic is now known as BasicOSX | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!