| jelmer | re | 00:19 |
|---|---|---|
| jelmer | maybe one day, after bzr-gtk gets a pqm, we can add a pqm for bzr-svn as well and make sure it always passes the testsuite... | 00:19 |
| lifeless | yes | 00:24 |
| lifeless | I"m blocked on that as I mentioned :( | 00:24 |
| sminnee | Hi everyone | 00:35 |
| sminnee | I was wanting to get some information about the current status of nested trees | 00:36 |
| poolie | sminnee: they're partially supported at the moment but still classed as expeirmental | 00:41 |
| sminnee | poolie: it seems as though it's been that way for nearly 2 years? | 00:41 |
| sminnee | do you know what kind of risks there are in using it that make them experimental | 00:41 |
| sminnee | I'm currently on svn and svn:externals are an absolutely critical feature for me. | 00:42 |
| poolie | abentley could probably give you a more accurate answer | 00:42 |
| poolie | i think not all merges work across them correctly | 00:42 |
| lifeless | ok, bbiab | 00:43 |
| sminnee | poolie: but if you were keeping your merges restricted to happening within a single subtree, you would be okay? | 00:43 |
| sminnee | for example, i have "projects" and use svn:externals to link the applicable modules into each project | 00:44 |
| sminnee | so if I was branching and merging solely within the context of individual modules, i would be okay? | 00:44 |
| poolie | i think that would work | 00:45 |
| poolie | possibly we should just promote this to properly supported and deal with anything else that crops up | 00:46 |
| sminnee | poolie: i would vote for that approach :) it's a very useful feature and has been in-development for some time. | 01:18 |
| sminnee | I might have a play with them and complain when they start breaking, then :P | 01:18 |
| poolie | that'd be good :) | 01:18 |
| poolie | spiv, do you want to talk about the unlock exception handling? | 01:18 |
| spiv | poolie: ok | 01:19 |
| poolie | here, or on the phone? | 01:19 |
| spiv | Here's fine, I think. | 01:20 |
| spiv | I'm still pretty uncomfortable about the suggestion to suppress exceptions during unlock. | 01:21 |
| poolie | btw i did your tweak regarding the default argument - in fact i removed it | 01:22 |
| poolie | so i'm not sure if it's simpler and cleaner, or just too careless | 01:22 |
| spiv | It feels like it moves the complexity of handling unexpected conditions from a single, obvious place (the callsite) to a much broader and harder to determine scope. | 01:22 |
| poolie | however, unless we can really think of a case where it makes a difference, i think we should do it | 01:22 |
| poolie | hm | 01:23 |
| poolie | that's one way to look at it | 01:23 |
| spiv | So concretely, doing what I propose is clearly correct, and we know how it will behave. | 01:23 |
| poolie | but another way is doing this just changes the particular cleanup functions, rather than adding something to every caller | 01:23 |
| spiv | And hiding exceptions from unlock isn't clearly correct, at least not to me :) | 01:23 |
| sminnee | I have another question if you're not sick of noobs: bzr svn-import for an HTTP svn repository doesn't seem to like 401 responses. Does it support authenticated svn repositories over HTTP? | 01:24 |
| poolie | i thought it did | 01:24 |
| poolie | if jelmer is still here you could ask him | 01:24 |
| jelmer | yep, I am | 01:24 |
| poolie | spiv, so i'd cast it as | 01:24 |
| jelmer | sminnee, What's the error you're getting | 01:24 |
| sminnee | jelmer: bzr: ERROR: Invalid http response for http://svn.silverstripe.com/.bzr/branch-format: Unable to handle http code 401: Authorization Required | 01:25 |
| poolie | clarifying the behaviour of unlock to say "if the transport is closed, unlock will not raise an error" | 01:25 |
| sminnee | ooh I see - it seems to think it's a bzr repos | 01:25 |
| spiv | So, here's another reason to do it my way: when we shift to requiring Python 2.5, I think we'll want to do it with a "with" statement anyway. | 01:25 |
| sminnee | I executed ~/bzr/test: bzr svn-import http://svn.silverstripe.com/ repos | 01:25 |
| jelmer | sminnee, bzr doesn't support http auth, bug 256612 | 01:25 |
| ubottu | Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612 | 01:25 |
| jelmer | sminnee, you can work around it by using svn+http://svn.silverstripe.com/ | 01:25 |
| sminnee | jelmer: thanks. Now I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("REPORT request failed on '/!svn/bc/64032'", 175002) " which sounds more like an issue with my repos. | 01:26 |
| sminnee | I could use svn: or svn+ssh: however I get a different error ;) bzr: ERROR: exceptions.UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data | 01:26 |
| jelmer | sminnee, are you using bzr-svn 0.4.13 ? | 01:27 |
| spiv | poolie: Hmm. I'm not sure that just suppressing/avoiding errors due to the transport being closed will actually fix these bugs. | 01:27 |
| sminnee | jelmer: yeah, looks like it. I just downloaded and installed bzr 1.7.1 | 01:27 |
| spiv | poolie: the underlying exception in at least one of these cases is some form of "revision X not present", i.e. a logic bug in bzr, rather than an environmental problem. | 01:28 |
| jelmer | sminnee, please file a bug | 01:29 |
| sminnee | jelmer: sure thing. | 01:29 |
| poolie | and then the knock-on effect is that there's already a request pending, or that there's a write group open? | 01:29 |
| spiv | Right. | 01:30 |
| poolie | spiv, so the difference in behaviour between these options (as opposed to in the code) | 01:30 |
| poolie | is just in the case where the unlock fails but there was no earlier failure, right? | 01:30 |
| spiv | Hmm. I think so. | 01:31 |
| spiv | So there are four cases, (operation ok, unlock ok), (operation fails, unlock ok), (operation ok, unlock fails), and (operation fails, unlock fails). | 01:32 |
| poolie | right | 01:33 |
| spiv | (Which co-incidentally is why there are four test methods for my proposed helper :) | 01:33 |
| poolie | in the current trunk code, we get case 4 wrong by showing the unlock exception when we want to show the original exception | 01:33 |
| spiv | We seem to be disagreeing about the (ok, fails) case. | 01:33 |
| poolie | mm | 01:33 |
| poolie | i should say i'll be glad to have this fixed whatever solution we decide on | 01:34 |
| spiv | In (ok, fails) I think I'd rather get the exception immediately. | 01:34 |
| jelmer | hmm, did the API of record_entry_contents() change? | 01:34 |
| poolie | yes | 01:35 |
| poolie | * ``CommitBuilder.record_entry_contents`` returns one more element in | 01:35 |
| poolie | its result tuple - an optional file system hash for the hash cache | 01:35 |
| poolie | to use. (Robert Collins) | 01:35 |
| poolie | if i'd reviewed it i might have asked for a new name for the new protocol.... | 01:36 |
| sminnee | jelmer: here you go: https://bugs.launchpad.net/bzr/+bug/281035 there were similar looking bugs reported with the 'ascii' codec but i didn't see a UTF8 one. | 01:36 |
| ubottu | Launchpad bug 281035 in bzr "unicode error on import-svn call." [Undecided,New] | 01:36 |
| poolie | spiv, so you said in the patch for http://bundlebuggy.aaronbentley.com/project/bzr/request/<20081008054310.GC19754%40steerpike.home.puzzling.org> | 01:36 |
| poolie | s/patch/letter | 01:36 |
| poolie | that you can't distinguish those cases from inside the unlock, which is correct as far as i know | 01:36 |
| spiv | Right. | 01:36 |
| poolie | i kind of dislike needing to push the contents of these blocks into separate functions just to wrap them this way | 01:37 |
| spiv | So the advantage of your idea is that unlock doesn't need to distinguish. | 01:37 |
| poolie | yes, it is | 01:37 |
| poolie | would anyone care? | 01:38 |
| spiv | Yeah. I don't much like it either, but I don't think it is actually *bad*, just mildly irritating. | 01:38 |
| spiv | And in the case of functions like commit, it was probably large enough that it should be broken up somewhat anyway ;) | 01:38 |
| poolie | with your patch the failure from unlock is totally lost | 01:38 |
| spiv | Well, we can make that emit a warning. | 01:39 |
| poolie | (though that is somewhat of a quibble because obviously we could both log it and re-raise) | 01:39 |
| poolie | right | 01:39 |
| spiv | I should have mentioned that idea in the patch (similarly we could do that in needs_write_lock) | 01:39 |
| spiv | So this requires a time machine, but how soon might we require Python 2.5? | 01:40 |
| spiv | If hypothetically it were tomorrow, then the decision I think would be easy: just start using with blocks. | 01:40 |
| poolie | sure | 01:41 |
| poolie | i don't think we should hold our breath | 01:41 |
| poolie | by making decisions in the hope of switching soon | 01:41 |
| poolie | because as was pointed out there, some distros are very slow | 01:41 |
| jonoxer | Is there are "bzr-noobs" channel I can ask user questions on? I don't want to hassle everyone here with my stupidity | 01:42 |
| poolie | hello jon! | 01:42 |
| poolie | you're welcome here | 01:42 |
| jonoxer | hey poolie! | 01:42 |
| spiv | jonoxer: this is it. I just hope noobs don't feel hassled by developers debating patches :) | 01:42 |
| poolie | spiv, so what would your __exit__ clause do if it hit an exception in unlocking? | 01:42 |
| poolie | allow it up, but only if there was no previous exception? | 01:43 |
| spiv | file:///usr/share/doc/python2.5/html/lib/typecontextmanager.html (assuming you have python2.5-doc installed) | 01:43 |
| spiv | If __exit__ blocks don't return a true value, then they propagate an error from within the block. | 01:44 |
| spiv | Er, s/__exit__ blocks/__exit__ functions/ | 01:44 |
| poolie | yes, i see | 01:45 |
| poolie | so you'd have something like this? | 01:45 |
| poolie | try: unlock() except e: if orig_exc_type: return False; else: raise | 01:45 |
| spiv | Well, just simply "try: unlock(); finally: return False" would be fine. | 01:46 |
| spiv | At least, AIUI. I haven't tried it out yet :) | 01:46 |
| poolie | really? | 01:46 |
| poolie | surely that will always hide the unlock execption? | 01:47 |
| poolie | in other words (ok, fail) -> ok | 01:47 |
| spiv | The __exit__ function receives the live exception as arguments (or three Nones if there is no exception from within the block). | 01:47 |
| spiv | Hmm, that's true. | 01:47 |
| spiv | So, your way is right :) | 01:47 |
| poolie | lol | 01:47 |
| spiv | Good thing I'd write tests... ;) | 01:48 |
| poolie | so, we're all set? ;-) | 01:49 |
| spiv | If we were using 2.5, sure :) | 01:49 |
| poolie | so basically, i don't want to put extra work on the callers unless we actually care about seeing exceptions from unlock | 01:50 |
| poolie | i'm not sure that we do | 01:50 |
| spiv | Any exceptions at all? | 01:50 |
| poolie | aside from systemerror | 01:51 |
| spiv | Also, it just occurred to me, it's harder to write a test for a negative. i.e. how do you write a per-branch test that "br.unlock() never raises"? | 01:51 |
| poolie | well, you can't, any more than you can write a test for 'foo always does the right thing' | 01:52 |
| poolie | however, you can test appropriate representative cases | 01:52 |
| poolie | so... | 01:55 |
| poolie | in practice i think we'd have a version that does raise exceptions, and we could test that | 01:56 |
| spiv | Suppressing errors still makes me nervous. How about this: unlock tries not to raise, but if it catches a non-internal error, warns the user | 01:56 |
| poolie | right | 01:56 |
| spiv | (And if it catches an internal error, maybe .bzr.log it) | 01:56 |
| poolie | or even warn in either case | 01:56 |
| spiv | At least that way if it goes wrong, we'll know why :) | 01:56 |
| poolie | i guess i just feel like doing otherwise is getting too twisted up about an error for which we can't do anything | 01:57 |
| poolie | there is another drawback though, which is that often people will get these warnings in addition to another error | 01:57 |
| spiv | Well, I don't think "Connection lost\nWarning: TooManyConcurrentRequests" is helpful for a user. | 01:57 |
| poolie | but that's probably reasonable, because it will tell them that the thing was not locked | 01:57 |
| poolie | no, but if it was | 01:57 |
| poolie | "Connection lost\nCould not unlock <.........>: smart medium already in use" | 01:58 |
| poolie | maybe that's more plausible | 01:58 |
| spiv | But then I find myself thinking "but if it's internal, and there isn't another exception, the user should know about it", i.e. I keep wanting it my way :) | 01:58 |
| spiv | Maybe I can break that habit ;) | 01:58 |
| poolie | should know about it in a stronger way than getting a warning? | 01:59 |
| spiv | A "Could not unlock: $reason" message seems ok, although it's still a bit poor UI-wise to spray internal details to the user. | 01:59 |
| spiv | Right, that's where my mind was taking me before I realised we'd been down that path already ;) | 02:00 |
| poolie | so, we can choose to show more or less details as appropriate | 02:01 |
| spiv | Ideally we'd tell the user "Could not unlock: connection was lost", I think. | 02:02 |
| poolie | i guess the main difference is that in the (fail, fail) case, your approach would show just the original message, and mine would show both | 02:02 |
| poolie | actually no, because i think we agreed earlier that it should log the exception too | 02:02 |
| spiv | Right. | 02:02 |
| poolie | and i think it is desirable not to ever hide them completely | 02:02 |
| poolie | so it's just a matter of making them reasonably presentable | 02:03 |
| spiv | The only significant difference is in the (ok, fail) case. Exception vs. warn-without-interrupting. | 02:03 |
| poolie | right | 02:03 |
| poolie | can you think of any particular case that would make it more clear which is better? | 02:04 |
| spiv | We almost always are just about to finish after an unlock, so the difference is usually minimal. | 02:04 |
| spiv | I wonder if GUIs have a different requirement? | 02:04 |
| poolie | i'm not sure | 02:05 |
| poolie | i think actually they're going to converge on the same behaviour: if an exception occurs during a bzrlib call, log it, but don't stop | 02:05 |
| spiv | Would LockBroken still be raised if the lock was broken from under us? | 02:05 |
| * spiv thinks about what bazaar.launchpad.net needs | 02:06 | |
| jml | bzr processes that take up a third as much memory :) | 02:08 |
| poolie | spiv, LockBroken is a good question but it makes me think that actually the higher-level code should be validating the lock earlier | 02:08 |
| poolie | eg before switching the names file | 02:08 |
| jonoxer | OK, time for my noob question. Scenario: migrating a team of devs from SVN to BZR. We have several existing SVN repos of varying sizes. I'm doing trials with a small repo while I figure this out. bzr-svn is installed. For simplicity we'll probably move to a central repo model on bzr so the workflow stays almost the same | 02:08 |
| spiv | I don't think that's right. | 02:09 |
| poolie | an exception indicating something bad happened in the paste is not much better than a warning... | 02:09 |
| poolie | jonoxer: ok | 02:09 |
| spiv | For SFTP, that would involve lots of round trips. I think it's reasonable to be optimistic that evil hasn't happened. | 02:09 |
| jonoxer | So far I've tried a couple of different things to see what happens... | 02:09 |
| poolie | (this is kind of a digression but surely it would just take one round trip, to read the lock info file?) | 02:10 |
| poolie | anyhow, yes, i think it's reasonable to be optimistic | 02:10 |
| poolie | launchpad is an interesting case too | 02:10 |
| spiv | It does, but you're proposing doing it several times, rather than just once when releasing the lock? | 02:10 |
| poolie | as is the smart server; what should it do if unlocking fails | 02:10 |
| poolie | am i? | 02:11 |
| spiv | Well, I don't know what you mean by "should be validating the lock earlier eg before switching the names files" then. | 02:11 |
| poolie | i guess my point was, if we want to avoid evil, it's better to check for it at the point where it'll actually help us avoid it | 02:11 |
| poolie | i was assuming that we rename the names file just once, at the end of the write group | 02:12 |
| spiv | Because at the moment over vfs transports we do do that one round trip at lock release time already, but it sounds like you're saying we should be doing something else? | 02:12 |
| spiv | If someone breaks a lock from under an active client, there's not much we can do to stop bad things happening. We can at least notice that it happened and let the user know, and that's what we're doing atm. I'm not sure there's real benefit to doing anything more, but then I'm unclear on what you're suggesting :) | 02:14 |
| poolie | i think the current behaviour is fine | 02:14 |
| jonoxer | 1. Branching off an SVN repo (using "bzr branch file:///home/subversion/repositories/test testbzr"), which gives me a local working copy. That seems fine | 02:15 |
| jonoxer | But what I need to do is create a shared repo, so... | 02:15 |
| poolie | spiv, i'm saying that if the point of it is to say "something bad happened in the past" then a warning may be enough | 02:16 |
| spiv | Ok. | 02:16 |
| poolie | on the other hand if we're trying to actively detect the lock being stolen and change the client's behaviour to cope, then it'd have to be checking it earlier than unlock time - but this is probably in vain, because it could be stolen at any time | 02:16 |
| spiv | Right. | 02:17 |
| poolie | jml, btw are you coming here for lunch? | 02:17 |
| jonoxer | 2. My reading (maybe wrong) of the guide at http://bazaar-vcs.org/SharedRepositoryTutorial is that I need to init a repo, then branch into it, so I tried this: | 02:18 |
| spiv | jonoxer: "bzr init-repo --rich-root-pack testrepo", then use "testrepo/testbzr" rather than "testbzr" as the destination. | 02:18 |
| jml | poolie: sure. was just waiting for your reply on #canonical :P | 02:18 |
| === Spazpaimon is now known as Spaz | ||
| spiv | jonoxer: the --rich-root-pack is necessary because bzr-svn requires a non-default format. | 02:19 |
| jonoxer | spiv: aha, thanks, trying that now | 02:19 |
| jonoxer | aha, seems to be good so far, thanks spiv! I'd tried "--dirstate-with-subtree" and "--subversion" (which I'd come across in some docs) but not --rich-root-pack | 02:21 |
| spiv | poolie: I think I'm ok with making unlock try not to raise. | 02:21 |
| poolie | spiv, anyhow, that's what i think, let's not spin on it | 02:21 |
| spiv | poolie: but... | 02:21 |
| spiv | poolie: what about fixing this bug for 1.8? :) | 02:21 |
| poolie | hm | 02:22 |
| poolie | so 1.8rc1 is already out, 1.8final is meant to be monday | 02:22 |
| poolie | do you think this should be merged across? | 02:22 |
| spiv | I think we should merge the initial patch I proposed as-is for 1.8. | 02:22 |
| poolie | which bug exactly? | 02:22 |
| spiv | https://bugs.edge.launchpad.net/bzr/+bug/230902 | 02:23 |
| poolie | 230902 | 02:23 |
| ubottu | Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] | 02:23 |
| jonoxer | OK, so now I need to make a branch from the repo, but a simple "branch" command fails ("ERROR: Not a branch...") | 02:23 |
| spiv | jonoxer: you branch branches, not repos. | 02:23 |
| poolie | ok, so this is more than just cosmetic | 02:23 |
| poolie | spiv, that's ok with me for 1.8 | 02:23 |
| spiv | Right. It'll still fail, but at least we'll know the real reason why :) | 02:23 |
| spiv | poolie: thanks | 02:23 |
| jonoxer | spiv: cool, so what is the equivalent to SVN's "checkout"? That seems synonymous with "branch" in bzr parlance | 02:24 |
| spiv | jonoxer: you also checkout branches (not repos). Let's see if I can find a good glossary for our terminology... | 02:24 |
| spiv | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts | 02:25 |
| jml | spiv, poolie: did you see the bug I filed yesterday about unlocking? | 02:25 |
| spiv | jml: that rings a bell, but man, that was a whole day ago! | 02:26 |
| jonoxer | spiv: thanks, I think I'm getting closer now. I appreciate the assistance | 02:26 |
| * jml pokes around for a link | 02:26 | |
| jml | https://bugs.edge.launchpad.net/bzr/+bug/280608 | 02:26 |
| ubottu | Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New] | 02:26 |
| spiv | jonoxer: so if you've created a repository "repo", and have branches inside that repo, e.g. "repo/branch1", "repo/branch2", then you can do "bzr branch repo/branch1 DESTINATION". You can't do "bzr branch repo DESTINATION" because there's no branch at "repo". | 02:27 |
| spiv | jonoxer: I'm guessing that's the confusion that caused your "Not a branch" error. | 02:28 |
| spiv | jml: that patch looks highly plausible to me. | 02:29 |
| jml | spiv: it's courtesy of lifeless. | 02:30 |
| spiv | Yeah, I saw. | 02:30 |
| jml | oh good. | 02:30 |
| spiv | I mean, not only does it come from lifeless, it also makes a self-evidently plausible improvement :) | 02:31 |
| jml | spiv: heh | 02:31 |
| jml | so, I'm not going to get around to turning it into a real patch. | 02:31 |
| jml | but it seems related to the discussion you were having earlier. | 02:32 |
| jml | speaking of bugs! | 02:32 |
| poolie | speaking of launchpad deleting leading whitespace sucking | 02:32 |
| jml | https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595 | 02:33 |
| ubottu | Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [Undecided,New] | 02:33 |
| poolie | isn't that particularly ironic for a project written in python? :) | 02:33 |
| jml | poolie: heh, I guess so :) | 02:33 |
| poolie | so that patch does look plausible, and i think it is relevant too | 02:33 |
| poolie | if unlock did not default to raising exceptions, it would tend to be safer when we need to unlock several things | 02:34 |
| spiv | poolie: in fact, the leading whitespace is intact, it's the non-leading whitespace that it's collapsed. | 02:42 |
| spiv | Thus screwing over exactly the most interesting parts of a diff. | 02:42 |
| poolie | trailing the + | 02:42 |
| poolie | that's true | 02:42 |
| jonoxer | spiv: that explanation made a bunch of things click in my head. Looking good so far | 02:47 |
| jonoxer | I now have a repo and a working copy that's branched from a branch in the repo :-) | 02:47 |
| poolie | bug 281051 | 02:48 |
| ubottu | Launchpad bug 281051 in malone "non-leading whitespace should be preserved" [Undecided,New] https://launchpad.net/bugs/281051 | 02:48 |
| jonoxer | spiv: I'm nearly there, problem now is I can't push commits from my local branch back to the repo, so I think I must have stuffed that up somehow | 03:02 |
| jonoxer | I get the "This transport does not update the working tree of..." warning | 03:02 |
| jonoxer | But I thought it was a repo, not a working tree? | 03:03 |
| spiv | jonoxer: you can have a repo, a branch, and a working tree co-located in the one directory. | 03:04 |
| spiv | (or a subset of those) | 03:04 |
| jonoxer | Cool, so I'm pretty sure what I have at that end is just a repo, nothing else, hence the "update working tree" warning | 03:05 |
| jam | poolie: bug #60730 is a bit more colorful about it | 03:05 |
| jonoxer | So what is the procedure for getting my locally committed changes back to the repo? | 03:05 |
| ubottu | Launchpad bug 60730 in malone "Malone breaks patches by messing with whitespace (dup-of: 2627)" [Undecided,New] https://launchpad.net/bugs/60730 | 03:05 |
| ubottu | Launchpad bug 2627 in launchpad-foundations "Bug comment and description whitespacing being munched yet again" [Medium,Confirmed] https://launchpad.net/bugs/2627 | 03:05 |
| poolie | hee hee | 03:06 |
| jam | poolie: also, what about getting accounts on the win32 host | 03:06 |
| jam | jonoxer: I would guess you have more :) but you can run "bzr remove-tree" on the remote end | 03:06 |
| spiv | jonoxer: you get that warning if the branch you're pushing to does have a working tree, and you're pushing over the network. If you don't want a working-tree there, run "bzr remove-tree" on the remote side. | 03:06 |
| poolie | yeah i thought it must have been reported already | 03:07 |
| poolie | jam, i'll send you a password soon | 03:07 |
| jam | poolie: I reported one of my own a while back, which was already marked "dupe" | 03:07 |
| poolie | i was trying to work out ssh | 03:07 |
| jam | as you can see, 2627 means it has been around for a *long* time | 03:07 |
| poolie | i won't go into details but for now you need to use rdesktop | 03:08 |
| jam | poolie: well, I spend 50% of the time on Vista, which has "Remote Desktop" or whatever, so I think I'm okay there | 03:09 |
| poolie | also 'apt-get install rdesktop' | 03:09 |
| jonoxer | spiv: at the other end it shows a directory called "trunk" (which was what I specified as the destination when I grabbed the data from the svn repo) which is odd, because I thought bzr repos kept everything in the '.bzr' dir. But when I do "bzr remove-tree" I get "bzr: ERROR: No working tree to remove" | 03:09 |
| poolie | jam, sent | 03:09 |
| jam | jonoxer: "trunk" is a branch | 03:09 |
| jam | branches also have locations on disk | 03:09 |
| jam | not like svn | 03:09 |
| jam | you need to do "bzr remove-tree trunk" or "cd trunk; bzr remove-tree" | 03:10 |
| jonoxer | jam: groovy, that didn't complain (left the trunk dir there, which I assume is normal), now to test if I can push to the repo | 03:11 |
| spiv | jonoxer: right, that's normal. | 03:12 |
| spiv | jonoxer: it's probably better to think of it as "pushing to the branch" rather than to the repo. Having a repo shared between multiple branches is essentially just an optimisation detail that doesn't affect behaviour. | 03:13 |
| jonoxer | Woot! We have success, local changes pushed OK, then pulled down to a branch in another location. Thanks spiv and jam! | 03:13 |
| spiv | jonoxer: you're welcome | 03:13 |
| jonoxer | spiv: yes, I think a lot of my problem is getting myself out of the SVN mindset | 03:13 |
| jonoxer | I read bzr tutorials and I *think* I get it, then realise I've totally misunderstood the intent behind it because I'm seeing things through SVN-colored glasses | 03:14 |
| spiv | Yeah, it's surprisingly hard to avoid making those sorts of assumptions. | 03:15 |
| jam | poolie: what is the username supposed to be? | 03:24 |
| Mez | is there cruisecontrol functionality available for bzr? | 03:39 |
| Mez | (or the other way round) | 03:39 |
| mwhudson | there's PQM, which might be a little bit the same | 03:40 |
| mwhudson | (i don't know much about cruisecontrol) | 03:40 |
| jonoxer | Speaking of PQM, is there a good howto on it somewhere? My google-foo is weak and I can't find one so far, and https://launchpad.net/bzr-pqm doesn't have much on it | 03:50 |
| AfC | jonoxer: that's question-of-the-day around here. | 03:52 |
| jonoxer | Hey AfC! Good to see you | 03:52 |
| AfC | jonoxer: heya mate :) | 03:53 |
| AfC | jonoxer: ['fraid I can't help you. We don't use PQM] | 03:53 |
| gnomefreak | im unable to break the lock i used "bzr break-lock" i also used "bzr break-lock lp-29094736:///~gnomefreak/iceowl/iceowl-0.x/.bzr/repository/lock" | 03:55 |
| RAOF | jonoxer: I don't think your google-fu is particularly weak; I just think PQM's documentation is particularly weak :) | 03:56 |
| gnomefreak | here is the output of the above commands http://pastebin.mozilla.org/551713 | 03:57 |
| jonoxer | RAOF: I've grabbed the package and looking through the code now to figure out what it does, but the package itself is remarkably documentation-free | 03:57 |
| RAOF | gnomefreak: "bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x" should work | 03:58 |
| RAOF | If it does, it's probably worth filing a bug that the URL that error suggests you use is stupid and wrong. | 03:59 |
| Mez | lp-29094736 ??? | 04:00 |
| gnomefreak | RAOF: thanks that worked. im not6 getting why its given me a lp-#### | 04:01 |
| gnomefreak | will file bug as soon as i get done with everything that i started | 04:02 |
| gnomefreak | file it under package bzr? | 04:06 |
| RAOF | Yeah, that's probably the best place. | 04:08 |
| RAOF | At least to start. | 04:08 |
| gnomefreak | ok thanks | 04:09 |
| mwhudson | gnomefreak: there is already a bug that the suggested url is stupid and wrong | 04:18 |
| mwhudson | https://bugs.edge.launchpad.net/bzr/+bug/250451 | 04:18 |
| ubottu | Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed] | 04:18 |
| gnomefreak | mwhudson: thanks i was reading that | 04:24 |
| poolie | sminnee: if you're still around, apparently there is another branch that's better for using nested branches | 04:36 |
| poolie | and that is | 04:36 |
| poolie | https://code.edge.launchpad.net/~larstiq/bzr/nested-trees | 04:36 |
| sminnee | thanks poolie | 04:37 |
| sminnee | out of interest, how have you found launchpad? | 04:37 |
| poolie | i just type in 'launchpad.net' and there it is :-) badabing | 04:38 |
| sminnee | *groan* | 04:38 |
| poolie | actually i think it's quite nice in many ways, though i've also got about 200 bugs i'd like fixed | 04:39 |
| gnomefreak | is there a different way to push to branches outside of bzr push lp:~gnomefreak/iceowl/iceowl-0.x | 04:45 |
| poolie | gnomefreak: which part do you want to do differently? | 04:45 |
| gnomefreak | poolie: the whole command | 04:45 |
| sminnee | poolie: this is a total noob question, but how do I download and install that version of bzr? :) | 04:46 |
| gnomefreak | that command is hanging | 04:46 |
| fullermd | Well, you could add an alias so you could "bzr gently-suggest" instead... | 04:46 |
| poolie | gnomefreak: did it say it's waiting for a lock or anything? | 04:46 |
| gnomefreak | no | 04:46 |
| poolie | sminnee: there should be a 'bzr branch' command on that page; run it, and then follow the INSTALL instructions in the resulting directory | 04:47 |
| gnomefreak | give me a minute | 04:47 |
| gnomefreak | poolie: http://pastebin.mozilla.org/551726 that is all and its benn running close to 30 minutes | 04:47 |
| poolie | gnomefreak: ah that would be why it's so slow | 04:47 |
| mwhudson | iceowl == unbranded thunderbird? | 04:48 |
| gnomefreak | mwhudson: sunbird | 04:48 |
| poolie | try running 'bzr upgrade sftp://gnomefreak@bazaar.launchpad.net/%7Egnomefreak/iceowl/iceowl-0.x' | 04:48 |
| mwhudson | oh ok | 04:48 |
| mwhudson | that's not likely to be so big i guess | 04:48 |
| poolie | or ask mwhudson to fix it on the server | 04:48 |
| poolie | mwhudson, jml, we should seriously do something about this ^^ | 04:48 |
| mwhudson | poolie: do some kind of mass upgrade to packs? | 04:49 |
| poolie | i think so | 04:49 |
| mwhudson | my kneejerk reaction says "no" | 04:49 |
| mwhudson | but i'm willing to be influenced | 04:49 |
| jml | poolie: so, we'd very much like to allow users to ask us to do a server-side upgrade. | 04:49 |
| gnomefreak | iceowl branch is big but never taken this long before. im waiting for lock to break | 04:49 |
| mwhudson | what we really do want to do is have a button that says "upgrade this branch" | 04:50 |
| poolie | right | 04:50 |
| jml | poolie: we've got a plan for this, but it's pending some db discussions | 04:50 |
| poolie | :/ | 04:50 |
| RAOF | I even filed a bug that proposed exactly that, so you can get your fill of bugfixing karma at the same time! | 04:50 |
| gnomefreak | poolie: what does this command do outside of bzr upgrade (already had done this | 04:51 |
| gnomefreak | )* | 04:51 |
| poolie | which command? | 04:52 |
| gnomefreak | bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x | 04:52 |
| mwhudson | rocky: if i wanted karma, i'd actually _use_ blueprints | 04:52 |
| poolie | it breaks the lock held by the previous process | 04:52 |
| mwhudson | RAOF: ^^ | 04:52 |
| poolie | you should kill the process on your laptop if it's not already | 04:52 |
| gnomefreak | i had screwed up my branch thats why i was trying to overwrite it | 04:52 |
| RAOF | mwhudson: :P | 04:53 |
| poolie | mwhudson/jml, is there any chance we could do these one-by-one on request? | 04:53 |
| poolie | gnomefreak: then it's probably easier to just delete the branch, | 04:53 |
| poolie | upgrade your local copy, and then push | 04:53 |
| poolie | that'll actually be faster | 04:53 |
| gnomefreak | ok try that | 04:53 |
| poolie | switch machines, biab | 04:53 |
| mwhudson | poolie: sure, i can run "bzr upgade lp:whatever" on devpad | 04:53 |
| gnomefreak | there really is something wrong and im getting tired | 05:03 |
| gnomefreak | even got trace back | 05:03 |
| gnomefreak | poolie: traceback | 05:03 |
| poolie | that's no good | 05:04 |
| gnomefreak | im gonna run outside for smoke here is the output http://pastebin.mozilla.org/551729 | 05:04 |
| spiv | gnomefreak: you need to run "bzr launchpad-login gnomefreak" first | 05:05 |
| poolie | spiv, would that really give a timeout? | 05:06 |
| spiv | Oh, hmm. | 05:06 |
| spiv | In that case, don't know :) | 05:06 |
| poolie | it looks to me like a transient timeotu | 05:06 |
| spiv | Hmm, that's probably the first network request that "bzr push lp:..." does. | 05:07 |
| spiv | It *might* be an issue with connecting to the HTTPS port? | 05:09 |
| spiv | Actually, why does the launchpad plugin need to connect to Launchpad to resolve "lp:~x/y/z"? | 05:10 |
| gnomefreak | should i try after login? | 05:11 |
| beuno | spiv, I think to check for permissions | 05:12 |
| gnomefreak | starting off same way | 05:12 |
| gnomefreak | ah it did work | 05:12 |
| gnomefreak | well ill check when its done | 05:12 |
| poolie | i'd just retry it and see if it gets the same thing, i think it's transient | 05:13 |
| gnomefreak | im getting the progress bar | 05:13 |
| spiv | beuno: hmm, surely the way to do that is to just try using it? :) | 05:15 |
| beuno | spiv, I'm sure there's a reason somewhere. Also, it's a wild guess based off things I read on IRC, so take with a grain of salt | 05:17 |
| beuno | and, it's 1am | 05:17 |
| spiv | beuno: go to sleep :) | 05:17 |
| beuno | you're a wise man | 05:17 |
| beuno | good night spiv | 05:17 |
| beuno | have a nice weekend! | 05:17 |
| mwhudson | spiv: because the client makes very few assumptions about the structure of urls | 05:19 |
| mwhudson | which is a good thing i guess *cough*source package branches* cough | 05:19 |
| gnomefreak | is there a way to login automagickly? | 05:19 |
| spiv | gnomefreak: you only need to run "bzr launchpad-login" once, then the userid is saved in your ~/.bazaar config. | 05:22 |
| poolie | night beuno | 05:22 |
| spiv | gnomefreak: or do you mean an SSH passphrase, or something like that? | 05:22 |
| gnomefreak | spiv: oh ok thanks | 05:22 |
| gnomefreak | spiv: no just the login command itself | 05:22 |
| gnomefreak | bzr launchpad-login gnomefreak | 05:23 |
| spiv | Ah right. Yeah. That only needs to be done once (and I believe current versions of bzr will warn you if don't have it set but need it set) | 05:23 |
| gnomefreak | good night its getting late | 05:23 |
| spiv | gnomefreak: good night | 05:23 |
| gnomefreak | thanks for the help everyone | 05:24 |
| abentley | lifeless: One way I could update my patch is to replace create_by_entry with something that uses the Tree API instead. Would that work for you? | 05:26 |
| lifeless | abentley: it likely would; I can't really say without seeing, but yes, looking at create_by_entry it just wants kind and file_id | 05:38 |
| lifeless | abentley: that sounds like a good idea to me | 05:38 |
| lifeless | abentley: I'm guessing my concerns made sense? | 05:39 |
| abentley | lifeless: cool. | 05:39 |
| abentley | lifeless: You raised some good points. I don't want to add an Inventory to PreviewTree, and changing it this way actually does get us further away from inventories. | 05:41 |
| abentley | In a meaningful way. | 05:41 |
| lifeless | excellent | 05:41 |
| jonoxer | Time for my next noob question. I now have a repo working, but I'm not sure of the best way to share it so multiple devs can pull/push to it. What's the current accepted wisdom? Using bzr+ssh requires them to have shell on the repo host, AFAIK, so maybe using the built-in smart server? We've been using webdav with SVN up until now | 06:34 |
| spiv | jonoxer: bzr+ssh is the usual approach | 06:36 |
| spiv | jonoxer: it's possible to use one system account with multiple SSH keys associated with it, I think | 06:37 |
| jonoxer | spiv: the host has LDAP and all devs have shell at the moment, but I'm guessing I'll have privilege problems on the repo itself | 06:38 |
| spiv | jonoxer: you can restrict SSH to only allow the user(s) to run bzr, i.e. disallow shells. | 06:38 |
| spiv | Make the repo group-owned (sticky) and group-writeable. | 06:38 |
| jonoxer | I just did a test as a different user and even with group write privs I got an access denied error. Playing with it now | 06:38 |
| jonoxer | Aha, I think I've found the problem, it was LDAP auto user creation not behaving how I expected so the user didn't have the privileges I thought it did- | 06:42 |
| jonoxer | I'm getting a traceback from bzr when trying to push as a different user. I've checked that the user I'm doing it as has write privs (I can SSH in, touch a file and remove it from inside the repo, and it works) but bzr dies each time | 06:53 |
| jonoxer | After the failure I do break-locks which reports that a lock has been created (and breaks it successfully) but pushing still fails with a traceback | 06:53 |
| spiv | jonoxer: pastebin the traceback? | 06:54 |
| jonoxer | spiv: yep, in a moment, just trying one or two more things now | 06:55 |
| jonoxer | I can still push as the original user (after breaking locks of the second user) | 06:55 |
| jonoxer | spiv: http://pastebin.com/d4a3e305e | 06:56 |
| spiv | Argh, ok, one of those. | 06:57 |
| spiv | I think that happens to be the one I'm about to land a fix for for 1.8 | 06:57 |
| spiv | Yep, almost certainly it is. | 06:57 |
| jonoxer | Aha, so I'm probably not doing anything specifically wrong? Any workarounds, or maybe I should try using the bzr server instead of bzr+ssh? | 06:58 |
| spiv | jonoxer: an error is occuring somewhere, but that triggers a secondary error which obscures the original error and triggers the traceback | 06:58 |
| spiv | jonoxer: the patch on https://bugs.edge.launchpad.net/bzr/+bug/230902 will fix the secondary error, and let the real error show. | 06:59 |
| ubottu | Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] | 06:59 |
| jonoxer | OK, so I probably still have something wrong but we can't tell what from the trace | 06:59 |
| spiv | The "ValueError: I/O operation on closed file" is an interesting clue, though. | 07:00 |
| spiv | Is there a ~/.bzr.log on the server-side? Does it have a traceback? | 07:00 |
| jonoxer | I'll see | 07:00 |
| spiv | I'm wonderinf if that short traceback at the top of your paste might have happened on the server side. | 07:01 |
| jonoxer | Yes, there are logs for both the first and second users | 07:01 |
| jonoxer | Trying again while tailing the log... | 07:02 |
| jonoxer | Got the entry while doing a failed push. Doesn't say much though | 07:02 |
| jonoxer | Just this: http://pastebin.com/d4e6272d8 | 07:03 |
| spiv | Double-check the permissions inside the remote .bzr directory and subdirectories? | 07:04 |
| vila | hi all | 07:05 |
| spiv | Googling suggests that others have seen this error when the permissions are somehow wrong inside the .bzr/repository/ directory on the server. | 07:05 |
| spiv | Another thing to debug this would be adding "-Dhpss" to the command line of the client, and the looking at the ~/.bzr.log to see where exactly in the network conversation it fails. | 07:06 |
| jonoxer | I've gone through the permissions fairly carefully, I think they're correct (not ruling it out though). I'll try -Dhpss now | 07:09 |
| spiv | I'd expect that if the permissions were wrong, it'd be fairly obvious (e.g. a file inside .bzr/repository/... owned and only readable by one user) | 07:11 |
| spiv | You're welcome to pastebin the ~/.bzr.log with the -Dhpss info in it. | 07:12 |
| jonoxer | The log looks normal until it gets to repo/.bzr/repository/pack-names, then does the traceback, checking now | 07:12 |
| jonoxer | I don't get it, the permissions on that file are fine for that user. I'll paste the log | 07:13 |
| jonoxer | spiv: http://pastebin.com/d249d52ee | 07:14 |
| spiv | jonoxer: hmm | 07:14 |
| spiv | jonoxer: the weird thing is that that log doesn't show that the client got a reply to its 'put' of the pack-names file. Which suggests that the *server* is breaking the connection, rather than merely returning an error. In which case I'd expect something to appear in the ~/.bzr.log on the server-side :/ | 07:17 |
| spiv | jonoxer: try over sftp:// instead of bzr+ssh:// ? | 07:17 |
| * spiv hopes jonoxer's IRC client reconnects... | 07:17 | |
| spiv | Ah, welcome back. | 07:17 |
| jonoxer | oops, back, sorry spiv | 07:17 |
| spiv | jonoxer: the weird thing is that that log doesn't show that the client got a reply to its 'put' of the pack-names file. Which suggests that the *server* is breaking the connection, rather than merely returning an error. In which case I'd expect something to appear in the ~/.bzr.log on the server-side :/ | 07:17 |
| spiv | jonoxer: try over sftp:// instead of bzr+ssh:// ? | 07:17 |
| jonoxer | spiv: tried sftp and got a more helpful error, it says "Generic path error: 'cjhuxwva3sro9dvdasy9.fetch': Failure: unable to rename to '../packs/f6cafb9b2fdb7d84f652ef20be2694e1.pack'" | 07:19 |
| jonoxer | which looks like permissions, as you say | 07:19 |
| spiv | It does indeed! | 07:20 |
| jonoxer | I'm probably only a step or two away from having this working but unfortunately I've gotta run. I'll have to pick it up again later, thanks for all your help Spiv, I appreciate it | 07:20 |
| spiv | Unless you have a wacky filesystem that doesn't support POSIX semantics for renaming files ? | 07:21 |
| spiv | jonoxer: Ok. Have a good weekend. I'll be around on Monday if inspiration doesn't strike :) | 07:21 |
| jonoxer | Ext3, so should be OK | 07:21 |
| spiv | Yeah, ext3 should be more than ok :) | 07:22 |
| jonoxer | I still have a feeling it's related to the way LDAP is dishing out the group to that user on login, so I'll try working through the auth logs etc as well and see if anything weird is going on. I'll also try creating a local user manually (avoid LDAP altogether) and see if that helps | 07:22 |
| jonoxer | Bye! | 07:24 |
| chmac | I ran something like `cd ~/bonkers/; bzr init; bzr add blah/; bzr ci -m "1"` | 07:44 |
| chmac | Now I've realised all my code is within blah/ and I'd like to do something like this | 07:45 |
| chmac | mv ~/bonkers/blah ~/blah | 07:45 |
| chmac | However, that will break the bzr repo as the ~/bonkers/.bzr/ directory will no longer be in the right place | 07:45 |
| chmac | Is there an alternative? | 07:45 |
| chmac | In svn each directory is self contained, so I can just ignore the parent dir, but not in bzr | 07:47 |
| chmac | Ok, this kinda worked `cd ~/bonkers; bzr mv blah/* ./; bzr ci -m "Move"; bzr rm blah/; bzr ci -m "Tidy"` | 07:52 |
| bob2 | kinda? | 07:56 |
| * spiv heads off | 08:29 | |
| === jamesh_ is now known as jamesh | ||
| EarthLion | hey can you put a limit on bzr log so you just see the last x amount | 12:06 |
| james_w | EarthLion: either --limit | 12:06 |
| james_w | or "-r -100.." or similar | 12:07 |
| EarthLion | thanks a lot | 12:07 |
| EarthLion | also is i want to do a bzr diff -r 100 but i just want to see a list of files that have changed (like when you do bzr status) instead of a readout of the changes | 12:09 |
| EarthLion | is that possible? | 12:09 |
| james_w | EarthLion: -v | 12:11 |
| james_w | EarthLion: you might want to look at "bzr help log" to see what else is available | 12:11 |
| EarthLion | ok thanks | 12:14 |
| EarthLion | makes those two commands make things a lot easiar :) | 12:14 |
| === Guest52963 is now known as jelmer | ||
| lakshmanan | hey.. i am using launchpad and i am using "staging" section of launchpad(staging.launchpad.net) to learn about launchpad.... i am not able to push my branch to my project's trunk branch.. please help | 14:54 |
| beuno | lakshmanan, what seems to be the problem? | 14:56 |
| lakshmanan | beuno, hey.. thanks for the response... i used this command bzr push lp://staging/schoolmanagement to push my changes to my sample project's trunk branch... but it says this error ..bzr: ERROR: Transport operation not possible: http does not support mkdir() now what should i do | 14:58 |
| beuno | lakshmanan, you need to specify your Launchpad username first with: bzr launchpad-login <username> | 14:59 |
| lakshmanan | but that was the url given in that branch's launchpad page | 14:59 |
| beuno | lakshmanan, the url is correct | 15:00 |
| lakshmanan | beuno, can you gimme the full command i must give to push my changes | 15:00 |
| beuno | you just need to be logged in to push to launchpad | 15:00 |
| lakshmanan | i am logged in | 15:00 |
| beuno | bzr launchpad-login your_launchpad_username | 15:01 |
| beuno | lakshmanan, ^ | 15:01 |
| beuno | you just need to do that once | 15:02 |
| lakshmanan | beuno, oh you mean i must login to launchpad via terminal... am i right? | 15:02 |
| beuno | lakshmanan, yes. bzr needs to know your launchpad username | 15:03 |
| lakshmanan | beuno, thanks,it works but it says... ERROR: Target directory lp://staging/schoolmanagement already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway ... but it worked. thanks...i dont understand how this thing(.bzr directory does not exists) works.... can u explain | 15:08 |
| beuno | lakshmanan, ah, right, that's a one-time error as well, because of you trying to push before | 15:08 |
| beuno | just add the --use-existing-dir flag once to the push command | 15:08 |
| beuno | and from now on, everything will go smoothly | 15:09 |
| lakshmanan | i did... it worked.. thanks | 15:09 |
| beuno | :) | 15:12 |
| strk | a 'branch ' is been running for over 2 hours, I don't see much processor, memory or network activity. bzr log doesn't give any sign either | 15:31 |
| strk | last time I killed the process the repository (on-line, shared) got corrupted. | 15:31 |
| strk | what do I do ? :> | 15:32 |
| beuno | strk, you're pushing or branching? | 15:34 |
| strk | branching | 15:38 |
| beuno | is the branch big? | 15:40 |
| beuno | 2 houts sounds too much | 15:40 |
| beuno | *hours | 15:40 |
| strk | yes, it's big | 15:44 |
| strk | last two lines from .bzr.log are: | 15:44 |
| strk | 2965.718 http readv of e74eb7f199645e105baf57aca1ee3638.pack offsets => 119 collapsed 6 | 15:44 |
| strk | 3013.203 http readv of 2c779c251220f8afce08bcec69277e32.pack offsets => 34285 collapsed 308 | 15:44 |
| strk | that's how much 50 minutes ? | 15:44 |
| jdo | anyway to undo a bzr clean-tree? | 17:02 |
| jdo | :-) | 17:02 |
| strk | I killed it, starting from scratch using sftp (it was http) | 17:12 |
| strk | now, I'll try to branch from a collegue machine on this lan, any help is appreciated with this experiment | 17:13 |
| === abentley1 is now known as abentley | ||
| Odd_Bloke | jdo: I'm not aware of one, I'm afraid. | 18:17 |
| jelmer | hmm, apparently there exists a funny VSS -> Subversion gateway | 18:37 |
| jelmer | and it does all kinds of funny things | 18:37 |
| jelmer | Microsoft's CodePlex site is running it | 18:37 |
| === BasicPRO is now known as BasicOSX | ||
| === ja1 is now known as jam | ||
| flacoste | what should I make of: | 19:32 |
| flacoste | bzr: ERROR: KnitPackRepository('file:///home/francis/canonical/windmill/.bzr/repository/') | 19:32 |
| flacoste | is not compatible with | 19:32 |
| flacoste | RemoteRepository(bzr+ssh://flacoste@bazaar.launchpad.net/%7Elaunchpad-pqm/windmill/trunk/.bzr/) | 19:32 |
| flacoste | different rich-root support | 19:32 |
| flacoste | ok, i think this is because i'm trying to branch a bzr svn branch into --1.6 format repository | 19:35 |
| flacoste | or just into a repository? | 19:35 |
| LarstiQ | flacoste: right, bzr-svn uses a rich root format, which is not the default | 19:39 |
| flacoste | can I make a shared repository that can be used by bzr-svn branches? | 20:25 |
| flacoste | init-repo --subversion i guess | 20:25 |
| flacoste | oh | 20:25 |
| flacoste | --1.6.1-rich-root | 20:25 |
| flacoste | that might also work | 20:26 |
| t3tech | Is there user documentation for the Eclipse plugin somewhere that I'm not finding? | 20:42 |
| beuno | t3tech, all I know of is: http://bazaar-vcs.org/BzrEclipse | 20:44 |
| beuno | but Verterok|out is the one to ask, unfortunetely he's off on vacation | 20:44 |
| t3tech | beuno: yeah that's I've been able to find. | 20:44 |
| beuno | t3tech, I suspect there's not help or tutorial for it | 20:46 |
| beuno | s/not/no | 20:46 |
| t3tech | I'm trying to figure out if there is some way to use it with an existing eclipse project that I'm just starting to use bzr on or if I need to create a new eclipse project .... etc. | 20:47 |
| beuno | maybe awilkins knows? | 20:49 |
| t3tech | well I just found this - https://answers.launchpad.net/bzr-eclipse/+question/25148 which basically says use richt click --> Team --> Share Project but that option is greyed out for me. Hmm | 20:59 |
| t3tech | Think I've figured it out... was right clicking in the wrong place. doh! | 21:20 |
| AmanicA | :) | 21:37 |
| nevans | just had a race condition error with bzr-svn: while I was in the middle of pushing three revisions, another developer committed a revision of their own. now "bzr pull" won't pull their revision down. :( | 21:41 |
| jelmer | nevans, hi | 22:21 |
| jelmer | nevans, can you perhaps pastebin the "svn log -v" output of the svn repository somewhere? | 22:22 |
| nevans | jelmer: yeah | 22:22 |
| nevans | I made a bugreport on lp, too | 22:22 |
| nevans | https://bugs.launchpad.net/bzr-svn/+bug/281460 | 22:22 |
| ubottu | Launchpad bug 281460 in bzr-svn "race condition when pushing to svn repo" [Undecided,New] | 22:22 |
| nevans | jelmer, do you want me to get svn log -v for the entire repo, or just that branch? also... how far back do you want the revision history? | 22:23 |
| nevans | it's got ~15549 revisions in just that branch. :) | 22:24 |
| jelmer | nevans, the entire repo - just the first 100 or so should do | 22:24 |
| nevans | I tried to run "bzr log -vr 15544" (the missing revision) from within the svn working copy... now bzr is busy "generating file id map 1455/15543" | 22:25 |
| jelmer | nevans, I mean svn log rather than bzr log | 22:26 |
| nevans | yeah... I'm getting that now. | 22:27 |
| nevans | just thought I'd let you know. :) | 22:27 |
| jelmer | yes, it's correct it'd be determining the file id map first in the case of bzr log | 22:27 |
| nevans | jelmer, I'm going home soon (at work now). Let me know if there's anything else that would be helpful (did you get my private msg with the pastebin URL?) | 22:40 |
| nevans | thanks! | 22:40 |
| jelmer | nevans, yep, thanks | 22:42 |
| nevans | jelmer, just let me know via the lp ticket if you need anything else to debug. | 22:43 |
| beuno | jelmer, hi! | 23:30 |
| beuno | I see you managed to get LH on Debian's NEW queue again :) | 23:30 |
| beuno | any plans to get it into Ubuntu, or are you going to let it trickle down in Jaunty? | 23:30 |
| jelmer | beuno, I'm going to let it pass for Intrepid | 23:52 |
| beuno | jelmer, so maybe we can upload it to bzr's PPA? | 23:53 |
| beuno | :) | 23:53 |
| jelmer | beuno, Sure, I'll leave the actual uploading to other folk though, I don't want to commit to keeping it up to date | 23:54 |
| beuno | jelmer, fair enough, I'll be "people" | 23:54 |
| beuno | thanks for all the work on the package ! | 23:54 |
| jelmer | beuno, you're welcome | 23:55 |
| beuno | I'm off home now | 23:55 |
| jelmer | Thanks for loggerhead (-: | 23:55 |
| beuno | :) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!