| lifeless | meep | 00:12 |
|---|---|---|
| lifeless | Raw size 3461880213 | 00:12 |
| lifeless | Compressed size 141152371 | 00:12 |
| lifeless | Compressed size 508555 | 00:12 |
| lifeless | thats the inventories from my main bzr repo | 00:13 |
| davidstrauss | Merging with no common ancestor is not working properly for me. | 00:13 |
| lifeless | Jc2k: ^ guess what the bottom compressed size is from | 00:13 |
| lifeless | davidstrauss: what it is doing | 00:13 |
| davidstrauss | lifeless: http://fourkitchens.com/blog/2009/01/17/distributed-version-control-provides-streamlined-alternative-vendor-branches | 00:14 |
| davidstrauss | lifeless: I'm trying the commented operation, but with "bzr merge --revision=1..-1 bzr://vcs.fourkitchens.com/drupal/6" as the merge | 00:14 |
| davidstrauss | lifeless: And I get TONS of conflicts | 00:14 |
| lifeless | if you run bzr init and add in a new tree,then the files have new identity | 00:15 |
| lifeless | so when you merge, and they have the same path, its a file name conflict | 00:16 |
| davidstrauss | lifeless: how can i force a common ancestor | 00:16 |
| lifeless | start from trunk rather than by doing 'bzr init' | 00:16 |
| davidstrauss | lifeless: that's impossible. the whole point of this procedure is that you've started your own project on its own | 00:16 |
| lifeless | I'm sorry if I'm not being really helpful - I'm trying to understand what your blog post is about | 00:16 |
| davidstrauss | lifeless: i want people who have drupal projects in bazaar branches to be able to migrate to using our drupal bazaar branch for upgrades | 00:17 |
| lifeless | davidstrauss: ah | 00:18 |
| davidstrauss | lifeless: despite having no established common ancestor | 00:18 |
| lifeless | so the -r x..y syntax will force an ancestor of x | 00:18 |
| davidstrauss | lifeless: yes, but we get tons of conflicts | 00:18 |
| lifeless | but the /content/ of the trees is unrelated, I would expect tons of conflicts | 00:18 |
| lifeless | do you know much about bzr internals? | 00:18 |
| davidstrauss | lifeless: not for content IDs | 00:19 |
| lifeless | ok, very quick primer so my answers will make sense to you | 00:19 |
| m4v | hi, quick question, does bzr track file permissions? | 00:19 |
| lifeless | m4v: execute bit only | 00:19 |
| bob2 | only execute | 00:19 |
| davidstrauss | lifeless: is there a way to force bazaar to understand that file name match = content match? | 00:19 |
| lifeless | m4v: see etckeeper for tracking full permissions, which supports bzr | 00:19 |
| lifeless | davidstrauss: each object that bzr is managing has a path and a fileid. The fileid is the globally unique ID for the object | 00:20 |
| davidstrauss | lifeless: I can see that now, but that doesn't really make it possible to efficiently merge without common ancestry | 00:20 |
| davidstrauss | lifeless: I mean, there *has* to be a way to merge efficiently without common ancestry | 00:21 |
| lifeless | davidstrauss: this is a 1:1 relationship in any tree - 1 path, 1 id. | 00:21 |
| lifeless | davidstrauss: over time you can get many different paths having the same id - when things are renamed and so on | 00:21 |
| lifeless | davidstrauss: so, to do a merge with an unrelated tree | 00:21 |
| lifeless | davidstrauss: such that future merges can be no-brainers | 00:22 |
| lifeless | davidstrauss: 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 sourcetree | 00:22 |
| davidstrauss | lifeless: is there a way to do that automatically? | 00:22 |
| lifeless | then you have to do a merge across the two file ids using the specified base, or else the old fileids local changes wil be lost | 00:23 |
| davidstrauss | lifeless: Is there a way to do that branch-wide? | 00:23 |
| lifeless | you need to identify the common revision in both branches as well | 00:23 |
| m4v | lifeless: alright | 00:24 |
| lifeless | davidstrauss: so - thats what needs to happen. The bad news is that noone (to the best of my knowledge) has written this code up | 00:24 |
| davidstrauss | lifeless: identifying the common revision in both branches is already part of my procedure | 00:24 |
| lifeless | davidstrauss: yes, but there is no way to tell bzr at the moment, you only manage to tell it 3 of the 4 coordinates needed | 00:24 |
| davidstrauss | lifeless: so is there an efficient way to resolve the conflicts? | 00:25 |
| garyvdm | vila: I managed to get qbzr to use CLIUIFactory rather than TextUIFactory. | 00:25 |
| lifeless | davidstrauss: it is scriptable in python | 00:26 |
| davidstrauss | lifeless: has it been scripted? | 00:26 |
| lifeless | davidstrauss: in fact, writing a custom conflict resolver could do it during the merge to make it seamless | 00:26 |
| lifeless | 11: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 up | 00:26 |
| davidstrauss | lifeless: what would the custom conflict resolver look like? | 00:27 |
| davidstrauss | lifeless: would it be in python or a shell command? | 00:28 |
| lifeless | davidstrauss: I think it would be a subclass of bzrlib.merge.Merge3Merger, though I haven't written a custom one myself | 00:31 |
| lifeless | http://paste.ubuntu.com/106710/ <- knit vs gc compression | 00:32 |
| lifeless | short story, 141MB to 0.5MB, but 10 times slower at extraction, at the moment | 00:33 |
| davidstrauss | lifeless: what is gc compression? | 00:36 |
| lifeless | davidstrauss: its a new delta compression I'm evaluation for bzr | 00:39 |
| davidstrauss | lifeless: is there a way to specify an external merge tool that runs in the shell? | 00:44 |
| lifeless | I think the extmerge plugin does this | 00:44 |
| lifeless | note though that I don't think it will handle the file id changing that you need | 00:44 |
| davidstrauss | ok | 00:44 |
| lifeless | fundamentally this needs code written to support it | 00:44 |
| davidstrauss | lifeless: I think this is one area git's architecture shines. | 00:47 |
| davidstrauss | apparently | 00:47 |
| lifeless | well its certainly simpler there, for git or hg | 00:47 |
| lifeless | its the inode abstraction that makes it complex to handle parallel imports | 00:48 |
| lifeless | I encourage you to file a bug, this is something we should put a canned answer to in the core | 00:48 |
| davidstrauss | ok | 00:48 |
| lifeless | for now, people that want to move onto your branch would be best served by: | 00:49 |
| lifeless | - pull your branch | 00:49 |
| davidstrauss | lifeless: 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 |
| davidstrauss | ok | 00:49 |
| lifeless | commit that patch | 00:49 |
| lifeless | then they are descendants of your branches | 00:50 |
| davidstrauss | lifeless: so, basically, start fresh | 00:50 |
| lifeless | yes | 00:50 |
| davidstrauss | lifeless: this seems similar to when you bzr bind after divergence | 00:50 |
| lifeless | gc is faster at compression, sweet | 00:52 |
| jelmer | we have a gc? | 00:55 |
| davidstrauss | lifeless: https://bugs.launchpad.net/bzr/+bug/318620 | 00:57 |
| ubottu | Launchpad bug 318620 in bzr "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Undecided,New] | 00:57 |
| lifeless | jelmer: groupcompress | 00:58 |
| lifeless | davidstrauss: thank you | 00:58 |
| garyvdm | What 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 |
| garyvdm | I think I better pastebin a dag to explain this.. | 01:08 |
| lifeless | garyvdm: you can do it if you want | 01:10 |
| lifeless | it just makes it look like a merge of a branch | 01:10 |
| garyvdm | Here is my dag just to make sure we are on the same wave length: http://pastebin.com/d23836559 | 01:12 |
| jelmer | lifeless, ah, that makes more sense (-: | 01:14 |
| spiv | jelmer: bzr-svn is working well for me these days, btw. | 01:18 |
| jelmer | spiv, cool | 01:18 |
| spiv | jelmer: the current 0.5 tip seems to be quite reliable at pulling from python's and twisted's repos. | 01:18 |
| spiv | jelmer: 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 |
| spiv | jelmer: it even does find_tags at a bearable speed now :) | 01:19 |
| jelmer | spiv, patches for import improvements are more than welcome | 01:20 |
| thumper | hi ho | 01:50 |
| thumper | I just went bzr init, and bzr stat | 01:50 |
| thumper | and got a traceback | 01:50 |
| thumper | is this a known bug? | 01:50 |
| thumper | bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose' | 01:50 |
| jelmer | thumper, do you have loom installed? | 01:51 |
| jelmer | thumper, I think you need a newer version of loom | 01:51 |
| thumper | plugin installed, yes | 01:51 |
| thumper | using it, no | 01:51 |
| jelmer | it wraps bzr status but doesn't cope with a new argument that has been added to status | 01:51 |
| jelmer | even if you're not using it | 01:51 |
| thumper | :( | 01:52 |
| jelmer | the last revision of the loom trunk fixes it | 01:53 |
| thumper | WTF? | 01:53 |
| thumper | :-( | 01:53 |
| thumper | bzr log --line -r-10..-1 now gives be non-mainline messages | 01:54 |
| thumper | this is very new | 01:54 |
| thumper | and I can't go --line --short, as that doesn't work | 01:55 |
| jelmer | yeah, I can confirm that has changed since 1.11 | 01:55 |
| thumper | can we change it back? | 01:56 |
| thumper | it is really annoying | 01:56 |
| jelmer | I'm not sure it's intentional or a regression that is a side-effect of the recent work on log | 01:57 |
| thumper | I don't think it is intentional | 01:57 |
| jelmer | probably worth filing a bug about | 01:57 |
| thumper | igc: my log --line now shows non-mainline revisions | 01:58 |
| lifeless | jam: are you around by chance? | 02:02 |
| igc | thumper: I thought jam has sent a quick fix to pqm for that but it looks like he hasn't | 02:15 |
| igc | I'll do it now | 02:15 |
| thumper | igc: that'd be grand | 02:28 |
| igc | thumper: in the pqm queue now | 02:29 |
| * igc lunch | 02:29 | |
| thumper | igc: fantastic | 02:29 |
| igc | thumper: try bzr.dev now and let me know if it's still broken | 03:08 |
| thumper | igc: ok | 03:08 |
| mwhudson | oops, 700 unread emails on the bzr list | 03:08 |
| S11001001 | hello all | 03:30 |
| S11001001 | I 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 my | 03:30 |
| S11001001 | branch, 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 |
| lifeless | either is fine | 03:35 |
| thumper | igc: lp:bzr is a few revs behind by the look of it | 03:52 |
| spiv | thumper: it's 3 hours behind, on average ;) | 03:54 |
| thumper | spiv: funny man | 03:55 |
| thumper | so when is bzr going to host trunk on LP? | 03:55 |
| lifeless | http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench | 03:58 |
| pygi | goooood morning | 04:52 |
| poolie | hello pygi | 05:32 |
| pygi | poolie, :) | 05:47 |
| pygi | chapter 1 coming to your address this week :) | 05:47 |
| davidstrauss | lifeless: http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem | 06:23 |
| === aumontabe is now known as abeaumont | ||
| vila | hi all | 07:35 |
| igc | hi vila | 08:03 |
| davidstrauss | What is the status of nested trees? | 08:36 |
| Lo-lan-do | They're full of birds? | 08:37 |
| jml | davidstrauss: they aren't there yet. interest is being renewed though. | 08:39 |
| davidstrauss | jml: The Drupal project is very interested in getting this support stable. | 08:39 |
| davidstrauss | jml: So we can effectively consider Bazaar for module development on Drupal.org | 08:39 |
| sdboyer | jml: like, very interested :) | 08:39 |
| * fullermd frowns. | 08:41 | |
| fullermd | NEWS is looking a little odd. | 08:42 |
| jml | sdboyer, davidstrauss: I *think* abentley intends to work on it very soon. | 08:42 |
| jml | but I couldn't say for sure. | 08:42 |
| fullermd | poolie: It looks like r3940 spuriously added a whole separate section on top of NEWS | 08:43 |
| sdboyer | jml: 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 provide | 08:46 |
| jml | sdboyer: cool :) | 08:46 |
| luks | can't https://launchpad.net/bzr-scmproj be used as an alternative? | 08:49 |
| jml | maybe! | 08:50 |
| * jml doesn't know anything about it. | 08:50 | |
| * igc dinner | 09:02 | |
| davidstrauss | bzr-scmproj looks kind of clunky | 09:03 |
| poolie | davidstrauss: it's trying to do it in a kind of minimal but useful way | 09:29 |
| vila | luks: Looks like gary merged a conflict in qbzr trunk, just deleting it seems enough though | 09:31 |
| poolie | hello vila | 10:10 |
| vila | hey ! | 10:10 |
| fullermd | poolie: Did you catch my above? | 10:19 |
| poolie | about news, or about nested trees? | 10:28 |
| poolie | i saw both | 10:28 |
| poolie | i'm making 1.11final tonight, and then will merge back and fix the news | 10:28 |
| * fullermd nods. | 10:28 | |
| fullermd | Just making sure IRC didn't eat it :) | 10:28 |
| * davidstrauss smiles in anticipation of 1.11 | 10:29 | |
| fullermd | Shucks, that means I have to update the port... | 10:30 |
| === asac_ is now known as asac | ||
| LarstiQ | sdboyer, davidstrauss: yeah, that would help | 10:43 |
| davidstrauss | :-0 | 10:43 |
| davidstrauss | :-) | 10:43 |
| * LarstiQ thinks he may need to rethink the current approach | 10:43 | |
| sdboyer | LarstiQ: great, we should definitely talk, then. cept probably not at 5am my time :) | 10:46 |
| LarstiQ | sdboyer: k, I'm in utc+1/+# | 10:46 |
| LarstiQ | 3 | 10:46 |
| davidstrauss | sdboyer: It's the same time here | 10:46 |
| LarstiQ | sdboyer: currently in .nl | 10:46 |
| LarstiQ | and some of my time in .fi | 10:47 |
| fullermd | Heck, it'll be that time here in about 15 minutes ;p | 10:47 |
| davidstrauss | I think Drupal could survive without nested branch support by simply having checkouts for each module. It's just not as elegant. | 10:47 |
| * LarstiQ nods | 10:48 | |
| sdboyer | sure. 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 swoop | 10: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 | |
| sdboyer | not essential for implementation, but probably wise. | 10:50 |
| sdboyer | however, unlike davidstrauss, who has been talking about needing to go to bed for two hours, i actually AM going to bed :P | 10:50 |
| fullermd | A lot of things are easier to setup than to re-setup.. | 10:50 |
| * sdboyer agrees with fullermd wholeheartedly | 10:51 | |
| * sdboyer waves g'night | 10:51 | |
| LarstiQ | poolie: the only other moves on nested trees has been scmproj, right? | 11:06 |
| poolie | i think so | 11:10 |
| LarstiQ | hmkay | 11:16 |
| LarstiQ | poolie: 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: ping | 11:18 |
| poolie | LarstiQ: interested in working on it? | 11:39 |
| poolie | i heard you had a branch that fixed some subtrees bugs? | 11:39 |
| LarstiQ | poolie: 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 motivating | 11:43 |
| * LarstiQ needs to put more regular time into it to move it forward | 11:43 | |
| LarstiQ | poolie: I'd very much like to get this moving somehow, yes. | 11:44 |
| poolie | hm | 11:44 |
| poolie | well, send them up and hopefully we can gradually reduce the problems | 11:44 |
| poolie | do they fix failures when a subtree format is the default? | 11:44 |
| LarstiQ | they 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 anyhow | 11:45 |
| poolie | i'm just wondering what tests you added to get failures | 11:48 |
| poolie | or what you changed | 11:48 |
| poolie | since the trunk test suite does not fail, it's presumably not testing everything | 11:48 |
| LarstiQ | poolie: right, lp:~larstiq/bzr/nested-trees is a continuation from Aaron's branch | 11:49 |
| LarstiQ | poolie: which is, afaik, the only place where work on by-reference trees is | 11:50 |
| LarstiQ | poolie: and by reference is I think where the brunt of the usecases are | 11:53 |
| Jc2k | lifeless: omg is that groupcompress!?!?! | 11:57 |
| james_w | pretty amazing :-) | 11:58 |
| * LarstiQ goes to lunch | 12:03 | |
| poolie | hello jc2k, james_w | 12:06 |
| james_w | hi poolie | 12: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/ | ||
| Jc2k | hi poolie | 12:06 |
| Peng_ | Whee | 12:08 |
| Lo-lan-do | I can't seem to find a description of this "groupcompress" thingy that everyone seems to happy about. Any pointer? | 12:17 |
| james_w | Lo-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_w | it's a different way of doing deltas than what is currently used, which gives a large compression win, but has trade-offs in other areas | 12:19 |
| Lo-lan-do | Okay. So smaller repository sizes, I guess? | 12:19 |
| james_w | currently decompression time, and I imagine annotation time, but that may not change as packs already damaged that | 12:19 |
| james_w | yes, *massively* smaller in the current implementation | 12:20 |
| Lo-lan-do | A new storage format too, I suppose. Will it be compatible with the current ones? | 12:20 |
| james_w | but that is at a cost of a 200% increase in decompression time, which is unacceptable in my opinion | 12:21 |
| Lo-lan-do | Um, yeah, sounds not-very-nice indeed. | 12:21 |
| james_w | yeah, 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_w | perhaps | 12:21 |
| james_w | first 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 format | 12:22 |
| poolie | it's currently only for inventory data | 12:22 |
| poolie | so the point is to speed up commit and extraction | 12:23 |
| james_w | ah, I thought it was texts too | 12:23 |
| poolie | the decompression time is something that still needs to be solved before we go ahead with ti | 12:23 |
| poolie | it could be applicable | 12:23 |
| james_w | yeah | 12:23 |
| james_w | is there any plan to move away from XML inventories? | 12:23 |
| poolie | to file texts too | 12:23 |
| poolie | however, for reasons i don't want to go into right now, it has some troubles with big files | 12:24 |
| poolie | ie it'll store too many full texts | 12:24 |
| poolie | (well, arguably too many) | 12:24 |
| poolie | Lo-lan-do: it'll be backward/forward compatible | 12:24 |
| poolie | in the usual way | 12:25 |
| Lo-lan-do | Thanks | 12:28 |
| yml | hello | 13:26 |
| yml | I 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 |
| yml | Is it possible ? | 13:28 |
| luks | it isn't | 13:29 |
| yml | Thank you for the confirmation | 13:33 |
| beuno | yml, you should, however, be able to export a directory | 13:33 |
| yml | beuno: how would you do this ? | 13:35 |
| yml | I mean my branch is hosted on launchpad | 13:35 |
| beuno | yml, ah. I guess you can only do that with local branches | 13:37 |
| === kiko-afk is now known as kiko | ||
| igc | night all | 13:49 |
| yml | beuno: I see. Thank you for your help | 13:55 |
| beuno | g'night igc | 13:56 |
| yml | I will create a symbolic link to put the folder in my pythonpath | 13:56 |
| edreamleo | Help! 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 |
| edreamleo | I 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 |
| edreamleo | BTW, "changed" files happen just after a fresh bzr branch. Is there a cache that should be cleared? | 14:00 |
| Jc2k | you dont do bzr branch bzr/1.10 to install a new version.. | 14:01 |
| edreamleo | Jc2k. 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 |
| Jc2k | does the output of bzr status say "unknown:" and then a list of file? | 14:03 |
| edreamleo | No. bzr status says modified. The actual file appears random, but compares binary equal to the file in other branches. | 14:04 |
| Jc2k | how odd | 14:05 |
| edreamleo | By "appears random" I mean the actual file that is reported varies from time to time, or rather, from branch to branch. | 14:05 |
| edreamleo | Yes! Odd indeed. | 14:05 |
| Jc2k | i had some weirdness moving branches between linux, flash drive and windows but this was over a year ago | 14:06 |
| edreamleo | At first I suspected bad memory. But the oddness happens on all branches. Maybe a bit got flipped in a central .bzr folder? | 14:07 |
| Jc2k | not really sure, im not a dev and what bits of the code i know are related to the workingtree stuff | 14:08 |
| Jc2k | *arent | 14:08 |
| edreamleo | I wonder. Does a fresh install change C:\Documents and Settings\HP_Administrator\.bzr ? I suspect not. Any reason not to trash this? | 14:10 |
| edreamleo | Is there a trouble-shooting guide or FAQ? | 14:14 |
| superm1 | Hi guys. I'm wondering how to push my tags to the main branch in LP without doing another revision. | 14:34 |
| superm1 | i can't appear to push because pushing requires a new revision | 14:35 |
| Peng_ | superm1: Push will push tags even if there are no new revisions. | 14:48 |
| superm1 | Peng_, is that only with newer versions of bzr? I'm on hardy, so 1.3.1-1ubuntu0.1 | 14:48 |
| james_w | superm1: 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 |
| superm1 | james_w, i pulled from another computer that's regularly been pulling from that same branch | 14:50 |
| james_w | ah, ok | 14:50 |
| james_w | it's probably just broken then, I don't remember it changing | 14:50 |
| superm1 | okay, 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 least | 14: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 |
| superm1 | Peng_, 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 available | 14:53 |
| Peng_ | Oh. | 14:53 |
| superm1 | sorry 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 |
| superm1 | Peng_, yeah i was pulling from http on the other computer, so that would explain it | 14:54 |
| james_w | glad to know it works :-) | 14:54 |
| james_w | there's a bug open about it not telling you what it's done | 14:55 |
| james_w | "No revisions to push" should be extended to mention that it pushed some tags | 14:55 |
| superm1 | yeah that would be useful | 14:55 |
| jelmer | james_w: Hi | 15:03 |
| jelmer | james_w: Are you aware of any guides about using bzr-loom as alternative to quilt/dpatch for Debian packaging? | 15:03 |
| james_w | jelmer: I'm not | 15:04 |
| LarstiQ | beuno, 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 http | 15:10 |
| ubottu | Launchpad bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Triaged] | 15:10 |
| bvk | hi, is there any quick way to branch lp:bzr instead of std bzr branch lp:bzr ? | 15:11 |
| LarstiQ | beuno, mwhudson: should I make a new bug, comment on that one, fix it if it is easy to do? | 15:11 |
| bvk | it never gets finished for me :( | 15:11 |
| LarstiQ | bvk: your two alternatives are the same? | 15:11 |
| beuno | LarstiQ, fix it is always the first option :) | 15:11 |
| beuno | if not, I think a comment on the bug is useful | 15:11 |
| LarstiQ | beuno: it is an area I'm rather unfamiliar with | 15:11 |
| LarstiQ | but I'll have a go | 15:11 |
| LarstiQ | beuno: any hints on where to start looking? | 15:12 |
| jelmer | bvk, if you mean an alternative URL, try http://bazaar-vcs.org/bzr/bzr.dev | 15:12 |
| bvk | LarstiQ, jelmer: no, i am looking for any tarbal with repository. is such a thing available anywhere? | 15:13 |
| LarstiQ | bvk: specifically to get one copy of bzr.dev? I could generate a tarball for you | 15:13 |
| jelmer | I'm curious though as to why branching lp:bzr doesn't work for you | 15:13 |
| bvk | LarstiQ, jelmer: no, i tried both urls, lp:bzr and http://.../bzr.dev :-( but both timeout from my computer always :( | 15:13 |
| LarstiQ | bvk: or do you mean, for a given launchpad branch, does it support downloading a snapshot tarball? | 15:13 |
| bvk | LarstiQ: yes, that would be of great; thanks | 15:14 |
| bvk | LarstiQ: no, my problem is 'bzr branch lp:bzr' always timesout and doesn't get finish. its too slow | 15:15 |
| LarstiQ | bvk: ok, it would be good to solve that if possible, but a tarball is coming up for you | 15:15 |
| bvk | LarstiQ: thanks LarstiQ | 15:17 |
| LarstiQ | bvk: http://richtlijn.be/~larstiq/bzr.dev-20090119.tar.gz | 15:17 |
| LarstiQ | bvk: that is my ~/src/bzr/bzr.dev as of now | 15:17 |
| LarstiQ | bvk: the file is ~5M, if that is too big, I can make a tarball of it after a `remove-tree` | 15:17 |
| LarstiQ | you would then have to `bzr co .` after unpacking and cding | 15:18 |
| === kiko is now known as kiko-fud | ||
| bvk | LarstiQ: 5MB is fine, i can easily download that. | 15:19 |
| bvk | LarstiQ: 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 |
| LarstiQ | hmm, good point, I recall it being 40~ ish | 15:23 |
| bvk | well, i was looking for a branch with full history :( | 15:24 |
| LarstiQ | bvk: it does seem to be so | 15:24 |
| bvk | btw, is there any way to make a branch with partial history? say, like 50 days history? | 15:25 |
| LarstiQ | meh, still not looking at the right place | 15:25 |
| Peng_ | bvk: No, there's not. | 15:25 |
| LarstiQ | bvk: --stacked might help you | 15:25 |
| LarstiQ | though it does not do it like that | 15: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 |
| LarstiQ | hth do I end up with a working standalonish branch but it's .bzr/repository is empty | 15:28 |
| Peng_ | .bzr/repository exists but is empty? | 15:29 |
| Peng_ | Maybe it's a stacked branch? | 15:29 |
| LarstiQ | yeah, it is... | 15:29 |
| LarstiQ | bvk: well. That explains why it is so small. | 15:30 |
| LarstiQ | and why logging all took longer than expected | 15: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 |
| LarstiQ | :) | 15:31 |
| LarstiQ | nullzip? ;) | 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 |
| LarstiQ | bvk: if you do continue downloading my tarball, you should end up with a stacked bzr.devc | 15:32 |
| bvk | okay, i just found out that i was using bazaar 1.5, where as latest one is at 1.11 | 15: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 |
| bvk | i just did 'bzr co .' in LarstiQ's 5MB tree and i got 'Bazaar Branch Format 7 (needs bzr 1.6)\n' :-( | 15:35 |
| bvk | i will upgrade my bzr and will try 'bzr branch lp:bzr' again | 15:35 |
| Peng_ | Well, 1.5 can branch from lp:bzr fine. | 15:36 |
| Peng_ | Or http://bazaar-vcs.org/bzr/bzr.dev/ | 15:36 |
| bvk | Peng_: my problem is that it takes too much time. I waited for half an hour and it didn't finish | 15: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. :P | 15:38 |
| bvk | Peng_: mine is macbook with 256Kbps internet | 15: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 |
| LarstiQ | bvk: my tarball should give you a workingtree of bzr.dev at a recent revision, plus .bzr/ bits to act as a stacked bzr branch | 15:42 |
| bvk | Peng_: true...but its UI always made me think it hung and i would endup either killing it in the middle (impatient :D) | 15:42 |
| LarstiQ | bvk: so if you extrac that, you can run the bzr _in there_ to branch with | 15:43 |
| LarstiQ | just run path/to/extracted/bzr.dev/bzr branch ... | 15:43 |
| Lo-lan-do | I 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 |
| LarstiQ | Lo-lan-do: did you see the progress indication that's not in 1.11? | 15:43 |
| LarstiQ | Lo-lan-do: it succeeds in subjectively making me feel it's waaaay faster | 15:44 |
| LarstiQ | Lo-lan-do: achieved by actually giving information :) | 15:44 |
| Lo-lan-do | LarstiQ: 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 |
| LarstiQ | Lo-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 EVAR | 15:46 |
| Lo-lan-do | Peng: 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. :D | 15:48 |
| Lo-lan-do | 1.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-do | Not 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 | ||
| jelmer | Lo-lan-do: :-) | 15:53 |
| jelmer | Lo-lan-do, I'm trying to get 0.5rc2 out today, hopefully I can have another look at your performance regression after that | 15:53 |
| Lo-lan-do | jelmer: I'm trying to single out a bug in svn-import, too :-) | 15:54 |
| jelmer | Lo-lan-do, argh, and I just got the bug count in bzr-svn back to < 30 :-) | 15:54 |
| LarstiQ | beuno: it looks to me like it may be a bit more complicated than trying to replicate the patch *somewhere* | 15:56 |
| Lo-lan-do | jelmer: Okay. Just ping me when it's < 29 then :-D | 15:56 |
| beuno | LarstiQ, a comment on the bug about the https is fine then :) | 15:56 |
| beuno | you did install python-pastedeploy, right? | 15:57 |
| LarstiQ | beuno: yup | 15:57 |
| LarstiQ | beuno: and it's working fine for my http vhost | 15:58 |
| === kiko-fud is now known as kiko-phone | ||
| LarstiQ | beuno: added a comment | 16:11 |
| LarstiQ | lifeless: is bicyclerepair completely bitrotted? | 16:18 |
| jelmer | any versionedfile API experts around? | 16:19 |
| * LarstiQ hides | 16:19 | |
| jelmer | LarstiQ, nevermind, already found the problem | 16:23 |
| jelmer | KnitCorruption caused by a text revision that has the same parent twice | 16:23 |
| jelmer | Lo-lan-do, never mind me, it's actually at 27 already :-) | 16:24 |
| Lo-lan-do | jelmer: Does 0.5rc2 change anything related to deleted files by any chance? | 16:25 |
| jelmer | Lo-lan-do: some things - what's the error you're seeing? | 16:26 |
| Lo-lan-do | bzr: 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 |
| jelmer | ah, good chance that's fixed in rc2 | 16:27 |
| Lo-lan-do | At 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-do | I'll try using http://people.samba.org/bzr/jelmer/bzr-svn/0.5 then, see if it helps. | 16:28 |
| jinRooma | so 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 |
| jinRooma | Peng_, when you say revision data, do you mean the actual files from the project | 16: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 |
| jinRooma | ok 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 basis | 16: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 |
| jinRooma | I see, so bzr does do some analysis / comparison of local & remote, and make decisions based on this. its not just a dumb upload | 16:44 |
| Peng_ | jinRooma: Right. | 16:46 |
| Peng_ | Now, bzr isn't the fastest vcs ever, but you have to give it *some* credit. :P | 16:46 |
| jinRooma | its the only vcs i have used, for some reason could not get my around sub version and cvs | 16:47 |
| jinRooma | but im using it mainly for back up than versioning | 16:47 |
| jinRooma | ... which is primitive but better than nothing | 16:48 |
| jelmer | LarstiQ, any idea what could cause a versionedfile revision to end up with the same parent twice? | 16:48 |
| jelmer | get_parent_map() seems to filter out the duplicate parent unfortunately, but add_lines() complains | 16:49 |
| jinRooma | i should probably use rsync or some such for my needs | 16:52 |
| LarstiQ | jelmer: 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 such | 16:55 |
| Peng_ | Does anyone else care about my bzr.dev tarballs, or can I delete them now? bvk? | 17:45 |
| bvk | Peng_: you can delete it now; thanks a lot | 17:47 |
| bvk | :) | 17:47 |
| Peng_ | bvk: Alright. | 17:48 |
| Lo-lan-do | jelmer: 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 |
| jelmer | Lo-lan-do, :-(* | 18:19 |
| jelmer | rocky, hi | 18:19 |
| jelmer | rocky, I've worked around the bug you were seeing, but I think it's a bug in bzr. | 18:19 |
| rocky | jelmer: heyo | 18:19 |
| jelmer | (not committed to 0.5, as it degrades performance, especially on large trees) | 18:19 |
| jelmer | http://samba.org/~jelmer/tmp/test-text-existance.diff | 18:20 |
| rocky | hm | 18:20 |
| jelmer | hopefully one of the australians can shed some light on the actual problem when they wake up | 18:21 |
| rocky | hehe | 18:23 |
| jelmer | alternatively, there's a one-line fix to bzr that will work around it without any performance regressions | 18:24 |
| jelmer | Lo-lan-do, ENOBUGREPORT | 18:24 |
| bvk | hi, is there any bzr plugin that would allow me to maintain bugs (and messages) within the code repository? | 18:26 |
| jelmer | bvk, You mean something like be (BugsEverywhere)? | 18:30 |
| jelmer | see bugseverywhere.org | 18:31 |
| bvk | jelmer: well, i don't know about bugseverywhere; let me check it out | 18:31 |
| jelmer | rocky, alternative test http://samba.org/~jelmer/tmp/fix-add-records-dupe-test.diff | 18:33 |
| bvk | jelmer: yes, it is what i was looking for. thanks | 18:39 |
| mwhudson | LarstiQ: i'd actually just noticed something similar the other day | 18:47 |
| mwhudson | LarstiQ: file a bug, i guess | 18:47 |
| Lo-lan-do | jelmer: http://bugs.debian.org/512325 | 19:20 |
| jelmer | Lo-lan-do, thanks, just found it | 19:20 |
| jelmer | I'm trying an import now, at r6132 atm | 19:21 |
| Lo-lan-do | I 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 |
| jelmer | Lo-lan-do, Some svn revisions probably cause multiple bzr revisions | 19:22 |
| Lo-lan-do | I supposed that much. Like, maybe some commits touched files in several branches at once. | 19:23 |
| Lo-lan-do | Not very important anyway. | 19:23 |
| flacoste | i've got a problem with bzr-svn repository | 19:25 |
| jelmer | hi flacoste | 19:25 |
| flacoste | hi jelmer! | 19:25 |
| flacoste | I have a bzr-svn branch tracking Windmill repository | 19:25 |
| flacoste | they moved to a failover server | 19:25 |
| flacoste | and now I get the following error when I do bzr pull | 19:25 |
| flacoste | http://svn.getwindmill.com/trunk is permanently redirected to http://svn.getwindmill.com/trunk/ | 19:26 |
| flacoste | bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Chemin '/windmill/!svn/vcc/default' non trouv\xc3\xa9", 175007) | 19:26 |
| flacoste | i can load the URL in the browser fine | 19:26 |
| flacoste | In English, the message reads "Path '...' not found" | 19:27 |
| jelmer | flacoste, This fails for me as well: | 19:27 |
| jelmer | svn ls http://svn.getwindmill.com/trunk/ | 19:27 |
| flacoste | hmm, yeah, they just found that out :-) | 19:27 |
| flacoste | ok, it's probably an error on their end then | 19:28 |
| flacoste | sorry for the noise | 19:28 |
| jelmer | np | 19:29 |
| jelmer | Lo-lan-do, did you remove the svn-cache as well as the bzr repository prior to trying the import? | 19:52 |
| Lo-lan-do | Ah, damn. No, I didn't. Should I do that? | 19:53 |
| * Lo-lan-do tries | 19:54 | |
| lifeless | -> LCA | 19:54 |
| lifeless | jelmer: compressbench may interest you, for your xdelta apply/create code | 19:54 |
| lifeless | Jc2k: did you see my gc stats? | 19:55 |
| jelmer | lifeless, 'morning | 19:55 |
| jelmer | Lo-lan-do, oh, never mind | 19:55 |
| jelmer | Lo-lan-do, just reproduced it | 19:55 |
| jelmer | lifeless, cool, I'll have a look | 19:55 |
| jelmer | lifeless, still there? | 19:55 |
| Jc2k | lifeless: yes | 19:55 |
| jelmer | lifeless, quick question about knits | 19:55 |
| Jc2k | lifeless: my reply was something like "omg thats groupcompress?!?" | 19:55 |
| lifeless | Jc2k: :) | 19:56 |
| jelmer | lifeless: 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 |
| lifeless | jelmer: node refs in indices is a list of lists of keys | 19:56 |
| lifeless | jelmer: for knit mapped packs | 19:56 |
| lifeless | jelmer: 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 tree | 19:57 |
| lifeless | jelmer: in all bzr repositories, the second must be either empty, or the first parent. | 19:57 |
| Peng_ | lifeless: "-> LCA"? | 19:57 |
| lifeless | but its intended to be arbitrary | 19:57 |
| lifeless | Peng_: linux.conf.au | 19:57 |
| Peng_ | Oh. | 19:57 |
| lifeless | jelmer: just not implemented yet | 19:57 |
| lifeless | jelmer: if delta=False, parents=True, the node refs length is 1, parents only | 19:58 |
| lifeless | jelmer: and False False is length 0 | 19:58 |
| jelmer | lifeless, 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 tuple | 19:58 |
| lifeless | jelmer: finally, delta=True, parents=False, is unimplemented in knits today | 19:58 |
| lifeless | jelmer: thats when one repository has a text compressed, and the other has a full text. The cross check is overly strict - that is a bug | 19:59 |
| flacoste | jelmer: they fixed it, but now when I bzr pull, it's refetching everything | 19: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 |
| lifeless | Peng_: please file a bug | 19:59 |
| Peng_ | lifeless: Alright. | 19:59 |
| lifeless | Peng_: 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 interactively | 20:00 |
| jelmer | lifeless, Ah, thanks! | 20:00 |
| jelmer | flacoste, did the repository change in some way ? Did you upgrade bzr-svn? | 20:00 |
| flacoste | jelmer: you mean the SVN repository, i don't think so, and I haven't update bzr-svn in a while | 20:01 |
| flacoste | jelmer: actually, i don't know if it will create new BZR revisions | 20:02 |
| flacoste | the message is | 20:02 |
| flacoste | Initialising Subversion metadata cache in /home/francis/.bazaar/svn-cache/7915dd7d-006c-436d-aff2-976aa4ca8641 | 20:02 |
| flacoste | and then fetching all revisions | 20:02 |
| flacoste | but if that metadata is keyed by hostname, then i guess it would be normal | 20:02 |
| flacoste | to refetch everything | 20:02 |
| lifeless | flacoste: thats the svn repo uuid | 20:03 |
| flacoste | the question is, will this create new bzr revisions | 20:03 |
| lifeless | flacoste: its stored in the repository | 20:03 |
| lifeless | flacoste: and yes | 20:03 |
| flacoste | ok, so copying the repository files should preserve the UUID? | 20:03 |
| lifeless | flacoste: I'm not sure exactly where it is stored, so can't answer that | 20:03 |
| flacoste | "It's a scripted mirror of the original repo, so it should be the same." | 20:03 |
| lifeless | god, that could mean anything | 20:04 |
| flacoste | they are using svnsync | 20:05 |
| Jc2k | flacoste: by default svnsync would have a different UUID, but i have a hack on bzr-mirror to preserve the UUID | 20:06 |
| flacoste | Jc2k: can this help me? | 20:06 |
| flacoste | i mean can I use this to trick bzr-svn in considering the two UUIDs as identical | 20:07 |
| Peng_ | Wow, "bzr check" sure spams .bzr.log. | 20:08 |
| Jc2k | flacoste: i dont know enough about what you are encountering | 20:10 |
| Kittens | hm... | 20:10 |
| flacoste | Jc2k: i have a bzr-svn branch of Windmil and the main server became unavailable, they had to switch to a failover mirror | 20:11 |
| flacoste | Jc2k: now when I do a bzr pull, it refetches every revision although there should only be about 4 or 5 that I don't have | 20:11 |
| Jc2k | ah. | 20:12 |
| flacoste | and I get: | 20:12 |
| flacoste | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 20:12 |
| flacoste | but that's not accurate | 20:12 |
| Jc2k | their failover mirror will have a different UUID; do you know if you can svnsync from their mirror? | 20:12 |
| flacoste | i don't know, i could check | 20:13 |
| flacoste | how would that help? | 20:13 |
| jelmer | flacoste: Do you have any local changes? If not, you can just "bzr pull --overwrite" | 20:13 |
| jelmer | flacoste, if you had a svn checkout I think you would get errors as well since the UUID of the repository changed | 20:14 |
| flacoste | i don't, ok, i'll do this | 20:14 |
| Lo-lan-do | Does svnsync preserve the uuid? | 20:16 |
| jelmer | Lo-lan-do, not by default I think | 20:16 |
| flacoste | jelmer: 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 |
| jelmer | flacoste, merging from where? | 20:17 |
| ubottu | Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/308353 | 20:17 |
| Peng_ | jelmer: Because that's what breaks bzr-search. :) | 20:18 |
| flacoste | jelmer: for example, if I merge the new branch into one made from the previous repository | 20:18 |
| Peng_ | lifeless: Filed bug 318935. | 20:18 |
| ubottu | Launchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New] https://launchpad.net/bugs/318935 | 20:18 |
| jelmer | flacoste, that will break, since they are fundamentally different repositories | 20:18 |
| flacoste | damn | 20:19 |
| flacoste | anyway to hack it? | 20:19 |
| jelmer | flacoste: Fix the upstream repository | 20:20 |
| flacoste | and is there an easy way to do this? | 20:20 |
| Lo-lan-do | jelmer: You're right. But one can hack the mirror's UUID by hand, according to http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt | 20:20 |
| flacoste | using svnsync? | 20:20 |
| flacoste | aha | 20:20 |
| jelmer | flacoste, svnadmin setuuid can do that for you | 20:21 |
| jelmer | Peng_, Not that I'm aware of | 20:23 |
| guilhembi | vila: still there? | 20:24 |
| flacoste | jelmer: setuuid is only a 1.5 command and they are running 1.4 :-( | 20:25 |
| Lo-lan-do | flacoste: What about "vi db/uuid"? | 20:26 |
| flacoste | Lo-lan-do: is that safe? | 20:26 |
| Lo-lan-do | It may not be safe at all, I have no idea. | 20:26 |
| flacoste | lol | 20:26 |
| Lo-lan-do | It's just that the uuid seems to be stored there. | 20:26 |
| Lo-lan-do | If it's *only* stored there, then my guess is that it's safe, but... | 20:26 |
| LarstiQ | Lo-lan-do: seems like it's time for some experimenting! ;) | 20:28 |
| Lo-lan-do | Yeah, I'm currently "experimenting" with grep -r :-) | 20:28 |
| Lo-lan-do | Only one result. db/uuid. | 20:28 |
| Lo-lan-do | Maybe it is safe after all. | 20:29 |
| LarstiQ | what about the svnadmin setuuid source? | 20:29 |
| wgrant | Lo-lan-do: I edited db/uuid in a fresh repository recently, and it worked fine. | 20:30 |
| Lo-lan-do | I'll read that too, although I don't really care for it (I was only asking about uuids out of curiosity). | 20:30 |
| flacoste | http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html | 20:30 |
| * Lo-lan-do deflects stuff to flacoste | 20:30 | |
| flacoste | there is a solution ^^^ | 20:30 |
| Lo-lan-do | LarstiQ: The source code has so many layers of indirection I gave up. | 20:33 |
| wgrant | I think one of my branches has suffered from bug #302698. Shall I just push my local copy, overwriting the remote branch? | 20:33 |
| ubottu | Launchpad 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/302698 | 20:33 |
| === spm_ is now known as spm | ||
| === davidstrauss is now known as dav1d | ||
| alevine | anybody have experience with bzreclipse? When I import a project by branching it, it seems to freeze | 21:25 |
| guilhembi | vila: sent a mail. Bonne nuit! | 21:38 |
| Necoro | hey - 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 |
| Necoro | because I want to display whether a bzr branch has been changed in my shell prompt | 21:47 |
| Necoro | and invoking bzr for this is way too slow | 21:48 |
| jelmer | Necoro, no you really need bzr for that | 21:48 |
| jelmer | you may be able to use the bzr service stuff though | 21: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 |
| Necoro | documentation somewhere? | 21:49 |
| jelmer | launchpad.net/bzr-service I think | 21:49 |
| Jc2k | jelmer: wow, someone already made the crack i was daydreaming about!! | 21:53 |
| jelmer | Jc2k, the ssh stuff you mean? | 21:54 |
| Jc2k | jelmer: no, bzr-service! | 21:55 |
| jelmer | ahh | 21:55 |
| jelmer | where someone is jam I think | 21:55 |
| Necoro | hmm - bzr-service seems to be outdated though | 21:55 |
| Jc2k | yes :( | 21:56 |
| Jc2k | hmm, didnt take much to make it work again tho | 21:59 |
| Necoro | I needed to deal a bit with imports ... but as I don't know the bzrlib API, this can only be counted as workaround | 22:00 |
| Necoro | it's fast however | 22:00 |
| Necoro | instead of using TCP/Unix Sockets/FIFOs one could also implement this using DBus | 22:01 |
| Necoro | (at least for unix) | 22:02 |
| mwhudson | bzr-service needs more unix crack related to pty's and pipes | 22:02 |
| Necoro | which would also allow to omit explicitly starting the service ;) | 22:02 |
| Jc2k | i just added an import bzrlib and killed the call trace.something and it worked | 22:02 |
| sevenseeker | I have been making changes to various files and just noticed I accidentally deleted an entire directory | 22:14 |
| sevenseeker | how do I restore it and keep my changes? | 22:14 |
| mwhudson | does bzr revert directory-you-deleted work? | 22:15 |
| beuno | mwhudson, I think that if the directory isn't there, bzr will barf | 22:15 |
| beuno | maybe not barf, but not do what you'd expect :) | 22:15 |
| sevenseeker | aha, yes... I don't know what I fat fingered earlier but it works great | 22:16 |
| * sevenseeker is embarrased | 22:16 | |
| sevenseeker | thanks | 22:16 |
| Necoro | hmm ... my shell prompt now works ;) | 22:17 |
| Necoro | though there are still some rough edges with bzr-service | 22:17 |
| === kiko-phone is now known as kiko-afk | ||
| alevine | how 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 traceback | 22:28 |
| Necoro | and I guess, I'll take the bzr-service client instead of bzr whenever possible ;) | 22:29 |
| Necoro | should be much faster | 22:29 |
| jelmer | alevine, prefix the URL with "svn+" | 22:32 |
| alevine | jelmer, thanks so much. did i miss something in documentation? | 22:33 |
| alevine | it says its deprecated | 22:33 |
| alevine | or is it just the fact that it cant figure out that it's subversion because it is authenticated | 22:34 |
| jelmer | alevine, yeah, it's deprecated - it's a workaround around a bug in bzr itself | 22:35 |
| Necoro | perhaps bzr-service should get polished and directly integrated into bzr ... this will probably be sufficient to reduce the "bzr is sooo slow" voices a bit | 22:37 |
| alevine | jelmer, good to know i really appreciate you being here to tell me that | 22:37 |
| jelmer | alevine, np | 22:37 |
| jelmer | Necoro, bzr-service has several issues, I think they're mentioned on the main page | 22:38 |
| Necoro | jelmer: only "unsecure" and "works only on windows" ... if you accept the last one as "who cares", the first one should be easy to fix | 22:39 |
| Necoro | s/only/not/ | 22:40 |
| jelmer | Necoro: bzr service will run under a different terminal | 22:40 |
| jelmer | that causes several problems for e.g. the GUI tools | 22:40 |
| jelmer | and I doubt it supports overriding environment variables right now | 22:41 |
| Necoro | hmm ok | 22:42 |
| alevine | jelmer, do you happen to know if branching an svn repo will download every file for every revision regardless of it has changed or not | 22:55 |
| jelmer | alevine, It will not download files when they have not changed | 22:56 |
| alevine | hm, ok. thanks | 22:58 |
| thumper | igc: I've confirmed with bzr.dev that log --line doesn't show non-mainline revs for me now | 23: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 ftp | 23:42 |
| _raz_ | as it seems, the files have no rights at all, directories only u+rwx | 23:43 |
| _raz_ | according to the launchpad tracker that was already fixed | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!