| lifeless | back online in a bit | 00:08 |
|---|---|---|
| jml | lifeless: so, the work I've done on testresources is broken up into three branches, but I think it'll be easier for both of us if you just review the final branch. | 01:18 |
| jml | lifeless: https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup/+merge/767 | 01:21 |
| nteon | does anyone know where the 'branch stacking' feature of 1.6 is documented? I'm trying to figure out what it is | 01:39 |
| bob2 | nteon: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches | 01:40 |
| nteon | bob2: ah, thanks! google was not helpful for me in this situation | 01:41 |
| markh | heh - so I entered a bug report with my ISP for the proxy yesterday, and they just rang me to arrange to put my account on a proxy bypass :) | 01:47 |
| === rocky is now known as rocky|away | ||
| rextilleon | anyone here | 02:10 |
| jml | yes. | 02:10 |
| rextilleon | whats up | 02:10 |
| rextilleon | quiet around here | 02:10 |
| rextilleon | jml, is there a directory site that gives you a master list of irc locations | 02:11 |
| jml | beuno: is there a nice URL for viewing the latest revision of a file in loggerhead? | 02:24 |
| xshelf | Is there anyway to handle symbolic links on windows in bzr? Like, creating a hardlink if NTFS or creating a copy of the pointed file as fall back and prevent any operations to be committed into bzr on such files | 04:37 |
| xshelf | I have read this article: http://bazaar-vcs.org/WindowsSymlinkSupport?highlight=(symlinks) | 04:39 |
| markh | xshelf: not that I'm aware of - but bzr shouldn't break IIUC - only things that try to follow the links will :) | 04:43 |
| xshelf | I have a perforce folder tracked by bzr on gnu/linux, I wanted to clone it on wxp. It had a few symlink files and it failed | 04:52 |
| xshelf | I did the following: I did a 'p4 sync' on gnu/linux, 'bzr init' followed by 'bzr add' and 'bzr commit'. I copied the .bzr folder to wxp and did a 'bzr revert' | 04:53 |
| xshelf | i just read, mercurial handles symlinks on system with no support to symlink! | 04:58 |
| === mario_ is now known as pygi | ||
| === thumper_laptop is now known as thumper | ||
| lifeless | xshelf: there is a plugin for bzr to do this | 06:19 |
| beuno | jml, you can use :head for the last revision | 06:20 |
| beuno | not sure about the path | 06:21 |
| beuno | (ue, not use the fileid) | 06:21 |
| xshelf | lifeless: which plugin is that, I need it please | 06:28 |
| lifeless | its called win32symlinks or something; its on the plugins page | 06:39 |
| xshelf | will look into it | 06:41 |
| arjenAU | lifeless: around? | 08:21 |
| lifeless | vaguely | 08:25 |
| arjenAU | lifeless: wa just trying to install the bzr-hg plugin and failing miserably | 08:26 |
| arjenAU | using the prescribed info | 08:26 |
| arjenAU | fastimport installs fine | 08:26 |
| xshelf | arjenAU: are you trying to import hg to bzr? | 08:26 |
| arjenAU | yea. for a gsoc project of a student of mine that needs to be public tonight | 08:27 |
| arjenAU | the hg repo is not public | 08:27 |
| xshelf | one dirty way: hg to svn | 08:28 |
| xshelf | svn to bzr | 08:28 |
| xshelf | or use tailor | 08:28 |
| lifeless | arjenAU: for one-shot conversions just use fastimport | 08:29 |
| arjenAU | lifeless: just did. works. the point was, I couldn't get your gizmo to even install. | 08:31 |
| arjenAU | which is probably my python incompetence, however fastimport did work | 08:31 |
| lifeless | arjenAU: bzr-hg is not complete at all | 08:33 |
| lifeless | arjenAU: but I do appreciate the feedback | 08:33 |
| arjenAU | hmm so fastimport makes me a master subdir... hmm | 08:34 |
| arjenAU | all is well, not just trying to understand launchpad for the rest | 08:43 |
| arjenAU | lifeless: ok. no worries! | 08:44 |
| arjenAU | lifeless: https://code.launchpad.net/sql-obfuscator whatever it says there, how to fix? | 08:45 |
| lifeless | FF is restarting for me | 08:46 |
| lifeless | I dunno what it says :) | 08:46 |
| arjenAU | I think I found it, needed to re-edit the project info. just checking now if that did it. | 08:46 |
| arjenAU | the branch (trunck) was not yetnoted as the dev focus for the project | 08:46 |
| arjenAU | A branch has not yet been specified as the primary development focus for SQL Obfuscator (set). | 08:47 |
| arjenAU | still says.... hmm | 08:47 |
| lifeless | click on set | 08:47 |
| arjenAU | hmm had to work out how the format worked in the set .... does it look ok now? | 08:49 |
| lifeless | dunno ;) | 08:55 |
| lifeless | let mepeek | 08:55 |
| lifeless | arjenAU: looks fine to me | 09:00 |
| robsta | hi | 09:01 |
| robsta | does `merge --pull' recognise whether the branches are in sync, except for the pulled changes? | 09:01 |
| arjenAU | lifeless: ye. once done once it's perfectly sensible. and it's oh so functional. was just trying to do this in a hurry while actually needing to do other stuff. tnx for your elp | 09:02 |
| arjenAU | +h | 09:02 |
| lifeless | robsta: it looks at the graph, not the content | 09:05 |
| robsta | graph == "chain of revision numbers", for noobs? | 09:06 |
| lifeless | directed acyclic graph of UUID | 09:07 |
| lifeless | which we show as a chain of numbers :) | 09:07 |
| robsta | the thing is, i'd only managed to "merge --pull" the other branch once, so i didn't have to commit myself | 09:07 |
| lifeless | merge --pull is a 'fast forward' in git terms | 09:08 |
| lifeless | if that helps | 09:08 |
| robsta | definitely not :P | 09:08 |
| lifeless | :) | 09:08 |
| robsta | does a pulling merge fall back to normal merge automatically when the branches are not in sync? | 09:08 |
| lifeless | its for when two people are 'sharing' a branch but they each have separate copies and no shared writable space | 09:08 |
| lifeless | yes | 09:08 |
| robsta | and there is no way to force pulling merge? | 09:09 |
| lifeless | pull --force? | 09:09 |
| lifeless | merge --pull is 'merge if you can't pull' | 09:09 |
| lifeless | got to go | 09:10 |
| robsta | thx, looks like that's what i want | 09:11 |
| robsta | to have the other author show up in the commit log | 09:11 |
| robsta | oh, there's commit --author too | 09:12 |
| xshelf | the win32symlinks plugin works, great! | 09:26 |
| EarthLion | hey, i have a directory under control. I then copied these files manually and started working on the files in their new directory. I want to place this under control but keep all the history of the revisions. I realise i should of started a new branch and then done a checkout. Is there anyway I can do this now? | 10:21 |
| bob2 | what do you mean by "these files"? | 10:33 |
| awilkins | EarthLion_: Did you copy the folder recursively? | 10:34 |
| EarthLion_ | yep | 10:34 |
| awilkins | Then it's already a bzr branch :-) | 10:34 |
| awilkins | Do a bzr info in it and see if you got the .bzr control dir | 10:34 |
| EarthLion_ | ok (scratches head) | 10:34 |
| awilkins | Well, only if you copied the whole tree from the root | 10:35 |
| thumper | if I have shared repo with no trees, and I want to check out a branch from within the shared repo, how can I specify the hardlink location? | 10:48 |
| thumper | so I have a working tree called trunk | 10:48 |
| thumper | and a branch called foo | 10:48 |
| thumper | in branch foo I do a `bzr co --hardlink ???` | 10:48 |
| thumper | how do I specify trunk as the hardlink source? | 10:49 |
| lifeless | thumper: you can't today | 10:52 |
| lifeless | thumper: unless you have a checkout of trunk | 10:53 |
| lifeless | thumper: in which case just cp -al it and then switch :P | 10:53 |
| EarthLion_ | awilkins: so dispite doing a recursive copy (it must of been because the directories are many levels deep, and the website still functions perfectly) but the .bazaar directory isn't there. a bzr info tells me that it isn't a branch | 10:59 |
| EarthLion_ | so is there a way to just commit a directory to an existing branch? | 10:59 |
| === rocky|away is now known as rocky | ||
| lifeless | EarthLion_: make a new branch, copy the directory into the branch | 11:07 |
| EarthLion_ | fair enough | 11:08 |
| EarthLion_ | lifeless: and just replace/overwrite existing files? | 11:12 |
| siretart | beuno: FYI, I've uploaded a bzrtools 1.6.0 package for hardy to my PPA. it is based on jelmer's package for debian/experimental. | 11:21 |
| ignas | hi, where do I find out what was added to 1.6rc3 compared to 1.6rc2? | 12:01 |
| dato | the NEWS file does not say? | 12:01 |
| ignas | found it, thanks | 12:03 |
| ignas | do you know if anyone is going to fix the memory consumption problems in 1.6 series? | 12:04 |
| mwhudson_ | which particular problems? | 12:05 |
| === mwhudson_ is now known as mwhudson | ||
| ignas | bzr upgrade | 12:05 |
| mwhudson | in any case, i don't think anything more is going to be fixed in 1.6 | 12:06 |
| ignas | ouch :/ | 12:06 |
| mwhudson | 1.7 is only about 3 weeks away tho | 12:06 |
| ignas | i guess I should start warning all of my colleagues to ignore the "your repository is too old, bzr upgrade it" warning | 12:07 |
| beuno | siretart, great! I'll copy over to the bzr PPA. Thanks :) | 12:07 |
| ignas | because that eats 1.5 Gb of ram quite reliably | 12:08 |
| mwhudson | ignas: :( | 12:09 |
| mwhudson | ignas: can you branch into a new repository instead? | 12:09 |
| mwhudson | at least you can probably do that in stages if you have to... | 12:10 |
| ignas | emm, that would be very painful | 12:12 |
| ignas | I would have to redo the central repository setup again | 12:12 |
| ignas | on a remote machine | 12:13 |
| ignas | and then hope that launchpad mirrors keep working, and no one commits to anything while i am switching | 12:13 |
| ignas | not even talking about the 20 branches in the shared repository on my machine :/ | 12:13 |
| ignas | mwhudson: what kinds of manipulations are you performing with the code to explode from 70mb repository on disk into more than 1.5 Gb in memory | 12:15 |
| ignas | ? | 12:15 |
| ignas | well, 140mb repository | 12:16 |
| mwhudson | ignas: i don't know, and am not a bzr developer either :) | 12:16 |
| ignas | hmm, I wonder if python gives memory allocation information when profiling | 12:20 |
| ignas | bzr branch from my shared repository to the outside is taking 7 minutes already | 12:21 |
| ignas | mwhudson: ouch, I can't branch using 1.6rc3 too | 12:23 |
| ignas | at least not without running out of ram | 12:23 |
| fullermd | Well, to be sure, I wouldn't so much expect (branch into new format) to have memory usage or performance much different from (upgrade to new format)... | 12:24 |
| * ignas is thinking that migrating to git might be faster than waiting for 3 weeks to be able to create new branches :/ | 12:25 | |
| ignas | I wonder how will launchpad migrate my branches to the new format... maybe branching from a remote repository will work out better ... | 12:25 |
| mwhudson | ignas: you can probably bzr pull -r 100 | 12:26 |
| mwhudson | then bzr pull -r 200 | 12:26 |
| mwhudson | etc | 12:26 |
| ignas | up to 6000? | 12:26 |
| mwhudson | ignas: is there a bug on lp? | 12:26 |
| ignas | ok 4000 | 12:26 |
| ignas | for upgrade - yes | 12:26 |
| mwhudson | ignas: maybe you can do 1000 at a time, or write a script ... | 12:27 |
| ignas | and make everyone who has a schooltool checkout do that... :/ | 12:27 |
| ignas | that will be as painful as migrating from svn to bzr was... | 12:28 |
| fullermd | You'll understand the reasoning next week, when Canonical starts selling RAM ;) | 12:28 |
| mwhudson | ignas: or rebranch, i guess | 12:28 |
| luks | haha | 12:28 |
| ignas | mwhudson: we have a distributed team, most of the developers are part time, and will be working only in a week, or in two weeks, and I don't even know what are update schedules of deployed instances, making everyone do "something" or *not* do "something" is a bit tricky ... | 12:30 |
| mwhudson | ignas: well, you _can_ pull from packs to knits and so on | 12:30 |
| mwhudson | ignas: anyway, i hope a fix is found soon, i am off to bed | 12:31 |
| ignas | good night | 12:31 |
| lifeless | ignas: disk compression is very good | 12:32 |
| lifeless | ignas: the memory usage is a bug, its the sum of the plain texts, I suspect | 12:32 |
| lifeless | ignas: but it shouldn't do that unless its cross-format | 12:32 |
| ignas | lifeless: cross-format? | 12:33 |
| lifeless | ignas: please file a bug about this, get someone here to mark it critical | 12:33 |
| lifeless | I need to go sleep right now | 12:34 |
| lifeless | ignas: 1.6 is nearly released, to please file the bug asap | 12:34 |
| ignas | lifeless: ok | 12:34 |
| dato | poor jam | 12:35 |
| ignas | https://bugs.launchpad.net/bzr/+bug/256757 is there already | 12:35 |
| ubottu | Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Undecided,New] | 12:35 |
| ignas | I can update it with new information | 12:35 |
| ignas | as soon as I'll be done bzr branching from a remote repository | 12:36 |
| ignas | I know that local branching is not working, so I want to see whether I can at least create new branches from my server | 12:37 |
| fullermd | Yeah, do stick repo size and revision coutn and all that yada yada on it. | 12:44 |
| * fullermd critical-bumps it. | 12:44 | |
| ignas | ok, will do that | 12:44 |
| ignas | fullermd: how do I get revision count? | 12:44 |
| dato | bzr info should say afaik | 12:45 |
| fullermd | info -v lists it, under the 'Repository' heading. | 12:45 |
| === kiko is now known as kiko-afk | ||
| fullermd | (total revisions in the repo, rather than the number of revs in a branch) | 12:45 |
| ignas | fullermd: posted full bzr info -v of one of the "main" branches in that shared repository | 12:48 |
| xshelf | quit | 13:20 |
| balor | Is there a way to recursively inventory a directory and see if I've forgotten to add some files a-la-tla's [U] flag for unknown files? | 13:40 |
| vila | hi all | 13:44 |
| vila | Can someone remind me why diffs from bzr viz are colored under Linux but not under windows ? | 13:45 |
| vila | I'm pretty sure it's some python package but can't remember which nor find one... | 13:46 |
| Toranin | whee, left bzr-svn svn-import running all weekend...looks like only another day or two for it to actually finish :p | 13:46 |
| Toranin | copying revision 58473/81533 | 13:47 |
| luks | hm, lots of revisions | 13:49 |
| Toranin | yeah | 13:50 |
| Toranin | it's (a) large project with (I think) 5 or 6 years' history, and (b) contains a bunch of 'content translation' commits in the last year or two from our i18n infrastructure. Ideally I'd like to see the translations moved to a separate repository, but right now I'm just doing basic feasability testing | 13:52 |
| fullermd | vila: gtksourceview? | 13:53 |
| vila | fullermd: the name rings a bell ! thanks | 13:53 |
| vila | fullermd: yup, that's the one | 13:54 |
| aantn | I'm trying to upgrade a repository to format 6 | 14:01 |
| aantn | do I need to do anything other than run bzr upgrade --development && bzr push? | 14:02 |
| aantn | err, sorry; there should also be a bzr commit --unchanged in there | 14:02 |
| aantn | is that correct? | 14:02 |
| fullermd | push won't update the format at the far side. | 14:04 |
| fullermd | You have to do an upgrade there (or give upgrade the URL, though remote upgrade'ing is likely to be really slow unless you're really close) | 14:04 |
| Necoro | aantn: and make sure the remote update won't fail (esp. if you are using LP) ^^ | 14:05 |
| Necoro | I haven't found a way of restoring the repository (except deleting and repushing the branch) | 14:05 |
| luks | why do you want to use a development format, though? | 14:05 |
| aantn | luks: I'm actually not certain that I do | 14:06 |
| luks | so what do you want to do? :) | 14:06 |
| aantn | luks: is format r the development version or is that default? | 14:08 |
| aantn | *format 6 | 14:08 |
| luks | I don't know, there is no "repository format 6" as far as I know | 14:08 |
| aantn | luks: sorry, branch format 6 | 14:09 |
| luks | that's the default | 14:09 |
| aantn | thanks | 14:10 |
| aantn | I misunderstood that | 14:10 |
| luks | and if you want to upgrade a remote branch, you need to run either bzr upgrade sftp://... or run it remotely on the server | 14:11 |
| aantn | luks: is there any way to run an upgrade on launchpad without doing it remotely? | 14:12 |
| luks | no :( | 14:12 |
| luks | sftp is the only way | 14:12 |
| Necoro | bzr upgrade bzr+ssh://... works too | 14:12 |
| luks | bzr+ssh doesn't work, it was implemented only in 1.6 and it still not more efficient than sftp | 14:12 |
| Necoro | ;) | 14:12 |
| aantn | luks: do you mind giving an example upgrade command for launchpad | 14:13 |
| Necoro | ok - I used 1.6 | 14:13 |
| aantn | I'd like to make sure that I don't mangle this up | 14:13 |
| luks | Necoro: the server needs 1.6 | 14:13 |
| luks | aantn: what's the branch you want to upgrade? | 14:13 |
| aantn | https://code.launchpad.net/~universal-applets-core/universal-applets/trunk | 14:14 |
| Necoro | aantn: make sure you have a local branch ready in case it fails ;) | 14:14 |
| aantn | Necoro: will do | 14:14 |
| luks | bzr upgrade sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/ | 14:15 |
| luks | or insert your username before the hostname, if you don't have it configures in .ssh/config | 14:15 |
| luks | *configured | 14:15 |
| aantn | luks: thanks; I'll try that in a few minutes | 14:15 |
| Necoro | luks: but ... I used bzr+ssh ... and at least it started ... it later failed - but with a message that does not read like "we don't support upgrading via bzr+ssh" | 14:16 |
| Necoro | "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data." was the error message to be specific | 14:16 |
| luks | Necoro: you did not specify the format | 14:17 |
| luks | and you can't convert rich-root formats into the default formats | 14:17 |
| Necoro | the old format there was dirstate-tags | 14:17 |
| luks | I think it was 'rich-root' :) | 14:18 |
| Necoro | luks: http://rafb.net/p/rRkVlp50.html | 14:18 |
| Necoro | thats the output of "bzr info" from before upgrading | 14:19 |
| luks | dirstate-with-subtree then, even worst | 14:19 |
| luks | *worse | 14:19 |
| Necoro | oh ... I should improve my reading skills ;) | 14:19 |
| Necoro | but - this format hell is not really easy to understand ;) | 14:20 |
| luks | yeah | 14:21 |
| Necoro | for example - I don't know where there is the difference between pack-0.92, rich-root and rich-root-pack | 14:21 |
| Necoro | and which one to use for my repositories | 14:21 |
| luks | with that specific branch you can upgrade only to --pack-0.92-subtree | 14:22 |
| luks | --dirstate-tags, --rich-root and --dirstate-with-subtree are basically the same format, but with different handling of "tree root" | 14:23 |
| luks | same for --pack-0.92, --rich-root-pack and --pack-0.92-subtree | 14:23 |
| luks | the subtree variants were never 'officially supported' | 14:23 |
| Necoro | hmm - I guess I used this on LP, because it is a converted svn repo | 14:24 |
| luks | yeah, bzr-svn used to need the subtree formats | 14:25 |
| luks | the rich-root formats were added basically only for bzr-svn | 14:25 |
| luks | to avoid the subtree ones | 14:25 |
| Necoro | hmm - ok ... so it is not necessarily a good idea to have nearly all my repositories (even these ones which are created directly in bzr and never saw any subversion) in rich-root-pack | 14:26 |
| luks | AFAIK, the plan was to make a rich-root variant the default | 14:26 |
| fullermd | AFAIK, it still is. That should land in 1.2 or so... | 14:27 |
| luks | but I guess they are still not the default, because it's much slower to upgrade the default formats to them | 14:27 |
| luks | it needs to rewrite a lot of data | 14:27 |
| luks | can't see any other reason do to not do it | 14:27 |
| fullermd | Last I heard, it was still blocked on the upgrade not actually doing everything right. | 14:27 |
| luks | oh, and that, yes | 14:28 |
| luks | but that was fixed in 1.5, no? | 14:28 |
| fullermd | BTFOOM. | 14:28 |
| Necoro | hmm - and by "rich-root", it is meant to have a repos A - and inside it another repos B? - or something different? | 14:28 |
| fullermd | abentley was working on it, and I thought he still had another bump when he got busy with other stuff. | 14:29 |
| === menesis1 is now known as menesis | ||
| robsta | hi | 14:39 |
| robsta | i'm trying to interoperate between gnome's svn and bzr-playground | 14:39 |
| robsta | rumor has it that the newest bzr has lots of svn fixes, but i can't install from the ppa | 14:39 |
| robsta | this is on hardy, looks like deps are missing | 14:40 |
| LarstiQ | can't install bzr, or can't install bzr-svn? | 14:40 |
| robsta | added deb http://ppa.launchpad.net/bzr/ubuntu hardy main to sources.list, but it won't let me update | 14:40 |
| robsta | when i try with hardy's 1.3 it says SvnRepository and KnitRepository are incompatible | 14:41 |
| robsta | or "not implemented" when i try to "push --overwrite" to gnome-svn | 14:42 |
| luks | robsta: the latest version will tell you the same thing, because it's not compatible | 14:42 |
| luks | well, that's different | 14:42 |
| luks | but push --overwrite is almost a good idea | 14:42 |
| luks | what are you trying to do? | 14:43 |
| robsta | push my bzr-playground branch to gnome svn | 14:43 |
| luks | damn, "almost NEVER a good idea" | 14:43 |
| robsta | ooooh | 14:43 |
| luks | the svn branch has probably diverged since then | 14:43 |
| robsta | it said it had, but actually trunk/ was empty | 14:44 |
| robsta | not i "svn import" ed the source tree and try to "push --overwrite" | 14:44 |
| robsta | no2 i "svn import" ed the source tree and try to "push --overwrite" | 14:44 |
| robsta | *now | 14:44 |
| robsta | so the state of svn is irrelevant, the project was born on bzr-playground | 14:45 |
| luks | oh, it never existed in svn before? | 14:46 |
| robsta | no | 14:46 |
| luks | and the trunk/ in svn is already created, right? | 14:46 |
| robsta | yes | 14:46 |
| luks | so it thinks it's a different branch | 14:46 |
| luks | I'm not sure what's the best fix | 14:46 |
| Jc2k | robsta: hi again | 14:47 |
| robsta | well, now it has the latest source, because it tried to import it with svn, and the overwrite with bzr | 14:47 |
| Jc2k | robsta: i'm afraid we need bkor or jelmer to do this | 14:47 |
| luks | push --overwrite to svn can't work | 14:47 |
| Jc2k | robsta: i have a link for you | 14:47 |
| luks | I'd personally use "bzr replay" to copy the branch | 14:47 |
| luks | but there is probably a better way | 14:48 |
| robsta | Jc2k: are you the guy that gave us bzr-playground? | 14:48 |
| Jc2k | robsta: not quite, i spawned bzr-mirror and then canonical people spawned the playground | 14:48 |
| luks | )but of course that would screw up revision numbers in the original bzr branch) | 14:48 |
| Jc2k | robsta: http://uwstopia.nl/blog/2008/06/importing-bazaar-branches-into-gnome-svn | 14:48 |
| luks | oh, a trick with moving the trunk | 14:50 |
| Jc2k | thats what jelmer came up with | 14:51 |
| robsta | Jc2k: thx, and anyway, bzr-playground rocks :) | 14:51 |
| Jc2k | yes, they did a sweet job | 14:52 |
| robsta | svn rm'ing trunk doesn't work because of the maintainer hook | 14:53 |
| Jc2k | robsta: thats why we need bkor | 14:53 |
| Jc2k | (or jelmer, who threatened to write a python script that was immune to that hook) | 14:54 |
| robsta | ah, hah | 14:54 |
| robsta | Jc2k: ok, no hurry | 14:54 |
| robsta | it's just i don't know if people are happy when i'm starting to release tarballs of a playground-only module | 14:55 |
| Jc2k | robsta: you are just being to nice | 14:56 |
| Jc2k | *too | 14:57 |
| Jc2k | afaik, telepathy isnt on svn.gnome.org for example | 14:57 |
| robsta | hmm | 14:58 |
| robsta | by the way, is there any chance that bzr will interoperate with git repose some day? | 14:58 |
| Jc2k | jelmer is working on it | 14:59 |
| robsta | oh rock | 14:59 |
| Jc2k | indeed | 14:59 |
| Necoro | hmm ... there is the need for one common format of storing repository information ;) ... and then just having git, bzr, hg, svn etc. as frontends -- so everyone can use what they prefer ;P | 15:00 |
| LeoNerd | Er.. no, becasue that misses the entire point | 15:00 |
| robsta | Jc2k: so there /is/ a light at the end of the tunnel for DVCS :P | 15:00 |
| Necoro | LeoNerd: ok | 15:00 |
| LeoNerd | The different systems store diffrent data, in different models, with different capabilities. No one system would cover them all | 15:00 |
| fullermd | Good idea. But it doesn't go far enough. We also need one common format of command interface too, for easy interoperability. | 15:00 |
| fullermd | Then git and bzr and hg and svn can just be different... uh... | 15:01 |
| Jc2k | oh dear, meta-dvcs talk is never good | 15:01 |
| Jc2k | robsta: i dont see light, really. if bzr talks git, then git wins anyway | 15:02 |
| Jc2k | robsta: which i dont call light at the end of the tunnel | 15:02 |
| robsta | Jc2k: honestly, i don't care who wins | 15:02 |
| Jc2k | robsta: i have phases, but the bzr team consistently impresses me and think its a better long term choice | 15:03 |
| robsta | yeah, but git has such an incredible head start | 15:03 |
| fullermd | You think that's bad, look at the head start CVS has. | 15:04 |
| pickscrape | Not in terms of usability it doesn't... | 15:04 |
| LeoNerd | No, git just has better marketing.. I.e. kernel uses it | 15:04 |
| LarstiQ | robsta: head start on what? Market share? | 15:04 |
| robsta | market share in number of projects | 15:04 |
| robsta | (and that is guesse) | 15:04 |
| LarstiQ | robsta: right | 15:04 |
| pickscrape | What worries me about git is that it is very much focused on "What the kernel devs need" | 15:05 |
| LeoNerd | Ya.. it's highly tuned to one specific use case.. It doesn't work too well outside of that | 15:05 |
| luks | but but... it's so fast! | 15:06 |
| pickscrape | Diminishing returns though. | 15:06 |
| LeoNerd | luks: "The wrong answer quickly is still wrong" | 15:07 |
| pickscrape | Plus, I found that the speed advantage of git was more than eaten up by the time taken to refer to the man pages and googling for help every 2 minutes :) | 15:07 |
| LarstiQ | lots of people are happy with it though. | 15:08 |
| Necoro | hmm - btw: the GHC folks - they wanted to leave darcs behind ... does anyone know where they ended (or whether they already found an end at all) | 15:09 |
| luks | no program is ever going to fit all use cases | 15:09 |
| luks | Necoro: I think they decided to go with git, and now they argue if it was such a good idea | 15:09 |
| LeoNerd | luks: Exactly my point above, on the "no we don't want one VCS" | 15:09 |
| Necoro | luks: hmm ... if they at least had chosen hg ^^ | 15:10 |
| * luks is not going into hg vs git debate :) | 15:11 | |
| Necoro | luks: the only point, why I would have preferred it is: "at least hg is not git" ;P | 15:11 |
| luks | there is nothing wrong with git, er... wait | 15:12 |
| * LarstiQ doesn't think this is particulary constructive. | 15:12 | |
| Necoro | LarstiQ: who wanted to be constructive? | 15:13 |
| Necoro | ;P | 15:13 |
| Necoro | perhaps it needs another bzr-hosting-service ... LP is a lil' bit too ubuntu-centric imho | 15:13 |
| luks | almost any webhosting can host bzr | 15:14 |
| LeoNerd | I've never quite seen the point... | 15:14 |
| luks | I don't see a problem there | 15:14 |
| LeoNerd | Any ol' webserver will do | 15:14 |
| Necoro | luks: webhosting with SSH access ... because pushing via FTP is annoying | 15:14 |
| Necoro | and this isn't the cheapest thing to get ;) (if you don't own one already) | 15:16 |
| LeoNerd | Why is FTP pushing worse than sftp/bzr+ssh ? | 15:19 |
| Necoro | always typing a password is annoying | 15:20 |
| Necoro | and no: I'm not saving the pwd as part of the push-branch-address | 15:21 |
| LeoNerd | Ahright.... | 15:23 |
| cody-somerville | LeoNerd, bzr+shh makes use of the smart server | 15:27 |
| gour | Necoro: still git (for GHC) without any other alternative really concerned. i sent some msg to ml and two days ago started some discussion on #ghc 'cause someone noticed that git's workflow is not all in all. unfortunately, #bzr was quite sleepy and there was nobody to explain how looms can replace need for git's rebase :-( | 15:30 |
| Necoro | gour: oh =| | 15:31 |
| hsn_ | i have checkout and want to checkout different revision from same tree into same directory bzr checkout -r give error 183: .bzr file exists | 15:31 |
| LarstiQ | lifeless, jelmer: do you have cycles to help gour with explaining things to #ghc people? | 15:31 |
| gour | LarstiQ: someone should go there and talk...i'm too young with bzr and didn't go into such stuff as looms | 15:33 |
| LarstiQ | gour: aye, and I have been away too long. | 15:33 |
| LarstiQ | gour: you mentioned rebase earlier, jelmer would be the guy for that. And in general, lifeless is good at explaining things. | 15:33 |
| Necoro | hsn_: I would say: bzr revert -r 183 | 15:35 |
| gour | LarstiQ: yeah, i called for 'em. btw, see (huge) thread http://www.haskell.org/pipermail/glasgow-haskell-users/2008-August/015134.html | 15:35 |
| gour | LarstiQ: thumper jumped in and helped a bit, but then he had to go quickly | 15:35 |
| Necoro | hsn_: but if you want to create a new branch that starts at rev 183, I would say, it would be saner, to delete the current branch and start fresh at rev 183 ... | 15:36 |
| LarstiQ | gour: I'll try to read that thread today. | 15:36 |
| LarstiQ | Necoro: bzr branch -r 183 . ../newstart ? | 15:37 |
| Necoro | LarstiQ: please read what hsn_ wants ;P | 15:37 |
| Necoro | " and want to checkout different revision from same tree into same directory" | 15:37 |
| LarstiQ | Necoro: I have difficulty parsing that sentence. | 15:37 |
| hsn_ | yes bzr revert -r works | 15:38 |
| LarstiQ | hsn_: could you describe some more what your desired end result is? | 15:38 |
| Necoro | LarstiQ: he wants to have rev 183 in the current directory (for whatever reason) | 15:38 |
| LarstiQ | Necoro: is that it? That's fine for testing a historicals behaviour for instance, sure. And you are right that revert -r 183 is the way to do that. | 15:38 |
| gour | LarstiQ: the most unfortunate thing is that bzr was ruled out due to speed only although on wiki page it is quite feature-rich - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation howver, maybe there is still chance 'cause they did not switch. someone knowledgeable should contact them, ask for common workflows and explain how to do it in bzr. i'll continue using bzr (came from darcs), but i'm sure that ghc's move will heavily | 15:39 |
| gour | influenced the rest of haskell community (the whole hackage - haskell' cpan - uses darcs) | 15:39 |
| Necoro | true ... but one should not modify and commit now ;P - except this is what is really intended ;) | 15:39 |
| LarstiQ | Necoro: there are reasons to do that, but yes, it is slightly peculiar. Ref my request for clarification of intent from hsn. | 15:41 |
| LarstiQ | hsn_: so. :) | 15:41 |
| Necoro | ah btw ... just because this is such a great tool: Thanks to all you Bzr-Devs for your efforts ;) | 15:42 |
| Necoro | (needed to be said today :D) | 15:42 |
| hsn_ | can i start bazaar without loading plugins? | 15:42 |
| LarstiQ | hsn_: yes, bzr --no-plugins | 15:42 |
| luks | --no-plugins | 15:42 |
| === mark1 is now known as markh | ||
| awilkins | markh: Are you building Python-flavoured builds? | 15:52 |
| aantn | luks: how would I attach my username to the url sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/ | 15:53 |
| luks | sftp://USERNAME@bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/ | 15:53 |
| aantn | luks: thanks | 15:55 |
| * aantn crosses his fingers and hopes nothing goes wrong with the remote upgrade | 15:55 | |
| luks | it will probably take some time | 15:55 |
| aantn | luks: yeah, bzr is still backing up the tree history | 16:54 |
| aantn | do I need to repull a local copy of my branch after I finish upgrading the remote branch? | 17:28 |
| LarstiQ | aantn: that depends. Was it previously up to date? | 17:30 |
| LarstiQ | aantn: If yes, the no pulling is needed. You might still want to make sure it uses the same format as remote (though not required). | 17:31 |
| LarstiQ | aantn: so bzr info local; bzr info remote; and bzr upgrade to remote's format if different | 17:31 |
| aantn | LarstiQ: thanks | 17:32 |
| === mark1 is now known as markh | ||
| TemplePrime | can I have multiple projects in a repository? | 17:55 |
| Tak | I must be doing something wrong here, correct? http://rafb.net/p/I0Yaxz51.html | 17:57 |
| LarstiQ | Tak: what do `bzr st` and `bzr missing` say? | 18:03 |
| Tak | `bzr st` returns empty | 18:03 |
| LarstiQ | Tak: there might be a bug there. Frankly, being bound to a branch but having zero revisions is a strange situation. | 18:04 |
| LarstiQ | How did you end up in that state? | 18:04 |
| Tak | ah, ok | 18:04 |
| Tak | I'm following the manual, setting up a new repo | 18:04 |
| LarstiQ | really? Which manual? | 18:04 |
| Tak | http://doc.bazaar-vcs.org/latest/en/user-guide/index.html | 18:04 |
| Tak | except I guess I mingled the working-offline section with the starting-a-central-branch section in a way that's not supported | 18:05 |
| LarstiQ | Tak: it mentions unbind a couple of times, but they don't seem to match. What section are you following? | 18:05 |
| LarstiQ | Tak: ah. | 18:07 |
| Tak | if I just can't do that with the initial revision, then that's cool | 18:07 |
| LarstiQ | Tak: I'm still trying to understand what you were trying to do. | 18:07 |
| LarstiQ | Tak: it is certainly a bug that bzr tells you to do something, you do it, and then it doesn't help you. | 18:08 |
| Tak | I was trying to do the initial file import on a checkout of a newly-created repo | 18:08 |
| LarstiQ | Tak: I have a hunch as to why things go awry in this case, but if you can give me a complete recipe for reproducing this, I can thwack the bug on it's head. | 18:09 |
| Tak | sure | 18:09 |
| LarstiQ | Tak: does the master have any revisions at all? | 18:10 |
| Tak | no | 18:11 |
| LarstiQ | Tak: thanks, that gave me enough info I think. 'bzr init sftp://localhost/tmp/master; bzr checkout sftp://localhost/tmp/master/ slave; cd slave; bzr unbind; touch foo; bzr add; bzr ci -m 1; bzr bind; bzr ci; bzr up; bzr ci;' gets me the same error. | 18:14 |
| Tak | yes, that's exactly what I did | 18:14 |
| Tak | I was just pastebinning an entire session for you ;-) | 18:14 |
| LarstiQ | Tak: I'll still look at it for your effort :) | 18:14 |
| LarstiQ | Tak: so, you'll find that if master actually has a revision, the update will do something. | 18:15 |
| Tak | ok, cool | 18:15 |
| LarstiQ | Tak: say, bzr checkout master slave2; cd slave2; touch bar; bzr add; bzr ci; cd ../slave; bzr update | 18:15 |
| LarstiQ | Tak: and status should show your initial local commit as a pending merge | 18:16 |
| Tak | `bzr push master` seems to rectify it for me | 18:16 |
| Tak | (for the zeroth => first revision) | 18:16 |
| LarstiQ | That is also an option. | 18:18 |
| LarstiQ | You're basically operating in standalone branch mode there, and not checkouts. | 18:18 |
| LarstiQ | Tak: what I'd personally would have done is probably: bzr init trunk; cd trunk; cp -a ../prebzr/* .; rm -rf CVS; bzr add; bzr ci; bzr push master (this will create the branch); bzr bind master; | 18:19 |
| Tak | I see | 18:19 |
| * Tak obviously new to bzr | 18:20 | |
| LarstiQ | Since you're setting up the branch from scratch. With a preexisting master it would just be 'bzr co master trunk; cd trunk; *hack*; bzr ci' | 18:20 |
| LarstiQ | Tak: that's ok, you help find bugs in cases more experienced users won't think of :) | 18:21 |
| === thekorn__ is now known as thekorn | ||
| jam | I just found a major regression in knit => pack performance :( | 19:27 |
| LarstiQ | namely? | 19:28 |
| jam | LarstiQ: "bzr branch knit pack" results in a 170MB repo when it should be 34MB | 19:29 |
| jam | https://bugs.edge.launchpad.net/bzr/+bug/256757 | 19:29 |
| ubottu | Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Triaged] | 19:29 |
| jam | It might actually only be in bzr.dev, though. | 19:29 |
| LarstiQ | Aha. | 19:29 |
| jam | the problem is that it does an "unsorted" fetch with all fulltexts | 19:29 |
| LarstiQ | I recently upgraded my bzr repo, it took all evening and was constantly thrashing. 2.3G committed memory. | 19:29 |
| jam | which means that the target repository | 19:29 |
| LarstiQ | so yeah. | 19:29 |
| jam | will insert fulltexts in random order | 19:30 |
| jam | and "random" doesn't delta very well | 19:30 |
| LarstiQ | oh boy. | 19:30 |
| Peng_ | Wow. | 19:30 |
| luks | doesn't it _always_ diff against the left-most parent? | 19:30 |
| LarstiQ | james_w: do you remember what happened to your test for bug 120968 ? | 19:35 |
| ubottu | Launchpad bug 120968 in bzr ""bzr update" in checkout of empty branch fails and breaks dirstate" [High,In progress] https://launchpad.net/bugs/120968 | 19:35 |
| Tak | hooray! | 19:35 |
| * LarstiQ has trouble finding a test for that in bzr.dev | 19:35 | |
| james_w | hey LarstiQ | 19:35 |
| jam | luks: When you insert in random order, the left-hand parent may not be *present* yet, and thus you get a fulltext | 19:36 |
| LarstiQ | Tak: that's a different bug though :) | 19:36 |
| jam | So about 50% of your deltas get expanded to fulltexts | 19:37 |
| LarstiQ | Tak: yours is #259146 | 19:37 |
| jam | Changing it to "topological" causes it to re-delta everything, which is costly CPU (and memory) wise, but at least the target repo isn't bloated. | 19:37 |
| luks | oh, I thought it would reject revisions with missing parents | 19:39 |
| luks | but thinking about it again, it wouldn't make sense for ghosts | 19:39 |
| jam | fullermd: ping about bug 256757 | 19:39 |
| ubottu | Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Triaged] https://launchpad.net/bugs/256757 | 19:39 |
| jam | I just want to check what version of bzr is involved | 19:39 |
| jam | as to whether this is a 1.6 regression, or just bzr.dev | 19:39 |
| * Tak subscribe | 19:40 | |
| james_w | LarstiQ: ah, that was never merged I think | 19:41 |
| james_w | I just never got round to writing the fix part of the patch | 19:42 |
| jam | damn, it *is* in bzr-1.6 | 19:43 |
| jam | beuno: I'm going to need a 1.6rc4... :( | 19:44 |
| LarstiQ | james_w: 1.5 doesn't break on this, but it isn't testing it afaics, so I don't want to close the bug yet. | 19:44 |
| jam | LarstiQ: have you tried 1.6rc? | 19:44 |
| LarstiQ | jam: nafaict | 19:44 |
| LarstiQ | jam: I _think_ it was 1.5, but I can do it again (I kept the old repo around, it didn't seem right to me) | 19:45 |
| LarstiQ | jam: du -mcs backup.bzr .bzr: 100 and 610 meg | 19:46 |
| pickscrape | jam: if you have a repository affected by this bug, will a "bzr pack" using a fixed bzr bring the repo down to normal size (obsolete_packs notwithstanding)? | 19:46 |
| * LarstiQ looks at the bug | 19:47 | |
| jam | pickscrape: no :( | 19:48 |
| jam | pickscrape: that is why it is an extreme blocker for 1.6 | 19:48 |
| pickscrape | Heck, yes indeed. | 19:48 |
| jam | we could *teach* pack to do so | 19:49 |
| jam | but it doesn't yet | 19:49 |
| jam | pickscrape: we probably should anyway, to get people who have already upgrade to get back into reality again | 19:49 |
| TemplePrime | hey guys, are there any bazaar hosting services around? free and non free? | 19:50 |
| Tak | launchpad? | 19:50 |
| TemplePrime | does it provide though security features, like only memebers of groups can see source? | 19:51 |
| LarstiQ | TemplePrime: any file hoster would do for bare requirements. | 19:51 |
| jam | TemplePrime: there *are* private branches, which is non-free | 19:51 |
| jam | And IIRC, not widely disseminated. I think it is still in a beta program. | 19:51 |
| TemplePrime | launchpad seems a decent service, I'll get an account | 19:52 |
| === kiko-afk is now known as kiko | ||
| LarstiQ | jam: started an upgrade with 1.5 to --pack-0.92 | 19:54 |
| jam | fullermd: thanks for marking the bug critical, btw. It caused me to investigate it. | 19:54 |
| jam | and it really is a critical regression | 19:54 |
| aantn | luks: by the way, thanks for the help earlier; I got my branch switched over successfully | 19:55 |
| beuno | jam, :( | 19:55 |
| jam | beuno: yeah, but when we start warning users that they need to upgrade, I don't think we want to bloat their repos by about 5:1 | 19:56 |
| LarstiQ | jam: hmm, that seemed to have gone wonderfully well | 19:57 |
| jam | LarstiQ: with 1.5? | 19:57 |
| LarstiQ | jam: yes | 19:57 |
| LarstiQ | jam: so perhaps I did the upgrade previously with bzr.dev, let me try that | 19:57 |
| beuno | jam, right. Makes sense :) When? | 19:58 |
| LarstiQ | jam: at 300 megs and rising, so far so good. | 20:01 |
| jam | beuno: Well, I would really like lifeless to wake up and review the patch | 20:02 |
| jam | Otherwise I'll be submitting a patch for review in about 10 minutes | 20:03 |
| LarstiQ | jam: ~1G and system becoming unresponsive. | 20:03 |
| jam | LarstiQ: yeah it was rev 3854 that introduced the bug | 20:03 |
| LarstiQ | so yeah, seems to be the same behaviour as last time. | 20:03 |
| jam | which is in 1.6 and bzr.edv | 20:03 |
| luks | aantn: what version did you use to upgrade? maybe it was not such a good idea after all :( | 20:03 |
| jam | luks: 1.5 is safe | 20:04 |
| jam | 1.6-final *will* be safe | 20:04 |
| luks | I think aantn was seing the upgrade warning | 20:04 |
| luks | which is only in 1.6-something | 20:04 |
| jam | luks: yep, and bzr.dev | 20:04 |
| clemente | Hey, „bzr log“ is slower in current bzr.dev than in 1.5 :-( 1' 30" vs 1' 15" for showing the log of lp:bzr.dev | 20:05 |
| aantn | luks: I upgraded to the repository format 6 | 20:06 |
| beuno | jam, alright, ping me and I'll try and upload tonight | 20:09 |
| beuno | I'm supposed to be on holiday today :) | 20:09 |
| jam | beuno: well, we *can* wait until tomorrow if you are busy. This is just a serious regression :( | 20:11 |
| pickscrape | On holiday already? :p | 20:12 |
| jam | On the plus side, with my fix the branch time drops from 5m => 30s, which actually makes knit => pack faster than it would be in 1.5 | 20:17 |
| jam | Of course, all of this is discovered while *3* core devs are on vacation | 20:19 |
| jam | (abentley, spiv, poolie are all away this week) | 20:19 |
| jam | beuno: LarstiQ, can you try to review the patch? | 20:19 |
| LarstiQ | jam: I'll look at it, but I don't promise to be worth anything. | 20:20 |
| jam | LarstiQ: well, the patch is pretty much 'trivial" as it was just a "not" logic inversion | 20:21 |
| jam | if you want to just download it and try it on your upgrade | 20:21 |
| jam | that would probably be enough for me. | 20:21 |
| LarstiQ | right | 20:22 |
| LarstiQ | that does look simple | 20:25 |
| jam | I think the problem is that the naming of the parameter is poor | 20:26 |
| LarstiQ | agreed. | 20:26 |
| jam | "fetch_uses_deltas" versus "include_delta_closure" | 20:26 |
| jam | the latter sure *sounds* like it sends deltas | 20:26 |
| LarstiQ | (on it being pure, don't know if that is _the_ problem) | 20:26 |
| jam | it actually means trace back through all deltas and make sure to include all the referenced info | 20:27 |
| LarstiQ | is it me, or is bundlebuggy slow/not resolving? | 20:27 |
| jam | abentley has been complaining about his hosting | 20:27 |
| LarstiQ | jam: well, _closure does sort of evoke that in my mind | 20:27 |
| jam | I'm not getting to the site | 20:27 |
| LarstiQ | sort of, because I didn't know exactly what a closure would involve | 20:27 |
| jam | LarstiQ: sure, though I will say lifeless wrote both apis and got it wrong :) | 20:27 |
| LarstiQ | jam: oh yes, I support you | 20:28 |
| jam | LarstiQ: BB is probably down right now, and abentley isn't around to ping to bring it back up. | 20:29 |
| jam | You'll have to just do a reply | 20:29 |
| jam | and assume BB will wake up later | 20:29 |
| LarstiQ | jam: I wanted BB to pull from, but I've saved the patch and scped it. Running the upgrade with a patched bzr.dev | 20:29 |
| jam | I don't think BB has even detected my patch yet | 20:31 |
| LarstiQ | jam: bzr: ERROR: Revision {('testrevisionnamespaces.py-20050711050225-8b4af89e6b1efe84', 'robertc@robertcollins.net-20051002215128-5686c7d24bf9bdb9')} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x895d90c>". | 20:31 |
| jam | LarstiQ: I just got a timeout with a "Proxy Error" | 20:31 |
| jam | LarstiQ: you need bzr.1.6 | 20:31 |
| jam | Though I would have thought that was merged into bzr.dev tip | 20:31 |
| LarstiQ | jam: this is my historical bzr repo | 20:31 |
| jam | LarstiQ: or is that what you get when upgrading? | 20:31 |
| jam | LarstiQ: it wouldn't be something that you need to 'bzr reconcile' would it? | 20:32 |
| jam | IIIRC the 1.5 fetch code could handle "broken" repos that need reconcile | 20:32 |
| jam | 1.6 doesn't | 20:32 |
| jam | And I would guess Robert's "bug" would let you fetch because it would cause everything to be sent as fulltexts... | 20:33 |
| jam | So it basically does reconcile on-the-fly | 20:33 |
| jam | but the fetch into-packs won't trigger the "auto-reconcile" code, which means you run into your problem.... | 20:34 |
| jam | hmmm | 20:34 |
| jam | LarstiQ: can you try a line for me, just a sec | 20:35 |
| jam | LarstiQ: http://rafb.net/p/Ux6YDH80.html | 20:36 |
| * LarstiQ is currently afk on the phone | 20:38 | |
| LarstiQ | jam: it was indeed what I got when upgrading *looks at rafb* | 20:48 |
| LarstiQ | jam: applied and trying again | 20:49 |
| jam | thx | 20:49 |
| LarstiQ | jam: same problem | 20:52 |
| jam | LarstiQ: can you post the traceback, so I can see where it happens? | 20:52 |
| LarstiQ | jam: http://rafb.net/p/bV38GS44.html | 20:54 |
| jam | LarstiQ: ok, it is getting to the failure before it gets a chance to reconcile. | 20:55 |
| jam | LarstiQ: unfortunately, I think the correct fix is to upgrade using bzr.1.5 and then run reconcile. | 20:55 |
| jam | or run reconcile first | 20:56 |
| jam | but that is generally very slow with knits. | 20:56 |
| LarstiQ | yeah | 20:56 |
| LarstiQ | I'll do some reconciling | 20:58 |
| jam | LarstiQ: keep an old copy of it, if it isn't too much overhead | 20:59 |
| jam | just so we remember stuff like that. | 20:59 |
| LarstiQ | jam: I'm working on copies of my original backup.bzr, it's too valuable to touch directly. | 21:01 |
| LarstiQ | great | 21:07 |
| LarstiQ | bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit inventory corrupt: | 21:07 |
| jam | LarstiQ: so... I would try upgrading with bzr-1.5, and then doing "bzr reconcile" and see where you get. | 21:19 |
| LarstiQ | will do. That was an 1.5 reconcile on the knit repo btw. | 21:21 |
| LarstiQ | jam: 1.5 upgrade, 1.5 reconcile -> oh hey, your repository is corrupt kthxbye! | 21:36 |
| LarstiQ | jam: trying a 1.5 upgrade, bzr.dev reconcile now | 21:36 |
| LarstiQ | just out of sheer desperation | 21:36 |
| jam | LarstiQ: I wouldn't expect much, if this is the bug I'm thinking of | 21:36 |
| * jam guesses LarstiQ pulled directly from one of abentley's repos at some time in the past when they had diverged when we didn't realize | 21:37 | |
| LarstiQ | maybe | 21:37 |
| LarstiQ | sha-1 548f019618118527ae97bb092643be0d187c0cf1 of reconstructed text does not match expected 89853621e92f00ae1bb075139284c4df9a0434d0 for version john@arbash-meinel.com-20051117204806-013b3027c63d642b | 21:37 |
| jam | LarstiQ: specifically, there were ghosts in aaron's repo, which caused "last-modified" entries to be different | 21:37 |
| jam | there were *deltas* generated against those texts | 21:37 |
| LarstiQ | jam: considering I have decendant code of nested-trees, it's not unlikely | 21:38 |
| jam | and those deltas were pulled directly on top of the other form | 21:38 |
| jam | without realizing that the base sha1 differed | 21:38 |
| wolever | I'm getting a message 'bzr: ERROR: Revision {...revision ID...} not present in "filename.py-...revision ID..."' -- how would I go about figuring out what's happening? | 21:57 |
| LarstiQ | jam: ehm, that 1.5 upgrade, 1.6 reconcile seemed to work. | 22:13 |
| LarstiQ | wolever: I don't have a good answer to that. | 22:13 |
| Peng_ | wolever: Not that this helsp, but the "filename.py-..." thing is a file ID, not a revision ID. | 22:13 |
| LarstiQ | jam: trying to comment on the patch, slow going because it means reading other parts of the codebase | 22:14 |
| zeth | Hi | 22:16 |
| pickscrape | Is it possible to create a branch of a branch with working tree that carries over the state of the working tree also? | 22:16 |
| lifeless | moining | 22:16 |
| zeth | So at the moment I am just going open('.bzr/branch/last-revision').readline().split()[0] to get the rev number, can I do this with bzrlib? | 22:16 |
| Peng_ | pickscrape: Well, you can use "bzr merge --uncommitted" after you branch. | 22:17 |
| awilkins | pickscrape: If you are using checkouts, you can push to a new branch and switch to it | 22:17 |
| lifeless | zeth: bzrlib.branch.Branch.open('.').last_revision() | 22:17 |
| Peng_ | zeth: You can also do something like "bzr revno". | 22:18 |
| pickscrape | Peng: I'll try that | 22:18 |
| lifeless | jam: hi | 22:18 |
| Peng_ | (well, that's if you're not doing it from Python) | 22:18 |
| pickscrape | awilkins: I don't want to commit what's in my WC yet, though I suppose I could do that and uncommit etc. | 22:18 |
| awilkins | pickscrape: I think if you push a new branch and switch what's left in your WC remains? | 22:19 |
| awilkins | I could be wrong | 22:19 |
| awilkins | hmm. Or you could shelve and switch | 22:20 |
| zeth | lifeless: cheers | 22:20 |
| zeth | Peng_: sorry should have said that from python | 22:20 |
| pickscrape | awilkins: yes, you're right. My current tree is in a checkout of a checkout (which actually works). I'm wanting to experiment with a loom, so I want to try it in a new branch | 22:20 |
| pickscrape | merge --uncommitted has basically done exactly what I wanted though. Thanks for the help :) | 22:20 |
| wolever | Peng_: Ah, excuse me. LarstiQ: Darn. Oh well, it's just a frustration, no lost work. | 22:22 |
| LarstiQ | wolever: other people should know though, but I wanted to say something and not let your question go without any reply. | 22:22 |
| LarstiQ | lifeless: heya | 22:22 |
| LarstiQ | lifeless: I think jam would like your feedback on [REGRESSION][1.6] fetching knits => packs | 22:23 |
| wolever | LarstiQ: Alright, I'll keep a copy of the offending repositories around then come back tomorrow | 22:23 |
| LarstiQ | wolever: if you can provide some more context on when it happens, that would help I think. | 22:24 |
| lifeless | LarstiQ: yes, I need to talk to him about it | 22:24 |
| LarstiQ | lifeless: good, then I'll stop looking at code and call it a day. | 22:25 |
| wolever | LarstiQ: I'd love to, but so far it's only happened once, and I'm not sure how to repeat it. My suspicion is that it's got something to do with either mismatched versions of bzr-svn and bzr or canceling an operation at the wrong time. | 22:25 |
| LarstiQ | jam: do you want me to do anything with the upgraded/reconciled repository? | 22:25 |
| lifeless | LarstiQ: lol :) | 22:26 |
| LarstiQ | wolever: hmm, I'd say it still shouldn't in those cases. Your ~/.bzr.log should contain a traceback for it btw. | 22:26 |
| awilkins | Is it me or is Bundle Buggy Busted? | 22:29 |
| LarstiQ | awilkins: it is not you. | 22:29 |
| jam | LarstiQ: you can keep it on the side if you want. Thanks for your help. You did miss a 'get_record_stream()' I didn't see. | 22:35 |
| jam | lifeless: I'd like your help to put together a quick test case for all the fetches | 22:35 |
| jam | I believe there are 4 or so | 22:35 |
| jam | revs, sigs, invs, texts | 22:35 |
| lifeless | jam: yah, I think there are two tests needed | 22:36 |
| lifeless | one with _fetch_uses_delta True, and one False | 22:36 |
| jam | I really want to get an rc4 out today if at all possible | 22:36 |
| lifeless | we can use the existing VersionedFilesDecorator to catch the get_record_stream_calls | 22:36 |
| lifeless | so its roughly | 22:36 |
| lifeless | make_repo_a | 22:36 |
| lifeless | make_repo_b | 22:36 |
| lifeless | repo_a.texts = VersionedFilesDecorator(repo_a.texts) | 22:36 |
| lifeless | .signatures | 22:37 |
| lifeless | .revisions | 22:37 |
| lifeless | .inventories | 22:37 |
| lifeless | repo_b.fetch(repo_a) | 22:37 |
| lifeless | inspect repo_a.texts.calls | 22:37 |
| lifeless | this is a bzrlib.tests.test_fetch test-case, because it doesn't need to be parameterised by formats | 22:37 |
| lifeless | and we should do it with repo_b as a pack, and again with repo_b as a weave, to get both values for _fetch_uses_deltas | 22:38 |
| lifeless | jam: I can actually write it if you want, I figure that handoff time doing that would be greater | 22:39 |
| jam | lifeless: I think you've given me enough | 22:40 |
| jam | I've already got the code here | 22:40 |
| LarstiQ | jam: those are all icw _fetch_uses_deltas afaics, the rest is in (True, False, include_delta_closure) | 22:41 |
| rick_h_ | lifeless: ping, I sent off the article I told you about. If you get a chance to peek at it. Pretty simple examples | 22:41 |
| rick_h_ | no big deal though | 22:42 |
| jam | LarstiQ: 'icw' ? | 22:42 |
| LarstiQ | jam: in combination with, sorry, that is a Dutchism. | 22:43 |
| awilkins | "I cuckold walruses?" | 22:43 |
| jam | awilkins: sorry to hear that awilkins | 22:43 |
| awilkins | :-P | 22:43 |
| awilkins | The standalone exe for win32 has all the source compiled inside it, yes? | 22:44 |
| awilkins | What does it do about things like GTK libraries? | 22:45 |
| LarstiQ | jam: the endresult now is 173 knitpack and 100 knit repos btw | 22:45 |
| jam | LarstiQ: with my patch... and does that include removing files from .bzr/repository/obsolete_packs ? | 22:45 |
| jam | reconcile, IIRC, creates an obsolete pack | 22:45 |
| LarstiQ | awilkins: last I looked at it, fall over. But maybe markh has done something smart to instrument import. | 22:46 |
| lifeless | awilkins: not sure, bundles I thought | 22:46 |
| LarstiQ | jam: reconciled with your patch, yes. *looks at oldpacks* | 22:46 |
| jam | LarstiQ: We don't have the gtk libraries bundled into the all-in-one so you can't use the bzr-gtk plugin | 22:46 |
| jam | awilkins: I thought there was a discussion about adding places to the search path | 22:46 |
| jam | but I don't think it got very far | 22:47 |
| jam | so, ATM, the win32 will bundle the QT libraries to go with qbzr and tortoise | 22:47 |
| LarstiQ | jam: and now it is 87 megs big, cheers. | 22:47 |
| jam | LarstiQ: that sounds better | 22:47 |
| awilkins | It must bundle some of the QT stuff because it uses qbzr now | 22:47 |
| LarstiQ | jam: iirc 14 meg bigger than just the 1.5 upgraded version. But reconciled, so I can live with that. | 22:47 |
| awilkins | markh has not posted the Python flavoured builds of the installer | 22:48 |
| awilkins | (for win32) | 22:48 |
| jam | LarstiQ: probably for the bits that had bad deltas, it inserted new fulltexts | 22:48 |
| jam | we should really teach 'bzr pack' to combine a bit better | 22:48 |
| jam | but that will probably wait for something like 'group-compress' | 22:48 |
| LarstiQ | jam: yes. | 22:48 |
| jam | where I see 100MB => ~20MB when done correctly | 22:48 |
| lifeless | rick_h_: cool | 22:53 |
| jam | lifeless: how do you want to handle the 'extra' calls, like get_parent_map() and iter_lines_added... | 22:55 |
| jam | should I just check the *last* entry, which is 'get_record_stream' ? | 22:55 |
| jam | or should I be asserting the whole thing | 22:55 |
| zeth | so back to bzrlib, bzr has some magic way of finding the branch always, even if you are symlinked off or whatever, any idea how to use that from bzrlib? | 22:57 |
| jam | zeth: bzrlib.branch.Branch.open? or open_containing | 22:58 |
| rockstar | lifeless, hi | 22:59 |
| zeth | jam!, sweet cheers! | 23:00 |
| lifeless | jam: I would check there is only one get_record_stream call, and that it has the right value for that parameter | 23:01 |
| lifeless | jam: thats all | 23:01 |
| jam | lifeless: yeah, I didn't think we wanted to check all of it is constant | 23:02 |
| lifeless | zeth: if you look at bzrlib.builtins, you can see the code we use | 23:02 |
| lifeless | rockstar: hi | 23:02 |
| lifeless | jam: doing wakeup-stuff, back in a little bit | 23:03 |
| jam | lifeless: of course, for signatures, we seem to be doing 2 calls . :( | 23:03 |
| rockstar | lifeless, I,ve been hacking on cscvs today. Have some questions when you get back. | 23:07 |
| jam | lifeless: also, it seems that the proper value is 'unordered' not 'unsorted'... | 23:16 |
| jam | 'unsorted' worked because anything other than 'topological' works | 23:17 |
| chadmiller | rockstar: Heya. Did you get mail from me (chad at sun com) about revno reset. | 23:19 |
| chadmiller | ? | 23:19 |
| lifeless | jam: meep | 23:19 |
| lifeless | rockstar: hi, just shoot | 23:19 |
| rockstar | chadmiller, I certainly did. Thank you! | 23:19 |
| rockstar | lifeless, aggregating now | 23:19 |
| chadmiller | rockstar: I have another case for you. :) :\ :( | 23:21 |
| rockstar | lifeless, testInitProtocolBadHost seems to hang | 23:21 |
| rockstar | chadmiller, yes? | 23:21 |
| chadmiller | rockstar: Same problem. Same three developers. | 23:21 |
| lzhang | is there a way to make bzr missing remember the branch that you want to want to run the command on? | 23:21 |
| jam | lifeless: ugh, it seems that for the 'iter_items_introduced_by' we do a direct get_record_stream() check for every revision to see if there is a signature | 23:22 |
| rockstar | chadmiller, and bzr resolve doesn't help? | 23:22 |
| rockstar | chadmiller, I mean bzr reconcile | 23:23 |
| lifeless | jam: thats in Model1To2 | 23:23 |
| jam | lifeless: no, it is in "item_keys_introduced_by" | 23:23 |
| lifeless | jam: so you are doing a plain->rich-root conversion in your test case | 23:23 |
| jam | lifeless: nope, it does a "get_signature_text() try/except" to decide if it is part of the stream | 23:23 |
| lifeless | jam: oh fugkly | 23:24 |
| jam | and get_signature_text is implemented as get_record_stream | 23:24 |
| jam | which we then discard when we actually stream | 23:24 |
| lifeless | still, its been like that for a while | 23:24 |
| jam | lifeless: sure, I'm trying to do the minimum possible | 23:24 |
| jam | so I'll cheat for that one with a big TODO/XXX | 23:24 |
| chadmiller | rockstar: "oh [reconcile] does fix it... we just lose about 3 hours daily running it to fix the corruption" | 23:24 |
| lifeless | ok, breakfast | 23:25 |
| lifeless | then I will be here uninterrupted | 23:25 |
| jam | chadmiller: do you happen to be using knits in one place, and packs in another? | 23:25 |
| chadmiller | rockstar: "then someone pushes and it goes to hell again." | 23:25 |
| rockstar | chadmiller, oh yikes. | 23:25 |
| chadmiller | jam, doubtful. | 23:25 |
| * chadmiller verifies. | 23:26 | |
| jam | chadmiller: well, a) you only need to reconcile the branch, which is a very small and fast portion of 'reconcile' and I think someone wanted to introduce a flag for only runing parts | 23:26 |
| jam | chadmiller: well, if it is a mysql tree, they never went public with a knit tree | 23:26 |
| jam | s/tree/repo/ | 23:26 |
| chadmiller | jam: it's an internal project, unpublished. | 23:27 |
| jam | b) the only time I've specifically seen this, is when someone is accessing a repo that is missing a mainline revision | 23:27 |
| chadmiller | Hrm. | 23:27 |
| jam | there was a way that an old client pushing pack => knit could cause this if they ^C at the right time | 23:27 |
| jam | it at least feels like someone has a branch with a bad pointer, and they keep pushing over your official location | 23:28 |
| rockstar | chadmiller, did the branch come from a conversion of another vcs? | 23:28 |
| chadmiller | rockstar: Yes. svn, iirc. | 23:28 |
| chadmiller | jam: all the branches I see pushed to are rich-root-pack. | 23:30 |
| jam | chadmiller: the problem is the 'from' (I'm guessing) | 23:31 |
| rockstar | That would make sense. | 23:33 |
| LarstiQ | hah. | 23:39 |
| jam | lifeless: if you get a chance, there is a patch up for review, and i'd like to get it submitted | 23:42 |
| jam | No standup today, unless igc comes around | 23:43 |
| chadmiller | jam, rockstar: One other weirdness out of this team is that they're using sftp as transport. | 23:44 |
| jam | chadmiller: I'm not particularly worried about that part | 23:44 |
| chadmiller | Alright. They're watching to see when it happens. I have them running "bzr revno" on the destination before and after each push, branch, and merge. | 23:46 |
| lifeless | jam: | 23:49 |
| jam | ? | 23:49 |
| lifeless | jam: sorry | 23:50 |
| lifeless | reading, I'm not sure about the assertion | 23:50 |
| jam | chadmiller: what would be nice is to have a post_branch_tip_changed hook, but you aren't using bzr+ssh to install it on the server, and it is probably a pain to install it on all the clients | 23:50 |
| lifeless | you didn't alter weaves for instance :) | 23:50 |
| jam | lifeless: I think we should have *something* to make sure recognized values are passed. I don't care a lot about that part | 23:51 |
| jam | and I just want to get a 1.6rc out that can actually become final | 23:51 |
| lifeless | bb:approve | 23:51 |
| === chadmiller is now known as chad|evening | ||
| jam | lifeless: with the assert left in? | 23:56 |
| lifeless | jam: yes | 23:56 |
| jam | thanks, submitted | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!