| loswillios | hah! | 01:09 |
|---|---|---|
| * loswillios waits for james_w to appear | 01:10 | |
| nir | What can cause this error on bzr merge ../other | 01:40 |
| nir | bzr: ERROR: [Errno 1] Operation not permitted | 01:40 |
| nir | both branches are local, both owned by me | 01:41 |
| nir | I merge changes in main in the other branch, but I can merge changes from other in main | 01:42 |
| nir | solved :-) | 01:47 |
| nir | One file was locked (mac os x feature) I don't have any idea why | 01:48 |
| nir | anyway, the error message is not helpful - it should show the path that failed | 01:49 |
| lifeless | nir: good point; its likely though that its an OSerror being raised rather than a bzr internal error that we can format and show useful data on | 01:51 |
| lifeless | we can certainly fix this particular case if you can provide the traceback and info for reproduction | 01:51 |
| === Verterok is now known as Verterok_ | ||
| minghua | Hi, I wonder if there is a way to combine multiple commits into a single one when doing "bzr rebase". | 03:03 |
| jelmer | minghua: not at the moment, no | 03:04 |
| minghua | jelmer: Thanks. | 03:05 |
| jelmer | minghua: Why would such a feature be useful? | 03:05 |
| minghua | jelmer: I am a translator. I commit my work every day. But it makes little sense to push or send patch of multiple changes when the translation is sent to upstream. | 03:07 |
| minghua | jelmer: If you read the bottom of http://wiki.debian.org/Teams/Dpkg/GitUsage you'll see the Debian dpkg upstream developers require translators to combine their changes before pushing. | 03:08 |
| jelmer | minghua: that's specific to git though | 03:10 |
| jelmer | when upstream merges your changes with bzr, there is only one additional revision on mainline | 03:10 |
| minghua | jelmer: Yes. That's why I am asking if bzr has something similar... | 03:10 |
| jelmer | minghua: I don't see how it clutters mainlines revision history with zbr | 03:10 |
| minghua | jelmer: Oh, maybe that's the case. I am a quite new bzr user. But I just did a "bzr rebase", and I got an empty commit for "merge from upstream". | 03:12 |
| minghua | I did some translation changes in my branch, then I "bzr merge" with upstream, then I "bzr commit" as revision #n, finally I decided to do "bzr rebase". And the revision #n is rebased as an empty commit. | 03:13 |
| jelmer | there shouldn't be a reason to do a rebase at all there | 03:13 |
| minghua | Hmm. Maybe there isn't. I should just run "bzr diff" across two branches. | 03:14 |
| jelmer | in general, if you do a merge of upstream+commit there's no need for a rebase and vice-versa | 03:15 |
| jelmer | minghua: If you don't use rebase at all, you won't clutter upstreams mainline | 03:16 |
| jelmer | and there will simply be one revision in mainline where your branch was merged | 03:16 |
| jelmer | no matter how many revisions it has | 03:16 |
| jelmer | "bzr log" will then show your revisions indented below that merge revision | 03:17 |
| jelmer | or not at all, depending on what you ask it to show | 03:17 |
| minghua | jelmer: I see. Thanks for the explanation. | 03:17 |
| jelmer | minghua: what are you trying to do exactly? Are you submitting a patch to dpkg? | 03:26 |
| minghua | jelmer: No. I was doing man-db's translation work, and upstream uses bzr. I did some small incremental changes to the translation. | 03:32 |
| minghua | There were also upstream changes in between, and I merge and commit them once in a while. | 03:32 |
| minghua | Today I want to see how many changes I've made and what they are, so I did rebase, now all my local changes are on top. | 03:33 |
| minghua | I'll probably send a patch to upstream since I can push into the upstream repo, but that's not really relevant to the discussion. | 03:34 |
| minghua | jelmer: So in summary, what I was trying to do is to see my changes over the past months (which are acutally on a single file). "bzr diff" across two branches should do that. It would be nicer to see them individually, though, and I don't know how to do that yet. | 03:36 |
| jelmer | bzr diff -c <revno> should show you the changes in an individual commit | 03:38 |
| minghua | jelmer: But that requires me to go through "bzr log" to get the revno of my commits, doesn't it? | 03:43 |
| jelmer | yep - you're looking for something that will present a concatenation of all those patches? | 03:51 |
| jelmer | I guess something like "for I in `seq FROM-REVNO..TO-REVNO`; do bzr diff -c $I; done" can do that, but I'm not aware of any command in bzr that can | 03:51 |
| minghua | Wouldn't that include changes I merged from upstream as well? | 03:52 |
| minghua | I am looking for a way to see individual patches of my commits, and my commits only. | 03:52 |
| jelmer | ahh, ok | 03:53 |
| minghua | Then say if I'm doing both translation work and code changes, I may want to put all my translation changes in one commit to upstream, but separate the translation and the code. | 03:53 |
| minghua | I admit that's quite a corner case, of course. And I probably should use two different branches for that. | 03:54 |
| radix | are you trying to maintain a branch long-term? | 03:54 |
| radix | because indeed, you're probably much better off using specific, task-oriented branches. | 03:54 |
| minghua | It will be long-term if I don't have much time to work on it... | 03:55 |
| lifeless | minghua: rebase destroys history and collaboration; if you don't plan to collaborate on the translations, you can rebase safely. But if you plan to collaborate, rebasing is a significant negative. | 04:39 |
| minghua | lifeless: No, no collaboration so far. Thanks for the warning, though. :-) | 04:41 |
| lifeless | np | 04:41 |
| lifeless | its a significant part of why rebase isn't a common workflow in bzr land; and one of the things I find most weird about the git culture | 04:41 |
| minghua | I am from SVN land. Both cultures are new to me, I am just trying to figure out what is the best way to construct my workflow. | 04:42 |
| lifeless | ok | 04:43 |
| === cprov-lunch is now known as cprov | ||
| === kiko-afk is now known as kiko | ||
| === cprov is now known as cprov-away | ||
| dato | if I `bzr pulled`, and then I decide eg. I pulled something I didn't want in my branch yet, is there a way to go back that isn't `bzr uncommit; bzr uncommit; bzr uncommit` ? | 13:18 |
| fullermd | pull from yourself at the chosen rev? | 13:22 |
| dato | `b pull -r 1284 --overwrite . ` did the trick, thanks fullermd | 13:23 |
| loswillios | james_w: hej | 13:41 |
| loswillios | james_w: I fixed it | 13:41 |
| loswillios | turns out, /usr/lib/python2.4/site-packages/bzrlib was missing __init__.py and such stuff | 13:42 |
| james_w | loswillios: wow. good catch. | 13:46 |
| loswillios | the debian package is missing some symlinks here. manually symlinking the stuff works now | 13:56 |
| james_w | loswillios: you're running a backported version? | 13:58 |
| loswillios | yep | 13:59 |
| loswillios | but the package in etch was missing the symlinks also (bzr-0.11, lol) | 14:00 |
| loswillios | I begin to think, that something with this debian installation is wrong | 14:00 |
| james_w | it sounds like something funky might be going on with python-central | 14:00 |
| dato | loswillios: how are you installing the .deb? | 14:01 |
| dato | loswillios: the .deb itself won't have the symlinks, they are created at instalation time | 14:01 |
| loswillios | yes.. they symlinked each file seperatly. symlinking the whole /usr/share/pycentral/bzr/site-packages/ to site-packages did the trick | 14:01 |
| james_w | dato: I believe he said aptitude yesterday. | 14:02 |
| loswillios | dato: yeah, I thought so. with aptitude / apt-get | 14:02 |
| dato | ok | 14:02 |
| ubotu | New bug: #165014 in bzr "IPv6 support" [Undecided,New] https://launchpad.net/bugs/165014 | 16:10 |
| jelmer | lifeless: ping | 17:21 |
| === YGingras__ is now known as YGingras | ||
| === abadger_afk is now known as abadger | ||
| === abadger is now known as abadger1999 | ||
| james_w | jelmer: congratulations on your DM advocation. | 17:50 |
| jelmer | james_w: thanks! | 17:55 |
| === weigon_ is now known as weigon | ||
| === kiko is now known as kiko-afk | ||
| mwhudson | bzr: ERROR: Installed bzr version 0.93.0.dev.0 is too old to be used with bzr-svn, at least 1.0 required | 18:25 |
| === Verterok_ is now known as Verterok | ||
| mwhudson | jelmer: where do i get bzr 1.0 ? :) | 18:26 |
| fullermd | We're keeping it in svn. Just use bzr-svn to check it out... | 18:38 |
| Odd_Bloke | ^_^ | 18:38 |
| mwhudson | heh | 18:39 |
| jelmer | mwhudson: whoops :-) Fixed now, thanks. | 18:45 |
| jelmer | mwhudson: btw, that bug you hit pushing pydoctor should be fixed now | 18:46 |
| jelmer | mwhudson: although pushing should still be somewhat slow | 18:46 |
| * mwhudson tries | 18:47 | |
| mwhudson | "finding branches" is still pretty slow | 18:53 |
| jelmer | mwhudson: yeah, I hope to fix that for 0.4.5 | 18:53 |
| jelmer | its result can be completely cached, with a little bit of work | 18:53 |
| mwhudson | jelmer: will it get cached once it's completed? | 18:53 |
| jelmer | mwhudson: bits of it, but not completely | 18:54 |
| mwhudson | i see | 18:54 |
| jelmer | it uses svn metadata to find those branches and that metadata already gets cached | 18:55 |
| mwhudson | puh, conflicts | 19:15 |
| jelmer | mwhudson: during svn push? | 19:15 |
| mwhudson | yeah, but legitimate ones | 19:16 |
| mwhudson | how i wish svn had uncommit | 19:22 |
| mwhudson | pushing again, let's see how that goes | 19:22 |
| mwhudson | !paste | 19:34 |
| ubotu | pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) | 19:34 |
| mwhudson | jelmer: hee! http://paste.ubuntu-nl.org/45816/ | 19:35 |
| mwhudson | radix: you are being mailbombed, sorry about that | 19:35 |
| jelmer | :-( | 19:36 |
| jelmer | mwhudson: this is with subversion 1.4? | 19:36 |
| mwhudson | jelmer: it's whatever's in gutsy | 19:37 |
| mwhudson | jelmer: it looks like 11 commits actually ended up in svn though | 19:38 |
| mwhudson | jelmer: i'm trying again after 'ulimit -c unlimited' | 19:39 |
| lifeless | jelmer: pong | 19:40 |
| mwhudson | wth | 19:41 |
| mwhudson | i accidentally ^Ced it | 19:41 |
| mwhudson | and this: http://paste.ubuntu-nl.org/45819/ happened | 19:42 |
| jelmer | lifeless: 'morning | 19:42 |
| jelmer | lifeless: I was wondering if you could advocate my application to become a Debian Maintainer? | 19:42 |
| lifeless | sure | 19:42 |
| jelmer | It should be a matter of replying to the thread in debian-newmaint | 19:44 |
| jelmer | http://lists.debian.org/debian-newmaint/2007/11/msg00157.html | 19:44 |
| mwhudson | hi lifeless | 19:44 |
| mwhudson | there was something i wanted to ask you, but i can't remember what it was | 19:45 |
| dato | jelmer: if you'd bounce him the mail, replying would keep the threading | 19:45 |
| jelmer | dato: good point - just did so | 19:46 |
| lifeless | mwhudson: :) | 19:52 |
| samiam | morning all | 19:57 |
| samiam | I have a really quick and possibly stupid question | 19:58 |
| samiam | is it possible to change a log entry for a commit, post-commit? | 19:58 |
| samiam | I just realized I had made an error and would like to correct it | 19:58 |
| dato | nope. | 19:58 |
| dato | but if it's the last commit | 19:58 |
| dato | you can `bzr uncommit` it | 19:58 |
| dato | and commit again, with a fixed message | 19:58 |
| samiam | good point | 19:58 |
| samiam | it isn't the last | 19:59 |
| samiam | its no big deal, I just thought that this might come up from time to time and felt I should investigate now | 19:59 |
| samiam | its a single-user repo anyway | 19:59 |
| samiam | thanks dato | 19:59 |
| mwhudson | at least in conception, bazaar revisions are totally immutable | 19:59 |
| samiam | mwhudson: I had never really seen this capability in other vcs' so I thought I would ask just in case | 20:00 |
| samiam | truthfully, that would be a really bad thing to have in a vcs, because you'd lose the integrity or value of the commit logs | 20:01 |
| mwhudson | samiam: right :) | 20:01 |
| mwhudson | samiam: you can use rebase in situations like this, if it's really important | 20:01 |
| mwhudson | (probably not for a commit message, tbh) | 20:01 |
| samiam | it isn't important at all | 20:01 |
| samiam | just exploring bzr right now and using it for personal work | 20:02 |
| mwhudson | cool | 20:02 |
| samiam | thanks for the feedback mwhudson | 20:02 |
| mwhudson | np | 20:03 |
| * mwhudson stares at merge.py | 20:07 | |
| radix | mwhudson: heh | 20:08 |
| radix | mwhudson: when are you going to start using bzr? :) | 20:08 |
| mwhudson_ | jelmer: so that run got nixed by my machine crashing :) | 20:28 |
| === mwhudson_ is now known as mwhudson | ||
| jelmer | not due to bzr-svn, I hope ? :-) | 20:30 |
| mwhudson | jelmer: don't think so :) | 20:30 |
| abentley | hey mwhudson, how goes? | 20:41 |
| radix | _there's_ the spam :) | 20:49 |
| radix | mwhudson: use Launchpad! | 20:50 |
| fullermd | Hm. I think progress bars on check are a little squirrely. | 20:54 |
| lifeless | radix: mwhudson is using bzr. merge.py is in the guts | 20:54 |
| fullermd | Unless checking versionedfile 0 really does take about 10 times as long as the other 200-some, I suspect it's doing something other than it claims at that time. | 20:55 |
| lifeless | fullermd: enumerating the versionedfiles requires a table scan in packs | 20:55 |
| fullermd | I'm using good old-fashioned knits. | 20:56 |
| lifeless | ah, then its disk IO | 20:56 |
| fullermd | All in cache. | 20:56 |
| lifeless | bleh | 20:56 |
| lifeless | hit ctrl-\ and type bt CR | 20:56 |
| fullermd | python's getting 100% CPU while it's doing whatever it's doing there... | 20:56 |
| fullermd | Inner frame at the bottom? | 20:57 |
| lifeless | yes | 20:57 |
| lifeless | but look up the stack for the relevant function names | 20:57 |
| fullermd | Seems to be spending a lot of time in xml_serializer stuff. | 20:59 |
| lifeless | so look up | 20:59 |
| lifeless | some function will probably have iter or some hint in the name | 20:59 |
| fullermd | Seems to be mostly in repository._generate_text_key_index() | 21:00 |
| fullermd | It probably spends about 20 seconds in that versioned file 0/xxx on a branch where check runs in under a minute. | 21:00 |
| lifeless | ok | 21:01 |
| fullermd | Lemme halt it a couple times for a sampling... | 21:01 |
| lifeless | so that is scanning all the inventories | 21:01 |
| lifeless | it's meant to do a progress bar for that | 21:01 |
| lifeless | but it's reasonable for it to be expensive, its the dominating data structure of bzr | 21:01 |
| fullermd | It seems new, though. Nowhere near that much time elapsed between the revision checking and versionedfile checking last week or so. | 21:03 |
| fullermd | It used to just start counting as soon as it was in versionedfile. | 21:03 |
| fullermd | A few samplings within the process: http://paste.ubuntu-nl.org/45844/ | 21:07 |
| mwhudson | radix: >:) | 21:07 |
| mwhudson | abentley: good thanks, about to have dinner | 21:08 |
| fullermd | Wait, "unreferenced text versions" can't possible be right. It's within 1% of total revisions * file-ids; that's more texts than should exist period. | 21:11 |
| abentley | lifeless: The thing about KindChange is that it must appear in the list at the end, and diff_text must be second. | 21:15 |
| luislavena | hello guys. | 21:15 |
| lifeless | abentley: KindChange I can understand; why Text ? | 21:15 |
| lifeless | hi luislavena | 21:15 |
| luislavena | quick question: anyone using bzr-gtk on windows? | 21:15 |
| luislavena | hi lifeless | 21:15 |
| lifeless | fullermd: have you reconciled this repository with 0.92 or bzr.dev ? | 21:15 |
| lifeless | luislavena: I know people have managed to get it to work, and bzr-tortoise incorporates parts of it | 21:16 |
| abentley | Difftext must be second-last, because it's a catch-all. If it's early, more specialized diffs will never be used. | 21:16 |
| luislavena | lifeless: I'm using Olive without problems, but the diff it generates aren't colorified :P | 21:16 |
| lifeless | abentley: I don't think it has to be second-last. I think it has to be after anything else that would diff the same files | 21:17 |
| lifeless | abentley: same with DiffSymlink | 21:17 |
| lifeless | abentley: if I had a variation on that, I have to put it before DiffSymlink | 21:17 |
| lifeless | abentley: in fact, *all* of these have an ordering. I don't think there is a problem in allowing a certain amount of rope though :) | 21:18 |
| abentley | Yes, but diff_text is an instance and can't appear in the factory list at all. | 21:18 |
| abentley | So it must either appear before all registered factories (disaster) or after (safe). | 21:19 |
| abentley | And KindChange must appear after diff_text. | 21:19 |
| fullermd | lifeless: Yep. http://paste.ubuntu-nl.org/45846/ | 21:19 |
| lifeless | abentley: oh; I must have glitched on this. I thought it would still be a factory | 21:20 |
| lifeless | abentley: let me check the patch again | 21:20 |
| abentley | No, its construction depends on what parameters are passed to show_diff_trees. | 21:20 |
| ubotu | New bug: #165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Triaged] https://launchpad.net/bugs/165061 | 21:20 |
| === kiko-afk is now known as kiko | ||
| lifeless | abentley: so the old and new label parameters seem applicable to all Diff classes | 21:22 |
| abentley | I don't think they are. | 21:22 |
| lifeless | abentley: and the internal_diff parameter is indeed a touch tricky | 21:22 |
| abentley | It's purely a unified diff formatting quirk. | 21:23 |
| abentley | It's so that patch -p1 works. | 21:23 |
| lifeless | abentley: they change the path prefix don't they ? we should be showing that on e.g. symlink changes too | 21:23 |
| abentley | patch can't understand symlink changes. | 21:23 |
| lifeless | thats true | 21:23 |
| lifeless | but humans will be weirded out by something like: | 21:24 |
| abentley | We've never used them for anything except unified diff formatting. | 21:24 |
| lifeless | old/text new/text | 21:24 |
| lifeless | ... | 21:24 |
| abentley | We don't use them in the === modified message. | 21:24 |
| lifeless | base/link changed/link | 21:24 |
| lifeless | oh hmm | 21:24 |
| lifeless | well. | 21:24 |
| lifeless | Like I said, if you don't agree - and it seems like there is good reason that its not trivial to do the entire thing I suggested, its fine as is | 21:25 |
| lifeless | I still think having Diff.__init__(self, a_diff_tree): would be good | 21:25 |
| abentley | Okay. So now we let poolie decide whether it's 1.0-worthy. | 21:25 |
| lifeless | because it opens the door to doing the rest later with less of an API change | 21:25 |
| abentley | I've done that change. | 21:26 |
| lifeless | sweet | 21:26 |
| abentley | Or rather, I created a real factory. | 21:26 |
| lifeless | I'm confused. Do you have a further tweak beyond your latest mail? | 21:26 |
| abentley | So that we can still construct the Diff classes in a straightforwardway. | 21:26 |
| abentley | I have a further tweak, if we want it. | 21:27 |
| abentley | But it doesn't allow us to put DiffKindChange in the factory list, which was the reason for your suggestion. | 21:28 |
| lifeless | right | 21:28 |
| lifeless | Do you think it looks nice other than that? If so, lets do it. | 21:28 |
| abentley | Sure. | 21:28 |
| lifeless | I'll be on the phone with poolie in 1.5 hours | 21:29 |
| lifeless | I'll raise this patch to his attention if it's not already there. | 21:29 |
| lifeless | brb | 21:29 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| lifeless | luislavena: I would suggest filing a bug on bzr-gtk | 21:31 |
| luislavena | lifeless: I'm googling for something like this before, maybe I missed something, but guess not. | 21:32 |
| cbx33 | hey all | 21:34 |
| lifeless | hi | 21:35 |
| luislavena | cbx33: hi | 21:35 |
| cbx33 | hi luislavena | 21:35 |
| luislavena | lifeless: done, there is no info about this on the web, so submited a new bug report to bzr-gtk team. thank you. | 21:44 |
| abentley | fullermd: versionedfile data and the inventory data are stored along different axes. So doing the first versionedfile requires reading most inventory revisions. That data's then cached. | 21:49 |
| lifeless | abentley: my lower memory reconcile changed check too | 21:50 |
| fullermd | Well, but it seems new, though. It used to just count up through the revisions, then count up through the vf's, without the big pause there. | 21:50 |
| lifeless | abentley: so it no longer incrementally generates a inventory->text cache at all. | 21:50 |
| lifeless | fullermd: it should be faster overall | 21:50 |
| fullermd | That might do it. When the vf numbers do start counting, they seem to go a lot faster than they used to. | 21:50 |
| lifeless | fullermd: if you run check with -v you should get a list of the text versions that are not referenced | 21:51 |
| lifeless | fullermd: and we can dig into why they are not being cleaned up | 21:51 |
| fullermd | It's not the existence; it's the wildly extreme number. I don't recall doing anything special in the history of these branches; there shouldn't be that many texts ever existing, much less unreferenced. | 21:53 |
| fullermd | There were some uncommits or discarded branch revs, but those would still be ref'd, AIUI. And this is a fresh branch, so it wouldn't bring those along. | 21:55 |
| fullermd | -v doesn't output anything different. | 21:55 |
| dato | jelmer: that was fast, eh? (re joeyh's mail) | 21:55 |
| lifeless | fullermd: ok thats weird. Is this a repo I can get access to ? | 21:56 |
| fullermd | Probably not... I can make a nothing-branch that starts showing up unref'd text versions, though... | 21:58 |
| lifeless | fullermd: if its in the same repo thats why | 22:00 |
| fullermd | No, in a fresh standalone. | 22:01 |
| jelmer | dato: wow, that /is/ fast | 22:01 |
| dato | :) | 22:02 |
| fullermd | lifeless: http://paste.ubuntu-nl.org/45848/ | 22:02 |
| fullermd | lifeless: It seems to need the second file; just stuffing text in foo and committing more revs doesn't make it show up. | 22:04 |
| lifeless | dato: what happened ? | 22:04 |
| lifeless | fullermd: blarh. please file a bug | 22:06 |
| lifeless | fullermd: (I reproduced it, just need a note to track it) | 22:12 |
| * fullermd nods. | 22:12 | |
| fullermd | Probably a check bug, and not that we're actually making extra texts? | 22:12 |
| dato | lifeless: he was already added to the debian-maintainers keyring | 22:14 |
| fullermd | Filed. | 22:14 |
| lifeless | dato: rofl | 22:19 |
| ubotu | New bug: #165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071 | 22:21 |
| jelmer | hmm, the quick reference doesn't contain any info about " | 22:31 |
| jelmer | bzr send" | 22:31 |
| jelmer | I wonder whether that should be considered a bug? | 22:31 |
| lifeless | jelmer: yes | 23:05 |
| sdh | can anybody tell me a good resource to learn how to use bzr in a mixed-type environment | 23:09 |
| sdh | so i have a central repos, and can branch onto my laptop, say, commit there, then commit all back later? | 23:09 |
| sdh | e.g. when on plane | 23:09 |
| sdh | probably not explaining well :) | 23:10 |
| lifeless | sdh: the tutorial probably is enough | 23:10 |
| sdh | lifeless: just realiesd that wasn't one of the docs i read, heh. thanks. :> | 23:11 |
| lifeless | :) | 23:12 |
| lifeless | please do ask for more details and hints once you've given it a shot | 23:12 |
| sdh | thanks... i did read lots... of blog posts ;) | 23:12 |
| sdh | so far today i've tried git, hg and now bzr... bzr "feels" good so far :) | 23:13 |
| lifeless | excellent | 23:13 |
| sdh | i watched a video of linus talking about git at google and learnt two things | 23:14 |
| sdh | 1) git is supposedly fast | 23:14 |
| sdh | 2) linus is even more arrogant than i thought | 23:14 |
| sdh | :) | 23:14 |
| fullermd | Pfft. Obviously, you are Ugly And Stupid :p | 23:15 |
| sdh | haha, that's the one ;) | 23:15 |
| ubotu | New bug: #165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Undecided,New] https://launchpad.net/bugs/165080 | 23:21 |
| sdh | is there a way to push to the parent branch without specifying it explicityly? | 23:44 |
| sdh | explicitly, even | 23:44 |
| abentley | sdh: just "bzr push". | 23:50 |
| abentley | That will push to the remembered branch. | 23:50 |
| mathrick | hiya | 23:50 |
| abentley | Which is actually a different location. | 23:50 |
| abentley | But you don't have to specify it explicitly each time. | 23:51 |
| mathrick | what is the right foo to get a working tree in a treeless branch? | 23:51 |
| sdh | it didn't work for me, i got: | 23:51 |
| abentley | mathrick: bzr checkout . | 23:51 |
| sdh | oh it works after the first push :) | 23:51 |
| abentley | sdh: right. | 23:51 |
| sdh | thanks | 23:51 |
| abentley | sdh: np | 23:52 |
| abentley | mathrick: or on recent Bazaars, "bzr reconfigure --tree". | 23:52 |
| mathrick | oh, already checkouted :) | 23:52 |
| mathrick | and yes, it's 0.93, so recent | 23:52 |
| fullermd | Mmp. We probably need a good section in the docs on reconfig (and that alias). I like to think I have a reasonable knowledge of bzr, but I couldn't guess what "Reconfigure to a tree" means. | 23:54 |
| mathrick | small inconsistency: bzr status takes -V, but bzr ls doesn't | 23:57 |
| mathrick | you have to use --versioned | 23:57 |
| lifeless | mathrick: yah, IIRC we put -V in for ui friendliness with svn | 23:59 |
| mathrick | it's a good alias | 23:59 |
| lifeless | please file a bug about -V for ls | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!