| mtaylor | does a tag get associated with a revid or a revno? | 00:18 |
|---|---|---|
| jelmer | mtaylor, a revid | 00:19 |
| mtaylor | ok. good | 00:19 |
| mtaylor | I just had a brief hrm | 00:19 |
| === Ursinha is now known as Ursinha-afk | ||
| === wgrant_ is now known as wgrnat | ||
| === wgrnat is now known as wgrant | ||
| poolie | hey spiv | 07:55 |
| poolie | feel free to do some more merge cleanups after your submission :) | 07:55 |
| poolie | on a brief readthrough that patch looks fine | 07:56 |
| spiv | I will :) | 07:57 |
| poolie | i'm going to keep scrubbing add | 07:59 |
| poolie | if i can stay awake :) | 07:59 |
| spiv | It's daytime in Europe, should be no problem ;) | 08:01 |
| poolie | hm | 08:03 |
| NET||abuse | hmm, pushing bzr repo's up to my web server seems to be very slow and i'm never certain it'll work | 09:19 |
| poolie | NET||abuse: over what protocol? what goes wrong? | 09:35 |
| NET||abuse | ssh | 09:36 |
| NET||abuse | it just hangs for ages | 09:36 |
| NET||abuse | it worked this time,, but i've often had it push up most of the files,, then it just hangs,, i ctrl+c out of the process after an hour,, but the files seem to have been put up | 09:37 |
| NET||abuse | i just feel worried at this piont that there's an error in my repository somewhere | 09:37 |
| NET||abuse | i run bzr check on the repo | 09:37 |
| NET||abuse | and it comes back clean | 09:37 |
| NET||abuse | it's just really weird | 09:37 |
| AfC | NET||abuse: you have full shell on the target server? If so, why not go there, bzr init-repo a new reository, bzr branch in whatever's already there (to pre-popuplate it), and then try your over the wire push again | 09:40 |
| AfC | [ {shrug} ] | 09:40 |
| NET||abuse | AfC, that's a good suggestion, i'll try that the next time i'm pushing up | 09:42 |
| NET||abuse | should be in the next 24 hours i'll be doing that again :) | 09:42 |
| NET||abuse | the repo i was pushing up was about 80MB | 09:42 |
| NET||abuse | so it wasn't too small | 09:42 |
| AfC | not too big, either | 09:42 |
| NET||abuse | yeh, but over my teathered android phone connection :) | 09:43 |
| NET||abuse | on the bus on the way to work :P | 09:43 |
| AfC | urgh | 09:43 |
| NET||abuse | hehe | 09:43 |
| AfC | Ok, well it's TCP that's burning you. | 09:43 |
| NET||abuse | :) hmmm i see | 09:43 |
| AfC | 3G UTMS is famous for dropping long duration connections at Layer 1 and/or Layer 2 (which then reestablish) but which | 09:44 |
| AfC | will result in TCP interpreting that as lost traffic (due to late or lost return ACKs) | 09:44 |
| NET||abuse | should bzr maybe have a little more in the way of timeouts and retry methods? | 09:44 |
| AfC | which will result in traffic congestion kicking in, | 09:44 |
| AfC | which will result in TCP thinking you're available bandwidth is sqrt(fuck all) | 09:44 |
| AfC | NET||abuse: it's got nothing to do with Layer 8 | 09:45 |
| NET||abuse | hmm, ok | 09:45 |
| AfC | NET||abuse: there's nothing bzr (or your web browser, or wget, or anything else) can do | 09:45 |
| NET||abuse | right fair nuff | 09:45 |
| AfC | if your network connection is lossy or "randomly" delays packets | 09:45 |
| AfC | TCP/IP, right? | 09:45 |
| NET||abuse | i'll have to push with git or other things for a while and see how that behaves.. | 09:45 |
| AfC | Should be TCP vs IP | 09:46 |
| NET||abuse | TCP vs IP? | 09:46 |
| NET||abuse | how do you mean? | 09:46 |
| AfC | Bazaar works *VERY* hard to do the right thing and is optimized for a) not losing things, b) performance over stable links | 09:46 |
| AfC | if you've got an unstable link, well, all bets are ff | 09:46 |
| NET||abuse | that's fair enough | 09:47 |
| AfC | because bzr+ssh rides over SSH which rides over TCP and TCP (by its design) cannot push large data volumes over lossy links. | 09:47 |
| AfC | and 3G modems are right back to the dark ages as far as actual link stability is concerned. | 09:48 |
| NET||abuse | i thought that it's design was good for exactly that? as opposed to udp | 09:48 |
| AfC | TCP will guarantee (mostly) delivery | 09:48 |
| AfC | of what it thinks the best average rate it can get away with is | 09:48 |
| AfC | if you're losing (say) return ACKs | 09:48 |
| NET||abuse | well the phone is the htc desire, so it's the H connection,, is that HSDPA or something else? | 09:48 |
| spiv | TCP copes very well with a very small percentage of dropped packets. | 09:48 |
| AfC | then it'll think that the available bandwidth is miniscule. | 09:48 |
| AfC | spiv: yeah | 09:50 |
| AfC | indeed, its designed to loose .... one | 09:50 |
| AfC | which is when it decides it's reached it's limit. Then it backs off one, tries again, etc | 09:50 |
| AfC | linear & sawtooth | 09:50 |
| NET||abuse | according to htc it's call HSPA/WCDMA | 09:51 |
| NET||abuse | they dropped the D? | 09:51 |
| AfC | spiv, NET||abuse: Paul Drain pointed me at a paper written by Glen Turner on this topic; you might enjoy it <http://www.gdt.id.au/~gdt/presentations/2010-07-06-questnet-tcp/glen-turner-tcp-performance-notes.pdf> | 09:52 |
| AfC | I've been doing a lot of work network tuning lately, so it was timely. | 09:53 |
| AfC | spiv: (do you know [of] Glen?) | 09:53 |
| AfC | spiv: frequent voice on linux-aus, etc | 09:53 |
| NET||abuse | that's an interesting read,, thatnks :) | 09:54 |
| NET||abuse | quick question,, obviously this is #gzr so there's a bias, but is there a set of circumstances where you'd choose git over bzr? | 09:54 |
| NET||abuse | or what task types do you use each for? | 09:55 |
| AfC | NET||abuse: no | 09:55 |
| AfC | none whatsoever | 09:55 |
| AfC | ever | 09:55 |
| AfC | [we comprehensively rejected Git ~2006, and remain pleased with that call] | 09:55 |
| AfC | but that's just my firm. Others will be more even handed in a perceived need to be even handed for some reason. :) | 09:55 |
| spiv | AfC: I've occasionally seen the name on mailing lists, but that's all I think. | 09:56 |
| AfC | spiv: he's good people | 09:56 |
| NET||abuse | ok, auto deployment,, i push a repo up to a test domain on a web server, so i can show a client or someone, i push up to a repo, it's adjacent to my webroot dir, i want to update the working copy on the remote server any changes, and then deploy to the app and webroot directory the relevant directories in the working copy | 10:12 |
| NET||abuse | so my server under /var/www/mydomain/ has a www/ dir the bzrrepo/ and i have a static copy of cakephp libraries there, and i have the app/ directory outside of the cakephp directory | 10:13 |
| NET||abuse | if i want to script a post receive push hook on the remote repo,, is there a good way to do that? | 10:13 |
| === Leonidas_ is now known as Leonidas | ||
| spiv | Write a plugin to use Branch's post_change_branch_tip hook, install it on the server. | 10:14 |
| spiv | (and use bzr+ssh to push, if you haven't already) | 10:15 |
| spiv | (Or possibly take a completely different approach and use bzr-upload on the client to just upload files rather than pushing branches?) | 10:15 |
| NET||abuse | spiv, yeh, i use bzr+ssh already :) | 10:16 |
| soren | Tags are not part of the revision data, are they? They're kept as a separate index somewhere, right? | 10:22 |
| soren | So if I merge a branch that has some extra tags in it... Do I get those tags, too? | 10:23 |
| poolie | soren: yes | 10:25 |
| maxb | Tags are pretty much a dictionary of name->revid that is kept in a *branch* (not a repo) | 10:27 |
| soren | poolie: Ok. Are there other things that do not show in "bzr diff" that I might be getting when merging a branch? | 10:27 |
| maxb | I am unsure, but signatures, perhaps? | 10:28 |
| soren | maxb: I'm not sure I understand the difference between a branch and a repo. | 10:28 |
| soren | In fact, I'm sure I don't understand :) | 10:28 |
| maxb | A repository is a store for revisions. Nothing more, nothing less. | 10:28 |
| maxb | A branch is a pointer to a specific revision id (the tip of the branch), plus tags | 10:29 |
| soren | I see, ok. | 10:29 |
| maxb | signatures go... somewhere. I'm not sure. I don't use them | 10:29 |
| soren | The reason I'm asking is that we (OpenStack) have a trunk that is handled by Tarmac. Someone submitted a branch with some extra tags in it, intending for those tags to be in the trunk, too. After the merge, the tags are not there. | 10:30 |
| maxb | soren: that's a little odd. I would *expect* a bzr merge to copy all (non-conflicting) tags | 10:30 |
| soren | ...and I'm trying to work out if that expectation was reasonable at all, and if so, what the problem might be. | 10:30 |
| maxb | However, if tarmac runs bzrlib functions, not the bzr command line, it's possible it fails to also run the stuff that merges tags | 10:31 |
| soren | maxb: https://code.edge.launchpad.net/~mordred/nova/release-0.9.0/+merge/31168 | 10:31 |
| soren | maxb: Tarmac does call bzrlib functions, afaics. | 10:31 |
| soren | maxb: Branching the proposed branch reveals the tags. | 10:32 |
| soren | maxb: Branching the trunk (which has the proposed branch merged into it now) shows no tags at all. | 10:32 |
| spiv | soren: it is a reasonable expectation, and suggests a bug in Tarmac (or the bzrlib API it is relying on) | 10:32 |
| maxb | It sounds to me like the first thing to do is to investigate whether tarmac *ever* merges tags | 10:32 |
| maxb | It is soundling like it does not | 10:32 |
| spiv | I think PQM had (has?) a similar issue. | 10:32 |
| soren | spiv: I checked the bzr trunk, and it definitely has tags in it. | 10:33 |
| soren | spiv: IIUIC, they cannot have gotten there by any other means than PQM? | 10:33 |
| === Leonidas_ is now known as Leonidas | ||
| spiv | Assuming PQM is the only way that branch was ever written too... | 10:33 |
| soren | Right. | 10:34 |
| spiv | s/too/to/ | 10:34 |
| soren | Well, there are recent tags, even. I imagine cowboying pathes onto the trunk would have been a thing of the distant past by now. | 10:34 |
| soren | builtins.py:cmd_merge does seem to take special care to merge the tags. | 10:38 |
| soren | Yet tarmac seems to just call tree.merge_from_branch(...). | 10:39 |
| soren | *headdesk* | 10:40 |
| soren | mtaylor already reported that bug. | 10:40 |
| soren | ...and rockstar apparantly fixed it. | 10:40 |
| * soren is always a step behind :) | 10:40 | |
| bialix | hello bzr! | 12:40 |
| jelmer | Hi bialix! | 12:41 |
| jelmer | Haven't seen you in a while, how have you been? | 12:41 |
| bialix | Heya jelmer! recently has returned from vacation | 12:42 |
| * bialix just finished to read mails | 12:43 | |
| === Ursinha-afk is now known as Ursinha | ||
| GaryvdM | Hi bialix! | 14:05 |
| === gnomefreak76 is now known as gnomefreak | ||
| mgz | anyone know what Jonathan Lange's irc nick is? | 14:25 |
| GaryvdM | mgz: jml | 14:26 |
| jml | hello mgz | 14:26 |
| mgz | thanks! saves me bouncing on things via email. | 14:26 |
| bialix | Heya GaryvdM, mgz~ | 14:26 |
| bialix | Heya GaryvdM, mgz! | 14:26 |
| mgz | jml: there are a few things that need shaking out still with the testtools unicode traceback stuff | 14:27 |
| jml | mgz, more than just trivial_last_time_for_this_line? | 14:27 |
| mgz | I've got one more brown paper bag thing to fix, and you variable name error you spotted is because that's currently dead code, until I turn the shelve I have for bug 592262 into a mp | 14:29 |
| ubot5 | Launchpad bug 592262 in testtools "testtools breaks if a string exception is raised (affected: 1, heat: 3)" [Wishlist,Incomplete] https://launchpad.net/bugs/592262 | 14:29 |
| mgz | bialix: did you have a nice holiday? | 14:29 |
| jml | mgz, hmm. | 14:29 |
| mgz | basically, it just needed a bit of real-world testing, as there are still codepaths the unittests don't cover | 14:30 |
| jml | mgz, well, that's not entirely true | 14:30 |
| jml | mgz, I mean, the test suite hasn't actually passed in some time. | 14:31 |
| mgz | hm? passes here on all the python implementations I've got. | 14:31 |
| mgz | we managed to screw up the one line in _details_to_str like, five times without the tests catching it. | 14:32 |
| jml | mgz, testtools revisions 74 through 80 don't pass for me on lucid. | 14:32 |
| jml | mgz, at least, not when run with make check. | 14:32 |
| jml | python2.6, standard build | 14:32 |
| jml | mgz, perhaps there's a locale config issue masking the problem on your machine (or causing the problem on mine, for that matter)? | 14:33 |
| mgz | hm, maybe that's just me being lame then. | 14:33 |
| jml | mgz, well, it's actually me being lame for not having some kind of automated gateway that tests things before landing them on trunk. | 14:35 |
| mgz | okay, so you're right, the tests *did* catch that one-line error (repeatedly) | 14:37 |
| jml | they catch it by completely exploding :) | 14:37 |
| mgz | anyway, I'll get a test and fix up for the remaining dumb error I left behind, then check what remaining shelves need acting on sooner rather than later | 14:38 |
| jml | mgz, can you please file critical bugs for all of these? | 14:38 |
| jml | mgz, once all this is done I want to make a release asap | 14:38 |
| mgz | well, most of this is just minor improvements as marked by # GZ ... comments in the current source | 14:38 |
| mgz | I'll file a bug for the current one | 14:39 |
| jml | (race against the clock: can we do this before pypi comes back up?) | 14:39 |
| mgz | (which is what's needed before release) | 14:39 |
| jml | ok thanks. | 14:39 |
| === Ursinha is now known as Ursinha-afk | ||
| bialix | mgz: yeah, good holiday, warm sea and beautiful mountains (in Crimea). but too short :-( | 14:43 |
| === Ursinha-afk is now known as Ursinha | ||
| mgz | okay, nearly there | 14:57 |
| mgz | jml: mp up. | 15:10 |
| jml | mgz, ta. | 15:10 |
| mgz | now I need some coffee... | 15:10 |
| GaryvdM | \o/ New qlog feature: http://imagebin.org/107278 | 15:19 |
| hazmat | if i do an update my working copy to a previous revision, how do i tell what revision my working copy is in? bzr stat just reports 'working copy out of date', bzr revno, just shows the latest rev in the repo... is there any way to identify the revision of the working copy? | 15:19 |
| GaryvdM | hazmat: use update, and not revert | 15:20 |
| bialix | GaryvdM: WOW \o/ | 15:20 |
| hazmat | GaryvdM, i'm basically bisecting to find a bug being introduced.. i've bzr update -r REVNO to get to a particular revision in my working copy.. but once i do that, its not clear how i can find out what the REVNO of the working copy is from the bzr tools | 15:21 |
| GaryvdM | hazmat: Hmm, not sure how to see it from the command line. You can see it in bzr qlog | 15:22 |
| * GaryvdM off to hockey practice. bbl | 15:23 | |
| hazmat | GaryvdM, cheers.. sadly qlog tosses me an exception traceback , looks like a pyqt version mismatch on lucid | 15:23 |
| hazmat | GaryvdM, fwiw traceback at http://pastebin.com/S2eNEg4r | 15:25 |
| bialix | hazmat: you have out-of-date qbzr version | 15:26 |
| bialix | hazmat: /home/kapil/.bazaar/plugins/qbzr [0.17.0dev] | 15:26 |
| bialix | hazmat: please, update to latest 0.18.6 | 15:26 |
| hazmat | bialix, thanks | 15:27 |
| hazmat | cool, so qlog does show the current revno for the working tree.. would be nice to figure out how to do this from the cli as well though | 15:27 |
| bialix | I think there is open bug about that | 15:32 |
| jam | hazmat: bzr revno --tree IIRC | 15:32 |
| bialix | heya jam | 15:35 |
| jam | hi bialix | 15:35 |
| jam | looking good GaryvdM | 15:35 |
| jam | now you just need a way to select a range and do the same thing :) | 15:35 |
| bialix | yep :-) | 15:38 |
| bialix | ~~~ | 16:00 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| mtaylor | anybody around who can help us out a bit with tags and tarmac? | 17:16 |
| mtaylor | I've got a trunk branch protected by tarmac, which is using lightweight checkouts of the trunk | 17:17 |
| mtaylor | then, I make a tag in a branch, propose it for merge, and tarmac merges it in | 17:17 |
| mtaylor | problem is- no taggy in trunk | 17:17 |
| mtaylor | lifeless had told rockstar a while back to change from heavy to lightweight checkouts and that everything should be fine - but perhaps we're still missing something? | 17:18 |
| rockstar | jam, maybe you can help? ^^ | 17:18 |
| jam | rockstar: how are you doing the merge in tarmac? | 17:19 |
| rockstar | jam, I create a lightweight checkout of the target branch, merge the source branch in, and then commit. | 17:20 |
| jam | rockstar: 'merge the source branch in' using bzrlib ? or using bzr? | 17:20 |
| rockstar | jam, bzrlib. | 17:20 |
| rockstar | jam, lemme find the code. | 17:20 |
| jam | rockstar: looking at cmd_merge, I see: | 17:21 |
| jam | from bzrlib.tag import _merge_tags_if_possible | 17:21 |
| jam | ... | 17:21 |
| jam | _merge_tags_if_possible(other_branch, tree.branch) | 17:21 |
| jam | So I think you have to do something like that in your code. As 'branch.merge(other_branch)' doesn't merge tags, only fs contents | 17:21 |
| jam | anyway, I'm off to lunch, etc. I'll be back later | 17:22 |
| rockstar | jam, great, thanks. | 17:23 |
| === Ursinha is now known as Ursinha-lunch | ||
| jam | rockstar: you should probably only do that after the test suite passes | 17:31 |
| jam | otherwise the target branch will get tags even if it doesn't actually merge the code | 17:31 |
| jam | (one of the clumsy parts about our tagging scheme) | 17:32 |
| rockstar | jam, so, I'm working with a tree, and I think that may cause complications. | 17:34 |
| === deryck is now known as deryck[lunch] | ||
| jml | mgz, you still around? | 18:10 |
| === Ursinha-lunch is now known as Ursinha | ||
| mgz | jml: I am again now. | 18:59 |
| jml | mgz, I've landed the MP you put up | 18:59 |
| jml | mgz, we still need one for the sclass thing, iirc. | 18:59 |
| jml | mgz, do you already have a patch w/ tests for that? | 19:00 |
| mgz | right, question on that front, you've got no moral objection to handling string exception on Python 2.4 and 2.5 right? | 19:00 |
| jml | mgz, not at all. | 19:01 |
| mgz | ^I've got a disabled test for the main part, just need to fiddle with RunTest._run_user | 19:01 |
| jml | mgz, cool. if ping me when that's up, I'll review & merge straight away | 19:02 |
| mgz | my current shelve for that it probably over-ambitious, it falls down on Python 3 because traceback._some_str is still pretty basic there | 19:02 |
| mgz | I'll pull it down to the essentials and put up a mp. | 19:02 |
| jml | mgz, other than that, are there any other known issues with the Python 3 compat? | 19:02 |
| jml | mgz, cheers. | 19:02 |
| mgz | nothing else known, want to check that what was causing problems on babune on 2.7 is now resolved, but even if it isn't may well be a bzr or subuit bug, not something I've broken in testtools | 19:04 |
| === deryck[lunch] is now known as deryck | ||
| mgz | jml: mp up, and I'm just going to grab some food, but will be generally around all evening | 19:28 |
| jml | mgz, cool. thanks. | 19:29 |
| tbnorth | hi all - what's the status of nested branches? Googling leaves me feeling support is incomplete / not in trunk, but I'm unsure? | 19:41 |
| cody-somerville | why does switch require a working tree? | 19:56 |
| rockstar | cody-somerville, why would you switch without a working tree? | 20:01 |
| cody-somerville | basically I have a cache of branches | 20:02 |
| maxb | Because without a working tree involved, a switch would be degenerate with a pull? | 20:02 |
| cody-somerville | and I want to be able to take a branch in the cache and make it a 'clone' of some arbitrary branch | 20:02 |
| maxb | pull --overwrite? | 20:03 |
| cody-somerville | the branches are all checkouts currently | 20:03 |
| rockstar | cody-somerville, wait, if you have a checkout, you have a working tree. | 20:05 |
| cody-somerville | yes I do | 20:06 |
| cody-somerville | was trying to with no working tree to see if that would avoid the conflicts and weird file moves | 20:06 |
| cody-somerville | I can get it to work with a 'working tree' but it says every file has been moved to the same place it was before | 20:07 |
| cody-somerville | ex. | 20:08 |
| cody-somerville | renamed: | 20:08 |
| cody-somerville | project => project | 20:08 |
| cody-somerville | sources-list/ => sources-list/ | 20:08 |
| maxb | I'm guessing that indicates the tree root file-id has changed | 20:09 |
| cody-somerville | yea, I'm switching between two completely different branches | 20:09 |
| maxb | I would guess that it's a bug that bzr doesn't switch the tree root, but rather switches everything under it | 20:10 |
| cody-somerville | Is there a difference between a checkout and a bound branch? | 20:27 |
| fullermd | Absolutely. Also: absolutely not. | 20:29 |
| maxb | hah | 20:30 |
| maxb | Well, a checkout must have a working tree involved, whereas the terminology "bound branch" doesn't specify whether there's a tree or not | 20:31 |
| mgz | jml: have you done the 0.9.5 testtools release yet? I don't see a version number bump in the log. | 20:31 |
| jml | mgz, uhh, which log are you looking at? | 20:32 |
| cody-somerville | maxb, how does it distinguish a bound branch with a working tree from a checkout? | 20:32 |
| jml | mgz, the answer is yes | 20:32 |
| maxb | I would say a bound branch with a working tree is identical to a heavyweight checkout | 20:32 |
| mgz | er, just on my branch which launchpad tells me is up to date | 20:32 |
| fullermd | A very long semantic discussion, in the end. | 20:33 |
| jml | mgz, what url? | 20:33 |
| cody-somerville | maxb, 'bzr info' seems to know the difference. I want to know how it figures it out. | 20:33 |
| mgz | ah, trunk. did you create a new one for the release and change the version there? | 20:33 |
| * mgz downloads the ta | 20:34 | |
| fullermd | It doesn't, because there isn't a difference. Sorta. It just gives particular names to particular conglomerations. | 20:34 |
| mgz | r | 20:34 |
| mgz | wait, now I'm really confused, launchpad tells me the 0.9.5 tar is 20 hours old. | 20:34 |
| mgz | ...it does have the right __version__ there though, so I shall stop worrying. | 20:35 |
| cody-somerville | hmmm... on a checkout, bzr update is about 3 seconds faster then bzr pull --overwrite -- I wonder why. | 21:08 |
| fullermd | Noise, I expect. It's all the same work. | 21:08 |
| lifeless | pull overwrite is likely doing a full history traverse | 21:08 |
| cody-somerville | creating a new branch from scratch takes the same amount of time | 21:08 |
| cody-somerville | or at least on this branch... Is it possible I'd see better performance with bzr pull --overwrite vs. bzr branch on bigger / more active branches? | 21:11 |
| lifeless | in principle yes | 21:13 |
| lifeless | it may nto be tuned to the limit | 21:13 |
| cody-somerville | lifeless, Basically I have a cache of branches containing config for each project. The URL to the config branch for a project could possibly change so I want to be able to update the cached branch to be a clone of the branch specified regardless if its the branch its already binded to or not. unbinding and then doing a bzr pull --overwrite seems to be the only way I can do this reliably but because it appears to takes the same amount o | 21:18 |
| cody-somerville | f time as it does to create a new branch from scratch it sort of defeats the purpose. Do you have any insight to a better solution? | 21:18 |
| lifeless | how long are you talking? 3-4 seconds ? | 21:20 |
| cody-somerville | lifeless, for the branches I've been testing with, 3-5 seconds yes | 21:20 |
| lifeless | sounds ok as it is | 21:21 |
| lifeless | though you don't need to unbind and pull overwrite | 21:21 |
| lifeless | you can just call bzr switch | 21:22 |
| cody-somerville | bzr switch has a bug I think | 21:22 |
| lifeless | or not be bound at all and use pull - if you want a mirror thats the usual idiom | 21:22 |
| cody-somerville | '<maxb> I would guess that it's a bug that bzr doesn't switch the tree root, but rather switches everything under it' | 21:22 |
| lifeless | that would suprise me a lot | 21:23 |
| lifeless | however, if its breaking - file a bug - - really | 21:23 |
| jam | cody-somerville: interesting. Though doing "bzr bind $NEW_URL; bzr pull --overwrite $NEW_URL" should be equivalent to "bzr switch" if you just want a workaround. | 21:35 |
| cody-somerville | its not. I looked at the source code. | 21:36 |
| jam | cody-somerville: as for tree-root id changing. we can't rename the root directory, so everything just appears as renamed into a new directory, which is at the same location | 21:36 |
| jam | if you do | 21:36 |
| jam | bzr mv directory other dir | 21:36 |
| jam | bzr mkdir directory | 21:36 |
| jam | bzr mv other_dir/* directory | 21:36 |
| jam | you should end up with similar behavior | 21:36 |
| cody-somerville | its equiv to bzr unbind; bzr pull --overwrite $NEW_URL; bzr bind $NEW_URL | 21:36 |
| jam | bzr st will show everything as renamed into the same dir | 21:36 |
| jam | cody-somerville: I'm pretty sure you can just do the bind $NEW without unbind | 21:37 |
| GaryvdM | jam: You can select a range and do a cherry pick, or reverse cherry pick. | 21:47 |
| jam | GaryvdM: \o/ | 21:47 |
| jam | very nice | 21:47 |
| GaryvdM | jam: The other options (tag, revert, and update) are only available if one revision is selected. | 21:48 |
| michaelh1 | Morning. Is there a way of retroactively marking a revision as fixing a bug? | 23:44 |
| jelmer | michaelh1: Not yet. | 23:48 |
| michaelh1 | jelmer: ta. I'm planning to use tickets to track the upstream patch state but I need to fix up past revisions | 23:49 |
| michaelh1 | jelmer: an entry in the ticket log will do it | 23:49 |
| lifeless | michaelh1: then surely you can just write that up :) | 23:50 |
| michaelh1 | lifeless: write what up? | 23:51 |
| lifeless | go to their ticket tracker | 23:51 |
| lifeless | and put a comment in saying 'fixed in rev abc' | 23:51 |
| michaelh1 | lifeless: Yip, plan to. Something like fixed-in: revno | 23:51 |
| michaelh1 | has to be machine readable | 23:51 |
| lifeless | if you want machine processing consider using the revid ( a UUID) or branch + revno | 23:52 |
| michaelh1 | related question: what's a nice short name to a revision on a branch, say rev 93543 on lp:gcc-linaro/4.4 ? | 23:52 |
| lifeless | lp:gcc-linaro/4.4,revno=93543 is planned but we haven't finished hooking up all the bits | 23:53 |
| lifeless | the -r parameter to many commands will accept lp:gcc-linaro/4.4:93543 | 23:53 |
| lifeless | but it has the context to know its doing a revision lookup already | 23:53 |
| michaelh1 | Which format should I use for my fixed-by comment? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!