/srv/irclogs.ubuntu.com/2009/11/18/#bzr.txt

igcmorning00:55
=== vxnick_ is now known as vxnick
mwhudsonlifeless, spiv : how close is lp:~spiv/bzr-builder/refactor to landing?03:30
spivmwhudson: hmm03:32
mwhudsonalso, what does it do?03:32
lifelessmwhudson: james_w needs to get back from UDS :)03:35
mwhudsonlifeless: that makes sense i guess03:36
spivmwhudson: that branch has some simple refactoring on top of lp:~lifeless/bzr-builder/bug-469874 that is used by lp:~spiv/bzr-builder/merge-subdirs-47970503:36
mwhudsonsounds like a fun stack of not-landed branches03:37
spivmwhudson: basically a replaces a list of 2-tuples where (*, None), (None, *) and (None, None) all mean different things, and replaces them with objects03:37
spivmwhudson: and replaces case statements about that with good ol' polymorphism03:38
lifelessmwhudson: why do you ask?03:38
mwhudsonlifeless: just poking at bzr-builder03:38
spivThe names I gave to the objects and methods can be improved, but the shape is certainly much nicer (and made merge-subdirs-479705 fairly straightforward).03:39
spivHmm, I guess I should make some merge proposals for those, not sure why I hadn't done that yet.03:40
lifelessspiv: you get to use the new dependent branches feature ;)03:42
Kamping_Kaiserdoes bzr have something like gits add --interactive? (allows commiting chunks of your current diff)03:45
spivlifeless: indeed :)03:45
spivMerge requests filed.  That should keep james_w busy for a while :)03:46
spivKamping_Kaiser: "bzr shelve", you can shelve the parts you don't want to commit yet, then bzr commit, then bzr unshelve.03:46
Kamping_Kaiserspiv: thanks, I'll have a go03:46
poolieigc: still around?03:58
pooliehi spiv, mwh03:58
mwhudsonpoolie: hello03:58
Kamping_Kaiserspiv: that works a treat, thanks.03:58
lifelessspiv: so you proposed the branch to my branch, not to trunk?04:14
lifelessspiv: oh nevermind, LP confused me04:14
poolie!!!04:19
poolie:-)04:19
lifelessyeah, news @ 1104:26
=== Peng__ is now known as Peng_
bob2lol04:40
* GaryvdM is back (gone 07:00:57)04:44
=== vxnick_ is now known as vxnick
RenatoSilvais there a way to bzr diff all non .xyz files?08:14
bob2you can use filterdiff (not part of bzr)08:17
RenatoSilvaok thanks anyway08:19
tumbleweedso, I've got a bot that's polling bzr branches on lp, and I'm getting RevisionNotPresent exceptions sometimes http://paste.pocoo.org/show/nHK9f5k22Vt40innuE6i/09:30
tumbleweedcode in question: http://bazaar.launchpad.net/%7Estefanor/ibid/icecast/annotate/head%3A/ibid/plugins/bzr.py09:30
tumbleweedshould I just ignore the exception and try again in a bit?09:31
lifelesstumbleweed: yes, I guess.09:43
MvGHi! Trying to push a branch to lp failed at fist try ("different serializers") but succeeded at second try: http://pastebin.com/m27e603bb09:48
MvGIs this a bzr issue or a launchpad issue?09:48
PengThat's clever! The failure on the first push leaves enough around that the second push doesn't try to auto-stack. I'll have to remember that!09:59
PengMvG: *Probably* a bzr bug, but I'm not going to set something equivalent up off-LP to verify it.10:00
PengNote to self: File a bug about stacking being broken on staging...10:01
MvGSo basically it is known current behaviour that auto-stacking doesn't work (due to some difference in repo formats?), and the fact that it worked the second time is more like a bug? Should I file anything?10:02
PengMvG: What format is your local branch? If it's 2a, than yes, it's known behaviour that stacking fails.10:02
PengMvG: Err, I mean, *not* 2a.10:03
MvGFormat is 2a, according to "bzr info ..", where .. is the shared repository.10:03
PengMvG: Oh, my mistake. You're using 2a, but lp:~trac-bzr-team/trac-bzr/trunk is on an older format.10:04
PengMvG: What happened is that the first push created some of the control directories before it realized the format difference and exited. On the second push, since they existed, it didn't try to stack, so you didn't run into the format issue.10:04
MvGI understand.10:05
PengMvG: Umm, I think it's worth filing, although I'm not sure it's worth fixing. :P10:05
MvGOK. will do so.10:06
MvGPeng: How do you tell lp:~trac-bzr-team/trac-bzr/trunk is older format? bzr info doesn't seem to help me there.10:10
PengMvG: The error message said it was a KnitPackRepository. 2a is CHKInventoryRepository.10:18
MvGAh, I see.10:18
PengMvG: FYI, in bzr.dev, "bzr info -v" gives useful format information for branches accessed over the smart server.10:20
PengMvG: In older versions, you can prepend "nosmart+" to the URL to force VFS access, e.g.: bzr info nosmart+lp:~trac-bzr-team/trac-bzr/trunk10:20
PengMvG: (I mean, you can do it in bzr.dev too, you just don't need to...)10:20
MvGAll of these give me info about the branch, but not about the repository format...10:21
PengMvG: It included all of it.10:22
MvGIn the Format section it says "repository: bzr remote repository"10:23
MvGAh, works now...10:23
MvGHad been using an older bzr setup here without realizing it...10:23
MvGfiled https://bugs.launchpad.net/bzr/+bug/48468510:24
ubottuLaunchpad bug 484685 in bzr "Failed auto-stacking on first push from 2a branch with non-2a trunk" [Undecided,New]10:24
Glenjaminhi guys, after running the bzr check command, i'm told there are ghost revisions and inconsistent parents10:32
Glenjaminis there a way to resolve these somehow?10:33
Glenjamindid those messages get blocked by the network for not being registered?10:33
bob2no10:34
Glenjaminah good, the freenode error message isn't all that clear :)10:34
bob2'bzr reconcile' should fix the inconsistent parents, I think (backup your branch/repository first)10:34
Glenjaminright, is there anything i can do about ghost-revisions? (and what are they?)10:36
PengGlenjamin: Ghosts are revisions that your repo doesn't actually have a copy of.10:44
Glenjamini was having issues with bzr-svn in a 2a repository10:45
gioeleGlenjamin: what kind of branch is that? A git or svn import?10:45
Glenjamini started again with 1.14-rich-root and it seems fine now10:45
Glenjamini did checkout(from svn) branch(locally) push(to svn), and it have an error about parent revisions10:45
gioeleGlenjamin: is it happening every time?10:46
Glenjaminit was with the 2a format, yes10:46
Glenjamincheers for the help guys :)10:56
bialixhi, any core devs here?11:13
spivI half am11:15
bialixho! spiv!11:16
bialixhello spiv11:16
bialixI have 2 problems11:16
spivGood evening :)11:16
bialixfor you evening, for me afternoon :-)11:16
bialix1) We have a problem with reconfigure of light checkout of bzr:// branch11:17
bialixspiv: I've fwd'd mail from qbzr ML about this problem11:17
bialixspiv: if you have any ideas how to debug this problem I'll be very appresiated11:17
bialixspiv: if you have any ideas how to debug this problem I'll be very appreciated11:17
bialix2) it seems 2a (or rich-roots) broke merge -r0..-1 when files have the same file-id11:18
spiv1) Interesting!  That seems quite weird.11:19
spivAs for 2), I would have expected that would get conflicts with or without 2a, or does it fail worse than merely conflicting?11:21
bialixspiv: 2) doesnot happens with pack-0.92 aka poor-rootsz11:22
* bialix pastebins11:23
bialixspiv: see Makefile: http://pastebin.com/m1324b1ae11:23
bialixspiv: with 2a format I've got path conflict11:24
bialixwith pack-0.92 I've got good merge11:24
bialixand with rich-root-pack too11:26
bialixrich-rot-pack -> conflict11:26
bialixbug https://bugs.launchpad.net/bzr/+bug/48470611:28
ubottuLaunchpad bug 484706 in bzr "merge 2 unrelated branches in rich-root format cause path conflict for the same file-id" [Undecided,Confirmed]11:28
spivYeah, I think it's a rich-root thing.  I think a conflict is reasonable in that case, I'm not sure why non-rich-root wouldn't conflict (in fact I'm tempted to think that's the bug, not the rich-root case).11:29
spivI don't see a good reason for it to be inconsistent, so there's certainly some sort of bug there.11:31
bialixspiv: I think non-rich-root behavior is *right* actually11:33
bialixthere is good reason to split big branch into 2 and then merge between them11:33
bialixspiv: if you have any ideas about 1) I'd like to get some hints11:34
spivWell, I cna see an argument for allowing it, for the same reason we treat a merge that applies the exact same change as being clean.11:34
spivI don't have a strong opinion either way, but my initial expectation was that it should conflict.11:34
bialixspiv: all this file-ids thingy is good only for 1 reason -- to track renames. But there is a lot of other reasons when file-ids only bad thing11:35
bialixparallel imports et al11:35
spivAnd if the content isn't identical it certainly should.11:35
bialixshould -> what?11:37
spivShould conflict.11:37
bialixif content is not identical it produce text conflict (for pack-0.92 format) and this is very good11:37
bialixbut path conflict is not good11:38
spivFor 1), I think I see the bug in remote.py11:41
spivIt doesn't look like RemoteRepositoryFormat.initialize copes properly with a non-RemoteBzrDir argument, even though there's some code to try handle that case.11:42
spivIt's getting late here, but I'll send an email summarising what I see.11:44
bialixok, thanks11:47
RenatoSilvais there any work/registered idea anywhere about "semantic/smart" diffs?11:58
RenatoSilvafor example, diff ignoring white spaces11:58
RenatoSilvaanother example, CSS diff11:58
bob2already possible11:58
bob2bzr diff --using=whatever11:58
bob2'--using=diff --diff-options=-w' will ignore whitespace11:59
RenatoSilvagreat :) but that's just an example12:00
bob2sure12:01
bob2if a semantic css diff program exists, bzr can use it12:01
RenatoSilvaI have had trouble with comparing css, and I thought it would help me if the diff algorith was "smart"12:01
RenatoSilvabob2: ok I'm being sort of offtopic because I don't know a right channel to ask, as the subject is cross-channel12:02
* RenatoSilva trying to remember a use case for a "semantic" css diff12:02
RenatoSilva* recall12:02
RenatoSilvahum, ordering, for example p {\n color: #333;\n margin: 0px; \n} should be considered the same as p {\n margin: 0;\n color: #333;\n}12:04
spivbialix: sent12:04
spivRenatoSilva: sure, but bob2's answer still seems applicable12:06
RenatoSilvathis becomes annoying when you have a lot of stuff like this and among these lines only 1 or 2 that really matter12:06
RenatoSilvaspiv: ok sorry, will stop now :)12:06
spivRenatoSilva: that is, bzr can already cope with that, you just need to tell it to use a diff program that knows how to do the diff you want.12:07
spivAnd if that diff utility doesn't exist yet that isn't exactly a bzr issue :)12:07
spiv(Although if there's some way in which bzr might help, then that would be worth discussing, but from what I see so far probably not)12:08
spivAnyway, bedtime for me.12:08
RenatoSilvaspiv: ok, actually I want those programs, which I'm afraid to exist12:08
RenatoSilvaI'm afraid to not exist12:11
bialixspiv: many thanks12:13
jammorning all14:42
bialixhello jam14:45
* bialix akways enjoys reading jam's articles15:09
* beuno remembers jam's "this week in bazaar"15:09
jambeuno: blame statik, he left me and TWiB fell apart15:10
* beuno looks at statik with disapointment15:12
bialixbeuno: ya, this week journal was very cool15:14
=== abentley1 is now known as abentley
henningeHi! I am using bzr-pipline for the first time.15:21
jamwadesworld: ping if you get some time to help debug the sftp stuff15:22
henningeI had made some changes in the last pipe and then switched to another pipe w/o committing the changes.15:22
henningeNow show-pipeline displays the "U" next to this pipe.15:23
henningeI returned to that pipe (so show-pipeline show "*U") but I don't see the uncommitted changes, at least not with "status" or "diff". Do I need to restore them somehow?15:24
gioelehenninge: try "bzr shelve --list", maybe the uncommited changes have been shelved15:26
henningegioele: "No shelved changes"15:27
henningegioele: rockstar also explained to me last week that pipelining is different from shelving.15:27
rockstarhenninge, bzr unshelve15:28
rockstarhenninge, when you change to another pipe, bzr automatically shelves the changes for you.15:28
henningerockstar: but does not automatically unshelve when I return?15:29
jamhenninge: I believe that is true15:29
gioelerockstar: but "bzr shelve --list" says that there is nothing to unshelve15:29
* henninge hasn't used shelve/unshelve before either15:29
jamswitch-pipe shelves but does not unshelve15:29
rockstarhenninge, so shelving is part of pipelines, but last week, the discussion was about shelving doing the same as pipelines, which is untrue.15:29
jampartially because "bzr merge --uncommitted ..." is able to pull stuff out of the shelf15:29
henningeah15:29
rockstarhenninge, I use shelves when I have some changes I'd like to keep instead of revert, but I need to commit something else before I commit those changes.15:30
rockstarIt's kind of like limbo for changes.  Not heaven or hell.15:31
henningerockstar: bzr unshelve also says, there is nothing on the shelve.15:31
henningerockstar: ;)15:31
rockstarhenninge, when you do bzr pipes, what does it say?15:31
rockstarEr, bzr show-pipeline15:31
* rockstar always forgets that he has aliases15:31
henningepipes works, too ...15:32
henningerockstar: "*U pipename"15:32
rockstarhenninge, and bzr status15:32
henningerockstar: nuttin'15:32
rockstarabentley, ^^15:33
henningerockstar: I have to say that I added and deleted a pipe and had a conflict which I resolved15:33
rockstarhenninge, that shouldn't affect your changes that should have been shelved.15:33
rockstarhenninge, I must consult the pipeline gods.15:33
abentleyjam: switch-pipe also unshelves.15:34
henningeI also tried "merge --uncommitted" (because I read that in the help somewhere) and it failed15:34
rockstarabentley, I thought it did.15:34
jamabentley: would make sense to be symmetric15:34
jamwhat if you have multiple shelved patches?15:34
jamjust the last one?15:34
abentleyjam: There's only one.15:34
rockstarabentley, it sounds like something's wrong with how changes got shelved.15:34
jamabentley: so 'bzr shelve' doesn't interact with the actual 'shelf' that is being used?15:35
henningehere is the failure: http://paste.ubuntu.com/321609/15:35
abentleyjam: Indeed.15:35
henningeoh, that is mostly explanatory text15:35
abentleyjam: The shelved changes are stored in the branch, not the working tree.15:35
rockstarAh, that's clever.15:36
rockstarSo bzr unshelve shouldn't actually unshelve the changes.15:36
henningehere is the crash file: http://paste.ubuntu.com/321612/15:36
abentleyrockstar: Right, and I also try to avoid referring to it as shelving.15:36
rockstarhenninge, try switching away from the pipe and switching back.15:36
rockstarabentley, yes, I can see why now.15:37
abentleyhenninge: doing "switch-pipe" to return to the pipe with the stored changes should restore them.15:37
abentleyhenninge: The crash you're getting is because you didn't specify a pipe to merge from.15:38
henningerockstar: yup, that helped15:38
rockstarhenninge, so it's working now?15:38
henningerockstar: yes, bzr status show my changed files again15:39
henningeshow15:39
henninges15:39
rockstarhenninge, great15:39
* rockstar scurries off to find a quiet hacking place15:39
henningerockstar: thanks15:39
henningerockstar: go to your room!15:39
henninge;-)15:39
henningeabentley: thanks, too.15:40
abentleyhenninge: I have filed bug #484846 about the merge issue.15:42
ubottuLaunchpad bug 484846 in bzr-pipeline "pipeline dies when location is not specified with merge --uncommitted" [Undecided,New] https://launchpad.net/bugs/48484615:42
abentleyrockstar: btw, "pipes" is an automatic alias for show-pipeline now.15:45
rockstarabentley, hooray!15:45
abentleyhenninge: Is it possible that when you originally returned to the pipe, you used "switch", not "switch-pipe"?15:45
rockstarabentley, actually, I found out last week that basically everyone at the lazr-js sprint using pipes were using my aliases.  I thought about submitting a patch to make those aliases official.15:46
abentleyrockstar: Well, I'm not sure about all of them, but just submit your aliases and I'll look them over.15:47
henningeabentley: "history | grep switch" only return switch-pipe ...15:47
henningerockstar: pdiff and pstatus? Very useful.15:47
rockstarabentley, cool.  Well, now that I see the aliases I use, they shouldn't all go up, but EVERYONE was using next and prev.15:48
rockstar...as well as pipes, which is now upstream anyway.15:48
henningerockstar: where do I find "your" aliases?15:49
abentleyhenninge: Okay, I'll look into why it didn't restore the changes.15:49
abentleyrockstar: I don't get "next" and "prev".  I use switch-pipe :last at least as often as switch-pipe :next.  So I've aliased "switch-pipe" to "swp".15:50
rockstarhenninge, http://theironlion.net/blog/2009/08/26/5-must-have-aliases-bzr-pipeline/15:50
rockstarI have a few more now, but they aren't anything special.15:50
rockstarAnd send-pipe is silly to have now anyway, since Launchpad ignores the bundle you send through email now.15:50
rockstarabentley, maybe there should be a bzr last then as well.15:51
abentleyrockstar: Anyhow, "next" and "prev" can't be automatic aliases.  Only command name abbreviations can be automatic.  But they could go in "help pipelines".15:51
rockstarabentley, ah, yeah.  You're right.15:51
rockstarabentley, okay, so it's more a doc patch now.  I can live with that.15:52
abentleyrockstar: It doesn't ignore the bundle.  It just has a tendency to fail to apply it correctly.15:52
abentleyrockstar: i.e. to give an incomprehensible oops.15:53
rockstarabentley, well, as far as the UI is concerned, it ignores it, because the preview diff is what's displayed.15:53
rockstarabentley, it's a moot point with pre-req branches though.15:53
abentleyrockstar: The diff was never part of the bundle, it's part of the merge directive.15:54
* rockstar facepalms15:54
rockstarThat's what I meant.  I blame UDS and lack of sleep.15:54
abentleyrockstar: actually, I tell a lie.  In bundle format 0.9 and earlier (bzr 0.18 and earlier), the diff *was* part of the bundle.15:55
abentleyrockstar: Anyhow, there's a new lp-submit in the very latest pipelines that uses the LP API to create merge proposals.15:57
abentleyrockstar: You get prerequisite branches automatically.15:57
rockstarabentley, wonderful.15:57
rockstarabentley, and the diff is generated correctly?15:57
abentleyrockstar: Yes.15:58
rockstarNiice!</borat>15:58
PengIs there a 2a copy of MySQL somewhere for those too impatient to spend 2 days converting it? :D16:07
henningeabentley: I have another crash for you ... http://paste.ubuntu.com/321629/16:07
Peng(I don't really care what branch; I just want it for testing.)16:07
brmassaguys, show can i create a patch between 2 revisions?16:08
Pengbrmassa: What for?16:08
abentleyhenninge: Your bzr C extensions are not up to date with your bzr.16:08
henningeabentley: how do you see that and how do I fix that?16:09
abentleyhenninge: You're running bzr from a package, right?  If so, only the packager can fix it.16:10
henningeabentley: from the nightly ppa.16:10
brmassaPeng: well... i created a branch for each x.x.x, 1.x.x and 1.1.x version of my app. now i submited some some to the minor branch (1.1.x), i want to generate a patch to apply into higher levels/versions16:11
abentleyhenninge: I know that it's a C extension problem only because I've experienced it myself, and since I run from source, I did "make" and it fixed it.16:11
henningeWoa! bazaar-vcs got a new look!16:11
Pengbrmassa: You should have done it the other way around so you could "bzr merge".16:11
Pengbrmassa: Make the change to the oldest branch, then "bzr merge" it into the newer branches.16:12
abentleyjam: henninge's running from the nightly PPA, but his StaticTuple is incompatible with his bzr.  Who takes care of that packaging?16:12
jamPeng: I don't believe there is. I think they've talked about upgrading, and I believe 'drizzle' has switched to 2a, but I'm not sure if drizzle is the full mysql history, etc.16:13
abentleyhenninge: Perhaps you can switch to the bzr beta PPA temporarily?16:13
jamabentley: the daily just needs to be rebuilt, there was a fix for that which has been around since 2.1.0b316:13
jamI thought james_w was doing dailies16:13
jamafaik, none of the 2.1 series was built into bzr-beta-ppa16:14
jamjohnf didn't have enough tuits16:14
Pengjam: Thanks.16:14
abentleyjam: I suspect james_w will be busy this week...16:14
henningeabentley: that is not 2.1 yet, I tried that first. bzr-pipeline only works with 2.1, so it told me ...16:14
Pengjam: MySQL's history is about 2000 revisions longer than Drizzle's, so I guess it doesn't. Darn.16:14
henningeabentley: I am running bzr-pipeline from source16:14
brmassaPeng: well... at one point all 3 branches were the same, but since 1.1.x is focused on bug fixing only and the other 2 includes new features, the codes might diverge...16:15
henningemaybe I should just run bzr from source, too16:15
abentleyhenninge: lp:bzr-pipeline/stable works just fine with 2.016:15
jamPeng: well, you really need to compare via "bzr ancestry" and not "bzr revno"16:15
jambut yeah, they might have started with a fresh codebase16:15
henningeabentley: ah, I could change that16:15
* Peng didn't know about "bzr ancestry".16:15
Pengjam: Ehh, true.16:15
Pengbrmassa: OK, um, commit your changes to the bugfix branch, then "bzr merge" that branch into your newer branches.16:16
jambrmassa: you can alwyays do "bzr diff -c REVNO" or "bzr merge -c REVNO", or .. create a daggy fix as Peng mentions16:16
brmassathanks guys... its just matter of getting used to the commands and concepts.16:17
Peng"bzr merge -c" does a cherrypick?16:17
CoffeeIVhow can I tell what will change from a bzr up command before actually doing it ?  bzr up doesn't seem to take the --dry-run option16:20
brmassaPeng: its working. now, is there a way to use the same commit messages used in the original branch while commiting the merge?16:22
brmassaof course without manually writting it...16:25
Pengbrmassa: You can copy and paste... :D16:28
brmassaPeng: yep. i was wondering about a parameter to to this automatically16:28
skxwhat do I need to install to get bazaar explorer? I'm on ubuntu16:47
skxgot it16:48
skxwow, you really managed to hide that info ;)16:48
LarstiQwe did?16:50
=== sdboyer_ is now known as sdboyer
PengAugh! "bzr pull" on MySQL died after almost 2 hours and 200-300 MB of bandwidth, losing all of hte progress it had made! :(19:29
mrooneyhey, I ran into an initially confusing situation, I just wanted to see if it was a bug or expected behavior19:38
mrooneyif I have a directory under VC foo, and I do bzr mv foo bar/baz when bar doesn't exist, I get the error "bar is not versioned"19:38
mrooneyso I spent a while trying to figure out what that means, because it was obvious to me it wasn't versioned since it doesn't exist19:39
LarstiQmrooney: while correct, I agree19:39
LarstiQ"bar doesn't exist" would be more helpful19:39
mrooneyyes it would have been much more helpful19:40
LarstiQmrooney: mind filing a request for that?19:40
mrooneysure19:40
LarstiQthanks19:40
mrooneyit would be great if there was an option to create the directories if needed19:40
mrooneyI keep hitting it over and over when restructing projects, "oh this file needs to be in a directory"19:42
LarstiQwhat kind of restructuring is that?19:43
LarstiQin my use I usually need a directory when I have multiple files already19:44
mrooneywhat is your fear of automatically creating directories? people typoing a mv when they expect the dir to exist, and silently getting a new one?19:45
LarstiQI haven't thought it through19:45
LarstiQbut my fear is overloading mv even more than it already is19:45
mrooneyany sort of cleaning up a project, where I accumulate too many files in a directory and want to mv them to new directories19:45
LarstiQmrooney: do you move more than one file at once to a directory that doesn't exist?19:46
mrooneyit isn't obviously that painful to bzr mkdir first, it is just a thing I have to keep in my head19:46
LarstiQright19:46
mrooneyno just one in these cases19:46
LarstiQmrooney: it's an alien proces to me :)19:46
LarstiQmrooney: how would the ui look?19:47
mrooneythe ui?19:47
LarstiQmrooney: of mv making dirs that don't exist19:49
* LarstiQ checks mkdir -p behaviour19:50
LarstiQmrooney: so one question that arises19:50
LarstiQmrooney: `bzr mv file non/existing/path`19:51
LarstiQmrooney: would that be non/existing/path/file or non/existing/path ?19:51
LarstiQhi LenzGr19:51
LenzGrHi!19:52
mrooneyLarstiQ: haha yes, that is ambiguous, I assume it becomes non/existing/path unless you did bzr mvfile non/existing/path/19:52
mrooneyI'd follow 'mv' there19:52
mrooneythough mv doesn't have a -p option like mkdir does19:53
LarstiQmrooney: right19:55
mrooneyLarstiQ: I got bug 484985 for you :)19:55
ubottuLaunchpad bug 484985 in bzr "bzr mv'ing something to a folder which doesn't exist results in unspecific error" [Undecided,New] https://launchpad.net/bugs/48498519:55
LarstiQmrooney: thank you :)19:55
mrooneythat would definitely at least make it obvious to the user what they need to do19:56
=== weigon__ is now known as weigon
ibrandtGreetings All.  I'm having an issue with bzr join.  I started a repo in /etc/httpd some time back.  Now I'd like to version /etc as a whole.  I ran bzr init in /etc, and added and committed everything but /etc/httpd.  Now I'm trying to join /etc/httpd by running bzr join httpd from the /etc directory.  I get "bzr: ERROR: An inconsistent delta was supplied involving u'httpd', 'tree_root-20091113022148-a0u1zuvcke3o9vtb-1' reason: Path alread21:41
ibrandtversioned".  Am I misunderstanding how join is supposed to be used?  Bzr 2.0.1 and repo formats are both 2a.21:41
gioeleibrandt: add https to .bzrignore21:42
gioeles/https/httpd21:42
ibrandtThanks for the help.  I just ran bzr ignore and got, "Warning: the following files are version controlled and match your ignore pattern: httpd These files will continue to be version controlled unless you 'bzr remove' them.", so apparently my statement that I added everything but httpd was incorrect.21:46
ibrandtLooks like I need a "bzr forget"21:47
gioeleah, no, wait. I don't think you can't you can do what you think21:48
ibrandtAh, "bzr remove --keep httpd"?21:49
gioele"bzr join" can only join branched created with bzr split21:49
ibrandtOh, I see.21:49
ibrandtAny way to push the root of httpd up one dir, keeping history?21:50
gioelefrom the help of join «Such trees can be produced by "bzr split", but also by running "bzr branch" with the target inside a tree.»21:50
gioeleibrandt: I don't know21:50
ibrandtI saw that.  Okay, thanks, I'll keep poking at it.21:51
gioeleI already asked for a new join (and a new split) that could do what you want but that proposal did not find the support of the core devs.21:51
gioelewhile you are at it, could you expose your case to the mailing list?21:51
ibrandtSure, do you have a thread link or a Launchpad bug I could comment on?21:52
ibrandtI got my ignores in order, and remove --keep'd httpd, and you're right, still no luck with join.21:55
gioeleibrandt: I will try to find the link to a gmane thread later21:58
ibrandtIt's strange because how is bzr branch into an unversioned subdir of a parent tree all that different from bzr init on the same?21:58
gioelenow I'd like to understand why it does not work21:58
gioeleibrandt: what about /etc/httpd/.bzr*?21:58
gioeledo you have just .bzr or also a .bzr.retired directory?21:59
ibrandtjust /etc/httpd/.bzr21:59
ibrandtMy thought was the join was all about merging the history for that into /etc/.bzr21:59
gioeleibrandt: I see the problem21:59
gioeleibrandt: join is not the culprit22:00
gioeleibrandt: when you first added the files in /etc (including /etc/httpd) some paths have been stored in /etc/.bzr. Now that you are trying to join it, bzr sees conflicts between the recorded paths and the new paths22:01
ibrandtmakes sense22:01
gioeleibrandt: can you start with a brand new /etc branch?22:01
ibrandtI can, just getting started, so no history there yet.22:02
gioeleibrandt: so just remove /etc/.bzr22:02
gioeleand do a bzr check in /etc/httpd, just to be sure22:02
gioeleabentley: I am using git to contribute to a project. Now I really appreciate bzr-pipeline behavior of shelving local uncommited changes when switching pipe22:04
abentleygioele: Cool.  I certainly find it handy.  There might be a way to automate it in git.  Don't think they have a concept like shelving, but you could do temporary commits, I expect.22:05
gioeleabentley: "pipe" switching is basic part of git. Shelving is called stashing. and it must be done manually when switching branch22:07
gioeleobviously the command to switch branch is called "checkout"...22:07
Peng\o/ I have a ~375 MB "upload" file that hasn't been touched for 1.5 hours. What are the chances this pull crashes and burns?22:10
abentleygioele: Ah, I'll remember that it's called "stashing".22:11
abentleygioele: The git stuff with colocated branches is similar to the pipeline thing, but pipes are ordered, while git uses "stacked git" to do an ordered series of patches.22:11
gioeleabentley: I know. Luckily in this case I am working on parallel branches, not stacked branches so I didn't try stgit (or any of its relatives).22:13
mwhudsonPeng: what project is that for?22:14
gioeleI wonder whether the future branch colocation feature of bzr will suffer of the same problem (no auto shelving): http://doc.bazaar-vcs.org/developers/colocated-branches.html22:16
ibrandtgioele: Huh, same problem.  bzr check in httpd reported no errors.  I rm'd /etc/.bzr and .bzrignore.  In /etc did bzr init, bzr ignore ./httpd, bzr add *, bzr commit (which I verified didn't include httpd this time).  But then bzr join gives the same error.22:17
dahostewow -- that's how awesome #bzr is.  I came in here prepared to ask a question, and I solved it without even asking.   woot!22:17
dahosteShine on, you crazy diamonds!22:19
jelmer:-)22:19
gioeleibrandt: did you use exactly "bzr add *"?22:20
=== Adys_ is now known as Adys
gioeleibrandt: well, I can replicate your problem22:20
ibrandtI did, assuming httpd would be ignored22:21
ibrandtI'm trying join now prior to adding anything22:21
gioeleibrandt: the * got expanded by the shell and bzr sees that you are _explicitly_ adding an ignored file so it lets you add it :)22:22
gioeleibrandt: if you used bzr add . it would be ignored correctly22:22
ibrandtAh, makes sense22:22
Pengmwhudson: Trying to "bzr pull" nearly all of lp:mysql.22:24
mwhudsonPeng: ah22:24
Pengmwhudson: And yes, I am doing an on-the-fly conversion. :D22:24
mwhudsonPeng: oh22:24
mwhudsonPeng: how long has this been going for?22:24
PengOh, I suppose this is the incredibly-long "convert everything" step.22:24
jamPeng: I really wouldn't do it on-the-fly22:24
PengI had assumed the downloading was stuck.22:24
jam48hrs is a bad thing to have fail22:25
Pengjam: Luckily I don't care that much! :D22:25
jamISTR that bzr branch foo; cd foo; bzr upgrade22:25
jamwill probably be faster22:25
lifelesspoolie: adsl will benefit from http://staff.psc.edu/mathis/MTU/index.html#pmtud22:32
lifelessjam: it shouldn't be any faster22:32
lifelessjam: we stream deltas over the network, with common code22:32
jamlifeless: the converter is different22:32
jamthe tests I had done with spiv22:32
lifelessjam: spiv put a lot of time into unifying them22:32
jamshowed that while his new streaming code was a lot faster when streaming22:33
PengOh aye?22:33
jamit was still much slower thna converting locally22:33
lifelessjam: even the final version?22:33
jamlifeless: ISTR there was a problem with still extracting too many full texts and comparing them over-the-wire22:33
jamyeah, I believe so22:33
jamat least for the "bzr serve ; bzr branch bzr://localhost" style of conversion22:33
jammaybe that was only for push ?22:34
jambzr serve; bzr push bzr://localhost/2a/repo22:34
lifelessDunno. I will note that that is still one-machine :)22:34
jamsure, but doing "bzr upgrade" locally was faster than doing it over the loopback22:35
Pengmwhudson: FYI, I just checked cache speed with LP's graph in my LH StaticTuple branch. Set is about the same speed, but I slowed get down from ~277 ms to ~1.4 secs. :(22:35
jamhence, shuold be faster than doing it over the network22:35
lifelessjam: how many cores do you have in your test machine?22:35
jam222:35
mwhudsonPeng: boo22:35
mwhudsoni have some other thoughts but they are incoherent and a bit angry :)22:36
mwhudsonand there are emails to write22:36
jammwhudson: can you check for me if 'lp:bzr-svn' is accidentally stacked on itself on the http side?22:36
jamI just got a very strange recursion failure22:37
jamlifeless: I thought we had a fix for not trying to open self if you screwed up the stacking rules22:37
jam'bzr info lp:bzr-svn' hangs indefinitely for me22:37
jamwell, probably until stack depth is exhausted22:37
lifelessjam: We fixed creation of that I believe22:38
lifelessand have a bug open for handling22:38
mwhudsonjam: it's stacked on ~jelmer/bzr-svn/1.0 i think22:38
mwhudsonah22:38
mwhudsonwhich is stacked on lp:bzr-svn22:38
jamand then 1.0 is stacked back on the other?22:38
jam /cry22:39
mwhudsonis one of them a mirrored branch, i wonder22:39
mwhudsonjam: yes22:39
jelmerI just changed bzr-svn to be hosted on launchpad22:39
jelmerbut pushing with --no-stacked didn't seem to have much effect22:39
jamjelmer: just to let you know, nobody can branch it now :)22:39
mwhudsonjelmer: bzr reconfigure --unstacked lp:bzr-svn maybe?22:39
jamwell, except for you, probably22:39
mwhudsonor i can do that22:40
jammwhudson: would that trigger an update to the mirrored side?22:40
mwhudsonjam: probably22:40
jamI'm wondering if the hosted side is fine, but the mirrored side is broken22:40
mwhudson:)22:40
jamnote that you can't actually "Branch.open()" the mirrored side22:40
jambecause it goes into infinite recursion22:40
jamso the branch puller may be dead as well22:40
jamat least that doesn't mean I configured the EC2 machine incorrectly :)22:41
jelmerI'll change it back to the original branch for now22:42
lifelessjelmer: just run bzr reconfigure --unstacked lp:bzr-svn22:43
lifelessor sftp in and zerg the setting ;)22:43
jelmerlifeless: reconfigure doesn't work,  maximum recursion depth22:43
lifelessmwhudson: does mirroring know to propogate stacking changes?22:43
jammwhudson: On ~bzr-svn/bzr-svn/1.0 I see: stacked_on_location = /~jelmer/bzr-svn/1.022:43
lifelessmwhudson: bzr pull doesn't :)22:43
mwhudsonlifeless: yes22:43
jamsame for ~bzr-svn/bzr-svn/trunk22:43
mwhudsonjam: suggests the puller isn't coping too well22:44
mwhudsonlifeless: the puller does a possibly surprising amount more than just 'bzr pull'22:44
jamand then in ~jelmer I see /~bzr-svn/bzr-svn/1.022:44
jamso it isn't trunk => 1.0 it is 1.0 => jelmer/1.0 => 1.022:44
jelmerjam: ~jelmer/bzr-svn/1.0 is mirrored, the original is not stacked22:44
jelmerjam: but perhaps the lp mirror is22:45
jamjelmer: mirrored branch are auto-stacked IIRC22:45
jamso that theydon't have to download the whole history versus the dev focus22:45
mwhudsoni think i see what happened22:46
mwhudsonjelmer/1.0 was the dev focus, and mirrored22:46
mwhudsonjelmer pushed bzr-svn/1.0 which was stacked on the dev focus, jelmer/1.0 at the time22:47
mwhudsonthen bzr-svn/1.0 was made the dev focus22:47
mwhudsonthe next time the puller  processed jelmer/1.0 it restacked it on bzr-svn/1.022:48
mwhudson--> pain and suffering22:48
mwhudsonjelmer: i think you can probably unset the dev focus, delete bzr-svn/1.0, push it again and reset the dev focus22:49
jambug #48506922:49
ubottuLaunchpad bug 485069 in bzr "open_fallbacks with a cycle loops forever" [High,Confirmed] https://launchpad.net/bugs/48506922:49
mwhudsonas to how to stop this happening again, pfffff22:49
mwhudsonno real idea :(22:49
lifelessjam: I thought there was a bug already. ce la vie22:50
jamlifeless: I had only seen one about a branch stacked on itself22:50
jamthis is a bit more complex22:50
jammwhudson: fail early with an exception rather than failing late22:50
mwhudsonjam: yes, but my brain is refusing to think about how to do that22:51
jammwhudson: well it is easy to do it for "Branch.open()" as you could just pass down 'seen_branches = [url1, url2]'22:53
jamI'm not sure how to do that for "set_stacked_on_location" unless we open that location, and check its fallbacks22:53
jamor we make "set_stacked_on..." always take a real Branch to start with.22:53
mwhudsonthat last feels a bit sane, at least22:54
ibrandtgioele: Hit another road block.  So I started fresh in /etc with just bzr init, bzr join httpd.  No errors, so I tried to commit that before adding everything else in /etc.  I get, "Committing to: /etc/ ; renamed  => httpd ; bzr: ERROR: An inconsistent delta was supplied involving 'httpdconf', 'conf-20091113022153-bk8us11fvhuf0cre-1' ; reason: working tree does not contain new entry"22:58
lifelessjam: http://staff.psc.edu/mathis/MTU/index.html is worth a read23:00
lifelessjam: I /really/ think upping the send and receive buffer size is important23:00
jamlifeless: Some interesting "hasattr() is evil" traceback: http://paste.ubuntu.com/321940/23:00
lifelessbefore changing the orderinging and compression logic23:00
jamThis is the error I got trying to branch bzr-svn23:00
jelmermwhudson: lp:~jelmer/meta-lp-deps/bzr-svn-reqs adds libapr1-dev and libsvn-dev to the dependencies (required for subvertpy)23:00
jamMy guess is that hasattr() is suppressing the StackOverflow exception23:01
lifelessyes23:01
jamand it ends up as an attribute error failure23:01
mwhudsonjelmer: ah23:01
mwhudsonjelmer: can you propose a merge?23:01
jelmermwhudson: Sure - Should I do that already, before the bzr-svn code has landed?23:01
jamlifeless: so I feel like I might have a handle on how to possibly do it on the client side, I don't have a good feel for what to do on the server23:01
mwhudsonjelmer: i don't really know how launchpad-dependencies works right now23:02
mwhudsonjelmer: now is good23:02
mkanatmwhudson: Just wanted to let you know that I'm on the loggerhead stuff today.23:02
mwhudsoni guess i should file an rt asking for it to be installed on the slaves...23:02
lifelessjam: well, if we start with bzr:// and test on that we can eliminate ssh interactions23:02
mwhudsonmkanat: woooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!23:02
PengLoggerhead stuff?23:02
gioeleibrandt: I have no clue about that :( especially so late at night ;)23:02
mkanatPeng: I was contracted to fix some loggerhead issues.23:02
gioeleibrandt: but many devs are here, fell free to bug them ;)23:03
PengCoool.23:03
mkanatOne's the memory leak issue, the other one I have to go look up to remember.23:03
ibrandtSure thing.  Thanks for the help.  Definitely made some headway.  Either join isn't baked, or more likely I'm just not understanding how it is supposed to be used.23:03
Pengmkanat: I love you.23:04
mkanatlol23:04
mkanatOh, right, the other one is bug 118625.23:05
ubottuLaunchpad bug 118625 in loggerhead "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/11862523:05
PengAh.23:05
mkanatmwhudson: Could you assign that bug and bug 156453  to me?23:05
jelmermwhudson, done23:05
ubottuLaunchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/15645323:05
Pengmkanat: lp:~mkanat?23:06
mkanatPengYep.23:06
mkanat*Yep23:06
mwhudsonmkanat: done23:06
mkanatmwhudson: Thanks!23:06
Pengmwhudson: You're quick. :)23:07
mwhudsonmkanat: you could probably join ~loggerhead-team i guess23:07
lifelessjelmer: still around?23:07
mkanatmwhudson: Yeah, possibly. Let's see how these two bugs go first, I think.23:07
jelmerlifeless, jep23:08
* mkanat tends to be very conservative about being assigned privileges or responsibilities. :-)23:08
lifelessjelmer: did you see the reviews I did?23:08
mwhudsonmkanat: does https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/12 make sense to you?23:08
ubottuLaunchpad bug 118625 in loggerhead "codebrowse sometimes hangs" [High,Triaged]23:08
lifelessjelmer: bzr-gtk doesn't have ~bzr as a member, or something - I can't actually approve or land things there.23:08
mwhudsonalso https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/1323:08
jelmerlifeless: ah, yes23:08
mwhudsonmkanat: basically i think the problems revolve around the revision graph cache23:08
lifelessjelmer: so you need to land em :)23:09
jelmerlifeless: I thought we made you a member of bzr-gtk some time back ?23:09
mkanatmwhudson: Yeah, that makes sense.23:09
jelmeror was that just in bundlebuggy?23:09
mwhudsonmkanat: if you can confirm that, it would be great to make building it and accessing it less all or nothing things23:09
mkanatmwhudson: I'm going to do my best to reproduce it, yeah.23:09
mkanatmwhudson: Okay.23:09
lifelessjelmer: bb I suspect23:09
lifelessjelmer: I'd add ~bzr23:09
lifelessunless you really want a partition23:10
mwhudsonmkanat: cool23:10
jelmerlifless: My main reason for not doing that yet is that everybody in ~bzr-gtk can commit directly to lp:bzr-gtk23:10
mkanatI'm already pretty sure I can repro the memory leak, because it happens on my own servers.23:10
mwhudsonmkanat: let me know if you want some logfiles to poke at23:10
jelmerlifeless, and I wasn't really sure what the membership policy for ~bzr was23:10
mwhudsonmkanat: although local reproduction would be better of course23:10
lifelessjelmer: you could ask :)23:10
mkanatmwhudson: Yeah, I totally will. Do you have a logfile analyzer for loggerhead or anything (since they get pretty big)?23:10
lifelessjelmer: also, I hear you can uncommit things that shouldn't be landed23:10
lifelessthere is also a '~bzr-core' team, I believe23:11
jelmerlifeless: Yes, but that would have taken *effort* :-)23:11
lifelessthough ~bzr-core includes bzr23:11
lifelesswhich is odd/inverted23:11
mwhudsonmkanat: i've written a bunch of crappy python scripts over the years :)23:11
mwhudsonthey're big but not totally crazy23:11
* mkanat nods.23:11
jelmerlifeless: Wasn't either one invented because people didn't want to receive email about other projects than lp:bzr ?23:12
lifelessyes, I think that is -core23:12
lifelessits not core in the sense that other projects use -core23:12
lifelessjelmer: https://edge.launchpad.net/~bzr/+members#active looks fairly sane23:13
lifelessnevertheless, I don't really care. I've reviewed all outstanding bzr-gtk merges, you need to land em :)23:13
jelmerlifeless: I've added ~bzr to ~bzr-gtk23:14
lifelesscool23:14
mwhudsonmkanat: have you seen the launchpad-loggerhead glue?23:24
mkanatmwhudson: No, I haven't.23:25
mwhudsonmkanat: https://code.edge.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel23:25
mkanatmwhudson: README should mention pygments too, shouldn't it (just as a side note)?23:25
mkanatmwhudson: Thanks.23:25
mwhudsonmkanat: i guess so23:25
mwhudsonmkanat: do you have a launchpad dev environment?23:27
mkanatmwhudson: I don't, at the moment, no.23:27
mkanatmwhudson: I may need to set that up for the hangs one.23:27
mkanatmwhudson: The memory leak one is independent of launchpad, for sure (since I experience it), so I can test that one separately.23:28
mwhudsonmkanat: i don't _expect_ either to be launchpad specific23:28
mwhudsonmkanat: although we do have scary thread killing code on launchpad23:28
mkanatmwhudson: Do you know about this? AssertionError: Attempt to set headers a second time w/o an exc_info23:38
mkanatmwhudson: I get that a LOT if I htdig a local loggerhead.23:38
mwhudsonyou get that if rendering fails somehow23:39
mwhudsonand oh man getting simpletal to tell you where something went wrong is ****ING ANNOYING23:39
mkanatlol23:39
mkanatYeah, I'm getting various tracebacks for that assertion.23:40
mkanatI seem to be reliably making the process grow, though.23:40
mwhudsonmkanat: we stream the output so the headers are set by the time rendering is happening23:40
mwhudson(and we don't want to change that)23:40
mwhudsonmkanat: time to break out meliae!23:41
mkanatmwhudson: Indeed!23:41
mkanatI'm just taking a bit of time to see if I can get it as big as it was on my servers, or if it's just going to hit a ceiling and stop (which wouldn't seem like a leak to me).23:41
igcmorning23:42
lifelesshi igc23:45
igchi lifeless23:46

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