lifelessRaw size 346188021300:12
lifelessCompressed size 14115237100:12
lifelessCompressed size 50855500:12
lifelessthats the inventories from my main bzr repo00:13
davidstraussMerging with no common ancestor is not working properly for me.00:13
lifelessJc2k: ^ guess what the bottom compressed size is from00:13
lifelessdavidstrauss: what it is doing00:13
davidstrausslifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches00:14
davidstrausslifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge00:14
davidstrausslifeless: And I get TONS of conflicts00:14
lifelessif you run bzr init and add in a new tree,then the files have new identity00:15
lifelessso when you merge, and they have the same path, its a file name conflict00:16
davidstrausslifeless: how can i force a common ancestor00:16
lifelessstart from trunk rather than by doing 'bzr init'00:16
davidstrausslifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own00:16
lifelessI'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about00:16
davidstrausslifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades00:17
lifelessdavidstrauss: ah00:18
davidstrausslifeless: despite having no established common ancestor00:18
lifelessso the -r x..y syntax will force an ancestor of x00:18
davidstrausslifeless: yes, but we get tons of conflicts00:18
lifelessbut the /content/ of the trees is unrelated, I would expect tons of conflicts00:18
lifelessdo you know much about bzr internals?00:18
davidstrausslifeless: not for content IDs00:19
lifelessok, very quick primer so my answers will make sense to you00:19
m4vhi, quick question, does bzr track file permissions?00:19
lifelessm4v: execute bit only00:19
bob2only execute00:19
davidstrausslifeless: is there a way to force bazaar to understand that file name match = content match?00:19
lifelessm4v: see etckeeper for tracking full permissions, which supports bzr00:19
lifelessdavidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object00:20
davidstrausslifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry00:20
davidstrausslifeless: I mean, there *has* to be a way to merge efficiently without common ancestry00:21
lifelessdavidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id.00:21
lifelessdavidstrauss: over time you can get many different paths having the same id - when things are renamed and so on00:21
lifelessdavidstrauss: so, to do a merge with an unrelated tree00:21
lifelessdavidstrauss: such that future merges can be no-brainers00:22
lifelessdavidstrauss: you have to replace the fileid of *every* file that is in the source tree and in the target tree, with the fileid from the sourcetree00:22
davidstrausslifeless: is there a way to do that automatically?00:22
lifelessthen you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost00:23
davidstrausslifeless: Is there a way to do that branch-wide?00:23
lifelessyou need to identify the common revision in both branches as well00:23
m4vlifeless: alright00:24
lifelessdavidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up00:24
davidstrausslifeless: identifying the common revision in both branches is already part of my procedure00:24
lifelessdavidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed00:24
davidstrausslifeless: so is there an efficient way to resolve the conflicts?00:25
garyvdmvila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory.00:25
lifelessdavidstrauss: it is scriptable in python00:26
davidstrausslifeless: has it been scripted?00:26
lifelessdavidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless00:26
lifeless11:21 < lifeless> davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up00:26
davidstrausslifeless: what would the custom conflict resolver look like?00:27
davidstrausslifeless: would it be in python or a shell command?00:28
lifelessdavidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself00:31
lifelesshttp://paste.ubuntu.com/106710/ <- knit vs gc compression00:32
lifelessshort story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment00:33
davidstrausslifeless: what is gc compression?00:36
lifelessdavidstrauss: its a new delta compression I'm evaluation for bzr00:39
davidstrausslifeless: is there a way to specify an external merge tool that runs in the shell?00:44
lifelessI think the extmerge plugin does this00:44
lifelessnote though that I don't think it will handle the file id changing that you need00:44
lifelessfundamentally this needs code written to support it00:44
davidstrausslifeless: I think this is one area git's architecture shines.00:47
lifelesswell its certainly simpler there, for git or hg00:47
lifelessits the inode abstraction that makes it complex to handle parallel imports00:48
lifelessI encourage you to file a bug, this is something we should put a canned answer to in the core00:48
lifelessfor now, people that want to move onto your branch would be best served by:00:49
lifeless - pull your branch00:49
davidstrausslifeless: would that handle the file ID mismatches?00:49
lifeless - apply their local changes as a plain patch (bzr diff -r x..y | bzr patch)00:49
lifelesscommit that patch00:49
lifelessthen they are descendants of your branches00:50
davidstrausslifeless: so, basically, start fresh00:50
davidstrausslifeless: this seems similar to when you bzr bind after divergence00:50
lifelessgc is faster at compression, sweet00:52
jelmerwe have a gc?00:55
davidstrausslifeless: https://bugs.launchpad.net/bzr/+bug/31862000:57
ubottuLaunchpad bug 318620 in bzr "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Undecided,New]00:57
lifelessjelmer: groupcompress00:58
lifelessdavidstrauss: thank you00:58
garyvdmWhat do you guys think about merging a number of revisions that are currently the tip of your mainline, with an older revision, just for the sake of grouping them together?01:07
garyvdmI think I better pastebin a dag to explain this..01:08
lifelessgaryvdm: you can do it if you want01:10
lifelessit just makes it look like a merge of a branch01:10
garyvdmHere is my dag just to make sure we are on the same wave length: http://pastebin.com/d2383655901:12
jelmerlifeless, ah, that makes more sense (-:01:14
spivjelmer: bzr-svn is working well for me these days, btw.01:18
jelmerspiv, cool01:18
spivjelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos.01:18
spivjelmer: I have some hackery to submit to make it import faster, though :)01:19
spiv(e.g. don't import subertpy all the time, etc)01:19
spivjelmer: it even does find_tags at a bearable speed now :)01:19
jelmerspiv, patches for import improvements are more than welcome01:20
thumperhi ho01:50
thumperI just went bzr init, and bzr stat01:50
thumperand got a traceback01:50
thumperis this a known bug?01:50
thumperbzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'01:50
jelmerthumper, do you have loom installed?01:51
jelmerthumper, I think you need a newer version of loom01:51
thumperplugin installed, yes01:51
thumperusing it, no01:51
jelmerit wraps bzr status but doesn't cope with a new argument that has been added to status01:51
jelmereven if you're not using it01:51
jelmerthe last revision of the loom trunk fixes it01:53
thumperbzr log --line -r-10..-1 now gives be non-mainline messages01:54
thumperthis is very new01:54
thumperand I can't go --line --short, as that doesn't work01:55
jelmeryeah, I can confirm that has changed since 1.1101:55
thumpercan we change it back?01:56
thumperit is really annoying01:56
jelmerI'm not sure it's intentional or a regression that is a side-effect of the recent work on log01:57
thumperI don't think it is intentional01:57
jelmerprobably worth filing a bug about01:57
thumperigc: my log --line now shows non-mainline revisions01:58
lifelessjam: are you around by chance?02:02
igcthumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't02:15
igcI'll do it now02:15
thumperigc: that'd be grand02:28
igcthumper: in the pqm queue now02:29
* igc lunch02:29
thumperigc: fantastic02:29
igcthumper: try bzr.dev now and let me know if it's still broken03:08
thumperigc: ok03:08
mwhudsonoops, 700 unread emails on the bzr list03:08
S11001001hello all03:30
S11001001I am maintaining a Trac with some modifications (my.desktopdoctorsinc.com) using a Bazaar branch.  I'm in the process of rebuilding it with upstreamable changes (~30% of the code) separated out.  I've built a bzr-loom with 7 patches so far, mostly non-interdependent, and can probably get a few more into upstreamable state.  I tend to merge upstream at new releases, the changes are typically larger than the total of all changes in my03:30
S11001001branch, and there are usually 2-3 conflicts.  Question is, would I be better off sticking with loom, or keeping separate ordinary branches for these changes?03:30
lifelesseither is fine03:35
thumperigc: lp:bzr is a few revs behind by the look of it03:52
spivthumper: it's 3 hours behind, on average ;)03:54
thumperspiv: funny man03:55
thumperso when is bzr going to host trunk on LP?03:55
pygigoooood morning04:52
pooliehello pygi05:32
pygipoolie, :)05:47
pygichapter 1 coming to your address this week :)05:47
davidstrausslifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem06:23
=== aumontabe is now known as abeaumont
vilahi all07:35
igchi vila08:03
davidstraussWhat is the status of nested trees?08:36
Lo-lan-doThey're full of birds?08:37
jmldavidstrauss: they aren't there yet. interest is being renewed though.08:39
davidstraussjml: The Drupal project is very interested in getting this support stable.08:39
davidstraussjml: So we can effectively consider Bazaar for module development on Drupal.org08:39
sdboyerjml: like, very interested :)08:39
* fullermd frowns.08:41
fullermdNEWS is looking a little odd.08:42
jmlsdboyer, davidstrauss: I *think* abentley intends to work on it very soon.08:42
jmlbut I couldn't say for sure.08:42
fullermdpoolie: It looks like r3940 spuriously added a whole separate section on top of NEWS08:43
sdboyerjml: well, our timeframe for making a vcs switch is anything but clear, but nested trees would be a _huge_ deal for us, so if part of the hold-up is having a really rigorous use case to put the code through, that's something we can provide08:46
jmlsdboyer: cool :)08:46
lukscan't https://launchpad.net/bzr-scmproj be used as an alternative?08:49
* jml doesn't know anything about it.08:50
* igc dinner09:02
davidstraussbzr-scmproj looks kind of clunky09:03
pooliedavidstrauss: it's trying to do it in a kind of minimal but useful way09:29
vilaluks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though09:31
pooliehello vila10:10
vilahey !10:10
fullermdpoolie: Did you catch my above?10:19
poolieabout news, or about nested trees?10:28
pooliei saw both10:28
pooliei'm making 1.11final tonight, and then will merge back and fix the news10:28
* fullermd nods.10:28
fullermdJust making sure IRC didn't eat it   :)10:28
* davidstrauss smiles in anticipation of 1.1110:29
fullermdShucks, that means I have to update the port...10:30
=== asac_ is now known as asac
LarstiQsdboyer, davidstrauss: yeah, that would help10:43
* LarstiQ thinks he may need to rethink the current approach10:43
sdboyerLarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :)10:46
LarstiQsdboyer: k, I'm in utc+1/+#10:46
davidstrausssdboyer: It's the same time here10:46
LarstiQsdboyer: currently in .nl10:46
LarstiQand some of my time in .fi10:47
fullermdHeck, it'll be that time here in about 15 minutes   ;p10:47
davidstraussI think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant.10:47
* LarstiQ nods10:48
sdboyersure. my interest in having nested branches really working prior to us beginning our coding work is that i'd rather do it all in one fell swoop10:48
* sdboyer is wary that delaying a piece like that until later could very well mean that by the time nested branches are ready, our coders have found other itches to scratch :)10:49
sdboyernot essential for implementation, but probably wise.10:50
sdboyerhowever, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P10:50
fullermdA lot of things are easier to setup than to re-setup..10:50
* sdboyer agrees with fullermd wholeheartedly10:51
* sdboyer waves g'night10:51
LarstiQpoolie: the only other moves on nested trees has been scmproj, right?11:06
pooliei think so11:10
LarstiQpoolie: and/but there is still interest in getting it done?11:17
LarstiQ(well, I know I'd _like_ to have it, but progress has been meh)11:17
Peng_Oh god. Now that bzr-svn can finally handle a certain pair of branches, bzr-search can't!11:18
Peng_lifeless: ping11:18
poolieLarstiQ: interested in working on it?11:39
pooliei heard you had a branch that fixed some subtrees bugs?11:39
LarstiQpoolie: I have a couple of small fixes. From time to time I try to merge bzr.dev, but with the 100k diffs, it's not the easiest thing to do and not very motivating11:43
* LarstiQ needs to put more regular time into it to move it forward11:43
LarstiQpoolie: I'd very much like to get this moving somehow, yes.11:44
pooliewell, send them up and hopefully we can gradually reduce the problems11:44
pooliedo they fix failures when a subtree format is the default?11:44
LarstiQthey fix failures on subtree formats, I don't know about specifically that being the default, but with bugs in the usage of subtrees, it's not ready for that yet anyhow11:45
pooliei'm just wondering what tests you added to get failures11:48
poolieor what you changed11:48
pooliesince the trunk test suite does not fail, it's presumably not testing everything11:48
LarstiQpoolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch11:49
LarstiQpoolie: which is, afaik, the only place where work on by-reference trees is11:50
LarstiQpoolie: and by reference is I think where the brunt of the usecases are11:53
Jc2klifeless: omg is that groupcompress!?!?!11:57
james_wpretty amazing :-)11:58
* LarstiQ goes to lunch12:03
pooliehello jc2k, james_w12:06
james_whi poolie12:06
=== poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11 (released 19 Jan) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
Jc2khi poolie12:06
Lo-lan-doI can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about.  Any pointer?12:17
james_wLo-lan-do: I don't think so. It's a new compression strategy for storage of texts inside packs (or anything else really)12:18
james_wit's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas12:19
Lo-lan-doOkay.  So smaller repository sizes, I guess?12:19
james_wcurrently decompression time, and I imagine annotation time, but that may not change as packs already damaged that12:19
james_wyes, *massively* smaller in the current implementation12:20
Lo-lan-doA new storage format too, I suppose.  Will it be compatible with the current ones?12:20
james_wbut that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion12:21
Lo-lan-doUm, yeah, sounds not-very-nice indeed.12:21
james_wyeah, it's just a change in the internal compression, so it will be a new format, but not a watershed one or anything.12:21
Peng_Can throwing more Pyrex/C at the problem improve decompression time?12:21
Peng_(I guess not if it's all in zlib.)12:21
james_wfirst thing will be to try limiting the delta chains. That will lose some of the win in terms of compression, but may still lead to a better overall format12:22
poolieit's currently only for inventory data12:22
poolieso the point is to speed up commit and extraction12:23
james_wah, I thought it was texts too12:23
pooliethe decompression time is something that still needs to be solved before we go ahead with ti12:23
poolieit could be applicable12:23
james_wis there any plan to move away from XML inventories?12:23
poolieto file texts too12:23
pooliehowever, for reasons i don't want to go into right now, it has some troubles with big files12:24
poolieie it'll store too many full texts12:24
poolie(well, arguably too many)12:24
poolieLo-lan-do: it'll be backward/forward compatible12:24
pooliein the usual way12:25
ymlI thought it was possible to do a partial checkout of a bzr branch. I would like to create a branch with only a subfolder ot the complete bzr repository.13:28
ymlIs it possible ?13:28
luksit isn't13:29
ymlThank you for the confirmation13:33
beunoyml, you should, however, be able to export a directory13:33
ymlbeuno: how would you do this ?13:35
ymlI mean my branch is hosted on launchpad13:35
beunoyml, ah. I guess you can only do that with local branches13:37
=== kiko-afk is now known as kiko
igcnight all13:49
ymlbeuno: I see. Thank you for your help13:55
beunog'night igc13:56
ymlI will create a symbolic link to put the folder in my pythonpath13:56
edreamleoHelp!  Bzr is, all of a sudden, acting bizarrely.  It started reporting changed files, but bzr diff gives nothing and bzr commit said "useless commit"  I tried installing bzr 1.11 and 1.10 with no improvement.13:57
edreamleoI just tried bzr branch bzr/1.10 from c:\ (I'm using XP) and bzr appeared to install, but now I see no installed folder.13:58
edreamleoBTW, "changed" files happen just after a fresh bzr branch.  Is there a cache that should be cleared?14:00
Jc2kyou dont do bzr branch bzr/1.10 to install a new version..14:01
edreamleoJc2k.  True, I installed bzr 1.10 from a downloaded zip file.  But I wanted to use bzr to grab bzr sources, and that appeared to work.14:03
Jc2kdoes the output of bzr status say "unknown:" and then a list of file?14:03
edreamleoNo.  bzr status says modified.  The actual file appears random, but compares binary equal to the file in other branches.14:04
Jc2khow odd14:05
edreamleoBy "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch.14:05
edreamleoYes!  Odd indeed.14:05
Jc2ki had some weirdness moving branches between linux, flash drive and windows but this was over a year ago14:06
edreamleoAt first I suspected bad memory.  But the oddness happens on all branches.  Maybe a bit got flipped in a central .bzr folder?14:07
Jc2knot really sure, im not a dev and what bits of the code i know are related to the workingtree stuff14:08
edreamleoI wonder.  Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ?  I suspect not.  Any reason not to trash this?14:10
edreamleoIs there a trouble-shooting guide or FAQ?14:14
superm1Hi guys.  I'm wondering how to push my tags to the main branch in LP without doing another revision.14:34
superm1i can't appear to push because pushing requires a new revision14:35
Peng_superm1: Push will push tags even if there are no new revisions.14:48
superm1Peng_, is that only with newer versions of bzr?  I'm on hardy, so 1.3.1-1ubuntu0.114:48
james_wsuperm1: I'm not sure, how did you verify that the tags hadn't been pushed?14:49
Peng_superm1: I don't think it's a new feature.14:50
superm1james_w, i pulled from another computer that's regularly been pulling from that same branch14:50
james_wah, ok14:50
james_wit's probably just broken then, I don't remember it changing14:50
superm1okay, well surely i'll be doing another revision at some point from this branch then. the tags will get pushed up at that time at least14:52
Peng_WFM in bzr.dev.14:52
Peng_superm1: Does the LP branch support tags?14:52
Peng_superm1: Does it have any tags currently?14:52
superm1Peng_, oh you know what, i just tried to pull again and i *did* get the tag this time. it must have committed but there was just a delay before it was available14:53
superm1sorry for the chatter james_w and Peng_ but thanks for helping indicate that it should be working :)14:53
Peng_superm1: If you're pulling from http://bazaar.launchpad.net/, there might be a (short) delay, yeah. There isn't one for bzr+ssh or sftp.14:54
superm1Peng_, yeah i was pulling from http on the other computer, so that would explain it14:54
james_wglad to know it works :-)14:54
james_wthere's a bug open about it not telling you what it's done14:55
james_w"No revisions to push" should be extended to mention that it pushed some tags14:55
superm1yeah that would be useful14:55
jelmerjames_w: Hi15:03
jelmerjames_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging?15:03
james_wjelmer: I'm not15:04
LarstiQbeuno, mwhudson: similar to https://bugs.edge.launchpad.net/loggerhead/+bug/260547 when I try to run serve-branches proxied by an ssl apache site, links to ../changes or ../annotate drop back to http15:10
ubottuLaunchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Triaged]15:10
bvkhi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ?15:11
LarstiQbeuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do?15:11
bvkit never gets finished for me :(15:11
LarstiQbvk: your two alternatives are the same?15:11
beunoLarstiQ, fix it is always the first option  :)15:11
beunoif not, I think a comment on the bug is useful15:11
LarstiQbeuno: it is an area I'm rather unfamiliar with15:11
LarstiQbut I'll have a go15:11
LarstiQbeuno: any hints on where to start looking?15:12
jelmerbvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev15:12
bvkLarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere?15:13
LarstiQbvk: specifically to get one copy of bzr.dev? I could generate a tarball for you15:13
jelmerI'm curious though as to why branching lp:bzr doesn't work for you15:13
bvkLarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :(15:13
LarstiQbvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball?15:13
bvkLarstiQ: yes, that would be of great; thanks15:14
bvkLarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow15:15
LarstiQbvk: ok, it would be good to solve that if possible, but a tarball is coming up for you15:15
bvkLarstiQ: thanks LarstiQ15:17
LarstiQbvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz15:17
LarstiQbvk: that is my ~/src/bzr/bzr.dev as of now15:17
LarstiQbvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree`15:17
LarstiQyou would then have to `bzr co .` after unpacking and cding15:18
=== kiko is now known as kiko-fud
bvkLarstiQ: 5MB is fine, i can easily download that.15:19
bvkLarstiQ: Is the branch with full history is of only 5MB? Then why was bzr took more than half hour and still didn't complete :(15:22
Peng_I think LarstiQ left out the repo.15:23
LarstiQhmm, good point, I recall it being 40~ ish15:23
bvkwell, i was looking for a branch with full history :(15:24
LarstiQbvk: it does seem to be so15:24
bvkbtw, is there any way to make a branch with partial history? say, like 50 days history?15:25
LarstiQmeh, still not looking at the right place15:25
Peng_bvk: No, there's not.15:25
LarstiQbvk: --stacked might help you15:25
LarstiQthough it does not do it like that15:25
* Peng_ watches bzip2.15:25
Peng_bvk: http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar -- it's almost 100 MB, and you'll have to run "bzr co .".15:27
Peng_Ehh, http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.bz2 saves about 10 MB.15:28
LarstiQhth do I end up with a working standalonish branch but it's .bzr/repository is empty15:28
Peng_.bzr/repository exists but is empty?15:29
Peng_Maybe it's a stacked branch?15:29
LarstiQyeah, it is...15:29
LarstiQbvk: well. That explains why it is so small.15:30
LarstiQand why logging all took longer than expected15:30
Peng_http://cheezum.mattnordhoff.com/tmp/bzr.dev.r3945.tar.gz saves almost as much as the bzip2 version, and I'm going to stop now.15:30
Peng_Thank goodness I don't have p7zip, lrzip and lzma on that machine. ;)15:31
LarstiQnullzip? ;)15:31
Peng_"bzr branch"'s new progress bars are neat. Reminds me a bit of all the info git gives, only prettier. ;)15:32
LarstiQbvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc15:32
bvkokay, i just found out that i was using bazaar 1.5, where as latest one is at 1.1115:32
Peng_bvk: Ok, but 1.5 should work fine.15:32
Peng_Well, it'll probably be slower and use more RAM than 1.11, but it'll *work*.15:33
bvki just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-(15:35
bvki will upgrade my bzr and will try 'bzr branch lp:bzr' again15:35
Peng_Well, 1.5 can branch from lp:bzr fine.15:36
Peng_Or http://bazaar-vcs.org/bzr/bzr.dev/15:36
bvkPeng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish15:37
Peng_Cool, lzma saves close to 20 MB, and that wasn't with the best compression.15:37
Peng_bvk: You can't wait half an hour? What kind of Internet connection and computer do you have? Not some Pentium II on dial-up, right?15:38
Peng_Ohnoes, bzr.dev has a new revision. Now my tarballs are out-of-date. :P15:38
bvkPeng_: mine is macbook with 256Kbps internet15:39
Peng_bvk: 256 Kbps? Yeah, that could do it...15:39
Peng_...It'd take you a long time to download 100 MB, wouldn't it?15:41
LarstiQbvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch15:42
bvkPeng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D)15:42
LarstiQbvk: so if you extrac that, you can run the bzr _in there_ to branch with15:43
LarstiQjust run path/to/extracted/bzr.dev/bzr branch ...15:43
Lo-lan-doI usually try a "watch du -hs .bzr" when I wonder if it's stuck.15:43
Peng_bvk: Well, it probably wasn't hung. And the next version (not today's 1.11) should have much a much more active progress bar when branching.15:43
LarstiQLo-lan-do: did you see the progress indication that's not in 1.11?15:43
LarstiQLo-lan-do: it succeeds in subjectively making me feel it's waaaay faster15:44
LarstiQLo-lan-do: achieved by actually giving information :)15:44
Lo-lan-doLarstiQ: I've grown used to just switching to another virtual desktop for a while :-)15:44
Peng_Hmm, it's kind of creepy that the server lets me monitor how far along bvk's download is, and how fast it's going.15:45
Peng_Lo-lan-do: You should try it. It's very nice. It gives a running count of the revisions downloaded.15:45
LarstiQLo-lan-do: I picked up that skill when I was on cable. 8kbs up/down combined. Cable modem attached via serial to the pc. Best idea EVAR15:46
Lo-lan-doPeng: I'm switching back and forth between 1.5 and 1.11rc1 these days, actually.15:48
Peng_Lo-lan-do: 1.11 final is out. :D15:48
Lo-lan-do1.11rc1 seems nice, but the corresponding bzr-svn version takes half an hour for every operation I do on a branch bound to a remote SVN repo, so I often downgrade back to a version that "only" takes four minutes.15:49
Lo-lan-doNot in Debian yet => it doesn't exist :-)15:49
Lo-lan-do(I keep pestering jelmer about it, but I also try not to burn him out)15:50
=== Spaz is now known as Kittens
jelmerLo-lan-do: :-)15:53
jelmerLo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that15:53
Lo-lan-dojelmer: I'm trying to single out a bug in svn-import, too :-)15:54
jelmerLo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-)15:54
LarstiQbeuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere*15:56
Lo-lan-dojelmer: Okay.  Just ping me when it's < 29 then :-D15:56
beunoLarstiQ, a comment on the bug about the https is fine then  :)15:56
beunoyou did install python-pastedeploy, right?15:57
LarstiQbeuno: yup15:57
LarstiQbeuno: and it's working fine for my http vhost15:58
=== kiko-fud is now known as kiko-phone
LarstiQbeuno: added a comment16:11
LarstiQlifeless: is bicyclerepair completely bitrotted?16:18
jelmerany versionedfile API experts around?16:19
* LarstiQ hides16:19
jelmerLarstiQ, nevermind, already found the problem16:23
jelmerKnitCorruption caused by a text revision that has the same parent twice16:23
jelmerLo-lan-do, never mind me, it's actually at 27 already :-)16:24
Lo-lan-dojelmer: Does 0.5rc2 change anything related to deleted files by any chance?16:25
jelmerLo-lan-do: some things - what's the error you're seeing?16:26
Lo-lan-dobzr: ERROR: Unable to find file id for child 'editreleases.php' in 'gforge/www/project/admin' in <RevisionMetadata for revision 999, path branches/Branch_gforge in repository 'c3c08832-fc22-4c88-9867-b2b84583e700'>.16:26
jelmerah, good chance that's fixed in rc216:27
Lo-lan-doAt first I suspected that there was a problem with repacking (since I seem to remember it happens on or near revisions 10^n), but that's apparently a different problem.16:27
Lo-lan-doI'll try using http://people.samba.org/bzr/jelmer/bzr-svn/0.5 then, see if it helps.16:28
jinRoomaso if i push to an ftp server, does it upload every file, or just the modified and new ones?16:38
Peng_jinRooma: It uploads the new revision data.16:40
jinRoomaPeng_, when you say revision data, do you mean the actual files from the project16:41
Peng_jinRooma: No, I mean the data in .bzr.16:41
Peng_jinRooma: Push doesn't deal with working tree files; it deals with revisions.16:42
jinRoomaok i see. THe way i want to use it is, i work offline on my project, and i then synch it with the server on a daily basis16:42
Peng_jinRooma: In answer to your question, it only uploads the new data.16:42
Peng_(Well, it will sometimes download some of the old data, combine it into fewer files, and upload it again, but that shouldn't be a big deal.)16:42
jinRoomaI see, so bzr does do some analysis / comparison of local & remote, and make decisions based on this. its not just a dumb upload16:44
Peng_jinRooma: Right.16:46
Peng_Now, bzr isn't the fastest vcs ever, but you have to give it *some* credit. :P16:46
jinRoomaits the only vcs i have used, for some reason could not get my around sub version and cvs16:47
jinRoomabut im using it mainly for back up than versioning16:47
jinRooma... which is primitive but better than nothing16:48
jelmerLarstiQ, any idea what could cause a versionedfile revision to end up with the same parent twice?16:48
jelmerget_parent_map() seems to filter out the duplicate parent unfortunately, but add_lines() complains16:49
jinRoomai should probably use rsync or some such for my needs16:52
LarstiQjelmer: I don't know, but yesterday I got my bzr.dev in a state where I can't revert because I have two parents or some such16:55
Peng_Does anyone else care about my bzr.dev tarballs, or can I delete them now? bvk?17:45
bvkPeng_: you can delete it now; thanks a lot17:47
Peng_bvk: Alright.17:48
Lo-lan-dojelmer: Back to 28, I'm afraid :-/18:11
Lo-lan-do(Report sent, off for dinner, back later if you have any insights)18:12
jelmerLo-lan-do, :-(*18:19
jelmerrocky, hi18:19
jelmerrocky, I've worked around the bug you were seeing, but I think it's a bug in bzr.18:19
rockyjelmer: heyo18:19
jelmer(not committed to 0.5, as it degrades performance, especially on large trees)18:19
jelmerhopefully one of the australians can shed some light on the actual problem when they wake up18:21
jelmeralternatively, there's a one-line fix to bzr that will work around it without any performance regressions18:24
jelmerLo-lan-do, ENOBUGREPORT18:24
bvkhi, is there any bzr plugin that would allow me to maintain bugs (and messages) within the code repository?18:26
jelmerbvk, You mean something like be (BugsEverywhere)?18:30
jelmersee bugseverywhere.org18:31
bvkjelmer: well, i don't know about bugseverywhere; let me check it out18:31
jelmerrocky, alternative test http://samba.org/~jelmer/tmp/fix-add-records-dupe-test.diff18:33
bvkjelmer: yes, it is what i was looking for. thanks18:39
mwhudsonLarstiQ: i'd actually just noticed something similar the other day18:47
mwhudsonLarstiQ: file a bug, i guess18:47
Lo-lan-dojelmer: http://bugs.debian.org/51232519:20
jelmerLo-lan-do, thanks, just found it19:20
jelmerI'm trying an import now, at r6132 atm19:21
Lo-lan-doI was puzzled by the fact that it copies something like 11k revisions even though there are less than 7k in the SVN repo.19:21
jelmerLo-lan-do, Some svn revisions probably cause multiple bzr revisions19:22
Lo-lan-doI supposed that much.  Like, maybe some commits touched files in several branches at once.19:23
Lo-lan-doNot very important anyway.19:23
flacostei've got a problem with bzr-svn repository19:25
jelmerhi flacoste19:25
flacostehi jelmer!19:25
flacosteI have a bzr-svn branch tracking Windmill repository19:25
flacostethey moved to a failover server19:25
flacosteand now I get the following error when I do bzr pull19:25
flacostehttp://svn.getwindmill.com/trunk is permanently redirected to http://svn.getwindmill.com/trunk/19:26
flacostebzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Chemin '/windmill/!svn/vcc/default' non trouv\xc3\xa9", 175007)19:26
flacostei can load the URL in the browser fine19:26
flacosteIn English, the message reads "Path '...' not found"19:27
jelmerflacoste, This fails for me as well:19:27
jelmersvn ls http://svn.getwindmill.com/trunk/19:27
flacostehmm, yeah, they just found that out :-)19:27
flacosteok, it's probably an error on their end then19:28
flacostesorry for the noise19:28
jelmerLo-lan-do, did you remove the svn-cache as well as the bzr repository prior to trying the import?19:52
Lo-lan-doAh, damn.  No, I didn't.  Should I do that?19:53
* Lo-lan-do tries19:54
lifeless-> LCA19:54
lifelessjelmer: compressbench may interest you, for your xdelta apply/create code19:54
lifelessJc2k: did you see my gc stats?19:55
jelmerlifeless, 'morning19:55
jelmerLo-lan-do, oh, never mind19:55
jelmerLo-lan-do, just reproduced it19:55
jelmerlifeless, cool, I'll have a look19:55
jelmerlifeless, still there?19:55
Jc2klifeless: yes19:55
jelmerlifeless, quick question about knits19:55
Jc2klifeless: my reply was something like "omg thats groupcompress?!?"19:55
lifelessJc2k: :)19:56
jelmerlifeless: what are the contents of node_refs ? The first part of the tuple are the parents of the text, what is the second?19:56
lifelessjelmer: node refs in indices is a list of lists of keys19:56
lifelessjelmer: for knit mapped packs19:56
lifelessjelmer: if the knit is defined with parents=True, delta=True, then the node refs length is 2, the first element is parents, the second is the compression tree19:57
lifelessjelmer: in all bzr repositories, the second must be either empty, or the first parent.19:57
Peng_lifeless: "-> LCA"?19:57
lifelessbut its intended to be arbitrary19:57
lifelessPeng_: linux.conf.au19:57
lifelessjelmer: just not implemented yet19:57
lifelessjelmer: if delta=False, parents=True, the node refs length is 1, parents only19:58
lifelessjelmer: and False False is length 019:58
jelmerlifeless, I'm seeing weird errors where add_record() crashes because the existing node_refs[1] contains the first parent and we're trying to add node_refs[1] that is an empty tuple19:58
lifelessjelmer: finally, delta=True, parents=False, is unimplemented in knits today19:58
lifelessjelmer: thats when one repository has a text compressed, and the other has a full text. The cross check is overly strict - that is a bug19:59
flacostejelmer: they fixed it, but now when I bzr pull, it's refetching everything19:59
Peng_lifeless: I wanted to bug you about something: One of my bzr-svn branches makes "bzr index" die, with "Did not find ids set([some file IDs])".19:59
lifelessPeng_: please file a bug19:59
Peng_lifeless: Alright.19:59
lifelessPeng_: I'll ask you to run some custom code based on the details in the bug report, but I have a plane to catch now, so can't do it interactively20:00
jelmerlifeless, Ah, thanks!20:00
jelmerflacoste, did the repository change in some way ? Did you upgrade bzr-svn?20:00
flacostejelmer: you mean the SVN repository, i don't think so, and I haven't update bzr-svn in a while20:01
flacostejelmer: actually, i don't know if it will create new BZR revisions20:02
flacostethe message is20:02
flacosteInitialising Subversion metadata cache in /home/francis/.bazaar/svn-cache/7915dd7d-006c-436d-aff2-976aa4ca864120:02
flacosteand then fetching all revisions20:02
flacostebut if that metadata is keyed by hostname, then i guess it would be normal20:02
flacosteto refetch everything20:02
lifelessflacoste: thats the svn repo uuid20:03
flacostethe question is, will this create new bzr revisions20:03
lifelessflacoste: its stored in the repository20:03
lifelessflacoste: and yes20:03
flacosteok, so copying the repository files should preserve the UUID?20:03
lifelessflacoste: I'm not sure exactly where it is stored, so can't answer that20:03
flacoste"It's a scripted mirror of the original repo, so it should be the same."20:03
lifelessgod, that could mean anything20:04
flacostethey are using svnsync20:05
Jc2kflacoste: by default svnsync would have a different UUID, but i have a hack on bzr-mirror to preserve the UUID20:06
flacosteJc2k: can this help me?20:06
flacostei mean can I use this to trick bzr-svn in considering the two UUIDs as identical20:07
Peng_Wow, "bzr check" sure spams .bzr.log.20:08
Jc2kflacoste: i dont know enough about what you are encountering20:10
flacosteJc2k: i have a bzr-svn branch of Windmil and the main server became unavailable, they had to switch to a failover mirror20:11
flacosteJc2k: now when I do a bzr pull, it refetches every revision although there should only be about 4 or 5 that I don't have20:11
flacosteand I get:20:12
flacostebzr: ERROR: These branches have diverged. Use the merge command to reconcile them.20:12
flacostebut that's not accurate20:12
Jc2ktheir failover mirror will have a different UUID; do you know if you can svnsync from their mirror?20:12
flacostei don't know, i could check20:13
flacostehow would that help?20:13
jelmerflacoste: Do you have any local changes? If not, you can just "bzr pull --overwrite"20:13
jelmerflacoste, if you had a svn checkout I think you would get errors as well since the UUID of the repository changed20:14
flacostei don't, ok, i'll do this20:14
Lo-lan-doDoes svnsync preserve the uuid?20:16
jelmerLo-lan-do, not by default I think20:16
flacostejelmer: but will this break merging?20:17
Peng_jelmer: With the fix for bug 308353, will bzr-svn create any particularly convoluted history?20:17
jelmerflacoste, merging from where?20:17
ubottuLaunchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/30835320:17
Peng_jelmer: Because that's what breaks bzr-search. :)20:18
flacostejelmer: for example, if I merge the new branch into one made from the previous repository20:18
Peng_lifeless: Filed bug 318935.20:18
ubottuLaunchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New] https://launchpad.net/bugs/31893520:18
jelmerflacoste, that will break, since they are fundamentally different repositories20:18
flacosteanyway to hack it?20:19
jelmerflacoste: Fix the upstream repository20:20
flacosteand is there an easy way to do this?20:20
Lo-lan-dojelmer: You're right.  But one can hack the mirror's UUID by hand, according to http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt20:20
flacosteusing svnsync?20:20
jelmerflacoste, svnadmin setuuid can do that for you20:21
jelmerPeng_, Not that I'm aware of20:23
guilhembivila: still there?20:24
flacostejelmer: setuuid is only a 1.5 command and they are running 1.4 :-(20:25
Lo-lan-doflacoste: What about "vi db/uuid"?20:26
flacosteLo-lan-do: is that safe?20:26
Lo-lan-doIt may not be safe at all, I have no idea.20:26
Lo-lan-doIt's just that the uuid seems to be stored there.20:26
Lo-lan-doIf it's *only* stored there, then my guess is that it's safe, but...20:26
LarstiQLo-lan-do: seems like it's time for some experimenting! ;)20:28
Lo-lan-doYeah, I'm currently "experimenting" with grep -r :-)20:28
Lo-lan-doOnly one result.  db/uuid.20:28
Lo-lan-doMaybe it is safe after all.20:29
LarstiQwhat about the svnadmin setuuid source?20:29
wgrantLo-lan-do: I edited db/uuid in a fresh repository recently, and it worked fine.20:30
Lo-lan-doI'll read that too, although I don't really care for it (I was only asking about uuids out of curiosity).20:30
* Lo-lan-do deflects stuff to flacoste 20:30
flacostethere is a solution ^^^20:30
Lo-lan-doLarstiQ: The source code has so many layers of indirection I gave up.20:33
wgrantI think one of my branches has suffered from bug #302698. Shall I just push my local copy, overwriting the remote branch?20:33
ubottuLaunchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/30269820:33
=== spm_ is now known as spm
=== davidstrauss is now known as dav1d
alevineanybody have experience with bzreclipse? When I import a project by branching it, it seems to freeze21:25
guilhembivila: sent a mail. Bonne nuit!21:38
Necorohey - is it possible to get the branch status w/o invoking bzr? - or at least to implement such things in C f.ex.21:47
Necorobecause I want to display whether a bzr branch has been changed in my shell prompt21:47
Necoroand invoking bzr for this is way too slow21:48
jelmerNecoro, no you really need bzr for that21:48
jelmeryou may be able to use the bzr service stuff though21:48
Necoro(I already managed to get rid of the "bzr nick" and "bzr revno" calls)21:48
jelmer(keeps bzr running in the background and makes incremental calls faster)21:48
Necoro"bzr service stuff" <-- sounds interesting ...21:49
Necorodocumentation somewhere?21:49
jelmerlaunchpad.net/bzr-service I think21:49
Jc2kjelmer: wow, someone already made the crack i was daydreaming about!!21:53
jelmerJc2k, the ssh stuff you mean?21:54
Jc2kjelmer: no, bzr-service!21:55
jelmerwhere someone is jam I think21:55
Necorohmm - bzr-service seems to be outdated though21:55
Jc2kyes :(21:56
Jc2khmm, didnt take much to make it work again tho21:59
NecoroI needed to deal a bit with imports ... but as I don't know the bzrlib API, this can only be counted as workaround22:00
Necoroit's fast however22:00
Necoroinstead of using TCP/Unix Sockets/FIFOs one could also implement this using DBus22:01
Necoro(at least for unix)22:02
mwhudsonbzr-service needs more unix crack related to pty's and pipes22:02
Necorowhich would also allow to omit explicitly starting the service ;)22:02
Jc2ki just added an import bzrlib and killed the call trace.something and it worked22:02
sevenseekerI have been making changes to various files and just noticed I accidentally deleted an entire directory22:14
sevenseekerhow do I restore it and keep my changes?22:14
mwhudsondoes bzr revert directory-you-deleted work?22:15
beunomwhudson, I think that if the directory isn't there, bzr will barf22:15
beunomaybe not barf, but not do what you'd expect  :)22:15
sevenseekeraha, yes... I don't know what I fat fingered earlier but it works great22:16
* sevenseeker is embarrased22:16
Necorohmm ... my shell prompt now works ;)22:17
Necorothough there are still some rough edges with bzr-service22:17
=== kiko-phone is now known as kiko-afk
alevinehow can I import an authenticated svn repo into bzr? when I try I get a 401 error and when I add username@ I get a traceback22:28
Necoroand I guess, I'll take the bzr-service client instead of bzr whenever possible ;)22:29
Necoroshould be much faster22:29
jelmeralevine, prefix the URL with "svn+"22:32
alevinejelmer, thanks so much. did i miss something in documentation?22:33
alevineit says its deprecated22:33
alevineor is it just the fact that it cant figure out that it's subversion because it is authenticated22:34
jelmeralevine, yeah, it's deprecated - it's a workaround around a bug in bzr itself22:35
Necoroperhaps bzr-service should get polished and directly integrated into bzr ... this will probably be sufficient to reduce the "bzr is sooo slow" voices a bit22:37
alevinejelmer, good to know i really appreciate you being here to tell me that22:37
jelmeralevine, np22:37
jelmerNecoro, bzr-service has several issues, I think they're mentioned on the main page22:38
Necorojelmer: only "unsecure" and "works only on windows" ... if you accept the last one as "who cares", the first one should be easy to fix22:39
jelmerNecoro: bzr service will run under a different terminal22:40
jelmerthat causes several problems for e.g. the GUI tools22:40
jelmerand I doubt it supports overriding environment variables right now22:41
Necorohmm ok22:42
alevinejelmer, do you happen to know if branching an svn repo will download every file for every revision regardless of it has changed or not22:55
jelmeralevine, It will not download files when they have not changed22:56
alevinehm, ok. thanks22:58
thumperigc: I've confirmed with bzr.dev that log --line doesn't show non-mainline revs for me now23:25
_raz_does anyone know why the .bzr dir and files have a wrong mode in 1.10?23:41
_raz_I cannot do a brnch or pull on the remote directory via ftp23:42
_raz_as it seems, the files have no rights at all, directories only u+rwx23:43
_raz_according to the launchpad tracker that was already fixed23:43

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