| bignose | $ bzr merge | 01:31 |
|---|---|---|
| bignose | bzr: ERROR: No location specified or remembered | 01:31 |
| bignose | How can I tell Bazaar to use the parent branch in those cases? | 01:32 |
| fullermd | bzr merge :parent | 01:32 |
| bignose | this is a branch created with ‘bzr cbranch’, if that matters. | 01:32 |
| bignose | fullermd: can I make it so it will know that the first time, so I don't have to distinguish &"^first time I merge from “subsequent times I merg” in a branch? | 01:32 |
| fullermd | Not short of code hackery. | 01:33 |
| fullermd | Maybe it could be frobbed via a plugin... | 01:33 |
| bignose | I seem to remember Bazaar knowing a default branch to merge from in previous versions. | 01:33 |
| bignose | did that get deliberately removed? | 01:33 |
| bignose | 'cause Bazaar usually guesses right in the absence of specifics, for many other operations. | 01:34 |
| bignose | and this one seems obvious, to me. | 01:34 |
| fullermd | I have vague recollection of merge falling through to parent loc, but I'm not sure if that's a real memory or not. | 01:34 |
| bignose | ah, here's the problem: bzr: ERROR: No parent location assigned.” | 01:35 |
| bignose | so perhaps I remember correctly about merge guessing correctly | 01:35 |
| bignose | but now the parent is unknonw. | 01:35 |
| bignose | maybe it does matter that ‘cbranch’ was used. shouldn't that set the parent? | 01:35 |
| fullermd | No idea. I've never used it. I'd sorta think it would. | 01:36 |
| fullermd | See what info says. | 01:36 |
| bignose | info shows no parent location. | 01:37 |
| fullermd | Seems like an odd thing to wind up with. | 01:38 |
| fullermd | Mmm. Pastebin the whole? | 01:38 |
| bignose | whole what? | 01:38 |
| fullermd | info output. | 01:38 |
| bignose | fullermd: <URL:http://dpaste.com/753595/> | 01:41 |
| bignose | thanks for spending time on this. | 01:41 |
| fullermd | Blargh. Bound breckout fallout, I'll wager. | 01:42 |
| fullermd | Bet you'll see a parent branch on `bzr info :bound` | 01:43 |
| bignose | fullermd: yes. | 01:43 |
| bignose | “bound brecket”? | 01:44 |
| bignose | “bound breckout”? | 01:44 |
| fullermd | The whole "bound branch" / "checkout" mess that I periodically rant upon. | 01:44 |
| bignose | heh | 01:45 |
| bignose | well, I no longer do checkouts | 01:45 |
| bignose | but I do use ‘bzr branch --bind’ and ‘cbranch’ | 01:45 |
| fullermd | Well, you do here ;p | 01:45 |
| bignose | so I guess it still falls in the scope of your rant | 01:45 |
| bignose | fullermd: what information should I put in a bug report? | 01:46 |
| fullermd | In this case, you're hitting the 'bound branch' behavioral side. You want the parent that you made this branch from, but the 'branch' that you made (and has that info) is the one on the far side, whereas the 'branch' you're working on is your local bound one. | 01:46 |
| fullermd | So your location aliases are resolving (or not, to be precise) there. | 01:47 |
| fullermd | Which, I would argue, _is_ the correct behavior for a bound branch. Though not for a checkout. | 01:47 |
| bignose | ugh | 01:49 |
| fullermd | So, I'm not quite sure it's actually a "bug" that's resolvable, short of "sort out the whole mess" :| | 01:49 |
| bignose | so, tell me what the bound branch and checkout distinction is here. | 01:50 |
| bignose | which one do I have? or is it both? | 01:50 |
| fullermd | Still, it's definitely a confounding behavior. Maybe that's worth a bug report just to stake it down... | 01:50 |
| fullermd | Well, it's bzr. You have both. Or, more precisely, neither. | 01:51 |
| bignose | I think I have been convinced in the past by your rants, and stopped doing ‘bzr checkout’ and started ‘bzr branch --bind’ instead | 01:51 |
| bignose | but I want the UI of ‘bzr cbranch’, so I continue to use that. is this confounding the problem? | 01:51 |
| bignose | and what can I use instead, if so? | 01:51 |
| fullermd | Well, I think the only difference between 'checkout' and 'branch --bind' is that the latter sets the remote to the parent location? | 01:52 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches is something I wrote up a while ago when I was in the middle of one of my rants on the topic. | 01:53 |
| fullermd | I should add something explicit about the locations too... | 01:53 |
| bignose | fullermd: thanks for your help. <URL:http://bugs.debian.org/675297> | 03:01 |
| ubot5 | Error: debian bug 675297 not found | 03:01 |
| bignose | ubot5: maybe not yet, but soon | 03:01 |
| ubot5 | bignose: I am only a bot, please don't think I'm intelligent :) | 03:01 |
| bignose | ubot5: I need a friend. | 03:01 |
| ubot5 | bignose: I am only a bot, please don't think I'm intelligent :) | 03:01 |
| === Ursinha` is now known as Ursinha | ||
| === Ursinha is now known as Guest90314 | ||
| mgz | morning all! | 07:29 |
| vila | \o | 07:36 |
| === jam1 is now known as jam | ||
| jml | just knocked up a silly plugin to measure how many LoC a branch introduces: lp:bzr-damage | 09:42 |
| mgz | vila: I'm confused, I thought you did do the merge-up when releasing 2.5.1 | 11:10 |
| vila | no, I didn't, too many stable branches with conflicts | 11:10 |
| mgz | darn. | 11:11 |
| vila | the merges up should be done by the ones who land on old stable branches, not by the RM | 11:11 |
| vila | *iff* there are no conflicts, I took the risk in the past that I won't introduce regressions by merging up. Here, there was conflicts that weren't trivial to my eyes, not mentioning they were different for each branch | 11:13 |
| vila | the fact that bialix's patch was lost in the noise is a painful fallout :-/ | 11:14 |
| mgz | right, jelmer or me could have resolved it without too much complication, but needed some knowledge of the change | 11:17 |
| vila | mgz: I *did* mention I wasn't merging up when raising the issue with conflicts last week | 11:17 |
| vila | yeah, indeed, landing on a stable branch implies merging up | 11:17 |
| vila | especially when conflicts are *expected* | 11:18 |
| mgz | needed to be an action item like backporting the rmbranch fix, got lost while struggling to get pqm to actually land things | 11:18 |
| vila | yeah, that one was more focused and relied on the same assumption: stable branches were left in a clean state | 11:19 |
| vila | mgz: so, to come back to your original question, I didn't merge up 2.5 into trunk after freezing because the older stable branches were not clean | 11:22 |
| vila | so the only part that would have been merged up was your backports which are already there | 11:22 |
| === Guest90314 is now known as Ursinha | ||
| === sagaci_ is now known as sagaci | ||
| jml | if I want a bzr plugin to have optional color output, is there a particular library I should use? | 15:21 |
| jml | otherwise I'm going to plagiarize / depend on the color support in twisted.trial. nobody wants that. | 15:21 |
| mgz | there's some code for colour in bzrtools | 15:22 |
| jml | is it sensible for a plugin to depend on that? | 15:24 |
| mgz | jml: probably not, but worth looking at, and to see what bzr-grep does, which may depend on it or do its own thing | 15:38 |
| mgz | it's all pretty ugly I seem to recall | 15:38 |
| === lamont` is now known as lamont | ||
| jml | mgz: thanks. | 15:45 |
| caravel | hi folks o/ | 16:06 |
| mgz | hey there | 16:06 |
| caravel | Form reading http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/stacked.html I understand the point of --stacked-on, but not quite --stacked | 16:08 |
| caravel | In the first --stacked example, where would `bzr push --stacked`push to ? | 16:08 |
| mgz | whatever you're trying to do, stacking is probably not the right thing :) | 16:09 |
| caravel | Is that also to the source-url given at first line (bzr branch) | 16:10 |
| caravel | ? | 16:10 |
| caravel | mgz: :) | 16:10 |
| bsd | caravel: I don't think push supports '—stacked', just '—stacked-on' | 16:10 |
| caravel | mgz: I'll expose my use case after that clarification :) | 16:11 |
| caravel | bsd: well, that's not what the manual says at the above URL | 16:11 |
| bsd | caravel: push has —stacked-on; branch has —stacked | 16:12 |
| bsd | caravel: so I think your question is: on 'bzr push --stacked-on X Y` where does the push go? I think it goes to Y; Y is stacked on X. But I've never tried it | 16:13 |
| caravel | bsd: this is not true, it seems push has both: | 16:13 |
| caravel | $ bzr push --help | grep stacked | 16:14 |
| caravel | --stacked Create a stacked branch that references the public | 16:14 |
| caravel | --stacked-on=ARG Create a stacked branch that refers to another branch | 16:14 |
| bsd | caravel: geesh — I even did quickly look at that before replying. Clearly need to get these glasses checked :) | 16:14 |
| caravel | bsd: no worries, I often have that knd of bug myself :) | 16:15 |
| caravel | so, the user manual matches the cli options, that is not he option | 16:15 |
| caravel | that is not the issue* | 16:15 |
| caravel | but I fail to understand, in the user manual example , where would `bzr push --stacked` ... push to ? | 16:16 |
| bsd | caravel: my guess is that 'push —stacked X' is equivalent to 'push —stacked-on :parent X' | 16:19 |
| mgz | caravel: the configured public location of the parent branch, is what the help says | 16:19 |
| mgz | specifically: | 16:20 |
| mgz | if stacked: | 16:20 |
| mgz | parent_url = br_from.get_parent() | 16:20 |
| mgz | if parent_url: | 16:20 |
| mgz | parent = Branch.open(parent_url) | 16:20 |
| mgz | stacked_on = parent.get_public_branch() | 16:20 |
| mgz | ...and then falling back to parent_url | 16:20 |
| bsd | ah, that's different from :parent | 16:21 |
| caravel | mgz: but is that not what `bzr push`would do anyway, in that example ? | 16:24 |
| * caravel really feels he's lacking to understand something | 16:25 | |
| caravel | note, in that user man page there are two examples, I am talking about the first one starting with a simple `bzr branch source-url my-dir` | 16:27 |
| mgz | no, these commands create a branch that omits history present in the parent | 16:28 |
| caravel | mgz: by parent, you mean the parent of the local branch i.e. in that example, "source-url" is the parent of "my-dir" right ? | 16:30 |
| mgz | have to go now, building shutting | 16:30 |
| caravel | Since the bzr push [LOCATION] is not specified, `bzr push` alone would push new revisions to "source-url" | 16:30 |
| mgz | but overall it's more trouble than it's worth | 16:31 |
| caravel | ^^ | 16:31 |
| caravel | So I don't understand what difference would `bzr push --stacked` make if no [LOCATION] is given | 16:32 |
| * caravel will patiently pray for anyone to clarify this :) | 16:34 | |
| hexsprite | hey.. how do i check what revision my working copy is at? i tried bzr info but didn't seem to show that… even with -v | 16:47 |
| caravel | hexsprite: `bzr update`should tell you that (and proceed with any update if available) | 17:00 |
| caravel | hexsprite: `bzr info -v` will tel lyou that too (without any action) | 17:01 |
| hexsprite | mmm if i don't want to proceed? | 17:01 |
| caravel | hexsprite: and there might be other commands which I don't know/use (I'm just a user) | 17:02 |
| hexsprite | thanks caravel | 17:02 |
| caravel | hexsprite: `bzr heads` might be what you are looking for, actually (it's a plugin from bzrtools) | 17:05 |
| caravel | hexsprite: oh, no !!! :) you just want `bzr version-info` | 17:07 |
| hexsprite | oh great | 17:07 |
| caravel | hexsprite: thanks hexsprite, hadn't even found this one before (neither really needed, actually ^^) | 17:07 |
| === deryck is now known as deryck[lunch] | ||
| vila | hexprite (too bad you're gone :-/), caravel : 'bzr revno --help', in some cases you will prefer 'bzr qlog' from the qbzr plugin | 18:00 |
| vila | caravel: you'll get all the details starting at cmd_push in bzrlib/builtins.py | 18:01 |
| vila | caravel: but I'm in full agreement with mgz: you probably don't want to use that. It's needed in an edge case where you want to have some access rights applied to the history of a branch. Most of time, there are better ways to organize history sharing. | 18:04 |
| fullermd | There really should be something in the docs there that says "ignore this section unless you're Launchpad". | 18:20 |
| === deryck[lunch] is now known as deryck | ||
| lduros | I forgot again, how do I get bzr to generate a source directory, the kind that you want to tar | 18:43 |
| lduros | like a source package, from a branch | 18:43 |
| lifeless | bzr export | 18:43 |
| lduros | lifeless: thanks much! | 18:43 |
| lduros | :-0 | 18:43 |
| lifeless | will export a revision | 18:43 |
| lifeless | or if you're using bzr builddeb, bzr bd does that all automatically as part of the build | 18:43 |
| lduros | hmm neat | 18:43 |
| lduros | it builds a deb package? | 18:44 |
| lifeless | very much so :) | 18:44 |
| lduros | that sounds very helpful | 18:44 |
| lduros | I'll try that very soon :-D | 18:44 |
| caravel | vila: thank you for your answers | 19:21 |
| caravel | vila: revno and even version-info, were not "spontaneous" to locate. I had looked at info, status just like hexprite I guess, but I can guess why it's good as it is now :) | 19:23 |
| caravel | vila: maybe they could be listed in basic commands help ? | 19:23 |
| caravel | vila: cf. stacked, ok I'll take your and mgz advices (and take note of the details location, will investigate later, then) | 19:24 |
| caravel | vila: essentially, my use case is not very specific and well described here http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/organizing_branches.html i.e. per-team/user/task branches on a central server to ease sharing, but all "mirrored" locally so that "some of us" can merge things | 19:29 |
| caravel | vila: from the stack description, --stacked-on was making a lot of sense to me : being one of the mergers (and having brought everyone to bazaar..) I have a local shared repo holding all the mirrors. So I thought I should use this if I wanted e.g. to setup a workspace on a distinct local volume | 19:33 |
| caravel | I understand that in our case it would be pointless to use that on the central server (where all branches are within a shared repo, without working tree, pretty standard I guess) | 19:35 |
| caravel | (althought I wioder if I shouldn't actually use it to protect some of our branches -- anyway we can live without that so far) | 19:37 |
| caravel | vila: so as a temp conclusion, I guess I'd agree with fullermd : manual should expand a little more about its pros and cons, maybe ? Is that also discouraged for local usage as I suggested above, i.e. with mirrors and workspaces located on a distinct local volumes ? | 19:40 |
| caravel | located on* distinct, seperated | 19:41 |
| fullermd | Dunno why you'd even consider it locally, unless your branches are gigantic and you have very limited and very slow storage. For that matter, it may well make it worse with slow storage since it'll blow the cache. | 19:45 |
| vila | caravel: I f you already have a shared repo, you're done. Nothing can beat it. | 19:46 |
| vila | caravel: if you want to organize your working trees differently, that's another story, but stacking in only between branches and repositories. | 19:47 |
| caravel | fullermd: vila by "distinct local volumes" I mean mount points, or eg. drive letters in Wind'Oz wonderland | 19:51 |
| caravel | So that the mirrored share repos would be located under a "third party" disk space, excluded from backup between other things, while the actual workspace stacked on it would be under the daily/personal data space. Does it not make any sense ? | 19:54 |
| caravel | (I mean, a local disk space dedicated to "third party" stuff, versus another one dedicated to "own contribs" stuff) | 19:55 |
| caravel | but yeah, I guess symlinks are my friends and provide the same result :) | 19:55 |
| caravel | huh, no actually | 19:56 |
| * caravel 's last comment about symlink was really silly, time to pull off for today I guess | 19:56 | |
| caravel | so , iis that not a good reason to use stacks ? or am I still missing the point ? | 19:58 |
| fullermd | I don't really understand your usecase (and don't have time to really try to grok it, sorry), but I can't say it sounds overly desirous of them. | 20:00 |
| fullermd | And that to one side, I've never heard of anybody but LP using stacking and having a good experience from it. If indeed LP is having a good experience... | 20:00 |
| thumper | lifeless: morning | 20:58 |
| thumper | lifeless: here is a question for you, what do you see the benefits of signing commits as | 20:59 |
| thumper | lifeless: and do you expect it? | 20:59 |
| Larsibarsi | Hello, I am a little confused about the different setups available, and I would like to ask if someone can point me to the right workflow setup for our workflow. I red already some of the docs, but feel unsure which one of the described workflows fits best to the one my colleague and me have established. | 21:03 |
| hbeck | what would be the appropriate method to update (pull or merge?) changes from a SVN repo into my bzr copy of that repo, to which I've made some changes? | 21:11 |
| hbeck | I'm trying "bzr merge svn+https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk" but it seems to think it needs to wholesale replace every file or something | 21:12 |
| Larsibarsi | Me and Peter both work on the same web site. Since we use a content management system that uses a database it is not practical to copy all stuff to local, so we both would edit the files directly on the host server. And the server doesn't allow SSH-connections or something similar - it would be a dump bzr-server. For keeping track of the changes and having an easy way to revert changed files I want to use bazaar... Where shall the main repo | 21:14 |
| Larsibarsi | sitory reside, and how can we use it then? | 21:14 |
| jave | hello | 21:39 |
| jave | i was trying out "bzr bisect" and now the branch is in a weird state. how can I restore it? | 21:39 |
| lifeless | thumper: hi | 21:40 |
| lifeless | thumper: projects that want to detect attempts to alter their history need commit signing. | 21:40 |
| anes | hi guys, I want to learn about bazaar, what does it actually mean? | 22:37 |
| lifeless | jave: bzr revert probably | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!