| poolie | spiv, hello | 00:01 |
|---|---|---|
| poolie | spiv, lifeless, igc, jam, call in a sec | 00:01 |
| jelmer | 'morning spiv, poolie | 00:05 |
| jelmer | how should I figure out what the parent revisions of an existing file text revision are? | 00:05 |
| jelmer | CommitBuilder.record_entry_contents() doesn't take any text_parents arguments | 00:06 |
| jelmer | lifeless: ^ | 00:14 |
| jml | abentley: how come I have to do 'bzr up' rather than 'bzr co' in the branches that export-loom makes? | 00:21 |
| lifeless | jelmer: it assigns the value itself | 00:22 |
| jelmer | lifeless: what if the text wasn't changed but inherited | 00:23 |
| jelmer | ? | 00:23 |
| lifeless | it may or may not assign a new one based on the per file graph | 00:23 |
| poolie | hello jelmer, lifeless | 00:23 |
| poolie | spiv, oh well that was probably a good place to wrap up | 00:24 |
| lifeless | what's the goal here, reimplementing this, or using it ? | 00:24 |
| * jml waves | 00:24 | |
| poolie | good luck | 00:24 |
| spiv | poolie: :) | 00:24 |
| jelmer | lifeless: but there's no way for CommitBuilder to figure out what the parents of a text are when recording an existing text | 00:24 |
| lifeless | jelmer: it has the parent trees as state | 00:24 |
| lifeless | jelmer: read the code :P | 00:24 |
| jelmer | lifeless, The parents of the text I mean | 00:24 |
| jelmer | lifeless: If you commit a merge for example and the merged revision is a ghost | 00:24 |
| jelmer | lifeless, and one of the texts wasn't changed | 00:25 |
| lifeless | then it cannot calculate it correctly because the ghost data is absent | 00:25 |
| jelmer | lifeless, is there no way to determine what the parents of the text are? | 00:25 |
| lifeless | so it calculates it based on the available data | 00:25 |
| lifeless | jelmer: you keep repeating this, but I'm really not understanding if you are asking a question, making an assertion, or seeking help solving a problem | 00:25 |
| jelmer | all three | 00:25 |
| lifeless | the statment doesn't make sense to me | 00:25 |
| lifeless | perhaps you could unpack whats going on so I'm not guessing at quite so much at once | 00:26 |
| jelmer | So, let me start by explaining the issue I'm trying to solve | 00:26 |
| jelmer | bzr-svn needs to make sure that the parents recorded for a text revision are correct | 00:27 |
| jelmer | generally, it will induce the parents for a specific text from the information in svn | 00:27 |
| jelmer | if that doesn't help, it'll look a specific svn property | 00:28 |
| jelmer | lifeless, Never mind, I just answered my own question | 00:34 |
| lifeless | :P | 00:34 |
| lifeless | jelmer: so commit builder has enough state to look in each inventory that is available to determine the files presence, and last-changed, in that inventory | 00:34 |
| lifeless | jelmer: doing a commit with ghosts should never happen except for an importer from tla | 00:35 |
| lifeless | ghosting is something that happens deliberately, after revisions are created, not adhoc | 00:35 |
| jelmer | lifeless: The thing is, bzr-svn uses the commit code also when pushing | 00:35 |
| lifeless | jelmer: when pushing, there should be no ghosts though | 00:35 |
| jelmer | lifeless: There can be - when pushing into svn you're not necessarily pushing merged revisions as well | 00:35 |
| lifeless | also, there is a hole in our ghost support infrastructure; a last-changed value in an inventory which is the value of a ghost will cause checkout/export to fail | 00:36 |
| jelmer | yes, several people have hit that using bzr-svn | 00:36 |
| lifeless | yah | 00:36 |
| lifeless | back shortly, food calls | 00:37 |
| lifeless | spiv: please let me know if my branch hook patch was sufficient unto the tests | 00:37 |
| spiv | lifeless: I'll take a look now | 00:38 |
| jelmer | lifeless: thanks for playing soundboard (hope that's a correct translation) | 00:38 |
| lifeless | jelmer: sounding board is probably more common, but soundboard is totally understandable :P | 00:41 |
| spiv | lifeless: looks ok to me. I can't think of any other worthwhile unit tests to add. | 00:42 |
| lifeless | spiv: well, its approved once trunk unfreezes | 00:43 |
| lifeless | spiv: I was more meaning 'does it do what you need' | 00:43 |
| spiv | lifeless: Oh I see. Yes, I think so. | 00:49 |
| lifeless | right, its now yours, enjoy. | 01:02 |
| * LaserJock crosses his fingers | 01:03 | |
| LaserJock | darn | 01:03 |
| LaserJock | lifeless: james_w set me up with a little hacky script to import both debian and ubuntu source packages | 01:03 |
| LaserJock | I got one to work fine | 01:04 |
| LaserJock | but 2 have died | 01:04 |
| mwhudson | ah, hi LaserJock | 01:04 |
| LaserJock | hi mwhudson | 01:05 |
| mwhudson | LaserJock: i didn't do anything about the matplotlib vs python2.4-matplotlib thing | 01:05 |
| LaserJock | oh? | 01:05 |
| mwhudson | LaserJock: i just confused about what the right thing would be | 01:05 |
| lifeless | LaserJock: oh, shame. | 01:05 |
| mwhudson | oh, wrong channel | 01:06 |
| mwhudson | except you're not in #launchpad :) | 01:06 |
| LaserJock | mwhudson: I'll join #launchpad | 01:06 |
| LaserJock | lifeless: well, it would be fun if it just worked without any problems | 01:09 |
| LaserJock | lifeless: but it looks like I might be able to help debug bzr-builddeb | 01:09 |
| LaserJock | so that's good anyway :-) | 01:09 |
| lifeless | LaserJock: cool | 01:13 |
| * markh cheers lifeless on his review-athon :) | 01:14 | |
| jelmer | oops | 01:17 |
| jelmer | 95 % of the memory usage of bzr-svn appears to be in reading ~/.subversion/config | 01:17 |
| RAOF | jelmer: That's with respect to the crazy "eat 1GB of ram on multi-pull" bug? | 01:19 |
| jelmer | RAOF: Yep | 01:19 |
| spiv | jelmer: whee! | 01:20 |
| * RAOF wonders how one can blow 1gb resident on reading a config file :) | 01:20 | |
| jelmer | it's parsing ~/.subversion/ for reading every file multi-pull tries to open | 01:20 |
| jelmer | and multi-pull tries to open a lot of files | 01:20 |
| RAOF | Aaah. And no GC gets done? | 01:20 |
| jelmer | RAOF, Nope | 01:24 |
| jelmer | RAOF, Ok, that fixes it.. | 01:25 |
| markh | lifeless: in the abspath mail you said to add a test that "sets sys.platform to something windows" - can you please elaborate? | 01:26 |
| markh | did you mean *checks*? | 01:26 |
| LaserJock | anybody got an idea of what http://paste.ubuntu.com/44717/ means? | 01:27 |
| LaserJock | it looks like it's trying to make a path with non-ASCII characters | 01:27 |
| markh | LaserJock: or possibly even any parent being non-ascii | 01:28 |
| LaserJock | is that anywhere in the bzr branch? | 01:29 |
| LaserJock | or does that just apply to the root directory of the branch | 01:29 |
| lifeless | markh: no, I mean sets | 01:30 |
| lifeless | markh: you have conditional code based on the platform right? | 01:30 |
| markh | so set sys.platform for the benefit of other platforms to be able to test it? | 01:31 |
| poolie | yay bubba :) | 01:31 |
| lifeless | markh: set sys.platform so that other platforms test that case, yes. | 01:31 |
| markh | heh - I'd figured that might be a dangerous thing to do, but OK... | 01:31 |
| lifeless | markh: look for sys.platform in the osutils tests | 01:32 |
| markh | will do, thx | 01:32 |
| lifeless | probably can be cleaner than that is, but its an example | 01:32 |
| * markh goes to wait in line for an hour at the chinese embassy... | 01:33 | |
| lifeless | markh: off to china? | 01:34 |
| markh | yeah - brother getting married there next month! | 01:34 |
| markh | I was actually visiting him there earlier this year - quite amazing - but you really need someone who speaks the language close by :) | 01:35 |
| markh | (which he does) | 01:35 |
| jml | markh: does he *read* the language? | 01:43 |
| === Spaz is now known as Kittens | ||
| lifeless | markh: when you get back, I have a branch I'd appreciate your testing | 02:48 |
| Verterok | a7p: still around? | 02:51 |
| a7p | jep | 02:55 |
| a7p | but I won't last more than another 30 minutes | 02:55 |
| Verterok | ok | 02:55 |
| Verterok | I'll make it short enough :) | 02:56 |
| Verterok | a7p: I can't reproduce the crash, also I don't see any related error in the log | 02:56 |
| Verterok | a7p: could you check ~/Library/logs/Java? | 02:56 |
| * a7p starts up a terminal | 02:56 | |
| Verterok | if the jvm crashed, there should be a log there | 02:57 |
| a7p | jep, got a couple of eclipse-crashfiles here | 02:58 |
| a7p | should I attach one to the bug? | 02:59 |
| Verterok | a7p: please :) | 02:59 |
| a7p | Verterok: done | 03:01 |
| Verterok | thanks! I'll keep digging | 03:02 |
| * a7p keeps supplying useless treasuremaps | 03:04 | |
| Verterok | a7p: not so useless :) | 03:11 |
| a7p | ;) | 03:12 |
| Verterok | a7p: it seems like a bug was fixed in Eclipse 3.3 | 03:12 |
| a7p | would be pritty bad, if they only introduced new ones... *g* | 03:13 |
| Verterok | a7p: http://lists.apple.com/archives/Java-dev/2007/Nov/msg00014.html | 03:13 |
| Verterok | a7p: sorry, "it seems that a similar bug was fixed in 3.3" | 03:15 |
| a7p | looks, pretty much like my problem. | 03:16 |
| Verterok | a7p: the widget used in the commit dialog will be replaced, pretty soon. it's a work in progress | 03:20 |
| a7p | wounderful, nice to hear | 03:21 |
| a7p | if i understood correctly, this is a osx 10.5 issue - other platforms won't suffer from it. | 03:21 |
| Verterok | I'll try to rollout a new build as soon as possible | 03:22 |
| * a7p looks happily forward to it - Thanks Verterok, that's Bugreporting the way I like it. | 03:27 | |
| a7p | and now I'm going to put my tired head to rest | 03:27 |
| lifeless | fooding | 03:29 |
| Peng_ | I should just try this myself, but what does Bazaar do if, when using HTTP, a /.bzr/ directory redirects somewhere else? | 04:14 |
| * Peng_ tries it himself. | 04:14 | |
| lifeless | spiv: http://marc.info/?l=linux-netdev&m=122091500114869&w=2 | 04:19 |
| lifeless | spiv: details on why coalescing the bytes written to the socket helped | 04:21 |
| Peng_ | Oh, good, it works. | 04:23 |
| spiv | lifeless: that's a nice clear description of things | 04:24 |
| spiv | lifeless: It's a pity I learned that stuff the hard way rather than by reading about it :) | 04:25 |
| lakin | Is there a pdf version of the html guide? | 04:25 |
| lakin | http://doc.bazaar-vcs.org/latest/en/user-guide/index.html | 04:25 |
| lakin | ? | 04:25 |
| lifeless | Peng_: you can redirect a branch, redirecting a repository is likely to die horribly | 04:27 |
| markh | jml: apparently well enough to read signs and stumble through things, but not well enough to comfortably read a newspaper for example | 04:28 |
| markh | lifeless: how can I help? | 04:28 |
| lifeless | markh: test my patch | 04:28 |
| markh | which one? :) | 04:28 |
| lifeless | the one I cc'd to you | 04:28 |
| lifeless | that prominently asks for help :P | 04:28 |
| markh | _walkdirs | 04:28 |
| markh | oh :) | 04:28 |
| jml | markh: when I visited, I found the inability to read the language much more frustrating than being unable to speak it. | 04:29 |
| markh | jml: I doubt we would have survived ordering in some of the places we ate at, for example. We would have ended up having a much more "westerners" experience I think | 04:30 |
| markh | I remember once thinking "surely I can order a coffee" - and failed misterably :) | 04:31 |
| markh | the "coffee" part was understood, but trying to explain I wanted it to take away was a sticking point :) | 04:32 |
| lifeless | just get it, then walk out the door | 04:32 |
| markh | yeah, and just keep walking :) | 04:33 |
| lifeless | well no, stop and let them change it around now they get the message :P | 04:33 |
| Peng_ | lifeless: Well, I'm redirecting both the branch and repo (from /foo/... to /bar/...). Hopefully it'll be okay. | 04:37 |
| Peng_ | lifeless: BTW, this is very trivial, but I think bzr-search's cmd_index wastes a transport. It opens one, and then passes the URL to index_url, which opens it again. | 04:39 |
| lifeless | Peng_: patches appreciated :P | 04:39 |
| Peng_ | lifeless: Heh. But what should I change it to do? Make index_url accept a transport? Rename index_url to index_transport or something? | 04:41 |
| === ajaksu is now known as ajaksu_away | ||
| lifeless | Peng_: I think there is a transport taking helper already | 04:46 |
| lifeless | Peng_: if there isn't, split the current one in two, and call the helper | 04:47 |
| markh | lifeless: is there a subset of the tests I can specify? Otherwise things get lost in the noise... | 04:54 |
| lifeless | ./bzr selftest --no-plugins osutils win32 walkdirs | 04:54 |
| markh | File "O:\src\bazaar\bzr\bzr.lifeless\bzrlib\tests\branch_implementations\test_parent.py", line 95, in test_win32_set_parent_on_another_drive | 04:55 |
| markh | base_url = b.abspath('.') | 04:55 |
| markh | AttributeError: 'BzrBranch6' object has no attribute 'abspath' | 04:55 |
| markh | x7 times | 04:56 |
| lifeless | heh | 04:56 |
| lifeless | well thats unrelated :P | 04:56 |
| uniscript | anyone know a way of using bzr on an svn project, but with local storage but not the whole history? | 04:59 |
| markh | lifeless: they are the only errors | 04:59 |
| Peng_ | Hmm, I think it winds up opening the branch twice too. | 05:00 |
| lifeless | markh: cool | 05:01 |
| lifeless | markh: care to review it ? :) | 05:01 |
| markh | having a quick look now | 05:01 |
| lifeless | uniscript: branch --stacked | 05:01 |
| uniscript | but the docs say that that's just a light checkout or am I reading it wrong? | 05:02 |
| uniscript | i.e. can I branch, ci merge etc. with such a branch locally with no access to the svn repo? | 05:02 |
| uniscript | and then just push / merge upstream later? | 05:03 |
| markh | hrmph - I'm not testing much as I haven't run a build | 05:05 |
| markh | things are a little uglier when I do :( | 05:06 |
| markh | lifeless: http://pastebin.com/m27ccab4c | 05:08 |
| lifeless | markh: could you fix? | 05:10 |
| lifeless | markh: the intent should be pretty obvious | 05:10 |
| markh | not today :( | 05:10 |
| lifeless | sure | 05:10 |
| lifeless | No windows dev environment here at the moment, so I can't | 05:11 |
| markh | np | 05:11 |
| lifeless | uniscript: no, no-access requires full history copied, today. | 05:11 |
| uniscript | OK thanks, at least I know not to go chasing after the wind :) | 05:11 |
| lifeless | uniscript: partial-local-storage is what you asked for :P, sorry that its not enough | 05:12 |
| uniscript | you say "today" is it in the pipeline? | 05:12 |
| lifeless | long term plans, nothing to hold breath over :) | 05:12 |
| uniscript | I can imagine that people would like to join an svn repo from some revision onwards | 05:13 |
| uniscript | Or I suppose it can be part of the ability to consolidate bzr repos | 05:13 |
| uniscript | does that exist? | 05:13 |
| lifeless | I'm not sure what you mean | 05:13 |
| uniscript | clear out irrelevant history? | 05:13 |
| uniscript | say I have 1000 revisions in my repo | 05:14 |
| uniscript | and I don't want all that history kept, can I say merge 200-300 as one revision and dump all that history? | 05:14 |
| Peng_ | Wait, it's just a one-line change to fix this. | 05:15 |
| Peng_ | Well, that's to stop it from wasting one transport. There are others too. | 05:16 |
| Peng_ | lifeless: Do you mind if I pass "foo/" to index_url instead of an URL like "file:///path/to/foo/" or whatever? | 05:21 |
| lifeless | Peng_: for testing? | 05:29 |
| lifeless | bug 248275 | 05:41 |
| ubottu | Launchpad bug 248275 in bzr "Crash when pulling with --no-plugins" [Undecided,Fix released] https://launchpad.net/bugs/248275 | 05:41 |
| lifeless | poolie: ^ is that a bubba alias? | 05:41 |
| mwhudson | i think it's probably a different mentally ill person | 05:42 |
| Peng_ | lifeless: No, because it's the least-invasive way to get rid of that wasted transport (it's just used like get_transport(url).base) | 05:44 |
| lifeless | Peng_: oh. well foo/ isn't a url, its a url fragment or possibly a unicode path | 05:45 |
| lifeless | I'd rather not pass paths to url functions, bad things tend to eventually happen | 05:45 |
| Peng_ | ok | 05:47 |
| vila | good morning bazaar ! | 07:01 |
| lifeless | man I hate libc maintainers sometimes | 07:18 |
| lifeless | st_mtime is a def __get__(self): | 07:19 |
| lifeless | return self._mtime | 07:19 |
| lifeless | bad paste sorry | 07:19 |
| lifeless | st_mtime is a defined macro from bits/stat.h now :( | 07:19 |
| lifeless | ok | 07:27 |
| lifeless | 10% shaving by using a compiled stat object | 07:27 |
| === mark1 is now known as markh | ||
| jonnydee | hi, I | 08:21 |
| jonnydee | 've got a question: I've got a checkout and did a "bzr ci --local" yesterday. Today I did a "bzr up" and now my local commit from yesterday shows up as a pending merge. Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge? | 08:21 |
| jonnydee | (for the case my last sentence got cut): Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge? | 08:22 |
| jonnydee | and what effects does a "bzr update" have on the local repository if it contains local commits? | 08:23 |
| Peng_ | jonnydee: (Your last sentence didn't get cut. IRC's line length limit is closer to 500 chars, and many/most IRC clients handle it sensibly.) | 08:26 |
| Peng_ | jonnydee: Sorry, but I don't have experience with checkouts, so I can't really answer your question. | 08:28 |
| jonnydee | Peng_: ok thanks for your feedback | 08:28 |
| bob2 | it's a lightweight checkout? | 08:29 |
| jonnydee | no, a normal checkout | 08:29 |
| jonnydee | does it make any difference? | 08:29 |
| jonnydee | (in my case) | 08:29 |
| Peng_ | jonnydee: My wild guess would be that you can't avoid a merge, because it would require rebasing, and bzr isn't big on that. | 08:31 |
| Peng_ | But I don't know the mechanics of local commits in checkouts, so that may be wrong. | 08:31 |
| jonnydee | probably you are right... So I'll do a merge... Thanks a lot for your help :) | 08:33 |
| jml | lifeless: you raiding tonight? | 08:39 |
| sabdfl | bzr diff -r date:2008-09-09,09:00:00 | 08:49 |
| sabdfl | doesn't seem to work | 08:49 |
| sabdfl | any suggestions? | 08:49 |
| uws | sabdfl: bzr diff -r date:2008-09-09T09:00:00 | 08:55 |
| spiv | sabdfl: seems to work ok for me | 08:55 |
| uws | with a comma it works for me as well | 08:56 |
| sabdfl | ./bzr diff -r date:2008-09-09TO09:00:00 ~/software/bzr.dev | 08:56 |
| sabdfl | bzr: ERROR: Requested revision: u'date:2008-09-09TO09:00:00' does not exist in branch: BzrBranch7('file:///home/mark/software/bzr.dev/') | 08:56 |
| uws | TO? | 08:56 |
| uws | sabdfl: it's a 0, not O | 08:56 |
| spiv | sabdfl: There probably isn't a revison after that time, hence the "no such revision" error. | 08:56 |
| uws | but with comma it works fine for me as well, as I said | 08:56 |
| sabdfl | doh | 08:57 |
| spiv | I don't think there's been any commits to bzr.dev since 2008-09-08 07:18:35 +0100 | 08:57 |
| uws | yeah, I get it with dates in the future as well | 08:57 |
| uws | but the error message is at the very least misleading | 08:58 |
| spiv | (And "-r date:..." calculates using your local timezone, so comparing is often confusing....) | 08:58 |
| spiv | Yeah, the error message could definitely be better. | 08:58 |
| bob2 | and different output for "no commits since that time to compare to" and "no commits at or after that time at all" | 08:59 |
| === fta_ is now known as fta | ||
| lifeless | jml: shutdown night | 10:04 |
| LeoNerd | lifeless: So.. I mailed the mailing list about my "log" range ideas... no response.. :/ | 11:45 |
| kinkie | Hi all.. I've made a little mess, by inadvertently deleting a branch from a repo. I have the branch pushed-to in launchpad, is there a way to recover the branch in my repo without branching and merging again? Thanks | 11:54 |
| uws | kinkie: if you branch it again, it will (re)use the revisions from your local repo, so it's cheap | 11:56 |
| awilkins | kinkie: bzr heads --all will show all tips in your repo | 11:56 |
| awilkins | And uws is also correct | 11:56 |
| uws | awilkins: What is the difference between "dead" and "alive" heads? | 11:57 |
| awilkins | My way is tricksier but requires no network connection ; his way is easy and requires minimal network | 11:57 |
| awilkins | uws: "Dead" heads are ones that are not in a branch | 11:57 |
| uws | awilkins: well, if you ask on irc i assume a network connection is available ;) | 11:57 |
| uws | awilkins: how does it know? | 11:58 |
| awilkins | uws: I presume it recurses, but I'm not sure. | 11:58 |
| awilkins | uws: I'm going to try it now :-) | 11:58 |
| * awilkins randomly deletes a branch | 11:58 | |
| awilkins | Yup, dead heads are ones with no branch, but still listed by all | 11:59 |
| uws | awilkins: it can't know if I have branches somewhere on my machine (or on another machine) that are on that specfic head, right? | 11:59 |
| uws | e.g. a checkout on another machine | 11:59 |
| uws | eh, s/checkout/branch/ | 11:59 |
| awilkins | uws: I think it restricts itself to branches within that repo | 11:59 |
| uws | ah, that makes sense (common setup anyway) | 11:59 |
| awilkins | Probably very wuick in a no-trees repo | 12:00 |
| kinkie | awilkins: ok, I found the head. What then? (I'm not so big on bzr recoveries yet ;) | 12:00 |
| awilkins | Pretty quick in a trees repo too ; it only has to check .bzr folders | 12:00 |
| kinkie | trunk is 'trunk' | 12:00 |
| kinkie | let's call the branch 'foo' | 12:00 |
| awilkins | You should be able to branch it from the listed revid: | 12:01 |
| kinkie | should I just 'bzr branch trunk foo'? And as long as the name matches, it'll just revive the branch? | 12:01 |
| awilkins | bzr branch trunk -r revid:<myrevid> foo ? | 12:01 |
| uws | awilkins: heads --all shows me a bunch of revisions that have been committed/merged into my branch ages ago. how come? | 12:02 |
| awilkins | uws: because they're all tips of branches that no longer exist in your repo | 12:02 |
| awilkins | uws: I suspect if you branch your trunk into another repo and try again they'll disappear | 12:03 |
| uws | awilkins: I still don't know how it figures that out | 12:04 |
| awilkins | uws: The help says "revisions without descendants" | 12:05 |
| uws | awilkins: yeah, but they're merged, so they have revisions on top of them | 12:05 |
| kinkie | awilkins: that did it. THANKS A LOT! | 12:06 |
| uws | awilkins: (but indeed, creating a new repo makes them disappear_) | 12:06 |
| awilkins | There may be more to it than meets the eye then | 12:06 |
| awilkins | kinkie: Thanks for helping me practice that, never done it before | 12:07 |
| kinkie | I honestly hope it's an one-shot affair ;-) | 12:08 |
| awilkins | kinkie: I had a small doubt that it might not work with a revision that was never merged into the branch I'm instructing it to branch, but I just tried it and that works just fine | 12:09 |
| uws | awilkins: hmmmm. it could be that revisions I've uncommitted show up as heads | 12:11 |
| awilkins | uws: Aha, yes, I think you've put your finger on it | 12:11 |
| uws | awilkins: I was triggered by the exceptionally high number of typos in the commit messages :) | 12:12 |
| Leonidas | maybe I am too stupid, but somehow bzr commit -x does not exclude anything. | 12:15 |
| poolie | night all | 12:56 |
| james_w | Leonidas: it works for me, but it doesn't affect the diff shown by --show-diff, which I will file a bug on, is that all you were looking at, or did you look at the committed diff? | 14:40 |
| Leonidas | james_w: when I committed it has included the file in the output, so I think it has committed it as well. I did an uncommit, but I'll test it again when I find some time to make sure it is not because I'm too stupid to use it. | 14:41 |
| james_w | Leonidas: I saw it was in the diff, but not the "modified foo" lines it prints, and "bzr diff -c -1" afterwards shows only the changes that I wanted | 14:42 |
| james_w | bug 268135 | 14:50 |
| ubottu | Launchpad bug 268135 in bzr "bzr commit -x doesn't change the --show-diff output" [Undecided,New] https://launchpad.net/bugs/268135 | 14:50 |
| === mvo__ is now known as mvo | ||
| james_w | that's not good: "branch.lock_read()" deleting the branch, there's something fishy going on here | 16:02 |
| Peng_ | I was just messing around because of the slow startup thread on the mailing list, I ran "bzr revert" on a single file, and it took like 5 seconds. :( | 16:04 |
| james_w | ah no, just me being stupid it seems | 16:04 |
| Peng_ | Stupid hard drives. | 16:04 |
| james_w | I have a problem with code I am writing | 16:23 |
| james_w | it does "revid = tree.commit()" and then "other_branch.fetch(tree.branch, last_revision=revid)" | 16:24 |
| james_w | this works fine when the branches are in separate repositories, but fails when they share one | 16:25 |
| james_w | as the fetch detects that it is fetching to the same repo, and just checks that the last_revision is present | 16:25 |
| james_w | this check is what fails | 16:26 |
| james_w | if I use pdb to pause just before the fetch "bzr log" and "bzr heads" from another process outside can see the revision in question | 16:26 |
| james_w | do I need to do something to make the current process see the just committed revision, or am I missing something else? | 16:27 |
| foebrian | morning all | 16:27 |
| foebrian | is there a way to remove a project from bazaar? to unregister it? | 16:27 |
| Odd_Bloke | foebrian: Why do you want to? | 16:29 |
| james_w | hi Odd_Bloke | 16:29 |
| Odd_Bloke | james_w: o/ | 16:30 |
| james_w | Odd_Bloke: how's the job? | 16:31 |
| foebrian | Odd_Bloke: well i setup bazaar on my home server, and missedtyped the project path, so now 6 projects are considdered one, so i want to unregister it, then fix by adding just one project. if that make sense | 16:31 |
| Odd_Bloke | james_w: Not bad. | 16:31 |
| Odd_Bloke | Currently work on OO.o. D: | 16:32 |
| Odd_Bloke | foebrian: What do you mean by 'projects'? | 16:33 |
| foebrian | Odd_Bloke: well i have a single project folder /storage/projects then below that i have my project 'branches' like /project1 /project2 /project3, so now all the folders are commited to one 'branch' even though they are seprate projects | 16:34 |
| foebrian | does that make sense? | 16:35 |
| Odd_Bloke | foebrian: Right, move /storage/projects/.bzr to somewhere else (just as a backup), and then 'bzr init' in each of the separate project directories. | 16:36 |
| Odd_Bloke | If the projects are related, you should consider running 'bzr init-repo /storage/projects' beforehand, it'll save space. | 16:36 |
| foebrian | Odd_Bloke: so the removal of .bzr will remove it then? unfornately they are not related, seprated things | 16:37 |
| Odd_Bloke | foebrian: Yeah. | 16:38 |
| foebrian | Odd_Bloke: awesome, it worked! thanks Odd_Bloke! | 16:42 |
| foebrian | chaos is removed! | 16:42 |
| james_w | bug 264705 if anyone has any ideas about my problem | 16:42 |
| ubottu | Launchpad bug 264705 in bzr-builddeb "merge-upstream fails when shared repository is present" [Critical,New] https://launchpad.net/bugs/264705 | 16:42 |
| Odd_Bloke | foebrian: No worries. | 16:43 |
| Odd_Bloke | james_w: Are you still working on versioning all of Ubuntu? | 16:48 |
| james_w | Odd_Bloke: yup | 16:49 |
| Odd_Bloke | james_w: How's it going? | 16:49 |
| james_w | Odd_Bloke: it's coming along, spending a week or two bug fixing at the moment before Ubuntu beta freeze, and then back to importing and documentation | 16:50 |
| Odd_Bloke | james_w: Ah, cool. | 16:50 |
| LeoNerd | By the way guys: I've just built myself a WinXP VM in VirtualBox. First thing I did was installed Bazaar, which has TortoiseBZR. I'd like to report it JustWorks. It's lovely ;) | 17:00 |
| * kinkie is away: see you later/tomorrow | 17:01 | |
| Odd_Bloke | kinkie: If you could disable away messages, for this channel at least, that would be appreciated. :) | 17:04 |
| === kiko is now known as kiko-fud | ||
| jam | lifeless: ping me when you wake up, I need you to make a 1.7 branch so I can do 1.7rc1 | 17:53 |
| * justizin wonders why the OSX 10.5 installer is an older version of bzr (1.5) than the OSX 10.4 installer (1.6) | 18:03 | |
| justizin | does the 10.4/1.6 not work on leopard? | 18:03 |
| Verterok | justizin: the installers are builded by the community | 18:11 |
| justizin | fair enough :) | 18:11 |
| justizin | looks like 1.6 installer wants python 2.5 on 10.4, complains i need python 2.5 even though i have it on leopard | 18:11 |
| Verterok | justizin: I build the 10.4, and 'ld like to build the 10.5 too, but no leopard nor mac-intel here :( | 18:11 |
| justizin | Verterok: can i run the build for you? ;) | 18:12 |
| justizin | i've got three intel macs here running leopard. | 18:12 |
| Verterok | justizin: the 10.4 installer depends on a user installed python. 10.4 only provides python2.3 by default | 18:12 |
| justizin | love to help.. | 18:12 |
| justizin | yeah i figure as much.. | 18:12 |
| justizin | how does the checking work? | 18:13 |
| justizin | seems it should be possible to look for python in /System/Library/Frameworks as well as /Library/Frameworks or ~/Library/Frameworks... | 18:13 |
| Verterok | justizin: let me check | 18:13 |
| justizin | but i know this is a challenge for many mac / python installers.. | 18:13 |
| justizin | np | 18:13 |
| justizin | 1.5 will serve my needs for now but i'd love to help make available better installers for mac any way i can. | 18:14 |
| Verterok | justizin: the 10.4 installer checks CFBundleShortVersionString property in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Info.plist | 18:14 |
| justizin | is it possible to configure alternative checks, or does it only allow one location to provide a dependency? | 18:15 |
| Verterok | justizin: I think it's possible, but I dont' know if its going to work | 18:16 |
| justizin | hm | 18:16 |
| justizin | is source for the installer accessible? | 18:16 |
| Verterok | justizin: all the C extensions are compliled against 10.4 dynlibs | 18:16 |
| justizin | fair enough | 18:17 |
| justizin | i suppose we can just port it to 10.5 | 18:17 |
| Verterok | justizin: I think phanatic builds the 10.5 installer, and have all the required bits | 18:17 |
| Verterok | justizin: check Issues section at http://bazaar-vcs.org/MacOSXBundle | 18:18 |
| justizin | got it | 18:18 |
| newz2000 | in eclipse using bzr-eclipse I've found that if I check out my work into a subfolder of the project (for example, trunk) then eclipse doesn't recognize the project as being managed by vcs. Does anyone know a workaround? | 18:22 |
| Verterok | justizin: if you don't have a reply, please let me know and I'll push my installer branch to some public location | 18:23 |
| Verterok | newz2000: Eclipse only support project level team provider mappings | 18:23 |
| newz2000 | oh, too bad | 18:23 |
| Verterok | newz2000: what is the layout you need? | 18:24 |
| justizin | Verterok: i'd like if you published it.. | 18:24 |
| Verterok | justizin: at your service ;) http://verterok.com.ar/code/bundle-10.4/ | 18:25 |
| newz2000 | well, I was taught an interesting way to manage my project... create a folder, keep my main trunk branch in a sub-folder, and when I'm fixing problems create a branch for the fix and work on it there. | 18:25 |
| newz2000 | I've been using it lately and its working out nice | 18:25 |
| Verterok | justizin: the pmproj file is a work in progress (tm) to include bzr-svn, just remove both bzr-svn entries and it 'll build ok :p | 18:26 |
| newz2000 | so my project might include these folders: trunk/ add-openid/ jquery126/ | 18:26 |
| justizin | ok | 18:26 |
| newz2000 | all branches | 18:26 |
| justizin | i was thinking about that challenge myself. | 18:26 |
| justizin | are you just including a copy of svn 1.5 or wha? | 18:27 |
| Verterok | justizin: most of the work is there, just need the glue :) | 18:27 |
| Verterok | justizin: I acctually build bzr-svn against both versions of subversion (1.4 and 1.5) | 18:27 |
| Verterok | justizin: and adds a check like the python-2.5 one | 18:28 |
| justizin | interesting.. | 18:28 |
| justizin | 1.4 needs to be patched to work, though, eh? | 18:28 |
| Verterok | justizin: not any more, bzr-svn now provides it own bindings | 18:28 |
| justizin | ah-ho | 18:28 |
| justizin | neato | 18:28 |
| newz2000 | oh, Verterok, you're Guillermo! Nice to meet you and nice work on the project. | 18:29 |
| justizin | i've just been using bzr-svn on my ubuntu box, then grab a copy using straight bzr from mac or other servers like RH which don't have bzr-svn yet | 18:29 |
| justizin | still will keep doing that but it'd be nice to have bzr-svn around other places sometimes :) | 18:29 |
| Verterok | newz2000: thanks! it's greatly appreciated! :D | 18:29 |
| Verterok | newz2000: maybe your need can be solved if bzr-eclipse provides a way to branch directly from a project | 18:30 |
| newz2000 | I wonder if it would be better to file a bug/feature request on eclipse, though I'm not sure how responsive they are | 18:30 |
| newz2000 | so that vcs can just live in sub folders | 18:30 |
| Verterok | newz2000: like: right click on on trunk --> branch as new Project. and create add-openid project | 18:30 |
| newz2000 | ah | 18:31 |
| Verterok | newz2000: that could work for your workflow? | 18:31 |
| newz2000 | yeah, that would work, but the only prob is the directory structure might become a mess | 18:31 |
| newz2000 | let me think it through for a second | 18:31 |
| Verterok | newz2000: you cound place the new project in any directory you want, i.e: like a share repo | 18:32 |
| newz2000 | so for example, I'm working on a project called XYZ | 18:32 |
| newz2000 | it would go into workspace/XYZ | 18:32 |
| newz2000 | and that would be the root of my project (no trunk/ folder) | 18:33 |
| Verterok | justizin: poke me if you need some help to get the whole build process working (I know it need documnetation) | 18:33 |
| newz2000 | and to add a feature I branch from there to a new project at workspace/XYZ-feature23/ | 18:33 |
| newz2000 | does that sound right? | 18:33 |
| justizin | np doing a few things atm but will prod a bit and see what errors i get if i try a build | 18:33 |
| Verterok | newz2000: that is one approach, actually, you could do taht with current bzr-eclipse | 18:34 |
| newz2000 | yes, I believe so | 18:34 |
| Verterok | newz2000: also, you can place the projects inside /whatever/path/you/like :) | 18:34 |
| newz2000 | oh, really? I just use the default options usually | 18:35 |
| newz2000 | then let me try that, it is probably the easiest solution | 18:35 |
| newz2000 | and fixes another problem I'm about to experience since the python-path in pydev is set per-project | 18:35 |
| Verterok | newz2000: also, if you want the "branch from project into a new project", please file a bug :) | 18:36 |
| newz2000 | ok, thanks for your time Verterok, I appreciate the help | 18:36 |
| Verterok | newz2000: np, glad to help | 18:37 |
| * newz2000 just tried it - it works! | 18:37 | |
| Verterok | great! | 18:39 |
| === beuno_ is now known as beuno | ||
| === kiko-fud is now known as kiko | ||
| === mark1 is now known as markh | ||
| === mw is now known as mw|food | ||
| ericvw | If I have standalone branch, but I want to migrate it into a centralized development work-flow because I will be on multiple computers, how would I go about migrating? | 19:54 |
| fullermd | Push it up to your central location, and use 'bind' or 'reconfigure' to turn its current location into a checkout of the central branch. | 19:55 |
| ericvw | fullermd: and it will know from the push where to update from and commit to? | 19:56 |
| sabdfl | hey beuno | 20:08 |
| beuno | hey sabdfl | 20:10 |
| beuno | how's it going? | 20:10 |
| sabdfl | groovy here, thanks. you? | 20:10 |
| beuno | better now that I have internet again :) | 20:10 |
| fullermd | ericvw: No, from the bind/reconfigure. | 20:14 |
| fullermd | ericvw: The push just sets up the data in the central location. | 20:14 |
| ericvw | fullermd: thanks! | 20:30 |
| === mw|food is now known as mw | ||
| strk | can a repository be downgraded to an older version to be compatible with older bzr clients ? | 20:53 |
| jelmer | strk, generally, yes | 20:56 |
| jelmer | strk: "bzr upgrade --old-format" (where old-format is the name of the format to downgrade to) | 20:56 |
| strk | Could not load movie 'http://request/remote.php?theme=touchscreen.swf' | 20:56 |
| strk | (sorry) | 20:57 |
| willyyam | any reason why bzr is a bad choice as a backend for a versioned backup system? | 20:58 |
| strk | willyyam: it's too new for debian stable users :) | 20:58 |
| strk | is also slower then CVS | 20:59 |
| willyyam | or, to put it another way, are twice-daily large binary blobs a problem over a long time (5+ years) | 20:59 |
| willyyam | actually, I use it on debian stable daily | 20:59 |
| strk | that one ships 0.11 it seems | 20:59 |
| strk | we're using 0.16 and somewhat lost compatibility | 21:00 |
| strk | so you can't fetch gnash sources from debian stable, unless you upgrade bzr | 21:00 |
| strk | it sucks | 21:00 |
| jelmer | strk: Lenny will be out soon hopefully :-) | 21:00 |
| jelmer | strk, performance is pretty bad with old formats though | 21:00 |
| strk | soon == few monts | 21:00 |
| strk | jelmer: I'm talking about performance with 0.16 unfortunately | 21:01 |
| jelmer | strk: but yeah, bzr upgrading to an older format should work | 21:01 |
| strk | I guess downgrade would make it even slower ? | 21:01 |
| strk | it takes from 15 to 30 minutes for a simple commit on a GPRS connection | 21:01 |
| strk | about 1 minute on a DSL | 21:01 |
| strk | the GPRS experience makes you hate it :) | 21:02 |
| strk | but you can commit to a local branch while out-of-the-office and merge when back on high bandwidth, which is a bit harder with CVS | 21:02 |
| === mario_ is now known as pygi | ||
| beuno | pickscrape, | 21:54 |
| beuno | "ping" | 21:54 |
| beuno | is this what I'm suppose to be looking at? lp:~pickscrape/loggerhead/directory_breadcrumbs | 21:54 |
| beuno | mwhudson, I'm trying to remember what was wrong with lp:~pickscrape/loggerhead/directory_breadcrumbs | 22:00 |
| beuno | but everything seems fine | 22:00 |
| beuno | do you remember why we didn't merge that in the end? | 22:00 |
| pickscrape | beuno: yes, I think that was it | 22:03 |
| lifeless | jam: made | 22:03 |
| jam | lifeless: thanks | 22:03 |
| beuno | pickscrape, it looks fine to me. You fixed everything, didn't you? | 22:03 |
| lifeless | the losas have that documented too FWIW | 22:03 |
| pickscrape | Probably some hideous use of METAL that would have made the loggerhead codebase horrible :) | 22:03 |
| pickscrape | I think I did, but it probably needs a really good test and review to make sure I didn't miss anything or code it into a hole or anything like that | 22:04 |
| beuno | pickscrape, fire off the merge request, I'll take a look at the code | 22:04 |
| beuno | I've been using it, and can't find any problems with the UI at all | 22:04 |
| pickscrape | merge request via LP right? | 22:05 |
| beuno | yeap | 22:06 |
| mwhudson | beuno: maybe i just haven't got aroudn to looking at the lastest version | 22:10 |
| beuno | mwhudson, yeah, me neither, but trying to get up-to-date today with LH stuff :) | 22:10 |
| beuno | thanks | 22:10 |
| mwhudson | beuno: good idea | 22:10 |
| pickscrape | Merge request sent | 22:10 |
| pickscrape | Just reading my commit comments on that branch, I was concerned about having to create an inventory object for the annotate view. | 22:11 |
| ivantis | hello | 22:14 |
| ivantis | how do i log in with bzr to launchpad? i need to push some code | 22:14 |
| ivantis | i already have an account | 22:14 |
| beuno | ivantis, https://help.launchpad.net/BzrHowto | 22:15 |
| ivantis | thx | 22:15 |
| kwah | hi everyone | 22:17 |
| kwah | I tried to ask on a mailing list... https://lists.ubuntu.com/archives/bazaar/2008q3/047006.html | 22:17 |
| kwah | but got no reply | 22:17 |
| kwah | either I could not find relevant information myself | 22:18 |
| kwah | or it is the lame question | 22:18 |
| kwah | any comments? | 22:18 |
| mwhudson | kwah: well, if you have a shared repo upgrading the repository is a separate thing from upgrading the branches | 22:19 |
| mwhudson | kwah: the main negative impact of upgrading is that people using older versions of bzr won't be able to access your branches | 22:20 |
| kwah | mwhudson, and what about branches that were checked out? | 22:20 |
| kwah | not branched, I mean | 22:20 |
| mwhudson | the branch/checkout distinction is basically irrelevant here | 22:21 |
| mwhudson | or do you mean lightweight checkouts? | 22:21 |
| kwah | I am wondering, because some people are working with repo and I do not know, what they will see | 22:22 |
| mwhudson | either way, the only impact would be better perfomance :) | 22:22 |
| kwah | error message upon checking in | 22:22 |
| mwhudson | no | 22:22 |
| kwah | no, not lightweight | 22:22 |
| mwhudson | ah | 22:22 |
| mwhudson | actually, the conversion process is kind of slow | 22:22 |
| mwhudson | so using a knit branch that's a checkout of a packs branch, say, might be a little tedious | 22:23 |
| mwhudson | but it would _work_ | 22:23 |
| kwah | so it will be just transparent for the user? | 22:23 |
| mwhudson | right | 22:24 |
| kwah | hm... I guess I have to experiment myself more. | 22:24 |
| kwah | anyway, it would be nice to have some points about this in documentation | 22:24 |
| kwah | help messages are kinda cryptic | 22:24 |
| mwhudson | file a bug, maybe? | 22:25 |
| kwah | mwhudson, thanks for the explanation | 22:25 |
| kwah | mwhudson, I may try | 22:25 |
| mwhudson | np | 22:25 |
| jam | lifeless: you created the 1.7 branch, but didn't give me authorization to commit to it. | 22:34 |
| lifeless | jam: fixing | 22:34 |
| lifeless | 7am :P | 22:35 |
| lifeless | done | 22:35 |
| jam | np | 22:37 |
| jam | thanks | 22:37 |
| lifeless | you forgot to time just python | 22:38 |
| lifeless | to get the delta for locale | 22:38 |
| jam | lifeless: sure, replied | 22:41 |
| beuno | mwhudson, http://launchpadlibrarian.net/17058288/loggerhead_changes_path.diff | 22:54 |
| beuno | related to: https://bugs.edge.launchpad.net/loggerhead/+bug/260363 | 22:55 |
| ubottu | Launchpad bug 260363 in loggerhead "unable to generate a link showing a file changes based on its path" [Undecided,New] | 22:55 |
| beuno | we're doing that everywhere else in LP | 22:55 |
| beuno | +1 to apply that patch? | 22:55 |
| beuno | s/LP/LH | 22:55 |
| beuno | I'm starting to get dizzy :) | 22:55 |
| mwhudson | beuno: s/not path is None/path is not None/ | 22:55 |
| mwhudson | and if we're really doing that EVERYWHERE in LH, i guess it should be in TemplateView | 22:56 |
| beuno | I knew this wasn't going to be that easy... | 22:56 |
| beuno | let me see how this can be refactored... | 22:56 |
| mwhudson | beuno: it seems all the views a pretty consistent about how they handle 'args' | 22:59 |
| mwhudson | either it's <revid>/path | 22:59 |
| mwhudson | or they ignore it | 22:59 |
| mwhudson | so we could change the signature from | 22:59 |
| mwhudson | get_values(self, h, args, kwargs, response) | 22:59 |
| mwhudson | to | 22:59 |
| mwhudson | get_values(self, h, revid, path, kwargs, response) | 23:00 |
| beuno | mwhudson, good idea. Let me change that and see how it looks | 23:02 |
| mwhudson | beuno: thanks :) | 23:02 |
| beuno | mwhudson, LH seems to be acting up again: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3697?file_id=setup.py-20050314065409-02f8a0a6e3f9bc70 | 23:05 |
| beuno | Verterok, w00t! | 23:18 |
| beuno | thanks for that | 23:18 |
| Verterok | beuno, mwhudson: ^ | 23:18 |
| * Verterok just send the review request | 23:19 | |
| mwhudson | ? | 23:19 |
| mwhudson | ah right | 23:19 |
| Verterok | mwhudson: Bug #243415 | 23:19 |
| ubottu | Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415 | 23:19 |
| poolie | good morning | 23:20 |
| === kiko is now known as kiko-fud | ||
| beuno | morning poolie | 23:20 |
| Verterok | mwhudson ,beuno: the template needs some love, but it would be great to get some early feedback | 23:20 |
| james_w | hi poolie. | 23:21 |
| Verterok | hi poolie | 23:21 |
| beuno | Verterok, I can give it some love. That's the easy part :) | 23:21 |
| * poolie feels welcome | 23:21 | |
| james_w | poolie: a friend told me that the "topics" thing on the mailing list doesn't seem to be working correctly, merge requests seem to be delivered even if the merge topic isn't desired. | 23:22 |
| lifeless | abentley: bb is down? | 23:24 |
| james_w | hey lifeless | 23:24 |
| Verterok | beuno: it would be *really* appreciated | 23:24 |
| abentley | lifeless: restarted | 23:25 |
| beuno | Verterok, I'll try and get to that after the refactor I'm doing | 23:25 |
| lifeless | abentley: thanks | 23:25 |
| Verterok | beuno: no hurry. thanks :) | 23:26 |
| * lifeless waves around | 23:26 | |
| poolie | hello lifeless | 23:26 |
| beuno | howdy lifeless | 23:27 |
| lifeless | turns out that the vodafone system allows their helpdesk line to be put in as the 'notify me that a bill has been emailed' number | 23:27 |
| * lifeless is satisfied | 23:27 | |
| james_w | if I have two branches which share a repository, and commit to one, should the commit be instantly visible in the branch.repository of the other? | 23:29 |
| james_w | https://bugs.edge.launchpad.net/bugs/264705 | 23:29 |
| ubottu | Launchpad bug 264705 in bzr-builddeb "merge-upstream fails when shared repository is present" [Critical,Confirmed] | 23:29 |
| mwhudson | pickscrape, beuno: i think that now History objects only last for the duration of a request, get_inventory should cache the inventories it returns | 23:29 |
| lifeless | james_w: if the other branch drops its read lock to 0, then ups it, yes | 23:31 |
| lifeless | james_w: but while locked the other repo may not refresh its indices list | 23:31 |
| lifeless | jam: ping | 23:32 |
| pickscrape | mwhudson: my worry was whether the breadcrumbs code adds an inventory object to the annotate page that was not needed before | 23:32 |
| mwhudson | pickscrape: it was created anyway | 23:32 |
| pickscrape | mwhudson: in that case I'm not worried :) | 23:32 |
| mwhudson | pickscrape: in annotate_file, and possibly in get_file_path | 23:32 |
| mwhudson | pickscrape: but it would be better to create it only once, hence the caching suggestion | 23:33 |
| james_w | lifeless: thanks. Any suggestions for how to solve this bug? | 23:33 |
| pickscrape | mwhudson: oh, you mean it doesn't actually do the caching at the moment? | 23:33 |
| mwhudson | pickscrape: right | 23:33 |
| pickscrape | ok | 23:34 |
| lifeless | james_w: what bug | 23:34 |
| james_w | lifeless: 264705 | 23:36 |
| lifeless | james_w: as I said, drop the references to the branch after the merge operation | 23:37 |
| Yasumoto | I'm working with the fiveadayapplet, does anyone happen to know what error code 104 is? | 23:37 |
| lifeless | no idea, we don't use numeric error codes | 23:37 |
| lifeless | so its either not related to bzr, or coming from the OS | 23:38 |
| james_w | lifeless: doesn't that introduce a race condition? | 23:38 |
| Yasumoto | kk, that'd make sense why Google wasn't showing anything related to bzr, thank you :) | 23:38 |
| lifeless | james_w: you say you have branch A and B, you do something on A, and then B fails to see the data? | 23:38 |
| james_w | Yasumoto: /tmp/5-a-day-applet.txt may help you to debug | 23:39 |
| lifeless | james_w: if B is locked prior to doing the task on A, B will not see new data introduced by A until B has been unlocked | 23:39 |
| lifeless | james_w: what races are you worried about ? | 23:39 |
| Yasumoto | james_w: awesome, thanks for the heads up | 23:40 |
| james_w | lifeless: well, if B is unlocked and locked again isn't there time for the branch to be modified leading to trouble | 23:40 |
| lifeless | is B write locked or read locked? | 23:41 |
| james_w | write locked, it needs to do a merge of this new revision | 23:41 |
| lifeless | and sure, someone else could grab a write lock | 23:42 |
| james_w | perhaps I don't need the fetch there, and can move it up a function | 23:42 |
| lifeless | but if you do rev = B.tip, B.unlock();b.lock_write(); check B.tip == rev | 23:42 |
| lifeless | you can be sure noone has altered the tip | 23:42 |
| lifeless | I don't understand why you would mutate branch A while holding a write lock on B | 23:43 |
| lifeless | which branch are you actually working on :P | 23:43 |
| mwhudson | pickscrape, beuno: i made a few more changes: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs | 23:43 |
| mwhudson | take a look? | 23:43 |
| mwhudson | pickscrape, beuno: here's the diff of all of em http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/216?remember=211&compare_revid=211 | 23:44 |
| james_w | lifeless: A is the "upstream" branch and B is the "packaging" one, this command commits the new upstream, and then merges it to the packaging one, so we need to write to both | 23:44 |
| james_w | lifeless: it locks B early to check there are no uncommitted changes, and get some info from it, but it could do the unlock I think. | 23:45 |
| lifeless | james_w: to me they are separate steps, is there any need to make the aggregate atomic ? | 23:45 |
| beuno | mwhudson, lovely. +1 | 23:45 |
| mwhudson | beuno: i guess i'll merge | 23:46 |
| james_w | lifeless: I think having it as one command makes sense. Is that what you mean by atomic? | 23:46 |
| lifeless | no | 23:46 |
| poolie | abentley, thanks for reading and replying to my mail | 23:46 |
| beuno | mwhudson, yes please! | 23:46 |
| lifeless | atomic - all-or-nothing | 23:46 |
| abentley | poolie: np | 23:46 |
| lifeless | indivisible etc | 23:46 |
| poolie | i have to admit the content of the reply was at first discouraging | 23:47 |
| james_w | lifeless: it doesn't really need to be. However the upstream branch is ephemeral, so currently it "disappears" on any error. | 23:48 |
| lifeless | james_w: ok, well I'd either patch bzrlib to have a public refresh-view method to trigger a refresh, or drop and reacquire the lock | 23:48 |
| lifeless | poolie: what email was discouraging? | 23:49 |
| pickscrape | mwhudson: all looks ok to me | 23:49 |
| mwhudson | pickscrape: good, because i just merged it :) | 23:49 |
| mwhudson | pickscrape: thanks! | 23:49 |
| pickscrape | hehe :) | 23:49 |
| poolie | aaron's re what do we do now | 23:50 |
| abentley | poolie: I'm sorry for any hurt feelings. I felt it was important to be frank. | 23:50 |
| poolie | it is | 23:50 |
| pickscrape | Funny how someone who is picky about whitespace can be picked up on whitespace by someone else who is also picky about whitespace :) | 23:50 |
| james_w | lifeless: thanks, it's late now, but you've probably given me enough to fix this tomorrow, thanks. | 23:50 |
| poolie | i'd prefer that to folks just smiling and nodding | 23:50 |
| lifeless | poolie: ah right | 23:52 |
| lifeless | hadn't found that reply at that point | 23:52 |
| lifeless | hmmm food, that will make me smile and nod | 23:52 |
| abentley | poolie: I was a bit surprised at your suggestion, because I thought we agreed that too many cooks contributed to our problems with stacking. | 23:53 |
| Verterok | mwhudson: I added a --reload option to serve-branches (mainly to ease dev's life :): http://bazaar.launchpad.net/%7Eguillo.gonzo/loggerhead/reloader/revision/220 | 23:53 |
| beuno | Verterok, :O | 23:54 |
| mwhudson | Verterok: ah, you look like someone that knows somethign about paste! | 23:54 |
| beuno | Verterok, gazillion thanks!!!! | 23:54 |
| Verterok | mwhudson: not at all :) | 23:55 |
| beuno | mwhudson, we need that merged. Now! | 23:55 |
| beuno | millions of hours spent restarting LH.... | 23:55 |
| Verterok | mwhudson: just readed some docs, and the source ;) | 23:55 |
| mwhudson | beuno: you have the powah | 23:55 |
| mwhudson | Verterok: :) | 23:55 |
| * beuno excercise it | 23:55 | |
| beuno | mwhudson, don't believe Verterok. He knows plenty, he's just shy | 23:56 |
| Verterok | beuno: before merging, let me update serve-branches.1 | 23:56 |
| Verterok | beuno: hehe | 23:57 |
| * Verterok hides | 23:57 | |
| beuno | Verterok, sure. Push, I'll pull, etc | 23:57 |
| igc | morning | 23:58 |
| james_w | morning igc | 23:58 |
| beuno | morning igc! | 23:58 |
| igc | hi guys | 23:58 |
| beuno | all the cool people are around today | 23:58 |
| Verterok | beuno, mwhudson: it's the --reload help description ok? | 23:58 |
| Verterok | hi igc | 23:58 |
| igc | hi | 23:58 |
| poolie | hello igc! | 23:59 |
| mwhudson | Verterok: i guess it should be clear that the application gets restarted when the application changes | 23:59 |
| igc | hi poolie | 23:59 |
| mwhudson | Verterok: you could possibly think that it was something to do with the branch changing | 23:59 |
| beuno | Verterok, and, I'd also add this is only really useful for development | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!