| jam-laptop | (it is just state based, and knows that key X follows key Y) | 12:02 |
|---|---|---|
| mhagger | Doesn't it work by parsing rlog output? Isn't that already ambiguous? | 12:02 |
| jam-laptop | mhagger: cvsps works by parsing rlog, I don't know the details on that side | 12:02 |
| jam-laptop | (As I work above cvsps, not below it) | 12:03 |
| bialix | mhagger: here some basic examples http://bazaar-vcs.org/Integrating_with_Bazaar | 12:03 |
| jam-laptop | Though I have some hooks to invoke cvsps with the "correct" arguments. | 12:03 |
| jam-laptop | I found the cvsps command line to be pretty ugly | 12:03 |
| bialix | and here http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html -- epydoc like docs | 12:04 |
| jam-laptop | So if your tree isn't too tricky, you can do "bzr cvsps-import CVSROOT MODULE OUTPUT" and not need to know anything about cvsps (other than have it available) | 12:04 |
| mhagger | jam-laptop: Would you be interested in working together on this? I bet we could have something done in a day or two | 12:04 |
| jam-laptop | mhagger: I would be happy to help when I can | 12:04 |
| jam-laptop | I work full time on the project | 12:05 |
| bialix | mhagger: just another question about cvsnt | 12:05 |
| bialix | cvsnt (as I say) have record about merge points | 12:06 |
| bialix | AFAIK before 1.5 svn does not record merges | 12:06 |
| mhagger | jam-laptop: Do you work for Canonical? | 12:06 |
| jam-laptop | mhagger: yes | 12:06 |
| bialix | is this concept fit to current cvs2svn? | 12:06 |
| mhagger | cvs2svn doesn't try to deduce merge points, because there is no such info in standard CVS | 12:07 |
| === bialix wonder if name of project one day becomes cvs2any... | ||
| mhagger | What is the form of the mergepoint information? | 12:07 |
| bialix | I understand it, hence my question | 12:07 |
| bialix | wait | 12:08 |
| bialix | something like this: mergepoint1 @1.5.2.1@; | 12:08 |
| jam-laptop | mhagger: so if you are interested in poking at it a bit, I'm guessing the only thing that would need to change would be to write a Parser to replace the cvsps Parser | 12:09 |
| jam-laptop | As long as the "_PatchSet" objects can contain the information you want to copy over | 12:10 |
| mhagger | jam-laptop: By "parser" I assume you mean "the huge amount of code needed to read RCS files and deduce the changesets" | 12:11 |
| jam-laptop | cvsps-import uses rcs to directly extract the texts, so it sort of depends on how cvs2svn extracts stuff | 12:11 |
| jam-laptop | mhagger: well the Parser takes cvsps Patches and turns them into meta-info plus a list of (file, version) data | 12:11 |
| mhagger | Maybe we should move this to #cvs2svn to avoid disturbing the good folks of #bzr? | 12:11 |
| jam-laptop | mhagger: but you've already done all the work to do that part of the parsing | 12:12 |
| jam-laptop | mhagger: na, this is an open channel | 12:12 |
| mhagger | Yes, of course | 12:12 |
| jam-laptop | the #bzr policy is to discuss anything even remotely related to #bzr | 12:12 |
| jam-laptop | unless the channel is extra busy | 12:12 |
| mhagger | Yes, we parse, then put everything in a dependency graph, then remove cycles in the graph, then topologically sort, and the changesets fall out. | 12:13 |
| bialix | btw, cvsnt mark changesets with ids: commitid 44441d436f80000; | 12:13 |
| mhagger | ...with lots of extra code for working with vendor branches, CVS's spurious commits, etc | 12:13 |
| jam-laptop | bbiab | 12:14 |
| mhagger | bialix: Does the mergepoint indicate that all changes on the 1.5.2 branch through 1.5.2.1 have been merged into that revision? | 12:14 |
| mhagger | ...or only that the single 1.5.2.1 delta has been merged, or what? | 12:14 |
| mhagger | bialix: To support CVSNT... | 12:15 |
| bialix | because I don't have access to docs -- I can't say for sure | 12:15 |
| bialix | but I can do some experiments | 12:15 |
| bialix | with TortoiseCVS | 12:15 |
| bialix | to see what happens | 12:15 |
| mhagger | (1) The RCS parser would have to be enhanced a bit. Currently it discards the newphrases | 12:16 |
| bialix | generally my TortoiseCVS workflow was very close to one we use in bzr | 12:16 |
| bialix | i.e. I'm always merge full branch history, not cherrypicking it | 12:16 |
| mhagger | (2) I think that CVSNT supports some other file modes (i.e., binary vs. text vs. keyword expansion etc) | 12:16 |
| mhagger | Those would have to be supported. | 12:16 |
| bialix | 2) -- I think so | 12:17 |
| mhagger | (3) The commitid information would have to be used. I don't think this would be very difficult. | 12:17 |
| bialix | 3) at least it could be used as suggestion? | 12:17 |
| mhagger | (4) Whatever different strange corner cases, corruption etc that exist in CVSNT repos would have to be dealt with. | 12:18 |
| mhagger | Yes, the most trivial thing to do with commitids is to use it as an exclusion criterion: if the commitids are different, then the revisions *cannot* be part of a single commit. | 12:18 |
| bialix | what do you mean by corruption? | 12:18 |
| mhagger | There are a few forms of CVS repo corruption that we have seen repeatedly. | 12:18 |
| bialix | ah, ok | 12:19 |
| mhagger | Probably resulting from CVS bugs in some historical version or something | 12:19 |
| mhagger | or maybe poor disaster recovery | 12:19 |
| mhagger | Presumably CVSNT has similar things | 12:19 |
| bialix | may be | 12:19 |
| bialix | btw, I don't remember, is cvs2svn supports CVS modules? | 12:20 |
| mhagger | Not the modules file. It is not clear what to do with it. | 12:20 |
| mhagger | but cvs2svn supports CVS repositories with multiple projects | 12:21 |
| bialix | in bzr we have concept of nested trees, but it still not production ready | 12:21 |
| mhagger | each project can be converted independently of the others; for example, branches and tags in different projects can be considered distinct. | 12:21 |
| jam-laptop | mhagger: well, that and the fact that most people do manual surgery to rename files, etc | 12:21 |
| jam-laptop | And if you do it "correctly" you still have a bunch of cvsadmin work to do | 12:22 |
| mhagger | Ouch let's not even talk about that | 12:22 |
| mhagger | :-) | 12:22 |
| mhagger | Often there is too little left in the history to know what happened, so figuring it out is too much to ask of a conversion tool | 12:23 |
| mhagger | Maybe it needs a "mechanical Turk" module :-) | 12:23 |
| bialix | mhagger: can you have some sort of description of real CVS format for ,v files? | 12:23 |
| mhagger | bialix: man rcsfile is a good start | 12:24 |
| bialix | yeah, but this man is a bit short and unclear | 12:24 |
| mhagger | Somewhere there is also documentation specific to CVS that describes their file extensions briefly | 12:24 |
| bialix | I mean: to understand what is standard CVS words, and what is cvsnt specific claims | 12:25 |
| lifeless | lo jam-laptop, welcome back to irc :) | 12:25 |
| jam-laptop | hi lifeless, good to be around :0 | 12:25 |
| mhagger | jam-laptop: I suggest that to get started you send an email to the cvs2svn dev mailing list with references telling us where to find cvsps-import and what modules to look at. | 12:26 |
| bialix | (jam was unhappy because there was no one to talk with, so we start to talk with ubotu) :-) | 12:26 |
| bialix | lifeless: ^ | 12:26 |
| mhagger | bialix: I don't know of better RCS file documentation. Of course one could try to figure it out from the CVS source code. | 12:27 |
| lifeless | well | 12:27 |
| lifeless | rcs source code :) | 12:27 |
| mhagger | I've seen enough of them to understand them pretty well | 12:27 |
| mhagger | Well, RCS files as used by CVS. So you need to know both. | 12:28 |
| lifeless | modules is well documented - new repos get a sensible modules | 12:28 |
| mhagger | CVS uses its own RCS file parsing machinery, so I guess it is definitive. | 12:28 |
| lifeless | its runtime evaluated | 12:28 |
| lifeless | IIRC that is. | 12:28 |
| lifeless | anyhow, I haven't read all the backlog, would someone like to clue me in on the question quickly :) ? | 12:29 |
| mhagger | We're discussing the possibility of adding a bzr backend for cvs2svn | 12:29 |
| mhagger | (I'm the cvs2svn maintainer) | 12:29 |
| lifeless | the cvs2svn script, last time I looked, was relatively easy to break with 'impossible' (but they happen) timestamp + ,v topological ordering combinations across files | 12:30 |
| mhagger | lifeless: Then I guess the last time you looked was before cvs2svn 2.0 :-) | 12:30 |
| lifeless | I don't mean this as a criticsm btw | 12:30 |
| lifeless | sounds like its improved massively | 12:30 |
| mhagger | The new code uses a dependency graph to deduce changesets, and fixed all the known bugs in 1.x | 12:31 |
| mhagger | It uses quite a bit more RAM, but otherwise works very well. | 12:31 |
| lifeless | does it ever run incrementally, or is it a 1-shot tool ? | 12:31 |
| mhagger | I don't know of a CVS repo that it can't handle | 12:31 |
| mhagger | 1-shot, unfortunately. | 12:31 |
| lifeless | righto | 12:31 |
| lifeless | cscvs for all its flaws is incremental | 12:32 |
| mhagger | Maybe a deep-pocketed sponsor could encourage an incremental conversion feature ;-) | 12:32 |
| lifeless | so it has extra state added to its output to allow incremental operation | 12:32 |
| mhagger | What are the pros and cons of cscvs? I'm not really familiar with it. | 12:32 |
| fullermd | I know every time it was tried on the BSD repo, it fell over. That might have been pre-2.0, though. | 12:32 |
| mhagger | FreeBSD works now. | 12:33 |
| fullermd | Sweet. | 12:33 |
| mhagger | There are some problems with symbols being defined multiple times in a single file. These have to be resolved manually using a "hints" file. | 12:33 |
| fullermd | There's some Scary Shit(tm) hidden in there. Any conversion that can swallow it deserves biiig kudos. | 12:34 |
| mhagger | It is not clear even how a perfect system would deal with corruption like that. | 12:34 |
| lifeless | well | 12:34 |
| mhagger | (The repeated symbols, I mean) | 12:34 |
| lifeless | one is doomed to failure | 12:34 |
| lifeless | the question is how close one wants to come to success ;) | 12:34 |
| lifeless | anyhow, cscvs, whats different - its geared for incremental runs, which means detecting ,v file moves and the like | 12:35 |
| lifeless | added complexity | 12:35 |
| lifeless | multiple front end and back ends | 12:35 |
| mhagger | There were some FreeBSD guys hanging around a couple of weeks ago (converting to git) and I'm pretty sure they were successful after I added the hints file workaround for their duplicated symbols | 12:35 |
| lifeless | its really vcs2vcs these days | 12:35 |
| mhagger | What input/output formats does cscvs have? | 12:36 |
| mhagger | I'm impressed by incremental conversions. I've thought about how to add it to cvs2svn and it will be a good chunk of work. | 12:37 |
| lifeless | its nasty | 12:37 |
| lifeless | don't :) | 12:37 |
| mhagger | [At least if your incremental conversions really work robustly! It's easy to do a "works most of the time" solution.] | 12:37 |
| lifeless | ddaa and mwh know cscvs way better than I do these days | 12:37 |
| lifeless | but reads-from svn, cvs | 12:38 |
| lifeless | writes to bzr (we use this), tla (but we don't use this - it may be bitrotten now) | 12:38 |
| mhagger | Does it read arbitrary svn repos, or only repos that use the stylized trunk/tags/branches structure? | 12:39 |
| lifeless | so, cscvs is meant to break loudly if the incremental conversion looks horked, and let you manually correct the state, then resume | 12:39 |
| lifeless | oh, thats probably the other big difference | 12:39 |
| lifeless | its branch-at-a-time | 12:39 |
| lifeless | so any svn repo, you just identify the path to convert | 12:40 |
| lifeless | what else is interesting | 12:40 |
| mhagger | CVS is also branch-at-a-time? | 12:40 |
| lifeless | oh yeah, there is pure python cvs wire protocol implementation in there | 12:40 |
| lifeless | yes | 12:40 |
| mhagger | Hmmm, that's curious | 12:40 |
| lifeless | cscvs was originally written for a vcs which had no concept of free-form branch naming | 12:41 |
| === mhagger thinks about whether that simplifies conversions significantly | ||
| lifeless | long as you convert the parent branch[es] first, and provide a way to find them | 12:41 |
| mhagger | It sure must reduce the computational resources needed for a conversoin | 12:41 |
| lifeless | thats one area could do with improvement actually | 12:42 |
| fullermd | Here's a Q: How easy would it be to use some of the properties work planned/done to store up info on file rev sources, so I could "bzr find src/foo.c cvsrev:1.234"? | 12:42 |
| lifeless | fullermd: theres a header in the revision already | 12:42 |
| lifeless | fullermd: have a look at one of the cvs conversions on launchpad | 12:43 |
| mhagger | OK it's bedtime in Berlin... | 12:44 |
| mhagger | Let me just repeat my offer: | 12:44 |
| mhagger | If somebody with bzr experience is willing to join forces, I'd be happy to work on a bzr backend for cvs2svn. | 12:44 |
| lifeless | well | 12:45 |
| lifeless | I'm happy to answer any questions and sketch out the right bits of the bzrlib api to use | 12:45 |
| mhagger | It shouldn't be more than a couple of days work | 12:45 |
| lifeless | we should have everything you might want already present | 12:45 |
| bialix | if it's possible to have some progress with merge points, I can help | 12:45 |
| fullermd | lifeless: Know one of them offhand? | 12:46 |
| lifeless | drop me a mail if you like, describing what the backend ends - 'robert at canonical' | 12:46 |
| mhagger | I mostly don't have time to find everything and learn all of the bzr concepts | 12:46 |
| lifeless | fullermd: no | 12:46 |
| lifeless | and I'll come back to you with a brain dump and such | 12:46 |
| mhagger | OK, thanks lifeless | 12:46 |
| mhagger | I'll try to get to it in the next couple of days. | 12:47 |
| mhagger | If you are interested, meanwhile look at cvs2svn source files cvs2svn_lib/git_output_option.py and git_repository_recorder.py | 12:47 |
| lifeless | I am swamped :( | 12:48 |
| mhagger | I guess what you need will be pretty obvious by analogy | 12:48 |
| lifeless | I'm racing against the next release clock to get my performance impoved repository merged | 12:48 |
| mhagger | Goodnight, thanks for the interesting conversation! | 12:48 |
| bialix | night | 12:49 |
| === mhagger is now known as mhagger-afk | ||
| lifeless | night | 12:50 |
| lifeless | I think I have one bug left in this bisection work | 12:56 |
| lifeless | and it will be done | 12:56 |
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| jelmer | hmm, 'InventoryDirectory' object has no attribute 'snapshot' | 01:11 |
| lifeless | right | 01:12 |
| lifeless | commit builder has that logic now | 01:12 |
| lifeless | faster, more tightly coupled to the repository so different repos can do different things | 01:12 |
| === p4tux [n=p4tux@189.169.95.23] has joined #bzr | ||
| === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| poolie | hi | 01:18 |
| lifeless | morning | 01:19 |
| lifeless | I think I am going to factor out a ParsedRegions class | 01:22 |
| lifeless | once I fix this bug | 01:22 |
| poolie | good morning | 01:27 |
| poolie | i'm feeling much better today | 01:28 |
| poolie | i made some progress on commit | 01:28 |
| lifeless | cool | 01:28 |
| lifeless | I'm a tad seedy | 01:28 |
| poolie | i suspect a bug in how update_base_.... interacts with the inventory cache | 01:28 |
| lifeless | and horms wedding party is tonight | 01:28 |
| === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr | ||
| lifeless | poolie: what sort of bug? | 01:30 |
| poolie | something like the inventory and dirstate being out of sync | 01:31 |
| poolie | it's just a gut feeling so i don't want to debate if it's likely or not | 01:31 |
| poolie | i'm just going to see if the same test fails on other wt formats | 01:32 |
| lifeless | fair enough | 01:34 |
| poolie | what i see in particular is that | 01:35 |
| poolie | an apparently correct delta is passed in, | 01:35 |
| poolie | but when the test looks at the inventory later, some files have not been removed | 01:35 |
| lifeless | so its looking at the inventory of the parent? | 01:36 |
| lifeless | or the inventory of the tree? | 01:36 |
| poolie | the test is looking at the wt inventory iirc | 01:36 |
| lifeless | that would be a bug | 01:36 |
| poolie | yes, apparently | 01:37 |
| lifeless | in the test - because the update_...delta() method is meant to update the parent tree | 01:37 |
| poolie | anyhow, that was what i suspected last night | 01:37 |
| poolie | oh, | 01:37 |
| poolie | interesting | 01:37 |
| poolie | of course | 01:37 |
| poolie | but really we seem to need something that both updates the parent tree and also the wt | 01:38 |
| lifeless | (you can see the method being tested in bzrlib.tests.workingtree_implementations.test_parents) | 01:38 |
| lifeless | why do we need to update both? updates to the current tree can be done directly in dirstate representation | 01:39 |
| === m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has joined #bzr | ||
| lifeless | poolie: unless there is a performance problem, it seems cleaner to me to do the wt changes and the basis tree changes separately; and theres no performance problem I see doing it separately | 01:44 |
| poolie | hang on | 01:44 |
| lifeless | okydoky | 01:45 |
| poolie | i think you're right, i was expecting it to update both of them the same way | 01:45 |
| poolie | which is not quite sensible | 01:46 |
| poolie | um | 01:46 |
| poolie | i agree you can probably do it efficiently with two separate calls | 01:46 |
| lifeless | the wt changes are uncommon | 01:47 |
| lifeless | whereas the parent changes always | 01:47 |
| poolie | right, only for autoremove and similar things | 01:47 |
| m0rra | umm. hasn't the documentation been updated for a long time or what..? instead of bzr in the documentation, i need to use baz. also it shows the latest version is 0.91, but i have 1.4.2 and all the commands are different.? | 01:47 |
| lifeless | m0rra: 'baz' is a very old tool | 01:47 |
| lifeless | m0rra: I think you have the wrong software package installed somehow | 01:47 |
| lifeless | m0rra: if you are on ubuntu/debian install 'bzr'. | 01:48 |
| poolie | we should fix that package naming | 01:48 |
| poolie | there is a bug for it | 01:48 |
| poolie | bazaar->baz | 01:48 |
| m0rra | ah, i see. i apt-get installed bazaar... | 01:48 |
| poolie | ok, i see the problem | 01:48 |
| lifeless | food time for roberts | 01:49 |
| lifeless | Do you want a morning sync; I have plenty to do without syncing | 01:49 |
| poolie | me too, i'm just going to persist with this | 01:49 |
| poolie | only question would be, do you want me to declare a freeze, declare a slip, do nothing? | 01:50 |
| === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr | ||
| igc | morning | 01:54 |
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| jml | why is build_tree in TestCaseInTempDir and not TestCaseWithMemoryTransport? | 01:58 |
| poolie | hi jml, igc | 01:59 |
| jml | poolie: hello | 01:59 |
| poolie | jml, i can't see a good reason why | 01:59 |
| igc | hi poolie | 01:59 |
| poolie | withMemoryTransport is robert's invention, he may be able to help when he gets back | 01:59 |
| jml | thanks. | 01:59 |
| lifeless | uhm | 02:00 |
| lifeless | those raisins are hysterical | 02:00 |
| jam-laptop | lifeless: doesn't 'build_tree' build on disk | 02:00 |
| poolie | hi jam-laptop | 02:00 |
| lifeless | disk or transport | 02:00 |
| jam-laptop | And "WithMemoryTransport" doesn't have a disk location? | 02:00 |
| lifeless | can do either | 02:00 |
| lifeless | MemoryTransport still has local disk, because of the bug where we write config files | 02:01 |
| lifeless | when you do anything | 02:01 |
| lifeless | and also because posix makes it hard to chdir /nonexisting/path :) | 02:01 |
| lifeless | poolie: release wise - your call, I'm fine however you play it | 02:01 |
| === m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has left #bzr ["<surnuaed>] | ||
| jelmer | lifeless: Btw, any news on my pqm patches - or should I wait until after 0.92 before asking you about those again? | 02:08 |
| === bialix [i=chatzill@77.109.17.57] has joined #bzr | ||
| lifeless | jelmer: yah, wait a bit | 02:25 |
| lifeless | very single-track right now | 02:25 |
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr | ||
| === fbond [n=fab@pool-71-169-154-64.burl.east.verizon.net] has joined #bzr | ||
| lifeless | hmm | 02:48 |
| lifeless | someone has disputed the neutrality of the bzr wiki page | 02:49 |
| lifeless | simply because it doesn't list cons | 02:49 |
| tetron | cons? | 02:54 |
| bialix | pros and cons | 03:01 |
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| bialix | bzr has only pros | 03:01 |
| spiv | bialix: I wish :) | 03:04 |
| === pete__c_ [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr | ||
| spiv | bialix: then I'd have no work to do ;) | 03:04 |
| keir | hmm, if i bzr push to a bzr+ssh server that doesn't exist, it shouldn't bail with a 20 item traceback, should it? it sais ssh: projects.launchpad.net not found; then a huge traceback follows | 03:04 |
| bialix | no, we work on new features, to increase amount of pros ;-) | 03:04 |
| bialix | no should not | 03:05 |
| keir | lifeless, which wiki page? | 03:05 |
| bialix | there is bug report about this | 03:05 |
| bialix | !ubotu fas | 03:06 |
| ubotu | Sorry, I don't know anything about fas - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 03:06 |
| bialix | stupid ubotu | 03:06 |
| bialix | !ubotu traceback | 03:07 |
| ubotu | Sorry, I don't know anything about traceback - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 03:07 |
| === orospakr [n=orospakr@bas4-ottawa23-1177612037.dsl.bell.ca] has joined #bzr | ||
| bialix | never mind | 03:07 |
| spiv | keir: no, it shouldn't, I think there's a bug open about that. | 03:07 |
| spiv | Oh, as bialix said :) | 03:08 |
| bialix | keir: it's also traceback when your connection suddenly dropped and some more unpleasant things | 03:09 |
| keir | that's not very nice | 03:09 |
| bialix | indeed | 03:09 |
| bialix | jam-laptop: ping? | 03:09 |
| === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr | ||
| i386 | hey lifeless | 03:14 |
| i386 | I managed to crawl into work | 03:14 |
| lifeless | lol | 03:15 |
| lifeless | I was working at the usual time :) | 03:15 |
| lifeless | keir: wikipedia's 'Bazaar_(vcs)' page | 03:15 |
| i386 | lifeless: I think I may go home | 03:16 |
| lifeless | lol | 03:17 |
| i386 | apparently Jaq didnt turn up for work this morning | 03:20 |
| lifeless | ahha | 03:20 |
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr | ||
| === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr | ||
| === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] | ||
| === poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has joined #bzr | ||
| === adhoc [n=kim@ppp121-45-74-196.lns10.adl6.internode.on.net] has joined #bzr | ||
| adhoc | hi guys... | 04:22 |
| adhoc | can i use bzr with an authenticated web proxy ? | 04:22 |
| lifeless | vila will really know | 04:26 |
| lifeless | but I think you can yes | 04:26 |
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === AfC [n=andrew@m770f36d0.tmodns.net] has joined #bzr | ||
| jam-laptop | spiv: ping | 04:43 |
| spiv | jam-laptop: pong, although I want to get some lunch in a minute | 04:47 |
| jam-laptop | spiv: k, I just wondered if you had any ideas about trying to track down memory leaks in python | 04:52 |
| jam-laptop | and what the gc.set_debug() flags really mean. | 04:52 |
| jam-laptop | Feel free to respond to my email | 04:52 |
| jam-laptop | (I'm worried I'm setting a refcount incorrectly, and wondering if gc.collect() can tell me about that sort of problem) | 04:52 |
| jam-laptop | It sounds like it can, but I'm not positive what everything means | 04:52 |
| lifeless | hi jam-laptop long call ? | 04:54 |
| jam-laptop | about 1 hr | 04:56 |
| jam-laptop | just dealing with other stuff | 04:57 |
| spiv | jam-laptop: I'm not very familiar with the precise meanings of the various gc.DEBUG_* flags. | 04:58 |
| spiv | jam-laptop: although if you're worried about refcounts, perhaps sys.getrefcount or gc.get_referrers may help you test hypotheses. | 04:59 |
| jam-laptop | well reading http://www.python.org/doc/current/lib/module-gc.html | 04:59 |
| === igc food | ||
| jam-laptop | DEBUG_UNCOLLECTABLE | 04:59 |
| jam-laptop | seemed relevant | 04:59 |
| spiv | (I'm not sure, but I'm guessing that Pyrex would tend to generate objects that play nicely with get_referrers) | 04:59 |
| jam-laptop | typing is slow with a baby in one arm Z) | 05:00 |
| spiv | Right, everything I know about those flags I learned from that page :) | 05:00 |
| spiv | Well, I guess I could spend some quality time with Modules/gcmodule.c ;) | 05:01 |
| jam-laptop | don't worry about it too much | 05:07 |
| lifeless | spiv: so is your reconcile patch landed? | 05:14 |
| === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === jamesh__ is now known as jamesh | ||
| lifeless | WOOT | 05:17 |
| lifeless | lunchies | 05:18 |
| === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| lifeless | so who is dogfooding | 05:48 |
| lifeless | packs that is | 05:48 |
| lifeless | mwhudson: ping | 05:48 |
| fullermd | bzr.dev is edgy enough for me... | 05:50 |
| lifeless | def all_revision_ids(self, transaction): | 05:53 |
| lifeless | """See RevisionStore.all_revision_ids().""" | 05:53 |
| lifeless | rev_file = self.get_revision_file(transaction) | 05:53 |
| lifeless | return rev_file.get_ancestry(rev_file.versions()) | 05:53 |
| lifeless | thats a WTF moment right there | 05:53 |
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| poolie_ | Subject: Should we baptized "in the name of the Father, Son, and Holy Spirit" or "in Jesus' name"? | 05:59 |
| poolie_ | now that is offtopic | 05:59 |
| poolie_ | "either, as long as it is a utf-8 name" | 06:00 |
| fullermd | Sounds like a difficult debate. We should compromise and do it in my name instead. | 06:00 |
| lifeless | wow | 06:00 |
| lifeless | I just managed to trip a md5 has collision on pull | 06:00 |
| poolie_ | really? | 06:01 |
| lifeless | yeah, packs with the same data have the same content :) | 06:02 |
| lifeless | so the question is why I'm copying this data at all | 06:03 |
| lifeless | igc: poolie_: jam-laptop: partial-index-using packs pushed to my usual 'repository' branch | 06:06 |
| === bratsche [n=cody@adsl-68-94-34-240.dsl.rcsntx.swbell.net] has joined #bzr | ||
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| poolie_ | (reading ian's paper) | 06:35 |
| lifeless | ah, I think I know | 06:44 |
| lifeless | see if this scans | 06:44 |
| lifeless | do a commit, adds a revision that triggers autopack | 06:45 |
| lifeless | something causes a failure right there | 06:45 |
| lifeless | mm more detail | 06:45 |
| lifeless | we autopack | 06:45 |
| lifeless | add the new pack and its indices | 06:45 |
| lifeless | then start removing the obsoleted packs | 06:45 |
| lifeless | which is where it breaks | 06:45 |
| lifeless | the result is that we have a set of packs, which when packed generate the same pack again | 06:46 |
| lifeless | and that new pack is already present | 06:46 |
| lifeless | if this theory is right | 06:48 |
| lifeless | doing a manual pack will let me pull bzr.dev | 06:48 |
| lifeless | because it doesn't aim for the log distribution | 06:48 |
| igc | thanks lifeless | 06:49 |
| lifeless | spiv: what did you think of my python bug ? :) | 06:50 |
| lifeless | yup, doing a pack let it work | 06:50 |
| lifeless | wow, performance jump :) | 06:51 |
| spiv | lifeless: cute | 06:53 |
| lifeless | spiv: is your reconcile patch ok'd ? and merging ? | 06:54 |
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| lifeless | poolie_: igc: spiv: requesting a review of the index bisection patch. | 07:00 |
| lifeless | This is the last patch needed to send in a patch adding packs. | 07:00 |
| poolie_ | hm, how big is it? | 07:01 |
| poolie_ | big | 07:01 |
| poolie_ | ok | 07:01 |
| === poolie_ rolls up his underscore sleeves | ||
| === poolie_ is now known as poolie | ||
| lifeless | NEWS | 10 | 07:02 |
| lifeless | bzrlib/bisect_multi.py | 64 ++++ | 07:02 |
| lifeless | bzrlib/index.py | 504 ++++++++++++++++++++++++++++++++++++-- | 07:02 |
| lifeless | bzrlib/tests/__init__.py | 1 | 07:02 |
| lifeless | bzrlib/tests/test_bisect_multi.py | 344 +++++++++++++++++++++++++ | 07:02 |
| lifeless | bzrlib/tests/test_index.py | 290 +++++++++++++++++++++ | 07:02 |
| lifeless | bzrlib/tests/test_knit.py | 12 | 07:02 |
| lifeless | 7 files changed, 1198 insertions(+), 27 deletions(-) | 07:02 |
| keir | sweet, we have patch markers now? | 07:02 |
| poolie | mm? | 07:03 |
| poolie | i imagine he ran diffstat by hand | 07:03 |
| poolie | it would be nice if send did it though | 07:03 |
| keir | oh, i didn't know that command existed | 07:03 |
| lifeless | keir: 'bzr send -o- | diffstat' | 07:03 |
| lifeless | also there is a diffstat plugin | 07:03 |
| lifeless | but I haven't used it so can't comment | 07:03 |
| === fullermd still misses CVSish +/- in log :| | ||
| lifeless | keir: my repository branch now does the naive bisection robustly | 07:04 |
| keir | lifeless, niiice! | 07:04 |
| poolie | fullermd, i can't remember what that is | 07:04 |
| lifeless | keir: looks like there is *tonnes* of room for improvement on this though, with the design we've been batting around | 07:05 |
| keir | lifeless, yeah, i like the differential encoding of the hash table | 07:05 |
| poolie | i'll read that patch then take a break i think | 07:05 |
| keir | lifeless, it's a nice little trick | 07:05 |
| fullermd | revision 1.7 | 07:05 |
| fullermd | date: 2006/01/21 01:17:04; author: mfuller; state: Exp; lines: +29 -7 | 07:05 |
| lifeless | yup | 07:05 |
| lifeless | I think that + topological grouping on the first graph, is going to be quite a huge win | 07:06 |
| keir | lifeless, i agree totally | 07:06 |
| fullermd | Easier on my eye than diffstat for a quick glance at magnitude. Maybe that's just familiarity, but... | 07:06 |
| lifeless | fullermd: per-file | 07:06 |
| keir | fullermd, i def. prefer diffstat | 07:06 |
| keir | i'd even like to get diffstat by default on commit and such, but i'm crazy | 07:07 |
| poolie | lifeless, is it possible at all for lookup_keys_via_location to be split up? | 07:07 |
| poolie | or _parse_region for that matter | 07:07 |
| keir | lifeless, on a slightly different note, i've been trying to figure out what i don't like about the bzr dev docs | 07:07 |
| lifeless | fullermd: also, you know about diffstat's format parameter ? | 07:07 |
| lifeless | keir: I think the diffstat plugin may do that | 07:08 |
| fullermd | I s'pose once I dig into writing commit mailings on bzr, I'll end up having to get my brain on diffstat, since it exists and a straight +/- doesn't. | 07:08 |
| lifeless | keir: if it doesn't, you can definately do a post-commit hook plugin to do it | 07:08 |
| keir | lifeless, and it's that there isn't a clear description of the underlying data structures but absenting implementation details | 07:08 |
| keir | lifeless, in a self-contained and digestible form | 07:08 |
| fullermd | lifeless: I've looked through the manpage; didn't see anything that would give me that sort of output... | 07:08 |
| lifeless | poolie: _parse_region is about 10 lines, are you looking at the updated patch ? | 07:08 |
| poolie | i'm looking at the current one in BB | 07:09 |
| keir | lifeless, i've done all this thinking about how to do nicer indicies and whatnot, and really, i still don't understand how _everything_ is structured | 07:09 |
| poolie | http://bundlebuggy.aaronbentley.com/request/%3C1191820213.8537.0.camel@lifeless-64%3E | 07:09 |
| lifeless | poolie: thats the old one | 07:09 |
| poolie | thump bb on the side :) | 07:09 |
| lifeless | actually list sluggishniss | 07:10 |
| lifeless | its not in my mailq | 07:10 |
| poolie | ok, i'll check again soon | 07:10 |
| poolie | am going to get fresh air first | 07:10 |
| lifeless | kk | 07:11 |
| poolie | if that's ok | 07:11 |
| lifeless | /wave | 07:11 |
| lifeless | fullermd: so there is a -f option | 07:12 |
| lifeless | fullermd: but none match your desire. However.. the good news is its open source | 07:12 |
| lifeless | :) :) :) :) :) | 07:12 |
| lifeless | also, we have a pure python version in the diffstat plugin I believe, that would be easy to do cvs style summaries | 07:12 |
| lifeless | keir: I think thats a good point; and one we're incrementally achieving with the doc/developers/ text files | 07:13 |
| keir | lifeless, but (apologies for being blunt) the dev docs are _all over the place_ | 07:13 |
| lifeless | keir: if you've read the doc/developer/repository.txt file from the pack branch | 07:13 |
| keir | the HACKING file is very good | 07:13 |
| keir | but the other stuff is... a bit of overload for starting out | 07:13 |
| lifeless | blunt is fine :) | 07:14 |
| poolie | keir, you could usefully point out 'doc/developer/something is crack' | 07:14 |
| lifeless | or | 07:14 |
| poolie | to provoke people to clear up or remove it | 07:14 |
| lifeless | 'where do I go to get XXX' ? | 07:14 |
| keir | heh | 07:14 |
| lifeless | which will either get better references made | 07:14 |
| lifeless | or a bug saying we're missing that | 07:14 |
| keir | what i want is a 1 or 2 page summary of the data structures i need to reason about in bzr | 07:14 |
| keir | and their relations | 07:14 |
| keir | for example. in repositories.txt, i expect to see a description of what repositories _are_ before going into the requirements of their commands! | 07:16 |
| keir | what data is in it? | 07:16 |
| keir | what are the types? | 07:16 |
| keir | their relations? | 07:16 |
| lifeless | hmm | 07:16 |
| lifeless | I think there are two separate things here | 07:16 |
| keir | everything in that file should go in repository_scaling_considerations.txt | 07:16 |
| lifeless | one is the interface | 07:16 |
| lifeless | the other is the implementation | 07:16 |
| keir | right | 07:17 |
| lifeless | much of what you are asking is implementation specific | 07:17 |
| keir | i don't think so | 07:17 |
| lifeless | and is/should be accessible by 'pydoc bzrlib.repofmt.pack_repo' | 07:17 |
| keir | fundamentally, bzr stores a bunch of DAG's with data tied to the edges / nodes | 07:17 |
| lifeless | well | 07:17 |
| === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| lifeless | the bzr-svn repo fmt does not store the same dags at all | 07:18 |
| keir | sure, bzrlib exposes an API for manipulating and accessing that format | 07:18 |
| keir | whaaa? | 07:18 |
| lifeless | heh | 07:18 |
| lifeless | meltdown ? :) | 07:18 |
| keir | this is what i mean | 07:18 |
| fullermd | Run! Run while you still can! | 07:18 |
| keir | what i like about git and mercurial, is that i can easily understand the structure | 07:19 |
| lifeless | bzr-svn is expected to meet the same interface | 07:19 |
| keir | so reading and understanding the code is a snap | 07:19 |
| lifeless | and we should document the interface in the manner you are talking about | 07:19 |
| lifeless | I agree we have a problem here | 07:20 |
| keir | i keep going back to mercurial's dev page: http://www.selenic.com/mercurial/wiki/index.cgi/Design | 07:20 |
| === adhoc [n=kim@ppp121-45-74-196.lns10.adl6.internode.on.net] has left #bzr [] | ||
| keir | honestly, my lack of understanding this stuff has made me less inclined to believe bzr is fundamentally better than the competition | 07:20 |
| keir | i really do agree with linus on 'get your data structures right; code comes and goes' | 07:20 |
| keir | and if bzr doesn't have it's data structures straight and documented... it's a bit scary | 07:21 |
| keir | i'm sure it's all sensible, but it's a big black box from the outside | 07:21 |
| keir | i've even read lots of the docs and hacked the code! | 07:21 |
| lifeless | I think that data structures come and go to | 07:21 |
| lifeless | *too* | 07:21 |
| lifeless | there is a higher cost in changing your mind | 07:22 |
| keir | yes | 07:22 |
| spiv | That doesn't mean we shouldn't document them clearly, though :) | 07:22 |
| lifeless | but only a god can predict what the data structure needs to be at the start of a project | 07:22 |
| lifeless | right | 07:22 |
| keir | i agree | 07:22 |
| keir | but nevertheless, perhaps the lack of documenting data structures and a bigger focus on api is what helped hg become 'preferred' in some sense, because it is much faster at network and most other stuff? | 07:23 |
| lifeless | so anyhow, we have varying degrees of quality here, on different things written at different times | 07:23 |
| === keir is ranting a bit :P | ||
| lifeless | uhm | 07:23 |
| keir | please take everything i'm saying with a grain of salt | 07:23 |
| lifeless | I think being faster at network and disk is much more noticable to users :) | 07:23 |
| keir | exactly | 07:24 |
| lifeless | note that you simply cannot do most things with hg over the wire | 07:24 |
| lifeless | wire level its push/pull only | 07:24 |
| keir | but regardless, hg seems to have hit the sweet spot | 07:24 |
| lifeless | well it hit a sweet spot, for some things | 07:24 |
| lifeless | they have made compromises I consider unacceptable | 07:24 |
| lifeless | like the 'fail to notice sub-stat-size-preserving granularity changes' | 07:25 |
| lifeless | bug | 07:25 |
| keir | ok | 07:25 |
| lifeless | and the renames are always heuristics | 07:25 |
| keir | anyway, i didn't want to start a hg debate | 07:25 |
| lifeless | and these things have come about, IMNSHO, because they put performance first and everything else has been assessed against that from day one | 07:25 |
| keir | mainly i want good docs on just what is stored in .bzr | 07:26 |
| keir | at the level of abstraction exposed by the api | 07:26 |
| keir | in form that lets me reason about how it might be represented on disk | 07:26 |
| keir | i understand both what git is storing and how it's storing it | 07:27 |
| keir | and i spent faaar less time with git! | 07:27 |
| fullermd | It's just that in git you can't figure out the commands to do stuff with it ;) | 07:27 |
| lifeless | so | 07:27 |
| keir | fullermd, yes. i am not saying git is better in usability. | 07:27 |
| lifeless | http://bazaar-vcs.org/Classes/ | 07:27 |
| lifeless | this is pre-the-recent-doc-layout-change | 07:28 |
| lifeless | before we were putting all docs into the tree | 07:28 |
| lifeless | but I was working towards basically what i think you want in that wiki-space | 07:28 |
| lifeless | its most definately not enough, but if its in the right direction, please say so | 07:28 |
| keir | i want gratuitius pictures with arrows :) | 07:29 |
| keir | i might even make them | 07:29 |
| keir | if i knew what to draw | 07:29 |
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === keir reads | ||
| keir | on the WorkingTree page | 07:30 |
| keir | the part 'basis inventory' | 07:30 |
| keir | is _exactly_ what i'm looking for but in much more detail | 07:30 |
| lifeless | bbiab, need to walk in circles and think about locking | 07:31 |
| lifeless | back | 07:38 |
| keir | the 'pending merges' should be 'an ordered list of secondary parents (aka, [revid] *) to give the next commit. | 07:42 |
| keir | (also on Classes/WorkingTree) | 07:42 |
| keir | maybe i'm crazy, but i want less english and more syntax :P | 07:42 |
| keir | so the revision history for a file is a sub-graph of the revision graph, correct? | 07:43 |
| lifeless | the nodes are a subset | 07:44 |
| keir | ok | 07:44 |
| lifeless | and the edges follow the same reachablility rules | 07:44 |
| lifeless | that is if A is reachable from C in a per-file graph | 07:44 |
| lifeless | then A is reachable from C in the revision graph | 07:44 |
| keir | now, is that an implementation by-product? i'd vote to describe that | 07:44 |
| lifeless | so the file graph is C:[A] | 07:44 |
| lifeless | but the rev graph is | 07:45 |
| lifeless | C:[B] , B:[A] | 07:45 |
| lifeless | this is a model, its part of the interface | 07:45 |
| keir | ok | 07:45 |
| lifeless | how you store/if you store is implementation | 07:45 |
| keir | yes, of course | 07:45 |
| keir | great | 07:45 |
| lifeless | theres a proof of this I sent to the mailing list a few weeks back FWIW | 07:46 |
| keir | seen this: http://eagain.net/articles/git-for-computer-scientists/ ? | 07:46 |
| lifeless | no browser handy sorrry | 07:49 |
| keir | vt100 got you down? | 07:49 |
| keir | :P | 07:49 |
| lifeless | no, the mozilla tree doe | 07:50 |
| lifeless | s | 07:50 |
| lifeless | 550MB of source | 07:50 |
| keir | oh wow | 07:50 |
| lifeless | its what I profile with | 07:50 |
| lifeless | smaller trees are too quick, not enough granularity from the profiler | 07:50 |
| lifeless | :) | 07:50 |
| fullermd | You probably have. It's the usual "there are blobs, and there are things that point at blobs, and things that point at things that point at blobs, and..." git exposiiton. | 07:50 |
| lifeless | righto | 07:51 |
| lifeless | 'I have a database thanks bye' | 07:51 |
| keir | gitkthxbye! | 07:51 |
| lifeless | poolie: patch has hit the list now; evo was retarted on me | 07:51 |
| === lilr0bbie [n=lilr0bbi@c58-107-243-71.sunsh7.vic.optusnet.com.au] has joined #bzr | ||
| lilr0bbie | hello | 07:52 |
| lifeless | what does everyone think about replacing 'knitrepo.py' with 'knits.py' and 'weaverepo.py' with 'weaves.py' | 07:52 |
| lifeless | spiv: oh, and ping, can we chat on the phone about lock tokens and packs ? | 07:52 |
| lilr0bbie | umm.. i was wondering if anyone could help me with problems using bzr on an ntfs fuse-mounted system? | 07:53 |
| lifeless | fullermd: this ones for you | 07:53 |
| spiv | lifeless: sure, just a sec | 07:53 |
| fullermd | Eek. | 07:53 |
| keir | what does a revision have in it | 07:53 |
| fullermd | lilr0bbie: Attribute changes? | 07:53 |
| keir | a list of parents; a list of chaged files (as fileid's? what's a fileid?) | 07:54 |
| lilr0bbie | fullermd: thats the one | 07:54 |
| lifeless | keir: parents, properties, commit message | 07:54 |
| lilr0bbie | fullermd: i have searched for solutions using google but none unfortunately | 07:54 |
| fullermd | Oh good. I identified the problem, now somebody else can handle the solution side :) | 07:54 |
| lilr0bbie | fullermd: argh lol... i am fearing atm that there is none... | 07:54 |
| spiv | lifeless: I'm probably about +0 on that file renaming, fwiw. | 07:55 |
| fullermd | I'm not sure there is one, actually. If all the files in the branch have the same (all +x or all -x), you might be able to change mount options to make it work right... | 07:55 |
| lilr0bbie | fullermd: I will try that... | 07:55 |
| fullermd | Another option would be to use the branch part of that branch (the VCS data), but use a working tree somewhere else and not touch the NTFS-mounted WT. | 07:56 |
| keir | lifeless, http://bazaar-vcs.org/DataStructures | 07:57 |
| keir | is the revision ID included in the revision also? as in the sequential numberings | 08:00 |
| fullermd | revno you mean (not revid). I don't think that's "included" anyway, just derived whenever; it's not consistent for the rev, so... | 08:00 |
| keir | ok | 08:01 |
| keir | so how are the changed files in a particular revision modeled? | 08:01 |
| keir | if a revision only has parents, properties, and a commit message | 08:02 |
| === keir drops a pin | ||
| lifeless | you do a diff between inventorie | 08:09 |
| lifeless | inventories | 08:09 |
| lifeless | for a revision id X, there is an inventory X | 08:09 |
| lifeless | the 'changes in X' really is code for 'the delta from X.parents[0] to X' | 08:09 |
| keir | aah | 08:11 |
| keir | so what's in an inventory? | 08:12 |
| keir | snapshots of file contents? | 08:12 |
| keir | *ducks* | 08:12 |
| lifeless | inventories map paths to fileid:content_version | 08:17 |
| lifeless | e.g. /foo -> 'foo_id':revisionid | 08:17 |
| lifeless | also they hold some inline things like the execute bit, symlink targets | 08:17 |
| lilr0bbie | fullermd: i found a way to make it work. I need to force the ntfs drive to mount with full permissions (i.e., fmask=0,dmask=0) in order to allow this to work, then it seems to "ignore" the fact that it can't set the permissions properly | 08:17 |
| lifeless | 'foo_id':revisionid there, is the key used in the .tix indices to retrieve texts | 08:17 |
| keir | fileid:content_version is like (fileid, revid) | 08:18 |
| lifeless | yes, I'm just changing syntax to confuse you | 08:18 |
| keir | lifeless, http://bazaar-vcs.org/DataStructures | 08:19 |
| keir | you can see where i'm going | 08:19 |
| lifeless | no browser ? | 08:20 |
| lifeless | lol | 08:20 |
| keir | so the inventory split is exposed at the API level? | 08:20 |
| keir | lynx is sufficient | 08:20 |
| keir | links rather | 08:20 |
| lifeless | what do you mean 'split' ? | 08:20 |
| keir | inventory / revision | 08:20 |
| lifeless | yes | 08:20 |
| keir | i have to run :( i'll come back and chat about this later | 08:20 |
| lifeless | revision objects are git commit objects | 08:20 |
| keir | but i want to fill out this document | 08:21 |
| lifeless | inventory objects are hg manifests | 08:21 |
| lifeless | roughly | 08:21 |
| lifeless | hmm | 08:27 |
| lifeless | do we have a handy three-way-diff-of-arbitrary-sequences? | 08:28 |
| lifeless | 3merge I mean | 08:28 |
| === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr | ||
| === herzel104 [i=herzel@gateway/tor/x-d0b2a37c4659c381] has joined #bzr | ||
| poolie | keir, can you please turn that wiki page into a doc patch at some point? | 08:42 |
| === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr | ||
| === cfbolz [n=cfbolz@p54AB80E9.dip0.t-ipconnect.de] has joined #bzr | ||
| mwhudson | lifeless: pong? | 09:29 |
| fullermd | Great, look what you did... | 09:33 |
| mwhudson | tee hee! | 09:34 |
| === Mez is now known as Mez|Away | ||
| === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| === RichardL [n=Skippy@78.32.35.169] has joined #bzr | ||
| === smartGPX [n=smartGPX@84-12-25-202.dyn.gotadsl.co.uk] has joined #bzr | ||
| === i386 [n=james@ppp239-169.static.internode.on.net] has joined #bzr | ||
| === mvo [n=egon@p54A6459C.dip.t-dialin.net] has joined #bzr | ||
| === mhagger [n=mhagger@ssh.berlin.jpk.com] has joined #bzr | ||
| === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr | ||
| === smartgpx [n=smartgpx@pc585.cc.le.ac.uk] has joined #bzr | ||
| smartgpx | Good morning. Is it appropriate to seek help with a 'broken' branch here? | 11:03 |
| === Mez|Away is now known as Mez | ||
| quicksilver | definitely | 11:13 |
| quicksilver | although I'm not the person who can help you :( | 11:13 |
| smartgpx | Running bzr v091 on winXP. I have a simple 'personal branch' [bzr-versioned working tree] that cannot be copied/cloned with the 'bzr branch' command. Fails with bzr: ERROR: Unable to delete transform temporary directory. | 11:34 |
| === bac [n=bac@canonical/launchpad/bac] has joined #bzr | ||
| === mvo [n=egon@p54A6459C.dip.t-dialin.net] has joined #bzr | ||
| smartgpx | The destination working tree is not populated. There are 4 files in limbo, but far more than this in the source tree. | 11:37 |
| quicksilver | hmm | 11:45 |
| quicksilver | have you always used it on winXP? | 11:45 |
| quicksilver | or was it ever on another OS ? | 11:45 |
| fullermd | I think that's come up before. Case-related, maybe? Dig around the list archives (I don't know anything beyond a vague memory of it being discussed before) | 11:46 |
| quicksilver | yeah, that's what I was probing at with other OSes | 11:50 |
| quicksilver | if you have two files identical other than case, OSX and XP will get very confused | 11:51 |
| quicksilver | (we have lots of OSX machines runnin bzr here) | 11:51 |
| === APXAHGEJI [n=user@wn2nat53.beelinegprs.ru] has joined #bzr | ||
| === APXAHGEJI [n=user@wn2nat53.beelinegprs.ru] has left #bzr [] | ||
| smartgpx | The branch has only resided on one machine. OS has been Win XP throughout. Branch +working tree was originally developed during 4Q06 using bzr at about v0.10. | 12:10 |
| smartgpx | Recently moved bzr to v091 and I think I was prompted to upgrade the branch? Might that have introduced a problem? | 12:11 |
| === bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr | ||
| quicksilver | can you clone old versions? | 12:24 |
| quicksilver | bzr branch -rXYZ foo new-foo | 12:24 |
| quicksilver | try for a few different revisions, from very old to quite recent | 12:24 |
| smartgpx | ' | 12:28 |
| smartgpx | "bzr branch -rXYZ foo new-foo" Interesting tip - I'll give it a try next time I'm at that machine. Thanks for now. DJ | 12:29 |
| === nir [n=nir@moinmoin/fan/nir] has joined #bzr | ||
| === mhagger is now known as mhagger-afk | ||
| metze | hi * | 01:24 |
| metze | how can I disable the process bar on bzr 0.8.2? | 01:25 |
| === mhagger-afk is now known as mhagger | ||
| === mhagger [n=mhagger@ssh.berlin.jpk.com] has left #bzr [] | ||
| === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| Peng | There were progress bars in 0.8.2? I would've thought they were newer. | 01:49 |
| === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr | ||
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| === mrevell is now known as mrevell-lunch | ||
| === niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br] has joined #bzr | ||
| === mwhudson_ [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr | ||
| === quicksilver [n=jules@212.69.38.59] has joined #bzr | ||
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| === luks [n=lukas@unaffiliated/luks] has joined #bzr | ||
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| === fbond [n=fab@pool-71-169-154-64.burl.east.verizon.net] has joined #bzr | ||
| vila | jam-laptop: pong (finally) | 02:43 |
| === mrevell-lunch is now known as mrevell | ||
| === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| === smartgpx [n=smartgpx@pc585.cc.le.ac.uk] has joined #bzr | ||
| === metze is now known as metze_away | ||
| === metze_away is now known as metze_asleep | ||
| === orospakr [n=orospakr@bas4-ottawa23-1177612037.dsl.bell.ca] has joined #bzr | ||
| smartgpx | FAO: quicksilver Re: 'broken' branch. I think you were right about it being a case-differentiation problem. | 03:43 |
| jam-laptop | morning vila | 03:43 |
| vila | jam-laptop: morning ! How are you and how goes the family ? | 03:43 |
| jam-laptop | all in all, things are going well | 03:44 |
| smartgpx | The first commit after the last one that will unpack correctly has this - amongst other changes: | 03:44 |
| jam-laptop | we aren't completely exhausted all the time :) | 03:44 |
| jam-laptop | I had a quick question for you on the new ConfigObj | 03:44 |
| vila | hehe, I know that :) | 03:44 |
| vila | seen the new bug ? | 03:44 |
| jam-laptop | I believe I'm seeing it have cycles (and thus not get properly garbage collected) | 03:44 |
| jam-laptop | vila: bug 151208? | 03:45 |
| ubotu | Launchpad bug 151208 in bzr "util/configobj should be deleted" [Undecided,New] https://launchpad.net/bugs/151208 | 03:45 |
| smartgpx | " removed: ReadFile.FEC - added: ReadFile.fec" | 03:45 |
| jam-laptop | I was just wondering if the new version did anything about that. (I'm guessing not) | 03:45 |
| vila | yes, still want a more detailed summary ? I can re-read the web page, but I think if you want more details than "it passes the test suite" you can... wait... you're searching a bug fix for your gc pr isn't it ? | 03:46 |
| === vila still can't read while typing ;-) | ||
| vila | I doubt it does, but I can double-check, but if you can reproduce your pb, just download the latests version and install it it's only one file, no zip no nothing | 03:48 |
| vila | seems the quickest and best check to me | 03:48 |
| smartgpx | If that really is the cause of the problem (which new readers might like to know is "bzr: ERROR: Unable to delete transform temporary directory ..../.bzr/checkout/limbo. - then is there a way to unravel the problem retrospectively? | 03:49 |
| jam-laptop | k | 03:52 |
| jam-laptop | I figured a quick check with you would be good :) | 03:52 |
| jam-laptop | I doubt it is the overall problem | 03:52 |
| jam-laptop | just something I encountered | 03:52 |
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| vila | jam-laptop: just re-read http://www.voidspace.org.uk/python/configobj.html#version-4-4-0 until version 4.2.0, nothing catches the eye | 03:53 |
| jam-laptop | np | 03:54 |
| === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| smartgpx | The only other instance of "Unable to delete transform temporary directory" in the Launchpad buglist is 137681. This is also a bzr v0.91 report. Might this be a new issue at v.091? | 04:04 |
| === bialix [n=chatzill@77.109.17.231] has joined #bzr | ||
| === NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr | ||
| === JWK [n=jwk@ip-159-113.sn2.eutelia.it] has joined #bzr | ||
| JWK | hello all | 04:18 |
| JWK | I was wondering....where can I find some sort of tutorial on bzrlib internals? | 04:19 |
| bialix | you mean: how to use bzr from python? or how to hacking bzr in python? | 04:19 |
| === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr | ||
| JWK | use bzr from python, to embed repository fetch/update/commit/branch features in my app | 04:21 |
| bialix | http://bazaar-vcs.org/Integrating_with_Bazaar | 04:22 |
| bialix | it's a little tutorial you want | 04:23 |
| bialix | then probably try to read bzrlib/builtins.py source code: it contains implementation for almost all commands | 04:23 |
| JWK | erm...I'd rather not use a working tree, but modify the repository directly | 04:24 |
| JWK | that doc reports: "Manipulating the Repository Directly => TBD (by someone else who knows what their doing)" | 04:24 |
| JWK | :-) | 04:24 |
| bialix | you cannot commit without working tree | 04:32 |
| bialix | but you can create new revisions | 04:32 |
| bialix | for fetch/update/branch -- you need to use branch API | 04:33 |
| JWK | hmm | 04:33 |
| bialix | good example of branch/repo manipulations is probably repo-push plugin | 04:33 |
| bialix | (may be and not so good and slightly outdated, but it works for me) | 04:34 |
| bialix | repository in the end is just big storage | 04:34 |
| JWK | can I use branch api without a working tree? | 04:35 |
| bialix | repository without branch is a but useless thing | 04:35 |
| bialix | JWK: yes, you can | 04:35 |
| bialix | because bzr have idea of treless branches | 04:35 |
| bialix | has^ | 04:35 |
| bialix | treeless branch -- branch w/o working tree | 04:36 |
| JWK | ok...so repository and branch modules should do | 04:36 |
| bialix | yes | 04:36 |
| JWK | If I need to add a new revision to a repository, I don't neew a wt either, right? | 04:38 |
| bialix | I'm not sure about commit though, but I think some plugin (e.g. conversion from CVS to bzr) is use direct commit of revisions in repo without creating real wt | 04:38 |
| bialix | if we think about commit as 2-step process: gather changes in tree, and then commit it | 04:39 |
| JWK | thanks...that's the kind of hint I was looking for :-) | 04:39 |
| bialix | then yes -- second step should not be heavily rely on wt | 04:39 |
| bialix | actually bzrlib/commit.py | 04:40 |
| bialix | contains logic to create new revisions | 04:43 |
| JWK | it appears that the core part is actually called CommitBuilder and is provided by repository.py itself | 04:48 |
| jam-laptop | bialix, JWK: You might be able to use CommitBuilder directly, but I'm pretty sure bzrlib/commit.py is fairly committed to using something on disk. | 04:54 |
| jam-laptop | Though maybe that is just through the Inventory layer... | 04:54 |
| jam-laptop | cvsps-import goes a different route... but wait | 04:54 |
| jam-laptop | it does use CommitBuilder, IIRC | 04:54 |
| === p4tux [n=p4tux@189.169.95.23] has joined #bzr | ||
| jam-laptop | igc: ping | 05:04 |
| jam-laptop | Are you still awake? | 05:04 |
| bialix | /me still awake | 05:06 |
| bialix | /me ? | 05:07 |
| jam-laptop | bialix: I never did respond to your ping yesterday, is there still something you need a response one? | 05:07 |
| jam-laptop | (on) | 05:07 |
| jam-laptop | I was wondering if igc was around | 05:07 |
| bialix | I understand | 05:07 |
| bialix | I'm working on fixing bug 129298 | 05:08 |
| ubotu | Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress] https://launchpad.net/bugs/129298 | 05:08 |
| bialix | my new code is bzr.exe-specific | 05:09 |
| bialix | have no Idea how to test it. and whether I should test it | 05:09 |
| tetron | why is bzr branching so damn slow? even with the smart server, it takes orders of magnitude longer to checkout a branch with only one (!) revision than it does to download a tarball | 05:11 |
| keir | tetron, we know, it's being fixed | 05:12 |
| keir | tetron, the problem is the current repository format requires two roundtrips per file | 05:12 |
| tetron | that's gross | 05:12 |
| keir | hopefully 0.92 will have packs (like git packs) | 05:12 |
| keir | tetron, i know, i was shocked when i learned that too. | 05:12 |
| jam-laptop | bialix: you are trying to create a 'plugins' directory somewhere on disk after the installer finishes? | 05:13 |
| tetron | I thought the whole point of the smart server is it asks for "everything from version X to version Y" and the server bundles it all up into one big compressed chunk and sends it all at once.. | 05:13 |
| keir | packs are 50% of rsync speed or sometimes better | 05:13 |
| tetron | that would be nice | 05:13 |
| jam-laptop | bialix: I would tend to focus on testing the functions you are using do what you want them to, and not worry too much about it happening after the installer runs | 05:13 |
| keir | tetron, sadly no. i actually wrote a plugin to do that aaages ago | 05:13 |
| tetron | keir: I've had to go through various contortious involving cron jobs that create tarballs to get around bzr checkout slowness | 05:14 |
| keir | tetron, have you tried the newer versions? it's gotten faster lately. | 05:14 |
| tetron | crap, I'm still using 0.18 | 05:15 |
| tetron | I thought I had upgraded on this box | 05:15 |
| keir | network stuff is still slow though :( | 05:15 |
| tetron | well, it's frustrating, I've been using bzr for a year and performance improvements have always been "right around the corner" | 05:17 |
| tetron | and maybe other stuff has gotten faster, but the checkout speeds are just embarassing, and that's probably driving a lot of people away from bzr | 05:17 |
| keir | tetron, i completely agree | 05:18 |
| keir | tetron, i came to bzr because of usability, launchpad integration, and the commitment to testing | 05:19 |
| tetron | actually, I know for a fact that it's driving people away from bzr, I know one project that switched away from CVS a couple months ago and they went with Hg on the basis of performance | 05:19 |
| keir | yeah | 05:19 |
| tetron | although Hg is a pain in the butt to use in other ways that bzr isn't | 05:20 |
| === bialix [n=chatzill@77.109.17.231] has joined #bzr | ||
| tetron | which is why I prefer bzr | 05:20 |
| keir | i still put bzr being baked at 1 year | 05:20 |
| keir | packs will help tons | 05:20 |
| tetron | yes | 05:20 |
| tetron | it sounds like it | 05:21 |
| bialix | jam-laptop: actually creating a directory without support inside bzrlib is worth nothing | 05:21 |
| bialix | so I modify default plugins path for bzr.exe | 05:21 |
| jam-laptop | well, moreso than packs will be getting spiv's streaming work merged into 0.92 | 05:23 |
| jam-laptop | Getting it *right* is actually pretty difficult | 05:23 |
| jam-laptop | bialix: well, that is why I say somewhere on disk | 05:24 |
| keir | streaming? | 05:24 |
| jam-laptop | since "inside bzrlib" means that it will be inside the zip file | 05:24 |
| jam-laptop | keir: the basic "give me everything for these revisions/everything in the ancestry of this one" | 05:24 |
| jam-laptop | The problem is making sure that you properly get everything | 05:24 |
| jam-laptop | associated with the fact that when you do "bzr branch" we ignore unreferenced revisions | 05:24 |
| jam-laptop | And handling shared repositories | 05:24 |
| jam-laptop | standalone branches | 05:24 |
| jam-laptop | etc | 05:24 |
| keir | yes | 05:25 |
| jam-laptop | Anyway, I think Andrew has actually done all the work to get there | 05:25 |
| jam-laptop | and I thought we wanted to land it this week | 05:25 |
| jam-laptop | But I know he got caught up in some specific details | 05:25 |
| keir | jam-laptop, do you have a sec to help me get the rest of the data structures into this doc: http://bazaar-vcs.org/DataStructures | 05:25 |
| jam-laptop | where we were recording 2 things slightly differently | 05:25 |
| bialix | jam-laptop: sorry for my english, but you misunderstand me | 05:25 |
| keir | jam-laptop, i'm trying to make a doc which is 'the data model as exposed by the bzr api' | 05:26 |
| jam-laptop | keir: how much do you want the "logic" versus what the disk is? | 05:26 |
| keir | jam-laptop, i want the data model | 05:26 |
| jam-laptop | Or I guess what the current api is | 05:26 |
| keir | jam-laptop, but implementation is relevant | 05:27 |
| keir | i don't care about the api at all really | 05:27 |
| keir | the api is just a way to access / manipulate things in some model of the data in .bzr | 05:27 |
| keir | what is that model? | 05:27 |
| keir | it's not clearly and concisely described anywhere | 05:27 |
| keir | hg and git both have very nice docs on this | 05:27 |
| keir | and bzr not having this has been a barrier for me on contributing | 05:27 |
| bialix | the main idea of that bug is not to have directory 'plugins' somewhere on disk, but IMO have proper support of installing and loading plugins from there | 05:28 |
| bialix | so I change a bit plugins.py: get_default_plugin_path() should return 2 directory for bzr.exe instead of one | 05:29 |
| jam-laptop | keir: care to point me to one of those references so that I have a better idea of what you are thinking | 05:29 |
| jam-laptop | bialix: you *could* look at "sys.frozen" | 05:30 |
| keir | jam-laptop, git for computer scientists | 05:30 |
| jam-laptop | and then have a test | 05:30 |
| keir | http://eagain.net/articles/git-for-computer-scientists/ | 05:30 |
| jam-laptop | such that if X is True, I get paths A and B | 05:30 |
| jam-laptop | if X is false, I get just path A | 05:30 |
| jam-laptop | And then the normal caller will use 'sys.frozen' as X | 05:30 |
| bialix | jam-laptop: I'm indeed look at sys.frozen. I tried to ask you opinion whether I should write a test for this complicated bzr.exe-only stuff | 05:30 |
| keir | for hg: http://www.selenic.com/mercurial/wiki/index.cgi/Design | 05:31 |
| bialix | jam-laptop: I'm feeling unhappy to write 20-100 lines test for 2-lines change | 05:31 |
| jam-laptop | bialix: I understand, but as a maintainer it means you don't have to worry about me breaking it in the future | 05:32 |
| jam-laptop | I don't think it has to be a huge amount of testing | 05:32 |
| keir | jam-laptop, i want to start with a very concise overview of the data model (which should be detailed enough that I could write a SQL schema for it), then have a couple examples of real dat | 05:32 |
| jam-laptop | keir: do you mind if I write up an overview in ReST on that same page, and then ask you to fill it in? | 05:33 |
| keir | jam-laptop, not at all | 05:33 |
| jam-laptop | if it is in ReST, then we will likely pull it into the core docs | 05:33 |
| keir | jam-laptop, i plan on making it ReST anyway | 05:33 |
| jam-laptop | rather than in Wiki | 05:33 |
| keir | jam-laptop, and putting it in core docs | 05:33 |
| bialix | jam-laptop: actually about this special test: it's never will be run on PQM, so I can't use it for automatic regression testing, otherwise I need very complicated fixture for test, and selftest anyway does not pass on win32 -- and this makes me unhappy about testing | 05:33 |
| keir | jam-laptop, i wanted to show people what i was working on | 05:33 |
| bialix | keir: you could use ReST in our wiki | 05:34 |
| keir | bialix, oh, news to me! | 05:34 |
| jam-laptop | bialix: you can write a test that function "get_plugin_paths(is_frozen)" returns different values when 'is_frozen' is true versus fals | 05:34 |
| jam-laptop | false | 05:34 |
| keir | jam-laptop, just add the rough content, i'll deal with making it nice and expanding | 05:34 |
| bialix | just add at the start of document line #! format rst | 05:34 |
| jam-laptop | keir: you start with a "#FORMAT rst" | 05:34 |
| jam-laptop | but I'll do that | 05:34 |
| keir | jam-laptop, should we bother with the wiki? i'd rather put it in core docs | 05:35 |
| keir | jam-laptop, and link prominently to it in HACKING | 05:36 |
| jam-laptop | keir: well, it is easier to collaborate between you and I on the Wiki | 05:36 |
| keir | jam-laptop, sure | 05:36 |
| jam-laptop | and then when we get it worked out | 05:36 |
| jam-laptop | move it | 05:36 |
| keir | jam-laptop, great | 05:36 |
| bialix | keir, err sorry, jam is right | 05:36 |
| bialix | here example: http://bazaar-vcs.org/Talks?action=raw | 05:36 |
| bialix | /me brain damaged by shebang | 05:37 |
| keir | tetron, what parts of hg do you dislike? | 05:42 |
| tetron | keir: the thing that annoys me the most is when doing a merge and there are conflicts, hg insists on popping up a merge window for every conflict, in order, with no way to go back or forward or just tell it to shut up and mark the files as conflicted like every other reasonable VCS | 05:44 |
| keir | tetron, oh, that would be annoying | 05:45 |
| bialix | keir: iiuc it play very terrible when you're on windows, because hg need some diff3/merge3 program | 05:46 |
| tetron | yup, it's obnoxious like that | 05:47 |
| tetron | it has a concept of multiple "heads" in a branch, which is usually just used for merging but it's possible to have them be named and distinct, which can cause chaos if somehow you branch off from someone and change the name, and then try to merge back later | 05:48 |
| tetron | the hg logs are flat, they don't show branch merges as distinct changesets the way bzr does | 05:49 |
| === BasicOSX [n=BasicOSX@errant.real-time.com] has joined #bzr | ||
| keir | is there a way to specify what bzr to run when doing bzr+ssh? the default path bzr+ssh uses gets the wrong one on my machine | 05:51 |
| jam-laptop | keir: try looking at it | 05:51 |
| jam-laptop | I don't have a lot more time right now, but it should give you a start | 05:51 |
| bialix | jam-laptop: thanks for suggestion. I think it's time to a some refactoring in plugins.py | 05:51 |
| jam-laptop | keir: The env var BZR_REMOTE_PATH | 05:51 |
| keir | jam-laptop, aah, cool. | 05:51 |
| keir | jam-laptop, but it's different for every host... | 05:51 |
| jam-laptop | keir: I think Aaron has a patch pending to allow you to set it in ~/.bazaar/locations.conf | 05:51 |
| jam-laptop | I'm not sure if that has been merged or not | 05:51 |
| jam-laptop | bbiab | 05:52 |
| bialix | keir, keir, Aaron's path is already merged | 05:53 |
| bialix | patch^ | 05:53 |
| keir | jam-laptop, this is going in a different direction than what i want. i literally want a bulleted-list style description such that i could go and write a SQL schema | 05:53 |
| keir | jam-laptop, i'll hack on it | 05:53 |
| === abentley [n=abentley@bas2-toronto02-1279462552.dsl.bell.ca] has joined #bzr | ||
| keir | hi aaron | 06:07 |
| keir | did your patch to allow setting BZR_REMOTE_PATH per-host in locations.conf get merged? | 06:07 |
| keir | abentley, nevermind bialix answered but i missed his response. | 06:19 |
| === bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| keir | in an InventoryEntry, what type is a 'parent_id'? | 06:23 |
| keir | is it a Revision ID? | 06:23 |
| keir | or a (fileid, revisionid) tuple? (aka another inventoryentry) | 06:24 |
| luks | file_id | 06:24 |
| === p4tux [n=p4tux@189.169.95.23] has joined #bzr | ||
| keir | and 'name' is just filename relative to the inventory root? | 06:25 |
| luks | to the parent | 06:25 |
| keir | what is the type of 'parent'? | 06:25 |
| luks | ehm, parent is the parent id, no? | 06:26 |
| luks | which is a fileid | 06:26 |
| keir | ok | 06:26 |
| keir | so why is name even necessary? | 06:26 |
| luks | to construct the full path | 06:26 |
| keir | so this 'name' entry is there for the strong renaming support? | 06:27 |
| luks | e.g. (1, 'foo', 0), (2, 'bar', 1) -> 'foo/bzr' | 06:27 |
| keir | and generally the 'name' field will be exactly the same 'myfile.txt' for ever rev, if it's not renamed? | 06:27 |
| luks | yes, but fileid is used in all internal operations | 06:27 |
| luks | if you rename a file, it will still have the same inventory entry | 06:28 |
| keir | yes | 06:28 |
| keir | ok | 06:28 |
| luks | heh, I just noticed I typed 'foo/bzr' instead of 'foo/bar' above :) | 06:28 |
| keir | :) | 06:29 |
| keir | in your above example you had (fileid, name, parent_file_id), right? | 06:29 |
| luks | yes | 06:29 |
| keir | ok. and in this case, parent is strictly relating to _directories_ and not revision history? | 06:30 |
| luks | yes | 06:31 |
| keir | damn. calling it parent_id is madly confusing | 06:31 |
| luks | well, calling it parent_id is very usual in databases | 06:31 |
| keir | because in revisions the 'parents' are relating to revisions | 06:31 |
| luks | to make a tree in flat DB | 06:31 |
| keir | right | 06:31 |
| keir | the SHA1 hash is a hash of the fulltext of that particular fileid,rev? | 06:33 |
| keir | or is it a hash of the delta? | 06:33 |
| luks | of the fulltext | 06:34 |
| luks | but generally, inventory can't know much about deltas | 06:35 |
| keir | interesting | 06:36 |
| keir | what is in Revision.parent_sha1s | 06:39 |
| === mvo_ [n=egon@p54A65DA6.dip.t-dialin.net] has joined #bzr | ||
| keir | obviously they are sha1's, but it's not clear what the 'sha1' of a parent is | 06:42 |
| keir | is it a sha1 of the textual representation of the parent revision? | 06:42 |
| luks | not sure about that | 06:42 |
| jam-laptop | keir: I'm pretty sure that is unused at the moment | 06:43 |
| keir | jam-laptop, yes, i just noticed that | 06:43 |
| jam-laptop | At 1 point references were (revision_id, sha1) tuples | 06:43 |
| jam-laptop | But that was a long time ags | 06:43 |
| jam-laptop | ago | 06:43 |
| keir | jam-laptop, refresh that page and see revision and inventory section | 06:43 |
| keir | jam-laptop, i am specifically not wanting paragraph-style descriptions because it is harder to digest | 06:44 |
| keir | so if you do bzr diff -r1:2 | 06:45 |
| keir | how is the inventory used? | 06:45 |
| keir | is the inventory linerally scanned to find (fileid,revid) tuples with the rigth fileid? | 06:45 |
| luks | it takes the inventory for r1 and r2 and checks the differences | 06:45 |
| === poolfool [n=poolfool@techsat21.itnes.com] has joined #bzr | ||
| luks | then it takes fulltexts for r1 and r2 or each modified file, and prints the diff | 06:46 |
| keir | so this is fast if it's sorted on revid | 06:46 |
| luks | keir: there is only one revision of a file in inventory | 06:46 |
| luks | so there is no need to find fileid,revid tuples | 06:46 |
| keir | i'm confused then | 06:47 |
| luks | inventory is a versioned file | 06:47 |
| keir | so there's one inventory per file? | 06:47 |
| luks | no | 06:47 |
| luks | one per repository | 06:47 |
| keir | if an inventory is a big list of (fileid,revid,metadata) | 06:47 |
| luks | but the content changes for every revision | 06:47 |
| keir | then for one rev, there will be many fileid's | 06:48 |
| keir | so if you sort by rev, you get all your relevant fileids in one spot | 06:48 |
| luks | it's more a dict fileid->metadata | 06:48 |
| keir | so you can go fileid-> complete revgraph for that file | 06:48 |
| keir | ? | 06:48 |
| luks | inventory is a snapshot of the tree at given revision | 06:49 |
| luks | there is always only one version of each entry in it (the most recent version) | 06:49 |
| keir | wait. so there's only one inventory per revision? | 06:49 |
| luks | not sure what do you mean by 'per revision' | 06:50 |
| keir | if i do a commit, is there a new, standalone inventory generated | 06:50 |
| luks | yes | 06:50 |
| keir | and there is an inventory per-file? | 06:50 |
| keir | sorry | 06:50 |
| keir | a new inventory file per rev? | 06:51 |
| luks | it's not really a file | 06:51 |
| luks | the inventory knit contains all the inventories | 06:51 |
| keir | so a repository has many inventories? | 06:51 |
| luks | you confuse me :) | 06:52 |
| keir | bzr confuses me! | 06:52 |
| luks | think of it like of a regular file in your branch | 06:52 |
| keir | ok | 06:52 |
| luks | if you commit, bzr will generate a new snapshow of inventory and store it in the inventory knit file | 06:52 |
| keir | so there's a 1-1 mapping revision to inventory | 06:52 |
| === dpm [n=dpm@p54A13505.dip0.t-ipconnect.de] has joined #bzr | ||
| luks | so there is only one inventory knit per repository | 06:53 |
| luks | but the knit contains also historical inventories | 06:53 |
| luks | keir: basically yes | 06:53 |
| keir | ok | 06:54 |
| keir | i was confused about that | 06:54 |
| keir | what i didn't understand is why bother storing the revision for each fileid in an inventory | 06:54 |
| keir | shouldn't an inventory have a _single_ revision ID and then every file inside has an implied revision id from the inventory? | 06:54 |
| keir | the description i've been hearing is that an inventory is a list of (fileid, revid, metadata) | 06:55 |
| keir | repeated per file changed in this revision | 06:55 |
| luks | you usually modify only some files in a commit | 06:55 |
| keir | sure | 06:55 |
| keir | ooh | 06:55 |
| keir | i see | 06:55 |
| luks | so most of the inventory entries wont even change | 06:55 |
| keir | so all that delta info gets duped? | 06:56 |
| keir | per rev? | 06:56 |
| keir | if it isn't changed? | 06:56 |
| keir | i.e. the (fileid, revid, metadata) in an inventory for rev 10 where that file wasn't changed since rev 5, will contain the same (fileid,revid,metadata) as in rev 5? | 06:56 |
| luks | yes | 06:57 |
| luks | but this all is stored in a knit, so the data are not duplicated on the disk | 06:57 |
| keir | why bother listing unchanged files? | 06:57 |
| keir | ah, ok | 06:57 |
| keir | so a revision isn't really a snapshot of a tree | 06:59 |
| keir | an inventory is | 06:59 |
| luks | I think inventory is a 'snapshot of a tree' by definition | 07:00 |
| jam-laptop | keir: It might help to realize that we *logically* think of things in "fulltext" form. We happen to store a lot of them as deltas | 07:03 |
| jam-laptop | but that is handled at a lower level | 07:03 |
| jam-laptop | (It depends on the Repository format) | 07:03 |
| keir | ok | 07:03 |
| jam-laptop | We will probably undergo another change in the near future | 07:04 |
| jam-laptop | to break an inventory into many separate files on disk | 07:04 |
| jam-laptop | for performance reasons | 07:04 |
| jam-laptop | but you can still think of it as logically one big manifest | 07:04 |
| keir | i thought the inventories were going to get packed? | 07:04 |
| === asak [n=alexis@201-27-62-87.dsl.telesp.net.br] has joined #bzr | ||
| luks | packs are just masked knits :) | 07:04 |
| jam-laptop | "packed" just means storing in a single delta-compressed file | 07:05 |
| jam-laptop | logically we still work in terms of a group | 07:05 |
| jam-laptop | And when they are in packs | 07:05 |
| jam-laptop | it just means they are in several distinct chunks inside the pack | 07:05 |
| jam-laptop | rather than one big hunk | 07:05 |
| keir | so right now 1) a single file has multiple inventories 2) the inventories are not spatially coherent? | 07:06 |
| jam-laptop | keir: yes, we are moving to storing all the data for one or more revisions in one big file (a pack) | 07:06 |
| jam-laptop | keir: I'm not sure what you mean by "single file". But right now: | 07:06 |
| jam-laptop | Every revision has a unique Inventory | 07:06 |
| jam-laptop | The revision maps the exact text for every file in the tree | 07:06 |
| jam-laptop | sorry | 07:06 |
| jam-laptop | The Inventory maps the exact text for every file in the tree. | 07:07 |
| jam-laptop | At the moment, that Inventory is serialized as one big text | 07:07 |
| jam-laptop | and it is stored delta compressed just like we store file texts | 07:07 |
| jam-laptop | And we have 1 file for every file object and Inventory and Revision | 07:07 |
| jam-laptop | (knits) | 07:07 |
| jam-laptop | In the future | 07:07 |
| jam-laptop | we will be switching from 1 file per object | 07:07 |
| jam-laptop | to having file texts stored next to inventories next to revision texts | 07:08 |
| jam-laptop | We are calling that a "pack" | 07:08 |
| jam-laptop | We are *also* moving to split up the 1-big inventory text into multiple smaller texts | 07:08 |
| keir | so what's in a knit? a series of deltas? | 07:08 |
| jam-laptop | keir: deltas + occasional fulltext snapshots | 07:08 |
| keir | that seems sensible. | 07:08 |
| jam-laptop | so if you have 10,000 entries you don't have to reconstruct all of them | 07:08 |
| jam-laptop | to get the last one | 07:09 |
| jam-laptop | a Knit is similar to Hg's revlog | 07:09 |
| jam-laptop | except we delta based on ancestry | 07:09 |
| keir | and you're going to change that by 'transposing' the current per-file storage so that related diffs occur coherently in a single file? | 07:09 |
| jam-laptop | rather than just the last node in the file | 07:09 |
| jam-laptop | keir: correct | 07:09 |
| jam-laptop | There are other things we might do (change what kind of diff algorithm we use, etc, etc) | 07:09 |
| jam-laptop | But that is at a disk storage layer, which is hidden underneath the Repository abstraction | 07:10 |
| keir | yes. i suspect switching to libxdiff or xdelta will be a big space win | 07:10 |
| keir | and a branch is a big list of revisions? | 07:15 |
| keir | corresponding to a linear thread of development? | 07:15 |
| luks | branch is a pointer to the 'head' revision | 07:16 |
| luks | other info is derived from the history graph | 07:16 |
| luks | and it's linearized by going through the left-most parents | 07:17 |
| keir | ok | 07:18 |
| === n2diy [n=darryl@wlk-barre-208-103-148-45.dynamic-dialup.coretel.net] has joined #bzr | ||
| fullermd | bzr is a magic cauldron; you put your data in, let it sit for 4-6 hours, baste occasionally. Serves 3-10000. | 07:28 |
| keir | :) | 07:28 |
| keir | where are weaves described? | 07:29 |
| keir | nevermind | 07:29 |
| keir | found it | 07:29 |
| keir | so how are inventories stored now so that they don't list duplicate (fileid,revidY) for files that didn't change in revidX? | 07:31 |
| luks | the same way usuall versioned files are stored - "19:08 < jam-laptop> keir: deltas + occasional fulltext snapshots" | 07:36 |
| keir | an inventory is not text; so it is serialized then diffed'? | 07:37 |
| luks | it's xml | 07:37 |
| keir | euwwwwrrrrrrr | 07:37 |
| luks | :/ | 07:37 |
| === keir gets an icky feeling | ||
| === bialix [i=chatzill@77.109.23.170] has joined #bzr | ||
| keir | that really is unfortunate | 07:40 |
| === Vernius [n=tomger@p508AD68E.dip.t-dialin.net] has joined #bzr | ||
| keir | so packs are the same? inventories are diff'd XML? | 07:46 |
| === pbor [n=urk@host102-21-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr | ||
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| keir | so right now, to generate a diff 1) find revision id A and B 2) find corresponding inventories 3) get list of files that differ 4) hit knits for the texts and do a diff | 07:50 |
| keir | so .bzr is really just revisions, inventories, and texts? | 08:02 |
| === cbarrett [n=cbarrett@adium/cbarrett] has joined #bzr | ||
| keir | ignoring branches | 08:02 |
| fullermd | And whipped cream. Don't forget the whipped cream. | 08:02 |
| cbarrett | ahoy | 08:02 |
| mneptok | ARRR! | 08:02 |
| fullermd | Ignoring the WT too. You're talking about .bzr/repository/ it seems. | 08:03 |
| keir | :) | 08:03 |
| keir | yes | 08:03 |
| cbarrett | mneptok: nice regurg impression | 08:03 |
| keir | so a WT is just the checked out files and a pointer to the branch? | 08:03 |
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| fullermd | Status of the checked out files. What revision it's on. Pending merges. Probably other bits&pieces... | 08:08 |
| keir | ok | 08:08 |
| === danigm [n=danigm@82.159.240.59.static.user.ono.com] has joined #bzr | ||
| JWK | bbl | 08:11 |
| === JWK [n=jwk@ip-159-113.sn2.eutelia.it] has left #bzr [] | ||
| === orospakr [n=orospakr@132.213.238.4] has joined #bzr | ||
| === poolfool [n=poolfool@techsat21.itnes.com] has left #bzr [] | ||
| danigm | hi, I'm learning bzr, I'll make some projects, and I'm considering svn, bzr, and other vcs. But I don't understand bzr. When I have a branch in a server, I make a branch to my pc, and work on it, and then merge and push it. It's a correct use of that? | 08:13 |
| Peng | danigm: Yes? | 08:19 |
| Peng | danigm: That's the same as all over the other distributed VCSes. | 08:20 |
| keir | danigm, you work (hack/commit/hack/commit/hack/...) then merge (gets new changes from server that happened inbetween) then push | 08:20 |
| Peng | You won't necessarily need to merge. | 08:20 |
| fullermd | Yes, it's _a_ correct use. The problem (and the great thing) is that DVCS's support a large number of possible workflows, so the 'correct' one is pretty situation-dependant. | 08:21 |
| danigm | if you don't merge, you can't push | 08:21 |
| Peng | danigm: If there are no new changes on the server, you don't need to merge. | 08:21 |
| cbarrett | usually it's called a "pull" to get new changes from the server. | 08:21 |
| Peng | That too. | 08:21 |
| cbarrett | a merge is an operation to decrease the number of heads, where a head is a revision with no children. | 08:22 |
| danigm | I only use svn before, and you make commit in server directly, it's possible with bzr? | 08:22 |
| Peng | danigm: Yes. But why? | 08:22 |
| danigm | I don't know | 08:22 |
| cbarrett | danigm: why do you want to use bzr? | 08:23 |
| danigm | cbarrett: I'll make a game with some people, and I need a vcs | 08:23 |
| danigm | I'm considering put the project in launchpad | 08:24 |
| === duckx [n=Duck@tox.dyndns.org] has joined #bzr | ||
| === Ohrmann [n=Ohrmann@p57AB5E77.dip.t-dialin.net] has joined #bzr | ||
| Ohrmann | Hello i need help with a freshly installed Windows version of bzr? Can anyone help? | 08:30 |
| james_w | Ohrmann: what's the problem? I haven't used Windows bzr before, but knowing the problem is a start. | 08:36 |
| Ohrmann | Ok i used the installer and now i try to "bzr init" and i get always an error "bzr: ERROR: Unknown branch format: 'Bazaar-NG meta directory, format 1\r\n'" | 08:37 |
| Ohrmann | Oh no im an idiot. I tried to use bzr in a subdirectory of an archive. | 08:39 |
| Ohrmann | Sorry for the nois | 08:42 |
| === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr | ||
| === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr | ||
| === Demitar [n=demitar@79.136.4.233] has joined #bzr | ||
| === jelmer is now known as jelmer_ | ||
| === michelp [n=michelp@70.103.91.130] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === deadwill [n=deadwill@146037.fln.virtua.com.br] has joined #bzr | ||
| === deadwill is now known as xxxxx1 | ||
| === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr | ||
| === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr | ||
| === thumper [n=tim@222.153.133.138] has joined #bzr | ||
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === thumper [n=tim@canonical/launchpad/thumper] has joined #bzr | ||
| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #bzr | ||
| Keybuk | a question about cherry-picking ... I'm doing merge -r X-1...X, which gives me a conflict in ChangeLog (shock) | 10:59 |
| Keybuk | the odd thing is that the conflict includes far more data from the ChangeLog than what was in that single commit | 10:59 |
| mwhudson | i wonder what bzr uses for the merge base in that situation | 11:00 |
| Keybuk | am I cherry-picking the right way? | 11:00 |
| luks | I usually get better results for such situations (especially changelogs) with the weave merge | 11:00 |
| mwhudson | maybe things might become a little more obvious if you passed --show-base to merge | 11:01 |
| Keybuk | mwhudson: example? | 11:01 |
| Keybuk | I'm doing the pretty standard use-case of cherry picking commits from trunk onto a stable branch to make a new stable release | 11:02 |
| Keybuk | so say I want to take revision 726 from trunk, how would I do that? | 11:04 |
| Keybuk | luks: weave made an even worse job of it | 11:05 |
| Keybuk | it merged the entire changelog from trunk into the branch | 11:05 |
| Keybuk | without even marking a conflict | 11:06 |
| === Alien_Freak [n=sam@adsl-69-209-192-74.dsl.chcgil.ameritech.net] has joined #bzr | ||
| Alien_Freak | hey guys | 11:09 |
| === BjornT_ [n=bjorn@ip-213-190-55-148.static.b4net.lt] has joined #bzr | ||
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| keir | so in the .tix, it seems (fileid,revid) entries have two parents. one is the text delta parent (i think?) and the other is the history parents. is this right? | 11:19 |
| === CardinalFang [n=c@user-0c6ti96.cable.mindspring.com] has joined #bzr | ||
| keir | and no delta parent implies a fulltext | 11:22 |
| keir | and the same for .iix files (inventory index) | 11:22 |
| CardinalFang | Ugh. Have developers tried the web site's download instructions lately? | 11:23 |
| === CardinalFang runs $ time bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev | ||
| keir | CardinalFang, we're working on it | 11:23 |
| keir | pack repos are coming in 0.92 | 11:24 |
| CardinalFang | I know speed-ups are on the map. Maybe the native non-HTTP server is better so that newbies aren't scared off. | 11:25 |
| keir | not much, yet | 11:26 |
| keir | someone else is hacking on that | 11:26 |
| CardinalFang | keir, I'm not sure you understood. I'm saying that "bzr://" would be better than "http://" if you're trying to make a good first impression. | 11:37 |
| === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| CardinalFang | I'm new, and I'm trying to test whether bzr will be useful for my new projects. By Ubuntu box comes with "bzr", but I know it's under rapid development, so I want to see if the recent code is good enough right now. Getting its own source took 18 minutes. | 11:40 |
| keir | CardinalFang, i agree, but it's not that much faster than http yet! | 11:41 |
| CardinalFang | Oh. | 11:41 |
| fullermd | Well. [bzr+] http would work too... | 11:47 |
| === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| james_w | Keybuk: it's hard to know what the problem is without seeing the revisions and the outcome. | 11:53 |
| james_w | Keybuk: however what you have said is the normal way to approch this. | 11:53 |
| james_w | if the merge includes things that are not present with diff with the same arguments then it may indicate a bug, I'm not sure. | 11:54 |
| Keybuk | $ bzr branch -r 665 http://bazaar.launchpad.net/~keybuk/upstart/main upstart | 11:55 |
| Keybuk | $ cd upstart | 11:55 |
| Keybuk | $ bzr merge -r 725..726 http://bazaar.launchpad.net/~keybuk/upstart/main | 11:55 |
| Keybuk | compare "bzr diff ChangeLog" to "bzr diff -r 725..726 http://..." | 11:56 |
| Keybuk | the conflict includes the *entire* ChangeLog text on the main branch | 11:56 |
| Keybuk | rather than what was actually in that commit | 11:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!