| mwhudson | so the fetch over sftp was much quicker, the autopack not so much | 00:03 |
|---|---|---|
| mwhudson | spiv: sftp push taking 8 minutes and bzr+ssh being killed after 45 minutes is pretty sad making :( | 00:04 |
| lifeless | mwhudson: in 1.12, if the branch was stacked, its the same code as 1.13 is doing | 00:14 |
| lifeless | mwhudson: _no_ change | 00:14 |
| lifeless | mwhudson: I realise its totally sad, but hey, thats why we added the streaming codepath | 00:15 |
| mwhudson | lifeless: no stacked branches here | 00:16 |
| * mwhudson resovles "less pointless grousing" | 00:16 | |
| jelmer | igc: hi | 00:19 |
| spiv | lifeless: it is a regression since InterOtherToRemote was removed; now InterPackRepo will never trigger if one end is bzr+ssh | 00:21 |
| spiv | lifeless: so even non-stacked pushes to packs suck if the server is 1.12 | 00:22 |
| spiv | lifeless: a "fix" would be to update my unmerged InterOtherToRemote hack that I did for John (that checks _is_remote_before((1,13))) to be in InterPackRepo | 00:23 |
| igc | hi jelmer | 00:23 |
| spiv | I'd be ok with merging that too, because that with the _ensure_real_inter mess gone that hack wouldn't have to cause get_parent_map RPCs to be skipped too. | 00:24 |
| spiv | (Which was my main objection to merging the hack for John) | 00:24 |
| jelmer | igc: So, I've been looking at implementing a svn-keywords filter | 00:29 |
| jelmer | igc: however, I'd ideally like its value to match the value of the svn:keywords property (to avoid the need to support two settings in the future) | 00:30 |
| igc | jelmer: ok | 00:31 |
| jelmer | igc: svn:keywords however contains a comma-separated list of keywords to expand | 00:31 |
| lifeless | spiv: alternatively we could add a cache when we're pushing, which we can detect | 00:32 |
| lifeless | spiv: or tell people to upgrade ;) | 00:32 |
| jelmer | igc: is there some way to support that atm? | 00:32 |
| jelmer | igc: It looks like the current filter registration function requires a dictionary with all possible settings | 00:33 |
| igc | jelmer: it does | 00:33 |
| igc | jelmer: maybe we want a 'catch-all' handler as well | 00:34 |
| igc | jelmer: basically, the current design makes it easy to ... | 00:34 |
| igc | have different filters for different values | 00:34 |
| igc | jelmer: but I think you want the *one* filter covering all values, don't you? | 00:35 |
| jelmer | igc: yeah, having separate filters, one per keyword, seems overkill | 00:36 |
| igc | jelmer: I don't feel it's overkill - it maps well to the eol case for example | 00:37 |
| igc | jelmer: but it's definitely not what you need I think | 00:37 |
| jelmer | igc: I don't think multiple *filters* is overkill | 00:37 |
| jelmer | igc: I think having one filter for $Id$, one for $Date$, one for $SVNHead$, etc is | 00:38 |
| igc | jelmer: right | 00:38 |
| igc | and the current keywords filter handle all keywords from memory | 00:39 |
| igc | it just doesn't a configurable list of which ones to expand | 00:39 |
| igc | s/doesn't/doesn't take/ | 00:39 |
| jelmer | igc: right, so a catch-all handler would basically mean registering a "fn(value) -> filterlist" callback rather than a dictionary ? | 00:44 |
| igc | jelmer: yes, something like that | 00:45 |
| jelmer | igc: ok, I'll look into that | 00:55 |
| jelmer | igc: did you see my patch for lazy registration? | 00:56 |
| jelmer | igc: Do you prefer an extra wrapper function or rather making the registry public? | 00:56 |
| igc | jelmer: just now - approved | 00:59 |
| igc | I prefer a wrapper fn (for now at least) | 00:59 |
| jelmer | igc: thanks | 01:02 |
| * igc starts reviewing jam's LRUCache patch | 01:09 | |
| trypticon | hey I gotta quick question about the FAQ page on http://bazaar-vcs.org/FAQ#head-e6448836a60a73c1954f287ef5e928b79e3ff005 . | 01:44 |
| trypticon | In section "4.1. Are binary files handled?" what are other tools that can be used to better handle binary files and or media files? | 01:45 |
| lifeless | trypticon: in what way | 01:47 |
| trypticon | I just wanted to know if there are better tools than bzr for handling binary files. | 01:47 |
| lifeless | I'm not aware of anyone with better answers in the open source version control space today | 01:48 |
| lifeless | ^distributed | 01:49 |
| trypticon | humm.... So would it be a good idea to use an app like bzr for handling Binary-only files for version control? | 01:49 |
| lifeless | well, plenty of folk do; it really depends on your requirements and what you mean by handling, and if your machine has the resources | 01:49 |
| lifeless | like, if you are versioning 10GB database, files, you'll need 35GB of main memory, or so, to do a commit | 01:50 |
| lifeless | but if you just want archiving, then maybe rsync is better and don't use version control at all | 01:50 |
| trypticon | I'm trying to set up an archive of binary files (iso's. executables, etc) that I would like to be able to quickly checkout and manage. I was wondering if bzr would work for this task? | 01:50 |
| lifeless | iso's may be noticably slow, (700MB is a lot to shuffle round), executables shouldn't be an issue | 01:51 |
| trypticon | why would you need 35G to handle a 10GB file? | 01:51 |
| lifeless | 10GB for the copy you are recording, 10GB for the basis copy to generate a diff, and python has some overhead for objet handling; doing a merge requires 3 copies, and some commits need to do a merge to generate annotations | 01:52 |
| lifeless | thats assuming we manage to perfectly avoid unnecessary copies in memory | 01:52 |
| trypticon | sounds to me like bzr probably isn't the tool I should be using. Humm..... | 01:54 |
| lifeless | I suggest giving it a spin and seeing if it does what you need | 01:55 |
| lifeless | we are improving things continually, and at some point will create drastically better handling for large files | 01:55 |
| SamB | jelmer: pong | 02:00 |
| trypticon | the thing is that I need something strictly for handling binaries though. Binaries as large as 4.5gigs. I don't have any more than 3gigs on my system so I'm not sure bzr will be able to do what I want it to. Either way I will take some time and look through the site because it sounds like a great system. | 02:00 |
| lifeless | trypticon: yes, I suspect you'd have some trouble using bzr for 4.5GB binaries on a 3GB memory system :) | 02:02 |
| trypticon | I'll continue to research | 02:06 |
| trypticon | thanks so much for your help | 02:07 |
| lifeless | my pleasure, good luck | 02:07 |
| spiv | mwhudson: lp:~spiv/bzr/remote-pack-hack probably fixes your performance issue | 02:17 |
| spiv | mwhudson: as a bonus, I think it improves pushing to stacked packs on old servers too | 02:17 |
| mwhudson | spiv: cool | 02:17 |
| spiv | mwhudson: e.g. pushing up that branch only took 175 RPCs (1m 27s) | 02:18 |
| spiv | mwhudson: which is still much worse than a 1.13 server :) | 02:18 |
| * spiv tries with bzr.dev to compare | 02:18 | |
| spiv | Oh, hmm, a test failure. | 02:19 |
| BasicOSX | I must have not been paying attention, 1.14dev NEWS file is totally different then 1.13 | 02:24 |
| * SamB wonders if he should bother to report that bzr repo-push doesn't work on launchpad urls ... | 02:32 | |
| thumper | SamB: what should repo-push do? | 02:35 |
| spiv | mwhudson: yeah, it's a bit better than bzr.dev even on this trivial branch | 02:36 |
| spiv | mwhudson: it should make a world of difference to pushing up a stacked branch with a large delta (ObNag: although still not as awesome as 1.13 on the server :) | 02:36 |
| mwhudson | spiv: that's coming | 02:37 |
| spiv | mwhudson: I know :) | 02:37 |
| spiv | mwhudson: just think of me as the kid in the car repeating "are we there yet?" | 02:37 |
| mwhudson | spiv: two can play that game | 02:37 |
| * mwhudson mumbles something about lazy inventories | 02:38 | |
| lifeless | mwhudson: heres one we prepared earlier | 02:43 |
| lifeless | BasicOSX: yes | 02:46 |
| lifeless | BasicOSX: its restier | 02:46 |
| BasicOSX | heh, isn't that more RESTful? Anyway, how can I do a local convert of the docts into html? I got some un-restier markup and PQM hates me | 02:47 |
| BasicOSX | make rst2html? | 02:48 |
| lifeless | make docs | 02:49 |
| spiv | Or to just do the NEWS file, "make doc/en/release-notes/NEWS.html" | 02:51 |
| lifeless | igc: ping | 02:52 |
| emmajane | w00t! /me continues to be a bad influence: * esmerel makes a brief mention of source control in one of the book chapters, and includes bzr cuz of you | 03:01 |
| * emmajane bets that didn't make sense to anyone else. | 03:02 | |
| poolie | can some people help with a quick test: go to bazaar-vcs.org and tell me if you see a search box in the top right | 03:03 |
| spiv | poolie: I do | 03:03 |
| emmajane | poolie, are you fixing templates again? | 03:03 |
| emmajane | I cleared cache and am still seeing a search box top right (under community and plugins) | 03:04 |
| poolie | i'm trying to help newz fix them | 03:05 |
| poolie | there's meant to be one | 03:05 |
| poolie | i don't see it, and i don't know why | 03:05 |
| emmajane | poolie, which browser? | 03:06 |
| BasicOSX | poolie: the merge of NEWS from 1.13.1 into bzr.dev with the format change was messy, think I got it, PQM is happy, but need another set of eyes looking at it | 03:06 |
| poolie | jaunty's firefox | 03:07 |
| emmajane | poolie, firebug is having a hard time finding the actual markup for the search box. | 03:07 |
| poolie | ah i see | 03:07 |
| poolie | i had my account set to use his preview stylesheet, not the default | 03:08 |
| emmajane | ah | 03:08 |
| emmajane | the tab index is screwy because of the edit stuff being at the bottom. not that it really matters, just "point of interest" | 03:09 |
| SamB | there is an attribute for tab indexes ... or is that how the problem arises? | 03:18 |
| Stanlin | hello | 03:29 |
| Stanlin | is there any how to start with bazaar ? | 03:30 |
| SamB | tried the manual ? the wiki ? | 03:30 |
| SamB | http://bazaar-vcs.org being the latter | 03:31 |
| lifeless | jelmer: I'm hearing scary rumours | 03:32 |
| lifeless | jelmer: about dulwich & history | 03:32 |
| SamB | what's dulwich? | 03:33 |
| lifeless | the bzr-git git implementation | 03:33 |
| SamB | and what are the scary things you've been hearing about it & history? | 03:35 |
| Stanlin | SamB thank you, first opensource project with documents | 03:36 |
| SamB | Stanlin: what? you've never seen documentation for an open source project before? | 03:36 |
| spiv | poolie: have you seen the Branch.open jail / ignore_fallbacks thread on the list? | 03:40 |
| spiv | poolie: a third opinion on that thread would be welcome | 03:40 |
| poolie | a bit; i'll look | 03:40 |
| lifeless | poolie: we need a tie break on 'boolean flag used explicitly in the server' and 'trinary flag with 'auto' as the default' | 03:41 |
| lifeless | poolie: you can nearly entirely ignore the rest of it - we're both happy with the code and its been reviewed etc | 03:41 |
| poolie | so if it was not "automatic in the server" then if some code in the server called it with "yes, open" it would run into the jail wall and fail? | 03:43 |
| lifeless | poolie: unless it had explicitly opened the jail first | 03:44 |
| poolie | interesting thread... | 03:44 |
| poolie | you know it's spiv when there's a correct unicode diaresis on "naïve" | 03:45 |
| poolie | diaeresis* | 03:46 |
| * igc lunch | 03:46 | |
| spiv | :) | 03:46 |
| lifeless | æ surel | 03:46 |
| lifeless | y | 03:46 |
| poolie | "næve"?? | 03:47 |
| lifeless | diæresis | 03:48 |
| poolie | oic; maybe | 03:50 |
| poolie | i tend to only use unicode when needed | 03:51 |
| lifeless | me too | 03:51 |
| lifeless | I can't see any of the unicode glyphs I just typed | 03:51 |
| poolie | lol | 03:51 |
| lifeless | ä | 03:52 |
| lifeless | î | 03:52 |
| poolie | *anyhow* | 03:52 |
| lifeless | ï | 03:52 |
| lifeless | ah yes | 03:52 |
| spiv | lifeless: stop flushing your vowels in public :P | 03:52 |
| lifeless | I'm in my own living room thank you very much :) | 03:53 |
| poolie | lifeless: i think you marked bug 181367 invalid | 03:54 |
| ubottu | Launchpad bug 181367 in bzr "bzr update should work in a treeless bound branch" [Low,Invalid] https://launchpad.net/bugs/181367 | 03:54 |
| poolie | despite filing it yourself :) | 03:54 |
| poolie | i have an old tree that starts to fix it | 03:54 |
| poolie | should i discard it? | 03:54 |
| lifeless | uhm | 03:54 |
| lifeless | I'll tell you once you tie break | 03:54 |
| poolie | sent | 04:03 |
| poolie | don't mix gaol and jail :) | 04:04 |
| lifeless | poolie: so, I don't think update() on a treeless bound branch is safe or sensible, you need a tree, as my last comment describes why | 04:04 |
| poolie | i agree with your reasoning | 04:05 |
| poolie | i just wasn't sure if you'd had educated second thoughts or what | 04:05 |
| lifeless | if you have a branch that makes update cleaner and safer, that is good; if your goal was just to fix that specific bug - delete it | 04:05 |
| spiv | poolie: I only use gaol in the branch nick :) | 04:06 |
| poolie | spiv: still. | 04:06 |
| poolie | people may search for it | 04:06 |
| lifeless | we need some fun! | 04:06 |
| spiv | This is a good moment for lifeless to say "they should use bzr search" ;) | 04:06 |
| lifeless | they should use bzr search | 04:06 |
| lifeless | and it should know | 04:06 |
| poolie | hee hee | 04:06 |
| lifeless | anyhow, we restrained from creating commonwealth gaol in the api | 04:07 |
| poolie | that was good | 04:07 |
| poolie | so the blackbox test fell to 23 calls because it was previously opening the fallback across the wire? | 04:07 |
| poolie | it would be nicer if this was not done in per-thread state but i suppose that's the only practical way for testing | 04:09 |
| lifeless | poolie: no | 04:09 |
| lifeless | poolie: it was because the server was opening the fallback | 04:10 |
| lifeless | poolie: and the hook to record events was getting the events generated by the server during its opening of the fallback; each of the 23 commandline client generated hpss calls that was on a branch was triggering many hpss operations in the server (to the server itself) | 04:11 |
| * ToyKeeper misses feature branches and bzr's merge-aware bisect tool | 04:14 | |
| * ToyKeeper is isolating a bug with hg :( | 04:14 | |
| poolie | lifeless: oh huh | 04:17 |
| lifeless | poolie: so fixing third-party access requests fixes the apparent request count :) | 04:26 |
| lifeless | poolie: btw, did you see jam's 'dont use =======' in news? | 04:26 |
| poolie | lifeless: yes i thought i fixed it | 04:26 |
| spiv | Hmm, not according to my copy of bzr.dev. | 04:27 |
| lifeless | not in .dev, it starts with ============= Bazaar Release Notes ... | 04:27 |
| ToyKeeper | ow... my head hurts. In this hg tree, revision 1 is between r783 and r784. | 04:29 |
| lifeless | fun | 04:29 |
| ToyKeeper | A bisect narrowed it down to r771 to r773, then jumped back to r491 (which apparently actually happened in-between). | 04:30 |
| ToyKeeper | I guess all I'm saying is... I love you guys. :) | 04:31 |
| lifeless | cool :) | 04:31 |
| poolie | lifeless: oh ok, i changed the others but not the toplevel one | 04:35 |
| poolie | i'll change that too | 04:35 |
| poolie | though, it's odd to me that resolve thinks they're conflict markers | 04:35 |
| poolie | which should be just '======= ' | 04:35 |
| poolie | i mean it should require 7 followed by a space | 04:35 |
| lifeless | I'm happy however you want to fix it :) | 04:35 |
| lifeless | though requiring whitespace to be significant is a little ugly too | 04:35 |
| lifeless | I mean, why not '=======\n' | 04:36 |
| * lifeless shrugs | 04:36 | |
| poolie | spiv, jml, i just got | 05:23 |
| poolie | LockFailed: Cannot lock LockDir(lp-46121936:///~mbp/bzr/controlfiles/.bzr/branchlock): Transport operation not possible: readonly transport in _remote_lock_write | 05:23 |
| poolie | trying to push to https://code.edge.launchpad.net/~mbp/bzr/controlfiles using bzr.dev | 05:23 |
| poolie | i thought this was strange | 05:23 |
| poolie | lifeless: apparently cvs established the convention that there must be a space there | 05:24 |
| poolie | and some tools expect it so we had to do it too | 05:24 |
| mwhudson | poolie: it's a mirrored branch | 05:24 |
| poolie | ah ok | 05:24 |
| mwhudson | there has to be read only access to it for stacking | 05:24 |
| poolie | that's a bit unobvious but of course you're right | 05:24 |
| mwhudson | and um well | 05:25 |
| mwhudson | accessing it :) | 05:25 |
| poolie | wbn if it said "mirrored branch is readonly" but i understand | 05:25 |
| jml | poolie: it'd still say "Cannot lock ...: Transport operation not possible: mirrored branch is read only" | 05:26 |
| mwhudson | can a readonly decorator be customized to complain in a specific way? | 05:26 |
| poolie | it would have given me a clue | 05:26 |
| poolie | mwhudson: sure just raise whatever you want | 05:27 |
| poolie | um and maybe refactor ReadonlyTransportDecorator to remove the duplications of that string | 05:27 |
| mwhudson | right, i meant the one in bzr | 05:28 |
| poolie | it would need either changing the one in bzr to allow passing in a string when it's constructed | 05:29 |
| poolie | or subclassing it | 05:29 |
| poolie | it's probably easy | 05:29 |
| poolie | i'll do the bzr bit if you're keen to do the lp bit | 05:29 |
| james_w | would it also be possible to improve the situation with lp: and no launchpad-login? | 05:31 |
| poolie | which particular situation? | 05:32 |
| james_w | so that we can get rid of the unpleasant warning in that situation | 05:32 |
| james_w | "bzr push lp:foo" without a launchpad login gives you "cannot lock ...: Transport operation not possible: http does not support mkdir()" | 05:32 |
| james_w | or similar | 05:32 |
| mwhudson | poolie: sure, the lp bit should be easy | 05:32 |
| james_w | I added a warning whenever lp: resolves to http to say "you haven't run launchpad-login, if you are doing a write operation it will fail" | 05:33 |
| poolie | spiv i'm just trying your stacking hack branch against lp | 05:33 |
| james_w | which is obviously not great | 05:33 |
| spiv | poolie: cool | 05:33 |
| poolie | and it's not drastically better :( | 05:33 |
| poolie | it might be a bit better? | 05:33 |
| lifeless | poolie: also, you're pushing to https ? | 05:34 |
| poolie | lifeless: no, of course i'm pushing to the ssh branch described on that page | 05:35 |
| poolie | so that was, to create a new stacked branch, 404 round trips in 5m16s | 05:35 |
| poolie | a new stacked branch with a few new revisions mind you | 05:35 |
| lifeless | poolie: there is no of course :) | 05:35 |
| spiv | poolie: on a small branch from bzr.dev it saved me ~10 round trips when pushing to launchpad | 05:35 |
| spiv | Which seemed about right given the small number of modified texts and new revisions in that file, and the savings were in append calls. | 05:36 |
| poolie | ok so fwiw i had 49 append calls using your branch | 05:39 |
| poolie | i'm just rerunning it with trunk | 05:40 |
| poolie | i realize even smalls improvements are worthwhile | 05:40 |
| igc | poolie: trying to review your doc patch ....http://rafb.net/p/ML5S7O90.html | 05:41 |
| spiv | I was expecting it to be more than a small improvement. Certainly if it does fix the regression vs. 1.13 that part is a big improvement... pushing a full history with that bug would hurt! | 05:41 |
| poolie | hm that's not so good | 05:41 |
| poolie | spiv, ok for trunk it was 489 rpcs in 5m30s | 05:42 |
| poolie | igc, ok, that seems to be a bug | 05:42 |
| poolie | probably easily addressed in the makefile by setting the path | 05:42 |
| igc | 'make docs' is fine in bzr.dev so I'm pretty sure your patch is causing that | 05:42 |
| spiv | That's a pretty substantial saving in rpcs. | 05:42 |
| poolie | yes, it probably is | 05:42 |
| poolie | because i moved the script | 05:42 |
| igc | poolie: the rest looks fine so I'll vote tweak | 05:45 |
| poolie | spiv, it is | 05:45 |
| Stanlin | is there any quickguide, without launchpad marketing?? | 05:51 |
| jml | james_w: we aren't running anything for http that's smarter than apache | 05:53 |
| james_w | ah, it has to come from the server side? | 05:53 |
| jml | james_w: well, it might not *have* to | 05:53 |
| jml | bzr asks launchpad to resolve lp:foo | 05:54 |
| jml | launchpad gives it a bunch of URLs | 05:54 |
| jml | bzr decides to use the http one since there's no launchpad-login | 05:54 |
| jml | bzr raises confusing error | 05:54 |
| jml | that's the rough flow. | 05:54 |
| Stanlin | why i need to sign up in launchpad to use bzr?? | 06:04 |
| jml | Stanlin: you don't | 06:04 |
| Stanlin | well all the docs points to launchpad | 06:05 |
| spiv | Stanlin: I don't see much reference to launchpad on http://bazaar-vcs.org/ http://doc.bazaar-vcs.org/latest/ | 06:07 |
| Stanlin | im trying to configure a server, and give full permission to all users to do what they want... what is the best scenario in this document?? http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#personal-version-control | 06:09 |
| spiv | Stanlin: simplest is to give each user a normal system account and get the users to put their branches in world-readable directories inside their home directories. | 06:10 |
| Stanlin | but they want to share the same files | 06:11 |
| spiv | And have bzr and ssh installed on the server so they can use bzr+ssh:// URLs to access those branches. | 06:11 |
| Stanlin | should they share the same branch? | 06:11 |
| spiv | Sure, if they want to write to the same branch. | 06:11 |
| Stanlin | oh its simple as that? | 06:11 |
| spiv | Right. Normal filesystem permissions with users and groups basically :) | 06:12 |
| Stanlin | they just point to that directory ... commit and voila? | 06:12 |
| spiv | Yep. | 06:12 |
| Stanlin | oh nice | 06:12 |
| Stanlin | well ill be annoying here for a while im new in bzr thanks for the cooperation | 06:13 |
| Stanlin | thanks a lot | 06:13 |
| Stanlin | time to sleep | 06:13 |
| spiv | G'night. | 06:13 |
| === Mez_ is now known as Mez | ||
| bignose | if branch ‘foo/’ has a loom, and I ‘bzr branch foo/ bar/’, should I expect ‘bar/’ to have the same loom? | 06:46 |
| bignose | 'cause it doesn't :-( | 06:46 |
| bignose | Bazaar (bzr) 1.13rc1, bzr-loom 1.4.0~bzr93-2 | 06:46 |
| lifeless | bignose: if 'a' and 'a' are the same branch, clearly they will, otherwise not unless you have run 'bzr record' | 06:46 |
| lifeless | bzr help loom may be useful for you | 06:46 |
| bignose | lifeless: ah. you don't yet have UTF-8 working properly? | 06:46 |
| lifeless | no, it will be months | 06:46 |
| bignose | if branch 'foo/' has a loom, and I 'bzr branch foo/ bar/', should I expect 'bar/' to have the same loom? | 06:46 |
| lifeless | there is something fucked deep in libx | 06:46 |
| lifeless | bignose: right, you need to run 'bzr record' to record the loom, it is for the loom as a whole what commit is for a tree | 06:46 |
| bignose | okay, I have *no clue* what that command does, and the help is no help. | 06:47 |
| lifeless | the loom is a stack of branches | 06:47 |
| lifeless | this is versioned | 06:47 |
| bignose | when am I supposed to run it? what does it do, that I might *not* want to run it? | 06:47 |
| lifeless | record records a version | 06:47 |
| lifeless | generally you should run it before you branch/push to a loom | 06:47 |
| bignose | so why would I not want it run, say, every time I commit? | 06:50 |
| bignose | okay, it requires a message argument. I don't know anything useful to say in the message. | 06:50 |
| bignose | all the useful stuff goes in a commit message, but apparently this is not a commit. | 06:50 |
| lifeless | an analogy may help | 06:50 |
| lifeless | imagine you are using a loom for a debian package | 06:50 |
| lifeless | where the bottom thread is upstream | 06:50 |
| lifeless | and the top thread is 'debian' | 06:50 |
| bignose | okay | 06:51 |
| lifeless | and the threads in between patch the upstream code | 06:51 |
| lifeless | such that you can patch bomb what other packages might have in debian/patches straight out of the loom | 06:51 |
| lifeless | the list of threads is something that we need to merge - if I merge my loom from you patches[threads] you have deleted need to be deleted in mine | 06:52 |
| lifeless | so record records the list of threads - the (name, revid) for each thread | 06:52 |
| lifeless | np | 06:59 |
| vila | hi all | 07:00 |
| igc | hi vila | 07:02 |
| === abentley1 is now known as abentley | ||
| * igc dinner | 07:45 | |
| === stianse_ is now known as stianse | ||
| CBro2007 | hey guys... if developers wanted to UPDATE their branches with what is in the MAIN branch or TRUNK ... do I get them to do a bzr merge or bzr pull? | 08:34 |
| CBro2007 | Just trying to understand the difference | 08:34 |
| bob2 | pull | 08:36 |
| Peng_ | CBro2007: If they're maintaining a mirror of the main branch, "pull". If they're developing independent branches that'll be merged into the main branch, "merge". | 08:42 |
| Peng_ | CBro2007: In the latter case, once they have been merged, they can use "pull", but it'll change how "bzr log" is organized. | 08:42 |
| CBro2007 | Peng_: I created a trunk copy first and then created their branches from it... so that should be a mirror yeah? | 08:43 |
| CBro2007 | I mean its got the exact same dir structures etc of the project | 08:43 |
| Peng_ | Ehhhh. | 08:44 |
| Peng_ | CBro2007: What's the workflow? Do you use "bzr branch trunk feature_branch", hack on feature_branch, and merge it back into trunk; or do you do stuff directly in trunk? | 08:45 |
| CBro2007 | Yeah the branches are each developer's own branch... where they work on different features ... run it past me for a code review and I merge their changes to TRUNK | 08:45 |
| CBro2007 | I got that part working... now I want to do the reverse.. where they synch their own branches with LATEST changes that I merged into the MAIN branch | 08:46 |
| CBro2007 | so I think a PULL would be the best way to go eh? | 08:46 |
| CBro2007 | Maybe for smaller changes I will put the change DIRECTLY into Trunk | 08:46 |
| CBro2007 | and then developers can update their branches accordingly... very much like the CVS update command that developers run every day before they start work | 08:47 |
| CBro2007 | [dchoon@onyaaltd02 dcrepo]$ bzr pull /goldRepo/ | 08:49 |
| CBro2007 | bzr: ERROR: Permission denied: "/goldRepo/.bzr/branch-format": [Errno 13] Permission denied: u'/goldRepo/.bzr/branch-format' | 08:49 |
| CBro2007 | Got this error when I was trying to PULL from the MAIN branch. | 08:49 |
| CBro2007 | have to check the permissions.... | 08:49 |
| CBro2007 | its hard to get the permissions correct | 08:51 |
| pygi | poolie, poke? | 10:18 |
| poolie | hi pygi | 10:18 |
| pygi | poolie, can I pm you? :) | 10:19 |
| pygi | or are you busy? | 10:19 |
| poolie | i am but you can | 10:19 |
| jelmer | lifeless: hi | 11:32 |
| jelmer | lifeless: yes, I dpushed dulwich | 11:32 |
| lifeless | jelmer: why? | 11:38 |
| lifeless | or are you developing it in git or something? | 11:39 |
| lifeless | [it broke mirrors and people tracking it] | 11:39 |
| jelmer | lifeless: yes, pushed into git so that others can contribute to it in git | 11:43 |
| lifeless | jelmer: I'm not clear do you commit to it in git, or bzr? | 11:57 |
| jelmer | lifeless: I personally commit to bzr then dpush | 12:01 |
| lifeless | jelmer: whew :P had me worried. | 12:05 |
| lifeless | jelmer: but why was a rewrite of the bzr history needed? | 12:05 |
| lifeless | surely just dpushing to a git branch would make it accessible to git users? | 12:06 |
| lifeless | *yawn* 11pm | 12:06 |
| * lifeless sleeps | 12:06 | |
| jelmer | lifeless: well, we don't have roundtripping yet in bzr-git | 12:13 |
| jelmer | lifeless: dpush changes the local history | 12:14 |
| jelmer | lifeless: so that it is in common with the history in the foreign vcs | 12:14 |
| jelmer | lifeless: I can now pull from people who contribute to dulwich in git without problems | 12:14 |
| MvG | Hi! I'm using bzr-svn from time to time, and have a local branch for this. After the latest bzr update to 1.13, I had to update bzr-svn as well in order to support that version of the API. While pulling, bzr died with a backtrace and a "KnitCorrupt" error message. That was while operating on a shared repo for all my bzr-svn branches. Initializing a new repo and creating a fresh checkout succeeded. In the original setup, the issue can be reproduced. Do | 12:30 |
| MvG | Hint: above problem is NOT about bzr-svn per se, so don't stop reading after hitting that keyword... :-) | 12:31 |
| jelmer | MvG: what bzr-svn were you running prior to that? | 12:40 |
| MvG | jelmer: jelmer@samba.org-20090202154824-ks8tepmvoam9dmpz if I'm not mistaken. | 12:41 |
| MvG | In case you want to have a look at the error message: http://rafb.net/p/kfbdrg91.html | 12:44 |
| jelmer | MvG: ah, it's the bzr-svn repository itself that you can't fetch? | 12:53 |
| jelmer | MvG: I doubt I can help there | 12:53 |
| igc | night all | 13:09 |
| abentley | jam: when you're punched in, can we do a skype call? | 13:13 |
| MvG | jelmer: Sorry, missed your reply. Fetching from scratch works, only updating fails. I guess I'll file a bug report, as I haven't found a related one, and as I don't think I've done anything evil on that repo to warrant this kind of error. | 13:25 |
| yogsototh | Hi, | 13:31 |
| yogsototh | I tried to understand what the plugin loom is about | 13:31 |
| yogsototh | and I didn't find any resources. | 13:31 |
| yogsototh | Can someone tell me what this plugin do | 13:31 |
| yogsototh | please ? | 13:32 |
| === nevans1 is now known as nevans | ||
| jam | abentley: sorry about the delay. I've been on for a bit. Sure we can do skype | 14:28 |
| abentley | jam: np | 14:29 |
| NEBAP | hi | 14:31 |
| NEBAP | is it correct that "bzr push .." is the only way to upload changes from a branch into the "trunk"? | 14:32 |
| yogsototh | I would say "bzr merge" could do the trick also | 15:07 |
| NEBAP | but, how I understand, merge can only be used to "download" the changes, but in my case the editor wants to upload his changes.. | 15:08 |
| NEBAP | like you would do in svn .. | 15:08 |
| LeoNerd | merge just pulls changes into the working tree, similar to a local edit | 15:09 |
| LeoNerd | Yuo still have to commit those changes with bzr ci | 15:10 |
| NEBAP | so what is the correct way? Bind my local branch to the "server-branch" and then commit? Or maybe, merge the "server-branch" into my local branch, then bind the local branch to the server branch, and then commit? | 15:11 |
| LeoNerd | Either works. | 15:13 |
| LeoNerd | They're basically the same. | 15:13 |
| LeoNerd | Depends if you want to leave it bound, or do a separate push operation | 15:13 |
| NEBAP | ok, I try to describe my workflow | 15:14 |
| NEBAP | there is a "server-repository" where the mainline of the code is stored. Know I want to add a new feature (or bugfix or whatever). For that I want to create a local branch (copy) of the mainline on the server. In this local copy I want to create a new branch with the name of the feature. Then I work on the feature branch and do local commits there. After I finished all, I want to merge thoses changes back into the server mainline... | 15:17 |
| jam | morning vila, how goes the battle on the starward front? | 15:17 |
| vila | jam: it's bloody and uncommitable so far, but I have good hope :) | 15:19 |
| vila | jam: I'll get back to you once I get at least failing tests instead or erroring out ones | 15:30 |
| jam | :) | 15:30 |
| jam | I'm happy to chat if you want | 15:30 |
| vila | jam: Thanks. I know that, but I need more meat first :) | 15:31 |
| SamB | hmm, how can I do a bzr push over SSH to a system where bzr is only installed in my home directory? | 16:08 |
| SamB | oh, sftp:// | 16:09 |
| jelmer | MvG: have you tried running "bzr reconcile" in the repository before pulling? | 16:11 |
| MvG | jelmer: not yet, trying... | 16:11 |
| MvG | BTW: filed as https://bugs.launchpad.net/bugs/347979 | 16:12 |
| ubottu | Ubuntu bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] | 16:12 |
| MvG | jelmer: No luck with reconcile. | 16:17 |
| MvG | Ran it in the repo dir, not in a branch. Is that correct? | 16:18 |
| abentley | SamB: You can also configure the location of the remote bzr using the BZR_REMOTE_PATH environment variable or the bzr_remote_path config variable. | 16:18 |
| SamB | the config variables sounds more promising | 16:19 |
| SamB | hmm, I'd want it as a per-host option though ... | 16:19 |
| SamB | how come the usual SSH paths aren't supported? | 16:21 |
| SamB | er, I mean, how come you can't say, e.g., sftp://cs.widener.edu:devel/dosemu/ to mean ~/devel/dosemu on cs.widener.edu? | 16:22 |
| Kinnison | sftp://cs.widener.edu/~/devel/dosemu/ | 16:24 |
| Kinnison | because the colon is the port separator? | 16:24 |
| SamB | oh. there *is* an ietf draft about this, and what you say is consistant with that. | 16:26 |
| SamB | where is it documented in bzr's help/docs? | 16:26 |
| Kinnison | dunno, it's always how I've used sftp URLs in gnome etc. | 16:28 |
| SamB | oh, hmm, I guess that's normal | 16:28 |
| SamB | I just hardly ever create that form myself ... | 16:29 |
| SamB | still, I think it should be documented ... | 16:29 |
| Kinnison | Is it truly up to bzr to document how URLs are formed? | 16:30 |
| SamB | well, the draft doesn't even have an RFC number | 16:30 |
| Kinnison | Should it explain about http[s]://[user[:password]@]hostname[:port]/... | 16:30 |
| Kinnison | most URLs are scheme://[auth info@]hostname[:port]/path | 16:31 |
| SamB | true | 16:31 |
| Kinnison | it's not a stretch to assume that for sftp | 16:31 |
| SamB | but most VCSes document the path formats they accept ... | 16:31 |
| SamB | e.g. see git-clone(1) | 16:32 |
| fR33b1Rd | hi. i've problem with .bzignore! Patterns only work for the topmost directory. Any patterns für subdirs don't work. any idea what could be wrong? | 16:32 |
| Kinnison | True | 16:32 |
| Kinnison | fR33b1Rd: Odd, I find plain patterns work anywhere. Did you put a slash in your pattern? | 16:33 |
| fR33b1Rd | i tried many different patterns. "*.tmp" etc. just doesn't work | 16:34 |
| Kinnison | Are you editing .bzrignore directly, or typing "bzr ignore *.tmp" ? | 16:37 |
| fR33b1Rd | I tried both. There's no difference | 16:37 |
| fR33b1Rd | is searched the whole docs, different forums, buglist etc. seems like nobody had such a problem before. | 16:37 |
| Kinnison | Well it works for me | 16:38 |
| Kinnison | I just did "bzr ignore '*.tmp'" | 16:38 |
| Kinnison | and then it ignored .tmp files in the top level and in subdirs | 16:39 |
| fR33b1Rd | okay, I just found the problem. "bzr ignored" doesn't show ignored files if the specific subdir is unknown, which is absolut plausible behavior. | 16:48 |
| fR33b1Rd | I thought it would be better to setup the ignore rules first and then add the dirs and files to version control. obviously not the best idea. | 16:50 |
| jam | vila: how's it going? | 16:51 |
| vila | jam: it's going :-) I get a bit distracted by unrelated failures since... bbc has a couple now :-) Last trip ended up in one more failing test for loom :-/ I thought I excluded them with -x '(?i)loom' but it came back by the window :0) | 16:54 |
| jam | vila: I was grabbing some food, and realized that it is ~ time for you to be done with work, right? | 16:56 |
| jam | Did you want to skip the call today? | 16:56 |
| vila | jam: yup, gf just came in anyway | 16:56 |
| jam | vila: k, have a good evening | 16:56 |
| OllieR | Hey, run into a problem on mac osx. I have done a complete restore from a backup and the system is running as it should but bzr has gone a little wrong, bzr: ERROR: Couldn't import bzrlib and dependencies. Please check bzrlib is on your PYTHONPATH. ImportError: No module named bzrlib. So from googling I have found out that i need to add bzrlib as a pythonpath but i can't figure out how to do this | 16:59 |
| Kinnison | How did you have bzr installed before? | 17:02 |
| OllieR | its looks like it was a macport | 17:02 |
| Kinnison | I'd suggest just reinstalling it then | 17:02 |
| Kinnison | it possibly didn't get backed up properly | 17:03 |
| OllieR | ok i am going to try the dmg | 17:03 |
| OllieR | not sure how this is going to react to the old macport version | 17:03 |
| OllieR | yes a simple reinstall solved things :) | 17:11 |
| fbond | Hi, is there any way to get bzr diff to put revision numbers instead of dates? | 17:15 |
| abentley | SamB: If you specify it in locations.conf, it's a per-host or even per-path option. | 17:22 |
| fbond | Oh, I found bzr-diff-revid. Will core diff integrate this change? | 17:30 |
| james_w | what does it do? | 17:31 |
| james_w | ah | 17:32 |
| james_w | it has been suggested that an extra comment line be added with the revision ids | 17:32 |
| james_w | it could certianly be an option IMO | 17:33 |
| abentley | jam: I'm looking at these iter_reference callsites. The two approaches I can think of so far are: 1. Implement a reference cache on RevisionTree when read_locked. 2. Pass iter_entries_by_dir output into WorkingTree.initialize, build_tree and _build_tree. Thoughts? | 18:07 |
| rocky | jelmer: hey i just instlaled bzr-gtk manually using the sdist ... how do i get nautilus to "pick up" the integration features? | 18:10 |
| rocky | nvm, found readme | 18:11 |
| exarkun | Is there something like "bzr missing <repo url>" which doesn't involve typing <repo url> where <repo url> is the remembered push location for the working copy? | 18:11 |
| jelmer | rocky: hi | 18:12 |
| jelmer | rocky: did you see my review of your trac-bzr patch? | 18:12 |
| === bac is now known as bac_afk | ||
| abentley | exarkun: "bzr missing :push". And of course, you can alias that to anything you like. | 18:14 |
| rocky | jelmer: sorry got dc'ed earlier, didn't catch what you were saying ... | 18:26 |
| rocky | jelmer: how would i go about troubleshooting the bzr-nautilus integration? is there a nautilus log i can view someplace? | 18:26 |
| rocky | don't suppose anyone knows if there is a $HOME dir script that gets run before nauitlus launches in ubuntu such that it can setup some env vars that will be available to nautilus ? | 18:39 |
| fbond | rocky: ~/.gnomerc | 18:41 |
| fbond | Gets run when your Gnome session starts. | 18:41 |
| rocky | ohh | 18:41 |
| jelmer | rocky: you can restart nautilus, and it will write to stdout | 18:43 |
| rocky | jelmer: what i'm trying to accomplish here is to use the nautilus integration of bzr-gtk where bzr (and bzr-gtk) are installed in a virtualenv ;) | 18:43 |
| rocky | and i just got it to work, woot | 18:44 |
| rocky | thanks fbond ;) | 18:44 |
| fbond | rocky: No problem. | 18:44 |
| rocky | jelmer: bzr-gtk doesn't display any sort of emblems on files in nautilus to show they're versioned? | 18:45 |
| rocky | scratch that | 18:49 |
| === bac_afk is now known as bac | ||
| jelmer | re | 18:57 |
| jelmer | beuno: ping | 18:57 |
| jam | abentley: back to iter_references call sites... | 19:13 |
| jam | A cache while read locked seems fine | 19:13 |
| jam | though I'm not 100% sure what paths are benefiting | 19:13 |
| jam | branch/sprout/whatever is an obvious case that needs to know about references, which is the 'fetch' fix we were talking about | 19:14 |
| jam | we don't really have a RevisionTree at that time | 19:14 |
| jam | for building the tree | 19:14 |
| jam | (checkout) | 19:14 |
| jam | it seems that build_tree could cache references it finds on the WT object | 19:14 |
| * adrianrf newb q: want good repo setup strategy for managing multiple Drupal client projects. want all to share core Drupal distro code, and also per site have some shared contrib modules, some unique. can I nest repos? or should I treat each client site as a branch of the main distro? | 19:16 | |
| jam | adrianrf: I'm not really sure how drupal projects are laid out. In general, if you want to version a group of files independently from others, then they should be in their own branch | 19:20 |
| jam | so that would hint that the various contrib modules would be independent branches | 19:20 |
| jam | you may want to look at the 'scmproj' plugin, as a way to aggregate multiple branches into a meta-project | 19:20 |
| jam | (we have some nested trees work, but that isn't fully baked yet) | 19:20 |
| jam | you *can* nest repos | 19:22 |
| jam | though you may be thinking of what we call "branches" and calling them a "repo" | 19:22 |
| abentley | jam: in principle, BzrDir.sprout can use the same RevisionTree for create_workingtree and iter_references. Though at present, it can't even accept a RevisionTree. | 19:29 |
| abentley | (create_workingtree can't accept a RevisionTree) | 19:29 |
| jam | abentley: so your idea is that if it created a working tree, it has already found the references, and it can just return those in the 'iter_references' call, right? | 19:30 |
| abentley | jam: Right. | 19:30 |
| jam | One can also contend that during the *fetch* portion of sprout, we would know the references | 19:30 |
| jam | (I think) | 19:30 |
| abentley | jam: For the purpose of fetching, yes. Not for the purpose of creating branches or trees. | 19:31 |
| abentley | because we wouldn't have encountered the references if fetch didn't do anything. | 19:31 |
| jam | abentley: so is this so that sprout recurses to create child working trees? | 19:32 |
| abentley | jam: right. | 19:33 |
| jam | is there a reason that create_workingtree wouldn't be the one creating them? | 19:33 |
| BFrank_ | hey, can someone help me. I created a directory, and added a symlink and commited. Now the symlink has changed. How do I commit just the symlink? | 19:33 |
| abentley | jam: Are you proposing that sprout first fetches everything for all branches, then creates all branches, then creates all working trees? | 19:34 |
| BFrank_ | anytime I try to commit the symlink by typing commit <symlink name>. I get this message... bzr: ERROR: Not a branch: "/symlink_path" | 19:35 |
| jam | abentley: I'm saying that a call to the top-most "create_workingtree()" then creates the children | 19:35 |
| jam | but I suppose you're saying the issue is that we haven't fetched them yet | 19:36 |
| abentley | jam: In order to do that, it would need to create the branches first... | 19:36 |
| abentley | And possibly the repositories. | 19:36 |
| abentley | BFrank_: That's a bug. | 19:36 |
| BFrank_ | is it a known bug? Or is there a place I need to file it or something? | 19:37 |
| jam | BFrank_: at the moment we have a bug with dereferencing symlinks at the wrong time. The workarounds are to commit the containing directory of the symlink | 19:37 |
| abentley | BFrank_: It's a known bug. | 19:37 |
| jam | and if that isn't specific enough | 19:37 |
| jam | you can use something like "bzr shelve" to temporarily remove your other changes | 19:37 |
| jam | then "bzr commit" then "bzr unshelve" | 19:37 |
| BFrank_ | ok, unfortunately, commiting the container directory will also commit a bunch of stuff I don't want to commit yet | 19:37 |
| BFrank_ | ahh | 19:38 |
| BFrank_ | I haven't messed with shelve yet | 19:38 |
| * adrianrf @jam: many thanks! will check out scmproj, and do some more experimentation. | 19:38 | |
| BFrank_ | also, with blame, is there any way to get the --long parameter to put the date and time on the line, instead of just the date? | 19:39 |
| abentley | jam: It's a whole layering problem. | 19:42 |
| abentley | jam: I don't think create_workingtree should be creating branches and repos. | 19:45 |
| abentley | jam: That sort of functionality seems to belong in sprout. | 19:45 |
| jam | abentley: sure, though it seems like create_workingtree should be creating working trees ... | 19:46 |
| jam | BFrank_: use "gannotate" or "qannotate" from bzr-gtk and qbzr respectively :) | 19:47 |
| jam | but no, I don't think annotate has a way to do so | 19:47 |
| BFrank_ | hmm | 19:48 |
| abentley | jam: Actually, I worry that such behaviour would be too smart for such low-level functionality. | 19:49 |
| jam | BFrank_: you'll find that gannotate is a much richer interface in general | 19:51 |
| jam | showing the commit message | 19:51 |
| abentley | jam: I don't think putting all this on fetch solves the problem either, because if you're creating nested branches, you need to know about all references, not just those that were fetched. | 19:51 |
| jam | and the whole information, etc. | 19:51 |
| jam | abentley: which is why fetch should be creating the branches | 19:51 |
| jam | and create_workingtree should be creating the child workingtrees | 19:51 |
| jam | ... | 19:51 |
| BFrank_ | thanks, I will have to look into that | 19:52 |
| jam | at least that feels like an appropriate layering to me | 19:52 |
| abentley | jam: But fetch doesn't have enough info to create all the branches. | 19:52 |
| jam | I don't have a specific problem passing the Revtree down to the working tree create | 19:52 |
| jam | since if we already have it | 19:52 |
| jam | we really should be using it | 19:52 |
| jam | abentley: it has all the information to create new ones | 19:52 |
| jam | and if it created them the last time it was fetched | 19:52 |
| jam | only things that have changed should be 'new' | 19:52 |
| abentley | jam: It won't fetch CHK nodes for revisions that are already present in the repo. | 19:53 |
| abentley | jam: But those CHK nodes must be used to determine which branches to create. | 19:54 |
| jam | abentley: but the previous time those nodes were fetched would have created them | 19:54 |
| abentley | jam: But you can branch something multiple times. | 19:54 |
| abentley | So when you branch the second time, into a new location, you don't create the branches. | 19:55 |
| abentley | i.e. the subtree branches. | 19:56 |
| abentley | Which would be bad. | 19:56 |
| jam | abentley: but you would have the revisions in the shared repo... | 19:57 |
| abentley | jam: But fetch won't have seen them, because they're already in the shared repo... | 19:58 |
| jam | sure, but you can't really create the branches until the meta-workingtree has been created, because otherwise you don't have the containing dirs created | 19:59 |
| jam | (you could create them ahead of time, but that would conflict with 'co') | 19:59 |
| jam | ... | 19:59 |
| jam | so what happens in a tree-less repository? | 19:59 |
| jam | or when doing 'bzr co --lightweight' | 20:00 |
| jam | or switch... ouch | 20:00 |
| jam | anyway, I think having the option to pass a revision tree to create_workingtree is a good idea | 20:00 |
| jam | if you can leverage that for iter_references, it is a fine starting point | 20:01 |
| abentley | jam: The more I think about it, it doesn't seem like a solution, because we still have to call iter_references with no cache when creating a treeless branch. | 20:04 |
| abentley | So it doesn't fix the case you were describing. | 20:04 |
| abentley | jam: If we assume 1. revision present in repo, 2. treeless repo, I can't see any way to avoid hitting the tree. (Except changing the data format or indexes) | 20:07 |
| jam | abentley: I posted some of this to bug 347070 | 20:14 |
| ubottu | Launchpad bug 347070 in bzr "'bzr branch' with revisions transferred takes 20s" [High,Triaged] https://launchpad.net/bugs/347070 | 20:14 |
| jam | it seems robert's reply got messed up by my mail client | 20:14 |
| jam | I'm not sure if you saw the same thing | 20:14 |
| abentley | jam: I haven't been reading bug mail. Looks okay on the web, though. | 20:24 |
| abentley | jam: Your summary looks good. | 20:25 |
| === bac is now known as bac_afk | ||
| lifeless | jelmer: does that mean you'll be continually rewriting the local history of dulwich ? | 21:29 |
| jam | morning lifeless | 21:43 |
| jam | lifeless, abentley: I just discovered a significant effect of api friction between "iter_files_bytes()" and TT.create_file() | 21:44 |
| jam | It seems the former returns a string | 21:44 |
| jam | and the latter calls f.writelines(contents) | 21:44 |
| jam | which works for strings | 21:44 |
| jam | but takes 6.7s to write all of launchpad | 21:44 |
| jam | rather than 1.0s when using f.write() | 21:44 |
| lifeless | jam: interesting | 21:56 |
| jam | yeah, I'm trying to decide what the best fix is | 21:56 |
| jam | isinstance(contents, str): f.write() | 21:56 |
| jam | or changing iter_files_bytes() to return chunks | 21:56 |
| lifeless | use type(contents) == str rather than isinstance | 21:56 |
| jam | lifeless: I believe that is type(contents) is str :) going by the recent patch submitted to change class comparisons to 'is' :) | 21:57 |
| lifeless | jam: yes :) | 21:57 |
| jam | lifeless: so you would change TreeTransform? (that was my basic feeling, but I thought I'd ask for feedback) | 21:57 |
| lifeless | IIRC iter_files_bytes is allowed to return chunks | 21:58 |
| lifeless | I'd need to check the docstring, but if a single string is valid for output,then yes, I'd change TT to cope | 21:58 |
| jam | lifeless: well it claims: bytes_iterator is an iterable of bytestrings for the file. | 21:58 |
| jam | of which | 21:58 |
| jam | a string is a valid iterable of single-character bytestrings | 21:59 |
| jam | just a really crummy one | 21:59 |
| jam | hmm.... it seems that RevisionTree.get_file_text() assumes that the return value is *exactly* a string | 22:01 |
| jam | especially since RT.get_file() wraps StringIO(self.get_file_text()) which wouldn't work for a list | 22:02 |
| igc | morning | 22:02 |
| jam | morning igc | 22:02 |
| igc | hi jam | 22:04 |
| lifeless | jam: they are possibly not honouring the contract and should be fixed | 22:07 |
| thumper | abentley: could I get a few line summary about the regression relating to nested trees? | 22:22 |
| jam | thumper: "iter_references()" takes a long time because it walks the whole tree looking for tree-references | 22:27 |
| jam | we are trying to find a way to either make that faster, or only do it when we are already walking the tree for some other reason | 22:27 |
| jam | (store a separate list of tree references, do it as part of building the working tree) | 22:27 |
| jam | the problem is that "bzr branch" in a shared repository with no trees | 22:28 |
| jam | never does an operation that walks the content | 22:28 |
| mwhudson | jam: so you have to do "for entry in tree: if entry.kind == 'ref': yield entry" sort of thing | 22:28 |
| jam | mwhudson: that sort of thing, yes | 22:28 |
| mwhudson | rather than "return entries.select(kind=='tree')" | 22:28 |
| jam | mwhudson: we don't have an "index" or tree kind | 22:28 |
| mwhudson | right | 22:28 |
| mwhudson | ugh | 22:28 |
| jam | s/or/on/ | 22:28 |
| jam | And if we need to create that index | 22:29 |
| jam | then we need a disk-format change | 22:29 |
| mwhudson | what format would need to change? inventory + dirstate? | 22:30 |
| === cprov is now known as cprov-afk | ||
| === fta is now known as fta_nano | ||
| === fta_nano is now known as fta | ||
| jelmer | lifeless: no | 22:50 |
| jelmer | lifeless: old revisions don't change | 22:51 |
| jelmer | lifeless: not even in git :-) | 22:51 |
| lifeless | jelmer: but, if you commit in bzr, then dpush, and that rewrites your branch, your branch will be continually changing? | 22:53 |
| lifeless | jelmer: we're tracking bzr | 22:53 |
| jelmer | lifeless: it only rewrites the new revisions in bzr | 22:58 |
| jelmer | lifeless: and I don't publish them before I push to git | 22:59 |
| lifeless | so you push to git then pull to the public bzr branch? | 23:00 |
| lifeless | Seems like a lot of swings and roundabouts to me, unless you're getting lots of git-side contributors | 23:00 |
| jelmer | lifeless: there's one additional command in my workflow | 23:01 |
| jelmer | lifeless: basically, before I push my changes to a public location, I dpush to git first | 23:01 |
| poolie | igc, if you're still in usertest mode, could you try to fix the trafficlight display on orcadas? | 23:05 |
| lifeless | jelmer: well its up to you; I know I'd be treating bzr as master and merging from git contributors - or have them mailbomb me | 23:05 |
| jelmer | lifeless: I am merging from git contributors | 23:07 |
| jelmer | lifeless: my current workflow allows me to not have to touch git | 23:07 |
| jelmer | and still keep contributors happy | 23:08 |
| lifeless | jelmer: ok; well I look forward to the day that the bzr trunk looks like it originates in trunk :) | 23:08 |
| lifeless | jelmer: how many git contributors are you getting? | 23:08 |
| jelmer | lifeless: one, but should be a major one | 23:08 |
| poolie | actually i see it just hasn't updated for some time | 23:08 |
| jelmer | lifeless: the guy who is working on pyrite ("Mercurial UI + Git file formats") is ditching his own implementation in favor of Dulwich | 23:09 |
| lifeless | jelmer: what are they doing? (And who is it, if thats not too nosy :) | 23:09 |
| lifeless | cool | 23:10 |
| lifeless | brb | 23:10 |
| lifeless | spiv: I hear its a hot day | 23:10 |
| jelmer | lifeless: in the short term, this will mean a proper git index implementation in dulwich | 23:12 |
| jelmer | lifeless: in the long term, it'll hopefully mean bug fixes and speed improvements | 23:13 |
| spiv | lifeless: :) | 23:14 |
| spiv | lifeless: sure, I can head to Epping. | 23:14 |
| igc | poolie: I'll take a look today hopefully | 23:16 |
| mwhudson | jelmer: so we should start our tests of git imports with the linux kernel, right? | 23:23 |
| mwhudson | :) | 23:23 |
| jelmer | mwhudson: How much terabytes of RAM do the Launchpad servers have ? :-) | 23:46 |
| mwhudson | jelmer: only a couple :) | 23:46 |
| mwhudson | jelmer: do you know what needs to be done to support large imports? | 23:48 |
| jelmer | mwhudson: yes | 23:49 |
| mwhudson | jelmer: good | 23:50 |
| mwhudson | jelmer: maybe i'll be able to get some time to helping you at some point :) | 23:50 |
| mwhudson | wow, the performance of converting a packs branch to knits blows | 23:51 |
| fullermd | Well, it's probably faster than converting to weaves at least ;) | 23:51 |
| lifeless | mwhudson: 'don't do that' | 23:52 |
| lifeless | mwhudson: it shouldn't be slow slow, just writing one knit and index per file, unless you're also changing rootedness | 23:52 |
| mwhudson | lifeless: i'm doing it so that i can test auto-upgrading of branches by the import system | 23:53 |
| mwhudson | i guess i should have found a smaller one to play with | 23:53 |
| fullermd | So apparently tomorrow I'm going to be trying to explain to somebody how to use bzr on windows. | 23:53 |
| mwhudson | hm | 23:53 |
| mwhudson | bzr: ERROR: Cannot convert to format <class 'bzrlib.branch.BzrBranchFormat5'>. No converter | 23:53 |
| mwhudson | seems to have worked though | 23:53 |
| lifeless | mwhudson: there isn't a branch downgrader | 23:54 |
| mwhudson | ah ok | 23:54 |
| lifeless | mwhudson: so use a custom format via bzrlib | 23:54 |
| mwhudson | i guess i should have said upgrade --dirstate-tags, not upgrade --knit | 23:55 |
| fullermd | You could init/pull instead of upgrade, too. | 23:55 |
| SpamapS | Does anyone know of bazaar users that have migrated from Perforce? I'm wondering if bazaar's changeset tracking is as good as Perforce's merge tracking. | 23:55 |
| fullermd | Well, going to knit lets you test the full gamut too; all 3 formats are different there. d-t -> packs is only 1 difference. | 23:56 |
| bob2 | better! | 23:56 |
| fullermd | Is it? I thought p4 had decent cherrypick handling. | 23:56 |
| fullermd | (of course, it's got plenty of insanity aside from that...) | 23:56 |
| bob2 | I don't know! | 23:57 |
| SpamapS | we've been relatively happy with Perforce | 23:59 |
| SpamapS | its just expensive.. and doesn't have any decentralized abilities.. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!