jelmermaybe 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
lifelessI"m  blocked on that as I mentioned :(00:24
sminneeHi everyone00:35
sminneeI was wanting to get some information about the current status of nested trees00:36
pooliesminnee: they're partially supported at the moment but still classed as expeirmental00:41
sminneepoolie: it seems as though it's been that way for nearly 2 years?00:41
sminneedo you know what kind of risks there are in using it that make them experimental00:41
sminneeI'm currently on svn and svn:externals are an absolutely critical feature for me.00:42
poolieabentley could probably give you a more accurate answer00:42
pooliei think not all merges work across them correctly00:42
lifelessok, bbiab00:43
sminneepoolie: but if you were keeping your merges restricted to happening within a single subtree, you would be okay?00:43
sminneefor example, i have "projects" and use svn:externals to link the applicable modules into each project00:44
sminneeso if I was branching and merging solely within the context of individual modules, i would be okay?00:44
pooliei think that would work00:45
pooliepossibly we should just promote this to properly supported and deal with anything else that crops up00:46
sminneepoolie: i would vote for that approach :) it's a very useful feature and has been in-development for some time.01:18
sminneeI might have a play with them and complain when they start breaking, then :P01:18
pooliethat'd be good :)01:18
pooliespiv, do you want to talk about the unlock exception handling?01:18
spivpoolie: ok01:19
pooliehere, or on the phone?01:19
spivHere's fine, I think.01:20
spivI'm still pretty uncomfortable about the suggestion to suppress exceptions during unlock.01:21
pooliebtw i did your tweak regarding the default argument - in fact i removed it01:22
poolieso i'm not sure if it's simpler and cleaner, or just too careless01:22
spivIt 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
pooliehowever, unless we can really think of a case where it makes a difference, i think we should do it01:22
pooliethat's one way to look at it01:23
spivSo concretely, doing what I propose is clearly correct, and we know how it will behave.01:23
pooliebut another way is doing this just changes the particular cleanup functions, rather than adding something to every caller01:23
spivAnd hiding exceptions from unlock isn't clearly correct, at least not to me :)01:23
sminneeI 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
pooliei thought it did01:24
poolieif jelmer is still here you could ask him01:24
jelmeryep, I am01:24
pooliespiv, so i'd cast it as01:24
jelmersminnee, What's the error you're getting01:24
sminneejelmer: bzr: ERROR: Invalid http response for http://svn.silverstripe.com/.bzr/branch-format: Unable to handle http code 401: Authorization Required01:25
poolieclarifying the behaviour of unlock to say "if the transport is closed, unlock will not raise an error"01:25
sminneeooh I see - it seems to think it's a bzr repos01:25
spivSo, 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
sminneeI executed ~/bzr/test: bzr svn-import http://svn.silverstripe.com/ repos01:25
jelmersminnee, bzr doesn't support http auth, bug 25661201:25
ubottuLaunchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/25661201:25
jelmersminnee, you can work around it by using svn+http://svn.silverstripe.com/01:25
sminneejelmer: 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
sminneeI 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 data01:26
jelmersminnee, are you using bzr-svn 0.4.13 ?01:27
spivpoolie: Hmm.  I'm not sure that just suppressing/avoiding errors due to the transport being closed will actually fix these bugs.01:27
sminneejelmer: yeah, looks like it. I just downloaded and installed bzr 1.7.101:27
spivpoolie: 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
jelmersminnee, please file a bug01:29
sminneejelmer: sure thing.01:29
poolieand then the knock-on effect is that there's already a request pending, or that there's a write group open?01:29
pooliespiv, so the difference in behaviour between these options (as opposed to in the code)01:30
poolieis just in the case where the unlock fails but there was no earlier failure, right?01:30
spivHmm.  I think so.01:31
spivSo there are four cases, (operation ok, unlock ok), (operation fails, unlock ok), (operation ok, unlock fails), and (operation fails, unlock fails).01:32
spiv(Which co-incidentally is why there are four test methods for my proposed helper :)01:33
pooliein the current trunk code, we get case 4 wrong by showing the unlock exception when we want to show the original exception01:33
spivWe seem to be disagreeing about the (ok, fails) case.01:33
pooliei should say i'll be glad to have this fixed whatever solution we decide on01:34
spivIn (ok, fails) I think I'd rather get the exception immediately.01:34
jelmerhmm, did the API of record_entry_contents() change?01:34
poolie    * ``CommitBuilder.record_entry_contents`` returns one more element in01:35
poolie      its result tuple - an optional file system hash for the hash cache01:35
poolie      to use. (Robert Collins)01:35
poolieif i'd reviewed it i might have asked for a new name for the new protocol....01:36
sminneejelmer: 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
ubottuLaunchpad bug 281035 in bzr "unicode error on import-svn call." [Undecided,New]01:36
pooliespiv, so you said in the patch for http://bundlebuggy.aaronbentley.com/project/bzr/request/<20081008054310.GC19754%40steerpike.home.puzzling.org>01:36
pooliethat you can't distinguish those cases from inside the unlock, which is correct as far as i know01:36
pooliei kind of dislike needing to push the contents of these blocks into separate functions just to wrap them this way01:37
spivSo the advantage of your idea is that unlock doesn't need to distinguish.01:37
poolieyes, it is01:37
pooliewould anyone care?01:38
spivYeah.  I don't much like it either, but I don't think it is actually *bad*, just mildly irritating.01:38
spivAnd in the case of functions like commit, it was probably large enough that it should be broken up somewhat anyway ;)01:38
pooliewith your patch the failure from unlock is totally lost01:38
spivWell, 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
spivI should have mentioned that idea in the patch (similarly we could do that in needs_write_lock)01:39
spivSo this requires a time machine, but how soon might we require Python 2.5?01:40
spivIf hypothetically it were tomorrow, then the decision I think would be easy: just start using with blocks.01:40
pooliei don't think we should hold our breath01:41
poolieby making decisions in the hope of switching soon01:41
pooliebecause as was pointed out there, some distros are very slow01:41
jonoxerIs there are "bzr-noobs" channel I can ask user questions on? I don't want to hassle everyone here with my stupidity01:42
pooliehello jon!01:42
poolieyou're welcome here01:42
jonoxerhey poolie!01:42
spivjonoxer: this is it.  I just hope noobs don't feel hassled by developers debating patches :)01:42
pooliespiv, so what would your __exit__ clause do if it hit an exception in unlocking?01:42
poolieallow it up, but only if there was no previous exception?01:43
spivfile:///usr/share/doc/python2.5/html/lib/typecontextmanager.html (assuming you have python2.5-doc installed)01:43
spivIf __exit__ blocks don't return a true value, then they propagate an error from within the block.01:44
spivEr, s/__exit__ blocks/__exit__ functions/01:44
poolieyes, i see01:45
poolieso you'd have something like this?01:45
poolietry: unlock() except e: if orig_exc_type: return False; else: raise01:45
spivWell, just simply "try: unlock(); finally: return False" would be fine.01:46
spivAt least, AIUI.  I haven't tried it out yet :)01:46
pooliesurely that will always hide the unlock execption?01:47
pooliein other words (ok, fail) -> ok01:47
spivThe __exit__ function receives the live exception as arguments (or three Nones if there is no exception from within the block).01:47
spivHmm, that's true.01:47
spivSo, your way is right :)01:47
spivGood thing I'd write tests... ;)01:48
poolieso, we're all set? ;-)01:49
spivIf we were using 2.5, sure :)01:49
poolieso basically, i don't want to put extra work on the callers unless we actually care about seeing exceptions from unlock01:50
pooliei'm not sure that we do01:50
spivAny exceptions at all?01:50
poolieaside from systemerror01:51
spivAlso, 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
pooliewell, you can't, any more than you can write a test for 'foo always does the right thing'01:52
pooliehowever, you can test appropriate representative cases01:52
pooliein practice i think we'd have a version that does raise exceptions, and we could test that01:56
spivSuppressing errors still makes me nervous.  How about this: unlock tries not to raise, but if it catches a non-internal error, warns the user01:56
spiv(And if it catches an internal error, maybe .bzr.log it)01:56
poolieor even warn in either case01:56
spivAt least that way if it goes wrong, we'll know why :)01:56
pooliei guess i just feel like doing otherwise is getting too twisted up about an error for which we can't do anything01:57
pooliethere is another drawback though, which is that often people will get these warnings in addition to another error01:57
spivWell, I don't think "Connection lost\nWarning: TooManyConcurrentRequests" is helpful for a user.01:57
pooliebut that's probably reasonable, because it will tell them that the thing was not locked01:57
poolieno, but if it was01:57
poolie"Connection lost\nCould not unlock <.........>: smart medium already in use"01:58
pooliemaybe that's more plausible01:58
spivBut 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
spivMaybe I can break that habit ;)01:58
poolieshould know about it in a stronger way than getting a warning?01:59
spivA "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
spivRight, that's where my mind was taking me before I realised we'd been down that path already ;)02:00
poolieso, we can choose to show more or less details as appropriate02:01
spivIdeally we'd tell the user "Could not unlock: connection was lost", I think.02:02
pooliei guess the main difference is that in the (fail, fail) case, your approach would show just the original message, and mine would show both02:02
poolieactually no, because i think we agreed earlier that it should log the exception too02:02
poolieand i think it is desirable not to ever hide them completely02:02
poolieso it's just a matter of making them reasonably presentable02:03
spivThe only significant difference is in the (ok, fail) case.  Exception vs. warn-without-interrupting.02:03
pooliecan you think of any particular case that would make it more clear which is better?02:04
spivWe almost always are just about to finish after an unlock, so the difference is usually minimal.02:04
spivI wonder if GUIs have a different requirement?02:04
pooliei'm not sure02:05
pooliei think actually they're going to converge on the same behaviour: if an exception occurs during a bzrlib call, log it, but don't stop02:05
spivWould LockBroken still be raised if the lock was broken from under us?02:05
* spiv thinks about what bazaar.launchpad.net needs02:06
jmlbzr processes that take up a third as much memory :)02:08
pooliespiv, LockBroken is a good question but it makes me think that actually the higher-level code should be validating the lock earlier02:08
poolieeg before switching the names file02:08
jonoxerOK, 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 same02:08
spivI don't think that's right.02:09
pooliean exception indicating something bad happened in the paste is not much better than a warning...02:09
pooliejonoxer: ok02:09
spivFor SFTP, that would involve lots of round trips.  I think it's reasonable to be optimistic that evil hasn't happened.02:09
jonoxerSo 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
poolieanyhow, yes, i think it's reasonable to be optimistic02:10
poolielaunchpad is an interesting case too02:10
spivIt does, but you're proposing doing it several times, rather than just once when releasing the lock?02:10
poolieas is the smart server; what should it do if unlocking fails02:10
poolieam i?02:11
spivWell, I don't know what you mean by "should be validating the lock earlier eg before switching the names files" then.02:11
pooliei 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 it02:11
pooliei was assuming that we rename the names file just once, at the end of the write group02:12
spivBecause 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
spivIf 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
pooliei think the current behaviour is fine02:14
jonoxer1. Branching off an SVN repo (using "bzr branch file:///home/subversion/repositories/test testbzr"), which gives me a local working copy. That seems fine02:15
jonoxerBut what I need to do is create a shared repo, so...02:15
pooliespiv, i'm saying that if the point of it is to say "something bad happened in the past" then a warning may be enough02:16
poolieon 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 time02:16
pooliejml, btw are you coming here for lunch?02:17
jonoxer2. 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
spivjonoxer: "bzr init-repo --rich-root-pack testrepo", then use "testrepo/testbzr" rather than "testbzr" as the destination.02:18
jmlpoolie: sure. was just waiting for your reply on #canonical :P02:18
=== Spazpaimon is now known as Spaz
spivjonoxer: the --rich-root-pack is necessary because bzr-svn requires a non-default format.02:19
jonoxerspiv: aha, thanks, trying that now02:19
jonoxeraha, 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-pack02:21
spivpoolie: I think I'm ok with making unlock try not to raise.02:21
pooliespiv, anyhow, that's what i think, let's not spin on it02:21
spivpoolie: but...02:21
spivpoolie: what about fixing this bug for 1.8? :)02:21
poolieso 1.8rc1 is already out, 1.8final is meant to be monday02:22
pooliedo you think this should be merged across?02:22
spivI think we should merge the initial patch I proposed as-is for 1.8.02:22
pooliewhich bug exactly?02:22
ubottuLaunchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]02:23
jonoxerOK, so now I need to make a branch from the repo, but a simple "branch" command fails ("ERROR: Not a branch...")02:23
spivjonoxer: you branch branches, not repos.02:23
poolieok, so this is more than just cosmetic02:23
pooliespiv, that's ok with me for 1.802:23
spivRight.  It'll still fail, but at least we'll know the real reason why :)02:23
spivpoolie: thanks02:23
jonoxerspiv: cool, so what is the equivalent to SVN's "checkout"? That seems synonymous with "branch" in bzr parlance02:24
spivjonoxer: you also checkout branches (not repos).  Let's see if I can find a good glossary for our terminology...02:24
jmlspiv, poolie: did you see the bug I filed yesterday about unlocking?02:25
spivjml: that rings a bell, but man, that was a whole day ago!02:26
jonoxerspiv: thanks, I think I'm getting closer now. I appreciate the assistance02:26
* jml pokes around for a link02:26
ubottuLaunchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New]02:26
spivjonoxer: 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
spivjonoxer: I'm guessing that's the confusion that caused your "Not a branch" error.02:28
spivjml: that patch looks highly plausible to me.02:29
jmlspiv: it's courtesy of lifeless.02:30
spivYeah, I saw.02:30
jmloh good.02:30
spivI mean, not only does it come from lifeless, it also makes a self-evidently plausible improvement :)02:31
jmlspiv: heh02:31
jmlso, I'm not going to get around to turning it into a real patch.02:31
jmlbut it seems related to the discussion you were having earlier.02:32
jmlspeaking of bugs!02:32
pooliespeaking of launchpad deleting leading whitespace sucking02:32
ubottuLaunchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [Undecided,New]02:33
poolieisn't that particularly ironic for a project written in python? :)02:33
jmlpoolie: heh, I guess so :)02:33
poolieso that patch does look plausible, and i think it is relevant too02:33
poolieif unlock did not default to raising exceptions, it would tend to be safer when we need to unlock several things02:34
spivpoolie: in fact, the leading whitespace is intact, it's the non-leading whitespace that it's collapsed.02:42
spivThus screwing over exactly the most interesting parts of a diff.02:42
poolietrailing the +02:42
pooliethat's true02:42
jonoxerspiv: that explanation made a bunch of things click in my head. Looking good so far02:47
jonoxerI now have a repo and a working copy that's branched from a branch in the repo    :-)02:47
pooliebug 28105102:48
ubottuLaunchpad bug 281051 in malone "non-leading whitespace should be preserved" [Undecided,New] https://launchpad.net/bugs/28105102:48
jonoxerspiv: 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 somehow03:02
jonoxerI get the "This transport does not update the working tree of..." warning03:02
jonoxerBut I thought it was a repo, not a working tree?03:03
spivjonoxer: 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
jonoxerCool, so I'm pretty sure what I have at that end is just a repo, nothing else, hence the "update working tree" warning03:05
jampoolie: bug #60730  is a bit more colorful about it03:05
jonoxerSo what is the procedure for getting my locally committed changes back to the repo?03:05
ubottuLaunchpad bug 60730 in malone "Malone breaks patches by messing with whitespace (dup-of: 2627)" [Undecided,New] https://launchpad.net/bugs/6073003:05
ubottuLaunchpad bug 2627 in launchpad-foundations "Bug comment and description whitespacing being munched yet again" [Medium,Confirmed] https://launchpad.net/bugs/262703:05
pooliehee hee03:06
jampoolie: also, what about getting accounts on the win32 host03:06
jamjonoxer: I would guess you have more :) but you can run "bzr remove-tree" on the remote end03:06
spivjonoxer: 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
poolieyeah i thought it must have been reported already03:07
pooliejam, i'll send you a password soon03:07
jampoolie: I reported one of my own a while back, which was already marked "dupe"03:07
pooliei was trying to work out ssh03:07
jamas you can see, 2627 means it has been around for a *long* time03:07
pooliei won't go into details but for now you need to use rdesktop03:08
jampoolie: well, I spend 50% of the time on Vista, which has "Remote Desktop" or whatever, so I think I'm okay there03:09
pooliealso 'apt-get install rdesktop'03:09
jonoxerspiv: 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
pooliejam, sent03:09
jamjonoxer: "trunk" is a branch03:09
jambranches also have locations on disk03:09
jamnot like svn03:09
jamyou need to do "bzr remove-tree trunk" or "cd trunk; bzr remove-tree"03:10
jonoxerjam: groovy, that didn't complain (left the trunk dir there, which I assume is normal), now to test if I can push to the repo03:11
spivjonoxer: right, that's normal.03:12
spivjonoxer: 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
jonoxerWoot! We have success, local changes pushed OK, then pulled down to a branch in another location. Thanks spiv and jam!03:13
spivjonoxer: you're welcome03:13
jonoxerspiv: yes, I think a lot of my problem is getting myself out of the SVN mindset03:13
jonoxerI 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 glasses03:14
spivYeah, it's surprisingly hard to avoid making those sorts of assumptions.03:15
jampoolie: what is the username supposed to be?03:24
Mezis there cruisecontrol functionality available for bzr?03:39
Mez(or the other way round)03:39
mwhudsonthere's PQM, which might be a little bit the same03:40
mwhudson(i don't know much about cruisecontrol)03:40
jonoxerSpeaking 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 it03:50
AfCjonoxer: that's question-of-the-day around here.03:52
jonoxerHey AfC! Good to see you03:52
AfCjonoxer: heya mate :)03:53
AfCjonoxer: ['fraid I can't help you. We don't use PQM]03:53
gnomefreakim 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
RAOFjonoxer: I don't think your google-fu is particularly weak; I just think PQM's documentation is particularly weak :)03:56
gnomefreakhere is the output of the above commands http://pastebin.mozilla.org/55171303:57
jonoxerRAOF: I've grabbed the package and looking through the code now to figure out what it does, but the package itself is remarkably documentation-free03:57
RAOFgnomefreak: "bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x" should work03:58
RAOFIf it does, it's probably worth filing a bug that the URL that error suggests you use is stupid and wrong.03:59
Mezlp-29094736 ???04:00
gnomefreakRAOF: thanks that worked. im not6 getting why its given me a lp-####04:01
gnomefreakwill file bug as soon as i get done with everything that i started04:02
gnomefreakfile it under package bzr?04:06
RAOFYeah, that's probably the best place.04:08
RAOFAt least to start.04:08
gnomefreakok thanks04:09
mwhudsongnomefreak: there is already a bug that the suggested url is stupid and wrong04:18
ubottuLaunchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed]04:18
gnomefreakmwhudson: thanks i was reading that04:24
pooliesminnee: if you're still around, apparently there is another branch that's better for using nested branches04:36
poolieand that is04:36
sminneethanks poolie04:37
sminneeout of interest, how have you found launchpad?04:37
pooliei just type in 'launchpad.net' and there it is :-) badabing04:38
poolieactually i think it's quite nice in many ways, though i've also got about 200 bugs i'd like fixed04:39
gnomefreakis there a different way to push to branches outside of bzr push lp:~gnomefreak/iceowl/iceowl-0.x04:45
pooliegnomefreak: which part do you want to do differently?04:45
gnomefreakpoolie: the whole command04:45
sminneepoolie: this is a total noob question, but how do I download and install that version of bzr? :)04:46
gnomefreakthat command is hanging04:46
fullermdWell, you could add an alias so you could "bzr gently-suggest" instead...04:46
pooliegnomefreak: did it say it's waiting for a lock or anything?04:46
pooliesminnee: there should be a 'bzr branch' command on that page; run it, and then follow the INSTALL instructions in the resulting directory04:47
gnomefreakgive me a minute04:47
gnomefreakpoolie: http://pastebin.mozilla.org/551726  that is all and its benn running close to 30 minutes04:47
pooliegnomefreak: ah that would be why it's so slow04:47
mwhudsoniceowl == unbranded thunderbird?04:48
gnomefreakmwhudson: sunbird04:48
poolietry running 'bzr upgrade sftp://gnomefreak@bazaar.launchpad.net/%7Egnomefreak/iceowl/iceowl-0.x'04:48
mwhudsonoh ok04:48
mwhudsonthat's not likely to be so big i guess04:48
poolieor ask mwhudson to fix it on the server04:48
pooliemwhudson, jml, we should seriously do something about this ^^04:48
mwhudsonpoolie: do some kind of mass upgrade to packs?04:49
pooliei think so04:49
mwhudsonmy kneejerk reaction says "no"04:49
mwhudsonbut i'm willing to be influenced04:49
jmlpoolie: so, we'd very much like to allow users to ask us to do a server-side upgrade.04:49
gnomefreakiceowl branch is big but never taken this long before. im waiting for lock to break04:49
mwhudsonwhat we really do want to do is have a button that says "upgrade this branch"04:50
jmlpoolie: we've got a plan for this, but it's pending some db discussions04:50
RAOFI even filed a bug that proposed exactly that, so you can get your fill of bugfixing karma at the same time!04:50
gnomefreakpoolie: what does this command do outside of bzr upgrade (already had done this04:51
pooliewhich command?04:52
gnomefreakbzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x04:52
mwhudsonrocky: if i wanted karma, i'd actually _use_ blueprints04:52
poolieit breaks the lock held by the previous process04:52
mwhudsonRAOF: ^^04:52
poolieyou should kill the process on your laptop if it's not already04:52
gnomefreaki had screwed up my branch thats why i was trying to overwrite it04:52
RAOFmwhudson: :P04:53
pooliemwhudson/jml, is there any chance we could do these one-by-one on request?04:53
pooliegnomefreak: then it's probably easier to just delete the branch,04:53
poolieupgrade your local copy, and then push04:53
pooliethat'll actually be faster04:53
gnomefreakok try that04:53
poolieswitch machines, biab04:53
mwhudsonpoolie: sure, i can run "bzr upgade lp:whatever" on devpad04:53
gnomefreakthere really is something wrong and im getting tired05:03
gnomefreakeven got trace back05:03
gnomefreakpoolie: traceback05:03
pooliethat's no good05:04
gnomefreakim gonna run outside for smoke here is the output http://pastebin.mozilla.org/55172905:04
spivgnomefreak: you need to run "bzr launchpad-login gnomefreak" first05:05
pooliespiv, would that really give a timeout?05:06
spivOh, hmm.05:06
spivIn that case, don't know :)05:06
poolieit looks to me like a transient timeotu05:06
spivHmm, that's probably the first network request that "bzr push lp:..." does.05:07
spivIt *might* be an issue with connecting to the HTTPS port?05:09
spivActually, why does the launchpad plugin need to connect to Launchpad to resolve "lp:~x/y/z"?05:10
gnomefreakshould i try after login?05:11
beunospiv, I think to check for permissions05:12
gnomefreakstarting off same way05:12
gnomefreakah it did work05:12
gnomefreakwell ill check when its done05:12
pooliei'd just retry it and see if it gets the same thing, i think it's transient05:13
gnomefreakim getting the progress bar05:13
spivbeuno: hmm, surely the way to do that is to just try using it? :)05:15
beunospiv, 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 salt05:17
beunoand, it's 1am05:17
spivbeuno: go to sleep :)05:17
beunoyou're a wise man05:17
beunogood night spiv05:17
beunohave a nice weekend!05:17
mwhudsonspiv: because the client makes very few assumptions about the structure of urls05:19
mwhudsonwhich is a good thing i guess *cough*source package branches* cough05:19
gnomefreakis there a way to login automagickly?05:19
spivgnomefreak: you only need to run "bzr launchpad-login" once, then the userid is saved in your ~/.bazaar config.05:22
poolienight beuno05:22
spivgnomefreak: or do you mean an SSH passphrase, or something like that?05:22
gnomefreakspiv: oh ok thanks05:22
gnomefreakspiv: no just the login command itself05:22
gnomefreakbzr launchpad-login gnomefreak05:23
spivAh 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
gnomefreakgood night its getting late05:23
spivgnomefreak: good night05:23
gnomefreakthanks for the help everyone05:24
abentleylifeless: 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
lifelessabentley: it likely would; I can't really say without seeing, but yes, looking at create_by_entry it just wants kind and file_id05:38
lifelessabentley: that sounds like a good idea to me05:38
lifelessabentley: I'm guessing my concerns made sense?05:39
abentleylifeless: cool.05:39
abentleylifeless: 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
abentleyIn a meaningful way.05:41
jonoxerTime 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 now06:34
spivjonoxer: bzr+ssh is the usual approach06:36
spivjonoxer: it's possible to use one system account with multiple SSH keys associated with it, I think06:37
jonoxerspiv: the host has LDAP and all devs have shell at the moment, but I'm guessing I'll have privilege problems on the repo itself06:38
spivjonoxer: you can restrict SSH to only allow the user(s) to run bzr, i.e. disallow shells.06:38
spivMake the repo group-owned (sticky) and group-writeable.06:38
jonoxerI just did a test as a different user and even with group write privs I got an access denied error. Playing with it now06:38
jonoxerAha, 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
jonoxerI'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 time06:53
jonoxerAfter the failure I do break-locks which reports that a lock has been created (and breaks it successfully) but pushing still fails with a traceback06:53
spivjonoxer: pastebin the traceback?06:54
jonoxerspiv: yep, in a moment, just trying one or two more things now06:55
jonoxerI can still push as the original user (after breaking locks of the second user)06:55
jonoxerspiv: http://pastebin.com/d4a3e305e06:56
spivArgh, ok, one of those.06:57
spivI think that happens to be the one I'm about to land a fix for for 1.806:57
spivYep, almost certainly it is.06:57
jonoxerAha, 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
spivjonoxer: an error is occuring somewhere, but that triggers a secondary error which obscures the original error and triggers the traceback06:58
spivjonoxer: the patch on https://bugs.edge.launchpad.net/bzr/+bug/230902 will fix the secondary error, and let the real error show.06:59
ubottuLaunchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]06:59
jonoxerOK, so I probably still have something wrong but we can't tell what from the trace06:59
spivThe "ValueError: I/O operation on closed file" is an interesting clue, though.07:00
spivIs there a ~/.bzr.log on the server-side?  Does it have a traceback?07:00
jonoxerI'll see07:00
spivI'm wonderinf if that short traceback at the top of your paste might have happened on the server side.07:01
jonoxerYes, there are logs for both the first and second users07:01
jonoxerTrying again while tailing the log...07:02
jonoxerGot the entry while doing a failed push. Doesn't say much though07:02
jonoxerJust this: http://pastebin.com/d4e6272d807:03
spivDouble-check the permissions inside the remote .bzr directory and subdirectories?07:04
vila hi all07:05
spivGoogling suggests that others have seen this error when the permissions are somehow wrong inside the .bzr/repository/ directory on the server.07:05
spivAnother 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
jonoxerI've gone through the permissions fairly carefully, I think they're correct (not ruling it out though). I'll try -Dhpss now07:09
spivI'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
spivYou're welcome to pastebin the ~/.bzr.log with the -Dhpss info in it.07:12
jonoxerThe log looks normal until it gets to repo/.bzr/repository/pack-names, then does the traceback, checking now07:12
jonoxerI don't get it, the permissions on that file are fine for that user. I'll paste the log07:13
jonoxerspiv: http://pastebin.com/d249d52ee07:14
spivjonoxer: hmm07:14
spivjonoxer: 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
spivjonoxer: try over sftp:// instead of bzr+ssh:// ?07:17
* spiv hopes jonoxer's IRC client reconnects...07:17
spivAh, welcome back.07:17
jonoxeroops, back, sorry spiv07:17
spivjonoxer: 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
spivjonoxer: try over sftp:// instead of bzr+ssh:// ?07:17
jonoxerspiv: 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
jonoxerwhich looks like permissions, as you say07:19
spivIt does indeed!07:20
jonoxerI'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 it07:20
spivUnless you have a wacky filesystem that doesn't support POSIX semantics for renaming files ?07:21
spivjonoxer: Ok.  Have a good weekend.  I'll be around on Monday if inspiration doesn't strike :)07:21
jonoxerExt3, so should be OK07:21
spivYeah, ext3 should be more than ok :)07:22
jonoxerI 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 helps07:22
chmacI ran something like `cd ~/bonkers/; bzr init; bzr add blah/; bzr ci -m "1"`07:44
chmacNow I've realised all my code is within blah/ and I'd like to do something like this07:45
chmacmv ~/bonkers/blah ~/blah07:45
chmacHowever, that will break the bzr repo as the ~/bonkers/.bzr/ directory will no longer be in the right place07:45
chmacIs there an alternative?07:45
chmacIn svn each directory is self contained, so I can just ignore the parent dir, but not in bzr07:47
chmacOk, this kinda worked `cd ~/bonkers; bzr mv blah/* ./; bzr ci -m "Move"; bzr rm blah/; bzr ci -m "Tidy"`07:52
* spiv heads off08:29
=== jamesh_ is now known as jamesh
EarthLionhey can you put a limit on bzr log so you just see the last x amount12:06
james_wEarthLion: either --limit12:06
james_wor "-r -100.." or similar12:07
EarthLionthanks a lot12:07
EarthLionalso 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 changes12:09
EarthLionis that possible?12:09
james_wEarthLion: -v12:11
james_wEarthLion: you might want to look at "bzr help log" to see what else is available12:11
EarthLionok thanks12:14
EarthLionmakes those two commands make things a lot easiar :)12:14
=== Guest52963 is now known as jelmer
lakshmananhey.. 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 help14:54
beunolakshmanan, what seems to be the problem?14:56
lakshmananbeuno, 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 do14:58
beunolakshmanan, you need to specify your Launchpad username first with:   bzr launchpad-login <username>14:59
lakshmananbut that was the url given in that branch's launchpad page14:59
beunolakshmanan, the url is correct15:00
lakshmananbeuno, can you gimme the full command i must give to push my changes15:00
beunoyou just need to be logged in to push to launchpad15:00
lakshmanani am logged in15:00
beunobzr launchpad-login your_launchpad_username15:01
beunolakshmanan, ^15:01
beunoyou just need to do that once15:02
lakshmananbeuno, oh you mean i must login to launchpad via terminal... am i right?15:02
beunolakshmanan, yes. bzr needs to know your launchpad username15:03
lakshmananbeuno, 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 explain15:08
beunolakshmanan, ah, right, that's a one-time error as well, because of you trying to push before15:08
beunojust add the --use-existing-dir flag once to the push command15:08
beunoand from now on, everything will go smoothly15:09
lakshmanani did... it worked.. thanks15:09
strka '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 either15:31
strklast time I killed the process the repository (on-line, shared) got corrupted.15:31
strkwhat do I do ? :>15:32
beunostrk, you're pushing or branching?15:34
beunois the branch big?15:40
beuno2 houts sounds too much15:40
strkyes, it's big15:44
strklast two lines from .bzr.log are:15:44
strk2965.718  http readv of e74eb7f199645e105baf57aca1ee3638.pack  offsets => 119 collapsed 615:44
strk3013.203  http readv of 2c779c251220f8afce08bcec69277e32.pack  offsets => 34285 collapsed 30815:44
strkthat's how much  50 minutes ?15:44
jdoanyway to undo a bzr clean-tree?17:02
strkI killed it, starting from scratch using sftp (it was http)17:12
strknow, I'll try to branch from a collegue machine on this lan, any help is appreciated with this experiment17:13
=== abentley1 is now known as abentley
Odd_Blokejdo: I'm not aware of one, I'm afraid.18:17
jelmerhmm, apparently there exists a funny VSS -> Subversion gateway18:37
jelmerand it does all kinds of funny things18:37
jelmerMicrosoft's CodePlex site is running it18:37
=== BasicPRO is now known as BasicOSX
=== ja1 is now known as jam
flacostewhat should I make of:19:32
flacostebzr: ERROR: KnitPackRepository('file:///home/francis/canonical/windmill/.bzr/repository/')19:32
flacosteis not compatible with19:32
flacostedifferent rich-root support19:32
flacosteok, i think this is because i'm trying to branch a bzr svn branch into --1.6 format repository19:35
flacosteor just into a repository?19:35
LarstiQflacoste: right, bzr-svn uses a rich root format, which is not the default19:39
flacostecan I make a shared repository that can be used by bzr-svn branches?20:25
flacosteinit-repo --subversion i guess20:25
flacostethat might also work20:26
t3techIs there user documentation for the Eclipse plugin somewhere that I'm not finding?20:42
beunot3tech, all I know of is: http://bazaar-vcs.org/BzrEclipse20:44
beunobut Verterok|out is the one to ask, unfortunetely he's off on vacation20:44
t3techbeuno: yeah that's I've been able to find.20:44
beunot3tech, I suspect there's not help or tutorial for it20:46
t3techI'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
beunomaybe awilkins knows?20:49
t3techwell 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. Hmm20:59
t3techThink I've figured it out... was right clicking in the wrong place. doh!21:20
nevansjust 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
jelmernevans, hi22:21
jelmernevans, can you perhaps pastebin the "svn log -v" output of the svn repository somewhere?22:22
nevansjelmer: yeah22:22
nevansI made a bugreport on lp, too22:22
ubottuLaunchpad bug 281460 in bzr-svn "race condition when pushing to svn repo" [Undecided,New]22:22
nevansjelmer, 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
nevansit's got ~15549 revisions in just that branch.  :)22:24
jelmernevans, the entire repo - just the first 100 or so should do22:24
nevansI 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
jelmernevans, I mean svn log rather than bzr log22:26
nevansyeah... I'm getting that now.22:27
nevansjust thought I'd let you know. :)22:27
jelmeryes, it's correct it'd be determining the file id map first in the case of bzr log22:27
nevansjelmer, 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
jelmernevans, yep, thanks22:42
nevansjelmer, just let me know via the lp ticket if you need anything else to debug.22:43
beunojelmer, hi!23:30
beunoI see you managed to get LH on Debian's NEW queue again  :)23:30
beunoany plans to get it into Ubuntu, or are you going to let it trickle down in Jaunty?23:30
jelmerbeuno, I'm going to let it pass for Intrepid23:52
beunojelmer, so maybe we can upload it to bzr's PPA?23:53
jelmerbeuno, Sure, I'll leave the actual uploading to other folk though, I don't want to commit to keeping it up to date23:54
beunojelmer, fair enough, I'll be "people"23:54
beunothanks for all the work on the package !23:54
jelmerbeuno, you're welcome23:55
beunoI'm off home now23:55
jelmerThanks for loggerhead (-:23:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!