| lifeless | EdWyse_Office: depends on where its happening | 00:55 |
|---|---|---|
| lifeless | EdWyse_Office: where is it happening | 00:55 |
| EdWyse_Office | on a commit | 01:01 |
| lifeless | there are two likely possibilities | 01:01 |
| spiv | Good morning. | 01:02 |
| lifeless | a) your dirstate is already damaged, so we need to replace it. | 01:02 |
| lifeless | b) you've found a new bug: congratulations. | 01:02 |
| lifeless | EdWyse_Office: what bzr version do you have? | 01:02 |
| EdWyse_Office | Not sure if that's entirely what you're asking for, but my user made a bunch of changes, and when she commits, there's a huge error message that's all about inconsitent delta. | 01:02 |
| EdWyse_Office | hehe | 01:02 |
| EdWyse_Office | thanks | 01:02 |
| EdWyse_Office | 2.0.3 | 01:03 |
| lifeless | I *think* that has the various fixes in it. Did you start with that version, or has your user been using bzr for a bit ? | 01:03 |
| EdWyse_Office | This user has been using this version since the start. | 01:04 |
| lifeless | ok | 01:06 |
| lifeless | uhm | 01:07 |
| EdWyse_Office | I'm leaning toward bug now... I've committed directories one-at-a-time and am succeeding (so far). | 01:07 |
| lifeless | if we can get a copy of the dirstate and the commit command that was failing, that would help use determine the bug | 01:07 |
| EdWyse_Office | I hate windows. (ugh) | 01:07 |
| lifeless | this would disclose file paths to the devs, but not file content. | 01:07 |
| EdWyse_Office | There's nothing you couldn't see by visiting our web site anyway.. hehe. | 01:08 |
| EdWyse_Office | well that's much better. I got it down to one file causing the problem. | 01:09 |
| EdWyse_Office | So you're asking for .bzr/branch-lock/dirstate, correct? | 01:12 |
| lifeless | .bzr/checkout/dirstate | 01:12 |
| EdWyse_Office | oops, yeah, that's what I meant. :D | 01:13 |
| EdWyse_Office | Ah, I see... so if the file in question isn't even in dirstate, that might be my problem. | 01:17 |
| lifeless | well | 01:22 |
| lifeless | you are getting an error that is opaque | 01:22 |
| lifeless | so we should fix it | 01:22 |
| lifeless | dirstate + the command that fails + a 'bzr st' -> enough data for an engineer to fix, I think. | 01:22 |
| lifeless | hi spiv | 01:28 |
| spiv | Hey lifeless. | 01:42 |
| chadrik | hi all, i've got a couple of quick questions about bzr. anyone here want to field them? | 01:52 |
| spm | chadrik: your best bet is to just ask them. if someone is willing and able to answer they will. | 02:02 |
| chadrik | i need to version control some very large files. git's loose object store is very well suited to this purpose, but i would really prefer a user-friendly dcvs written in python | 02:07 |
| mkanat | It's amazing how three people have come and asked that question today. | 02:08 |
| chadrik | mercurial is just too slow and wasteful with large files: renames cause duplicate data (and time associated with this), and delta compression wastes time. | 02:08 |
| chadrik | haha | 02:09 |
| mkanat | chadrik: bzr is also currently rather wasteful, last time I checked. | 02:09 |
| chadrik | so, i come to bzr with the hopes of finding a middle ground | 02:09 |
| mkanat | chadrik: It's something that should hopefully be improved in the future. | 02:09 |
| mkanat | chadrik: The problem that I know about right now is that bzr uses RAM in an amount somewhere between 3x and 6x the size of the largest file it deals with. | 02:10 |
| chadrik | hg has similar problems. | 02:11 |
| mkanat | I think lifeless or jam was talking about doing something about it. Or maybe it was somebody else; I forget. | 02:11 |
| chadrik | in reading through the docs, it seems that bzr is designed in such a way that it is possible to add new storage formats | 02:11 |
| chadrik | i imagine this is quite a bit of work | 02:12 |
| spiv | It is. | 02:12 |
| spiv | There's a bug about the excessive memory consumption when dealing with large files. | 02:13 |
| chadrik | but it is designed to be able to use different models? is this correct? | 02:13 |
| chadrik | so it would be feasible to implement a model designed specifically to handle large files? | 02:13 |
| spiv | The short answer is we know how to fix it, but it's a fair bit of work and not a priority for Canonical staff at the moment (our priority is making bzr handle source code really really well). | 02:14 |
| spiv | Definitely; see the bug for some discussion. | 02:14 |
| chadrik | for me, the memory thing is only part of the problem. | 02:14 |
| spiv | (I think it would be feasible to implement a format that copes well with large files with no significant penalty for smaller files) | 02:15 |
| chadrik | 90% of what i need to version control are large binary files, many over 1GB | 02:15 |
| chadrik | before i go further with this, let me ask a couple of basic questions | 02:16 |
| chadrik | does bzr currently use deltas for large files? | 02:16 |
| chadrik | spiv: where can i find the bug? | 02:17 |
| chadrik | my hope is to create a storage format like git's loose object store, but where the file/blob data is left completely unchanged. blobs in the store will be read-only, such that they can safely be hard linked or symbolically linked into the working directory | 02:27 |
| rubbs | chadrik: IIRC this is the bug you're looking for: https://bugs.launchpad.net/bzr/+bug/109114 | 02:36 |
| ubot5 | Launchpad bug 109114 in Bazaar "[master] bzr holds whole files in memory; raises MemoryError on large files (affected: 21, heat: 188)" [Medium,Confirmed] | 02:36 |
| chadrik | rubbs: thanks | 02:36 |
| rubbs | np, it could be wrong, but I think that is the onw spiv was talking about | 02:37 |
| chadrik | looking now. def looks like the one | 02:39 |
| rubbs | It's been a while since I've been involved with bzr as a project. Work and other pressing projects have taken my time, so I'm more or less out of touch. | 02:40 |
| rubbs | I lurk here so I don't get left too far behind ;) | 02:40 |
| chadrik | i've come to realize that what i need is just too specific to expect to find it natively in a dcvs. | 02:41 |
| chadrik | i guess i'll look into what is necessary to implement a new storage model | 02:41 |
| rubbs | AFAIK it's pretty hard, but it might be worth trying. The devs here would help you out I think. It could be useful for other too. | 02:43 |
| chadrik | have you heard of dulwich? it's a pure-python implementation of the git object model | 02:44 |
| chadrik | my goal would be to use it to drive the new storage model | 02:45 |
| lifeless | git has the same problem chadrik | 02:46 |
| lifeless | bzr's core is plenty sufficient to implement sharding of large files on | 02:46 |
| chadrik | lifeless: do you mean the memory consumption? | 02:47 |
| lifeless | yes | 02:47 |
| chadrik | my use case is pretty specific since i will be working almost entirely with non-mergable binary files | 02:48 |
| chadrik | effectively, i'll just be copying files into the store. i'll just need to read them in order to generate a hash | 02:49 |
| chadrik | merging is simply a matter of choosing A or B | 02:49 |
| chadrik | once the files are in the store they are made read-only. then they can be symlinked or hard linked into the working copy | 02:49 |
| chadrik | specifically, my use case is this: provide many users read-only access to large binary files on a local file system | 02:51 |
| lifeless | poolie: ring whenever | 04:43 |
| === mtaylor is now known as Trouble | ||
| === Trouble is now known as mtaylor | ||
| cpsmusic | Hi | 05:33 |
| cpsmusic | I'm new to Bazaar | 05:33 |
| cpsmusic | But I've worked with SVN | 05:33 |
| cpsmusic | I have a question | 05:33 |
| cpsmusic | I've setup up a branch of a project on Launchpad | 05:33 |
| cpsmusic | But I can't figure out how to check it out | 05:34 |
| cpsmusic | I keep getting an error msg saying | 05:34 |
| cpsmusic | bzr: ERROR: Not a branch: | 05:34 |
| parthm | cpsmusic: what is the command you are using? | 05:34 |
| cpsmusic | the branch is at | 05:35 |
| cpsmusic | lp:~cpsmusic/pencil/audio | 05:35 |
| cpsmusic | I've tried | 05:35 |
| cpsmusic | bzr branch lp:~cpsmusic/pencil/audio | 05:35 |
| cpsmusic | also | 05:35 |
| cpsmusic | bzr checkout lp:~cpsmusic/pencil/audio | 05:35 |
| parthm | cpsmusic: the branch page ( https://code.launchpad.net/~cpsmusic/pencil/audio ) says "This branch has not been pushed to yet." | 05:36 |
| cpsmusic | yep I saw that | 05:37 |
| cpsmusic | what does it mean | 05:37 |
| parthm | looks like you created the branch with the webui (?). you will need to push it up. | 05:37 |
| cpsmusic | i thought pushing was like committing changes | 05:37 |
| cpsmusic | ah | 05:37 |
| parthm | if its new content, you should be able to bzr init; and bzr push lp:~cpsmusic/pencil/audio | 05:37 |
| spiv | cpsmusic: how did you create the branch on Launchpad? Typically if you are starting a project you just "bzr init" a directory locally, make and commit some changes, then you "bzr push" to publish that branch to somewhere like launchpad. | 05:38 |
| cpsmusic | it's a branch of project that's already on Launchpad | 05:38 |
| cpsmusic | I used the web pages | 05:38 |
| spiv | Ok, if you want to make a branch of an existing project, it's just "bzr branch $existing_branch" to your local system, and when you have changes locally you want to publish, "bzr push" them somewehre | 05:39 |
| cpsmusic | I used "Register a branch" on Pencil's Code page | 05:39 |
| cpsmusic | Ah, I see | 05:40 |
| cpsmusic | I thought that once I made the branch I'd have to checkout from it. | 05:40 |
| spiv | The "Register a branch" link is an attractive nuisance for branches you are making yourself :( | 05:43 |
| spiv | You don't need to register it in advance at all, you can just push to create the branch on Launchpad. | 05:46 |
| maco | git user? | 05:47 |
| spiv | SVN, apparently. | 05:47 |
| spiv | Are you thinking it's confusing vs. how github operates? | 05:47 |
| maco | well i remember keybuk getting all upset about how git's hard to use because you have to *do things* on the remote server before pushing, unlike bzr | 05:48 |
| spiv | Ah right. | 05:50 |
| cpsmusic | the thing I found confusing was that once "Registered a branch" I thought there would be a complete branch | 05:51 |
| cpsmusic | It's actually just a placeholder until the first lot of code is pushed into it - is that right? | 05:51 |
| lifeless | yes, don't use it in fact,. | 05:52 |
| lifeless | its something we want to delete | 05:52 |
| parthm | cpsmusic: i never use the "register a branch" feature. to branch from existing project, I tend to use 'bzr branch lp:proj && hack && bzr push lp:~username/proj/branch-name' | 05:53 |
| cpsmusic | I'm new to Launchpad and Bazaar - it was the first thing I saw | 05:54 |
| cpsmusic | and I was told to make a branch there by one of Pencil's devs | 05:54 |
| lifeless | yeah | 05:54 |
| lifeless | its confusing | 05:54 |
| lifeless | thats why we want ot remove it ;) | 05:54 |
| parthm | i was going through the large file mail on the mailing list and decided to do a 'bzr mv' experiment with a 100MB file. http://pastebin.com/G5vqByFM | 05:54 |
| parthm | i was surprised to find that the mv increases the space used by the file size. is this expected? i was under the impression that files moved are meta data. | 05:55 |
| parthm | ^ s/space used/size of .bzr/ | 05:56 |
| lifeless | parthm: ? | 05:57 |
| parthm | lifeless: hi | 05:57 |
| parthm | lifeless: i was just wondering why the space usage goes up. i know bzr as first-class support for files so i thought mv would probably be some meta-data update. is that not the case? | 05:59 |
| lifeless | what do you mean by space usage goes up | 05:59 |
| fullermd | Don't commits just always store fulltexts of every file touched? | 05:59 |
| lifeless | fullermd: yes, because snapshot based. | 05:59 |
| maco | should just store a diff | 05:59 |
| spiv | lifeless: see his paste; 'du -hs .bzr' goes up | 05:59 |
| lifeless | oh | 06:00 |
| lifeless | parthm: do a bzr pack | 06:00 |
| parthm | lifeless: for a 100mb file the mv makes .bzr go from 100mb to 200mb | 06:00 |
| fullermd | Yes, but I mean physically storing fulltexts, not delta compressed 'till pack. | 06:00 |
| lifeless | fullermd: yes, exactly. | 06:00 |
| parthm | the file doesn't compress as its /dev/urandom data. | 06:00 |
| lifeless | parthm: every time a file changes we store the file under (fileid, revisionid) in our tuple space. | 06:00 |
| * parthm runs pack command. | 06:00 | |
| parthm | lifeless: i haven't changed the file. its just a mv. http://pastebin.com/G5vqByFM | 06:01 |
| spiv | lifeless: where "changes" includes metadata changes, I presume? | 06:01 |
| lifeless | yes | 06:01 |
| lifeless | spiv: a refactoring I considered, but deferred in the 2a work was to separate 'inode data' and 'content data' | 06:02 |
| parthm | lifeless: neat. pack brings the size down to 101MB again http://pastebin.com/2Gv4NFHh | 06:02 |
| lifeless | spiv: which would have made a mv an inode-data only change, and not stored a text at all; the per file graph would be more capable there etc | 06:02 |
| parthm | lifeless: thanks | 06:04 |
| lifeless | hmm | 06:05 |
| lifeless | spiv: do 'bzr help other-formats' for me | 06:06 |
| lifeless | spiv: what do you see? | 06:06 |
| * lifeless hates regressions | 06:06 | |
| spiv | lifeless: no formats | 06:06 |
| spiv | Which does indeed sound like a regression. | 06:07 |
| parthm | spiv, lifeless: so should the .bzr size not be going up in the first place? | 06:07 |
| spiv | lifeless: separating out the inode data does sound attractive. Why was that deferred, just lack of tuits? | 06:08 |
| lifeless | spiv: yeah | 06:08 |
| spiv | Yeah, I'm not surprised :) | 06:08 |
| lifeless | spiv: which was accurately judged in hindsight. | 06:08 |
| spiv | Agreed :) | 06:08 |
| lifeless | parthm: it should because you changed the inventory entry for the file. And that means it stores a copy of the file. | 06:08 |
| lifeless | parthm: then, when you pack they are identical and it just references a single compressed version | 06:09 |
| parthm | lifeless: ok. that makes sense. i was wonder what regression you were referring to. | 06:09 |
| lifeless | parthm: 'bzr help other-formats' should list rich-root-packs and other things like that | 06:10 |
| parthm | lifeless: oh. ok. | 06:11 |
| parthm | separate inode-data and content-data would have been really cool. | 06:12 |
| vila | hi all | 07:43 |
| vila | parthm: where are you ? | 07:43 |
| swathanthran | bzr documentation site is down? | 08:02 |
| lifeless | shouldn't be | 08:02 |
| swathanthran | oh ok, pdnsd was down here | 08:04 |
| detritux | hi. I have a problem: I just pulled my branch from launchpad and all my files are not writable (even if I do a chmod +w on them) | 09:27 |
| detritux | -rw-r--r-- 1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt | 09:28 |
| detritux | chmod +w CMakeLists.txt | 09:28 |
| detritux | -rw-r--r-- 1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt | 09:28 |
| detritux | any idea? | 09:28 |
| mwhudson | well, that's writeable by you now | 09:28 |
| mwhudson | but not by people only in the 'ugo' group or random others | 09:28 |
| mwhudson | this seems mostly sane... | 09:29 |
| detritux | it's writeable by root only | 09:30 |
| detritux | my bad... it's my emacs that's acting crazy: I have the correct permissions, but I can't edit it with emacs... have to look into that | 09:50 |
| detritux | cheers | 09:51 |
| vila | detritux: smells like a backup directory owned by root which forbids emacs to create backups, oh wait, you're not here aymore to read that :-/ | 09:55 |
| vila | I so love people asking questions in write-only mode :) | 09:56 |
| mwhudson | yay | 09:56 |
| Kennef | hi | 11:22 |
| Kennef | I have a problem installing bzr, could someone help me ? | 11:29 |
| Kennef | I install it correctly on my Ubuntu | 11:30 |
| Kennef | and then when I launch it, it segfaults | 11:30 |
| Kennef | I have absolutely no idea of what the problem could come from | 11:30 |
| Kennef | nobody ? | 12:50 |
| maxb | You have not given much information - people would need to know 1) exactly how you installed it, and 2) exactly how it's crashing, to have a reasonable chance of starting a diagnosis | 12:57 |
| Kennef | ok sorry for that | 13:01 |
| Kennef | I installed it by adding the ppa to my system (add-apt-repository ppa:bzr/ppa), and then sudo aptitude update and sudo aptitude install bzr-explorer | 13:02 |
| maxb | The best way to attract help on IRC is to make it easy for people glancing at the channel to quickly decide whether helping you lies within their skill set :-) | 13:02 |
| Kennef | and the crash has nothing special, I just "bzr-explorer" in my shell and it answers me "segmentation fault" | 13:04 |
| Kennef | :/ | 13:04 |
| Kennef | (being right back, my boss pays me meal) | 13:04 |
| maxb | I am unfamiliar with bzr-explorer, try checking whether plain bzr works | 13:04 |
| spiv | Kennef: that's pretty strange, please file a bug with those details. My best guess from the info so far is something mismatch with the python-qt bindings. | 13:43 |
| Kennef | maxb: with my shell, bzr works perfectly, I can pull / push / branch without any problem. I will use that mean to work while I'm trying to find where the problem comes from | 13:58 |
| Kennef | spiv: I will do that, thank you for the advice | 13:58 |
| === khmarbaise_ is now known as khmarbaise | ||
| thrope | how do I get my working tree to be at an earlier revision? | 16:34 |
| thrope | bzr checkout -r 423 gives an error file exists | 16:34 |
| parthm | thrope: bzr update -r | 16:35 |
| thrope | cool thanks | 16:36 |
| parthm | jam: ping | 16:36 |
| thrope | any loggerhead folks here? commit 424 breaks support for python2.4 (uses defaultdict) | 16:36 |
| thrope | not sure if you're planning to support python2.4 but as its still default on centos (as far as I know) I'd vote to keep it | 16:37 |
| parthm | thrope: bzr supports 2.4 so i would assume loggerhead would support it too. | 16:38 |
| === deryck is now known as deryck[lunch] | ||
| thrope | ill file a bug then | 16:39 |
| jam | hey parthm | 16:44 |
| parthm | jam: hi | 16:45 |
| parthm | jam: i was able to reproduce bug #603461 ... its python2.5 specific. i will look into fixing it. | 16:46 |
| ubot5 | Launchpad bug 603461 in Bazaar "bzrlib.tests.blackbox.test_log.TestLogErrors.test_log_bad_message_re failing (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/603461 | 16:46 |
| jam | parthm: thanks | 16:46 |
| jam | also, we should watch out for the "unprintable" exception | 16:46 |
| jam | We might want to use "assertNotContainsRe" | 16:46 |
| jam | as we want to make sure the exception can be printed | 16:46 |
| parthm | jam: ok. | 16:46 |
| jam | parthm: are you working on that now? | 16:47 |
| jam | I would like to get it into the 2.2b4 code if possible | 16:47 |
| jam | which I want to release today | 16:47 |
| parthm | jam: regarding bt.test_errors, is that only for format check? i am wondering if the test case should import re and check assertion or just raise InvalidPattern("message") and check formatting | 16:48 |
| parthm | jam: yes. i can look into it now. i don't think it will be a big fix. | 16:48 |
| jam | thrope: so there was a brief discussion about this, but we now also depend on sqlite directly, which is bundled with python2.5+ | 16:49 |
| jam | so if someone wants to put in the effort for 2.4 compat, we would probably take it | 16:49 |
| jam | but it isn't a strict focus like it is for bzr | 16:49 |
| jam | parthm: test_errors is generally just formatting tests | 16:49 |
| jam | fairly low-level testing | 16:49 |
| jam | it catches stuff like parameters that aren't passed correctly, etc | 16:50 |
| parthm | jam: sounds fine. i will add that also. | 16:50 |
| parthm | jam: ok. | 16:50 |
| thrope | jam: fair enough - have to look at upgrading python then... th | 16:54 |
| parthm | jam: hmm. is there something special about the name "message" for the argument? changing this to "msg" fixes it in 2.5. python exception handling is the same so that wasn't the issue. | 17:03 |
| parthm | ah. well. there is a comment in errors.py "'msg' is used instead of 'message' because python evolved and, in 2.6, forbids the use of 'message'." | 17:09 |
| bigjools | hi all - can you make bzr reveal the location of the uncommitted branch you've merged? | 17:18 |
| jam | parthm: there is something special about message | 17:28 |
| jam | but I see you found that ): | 17:29 |
| jam | :) | 17:29 |
| jam | bigjools: 'uncommitted branch you merged" ? | 17:29 |
| jam | the location you just merged from? | 17:29 |
| bigjools | jam: yes | 17:29 |
| bigjools | so in a shared account, I can see where someone merged from if there's uncommitted changes | 17:30 |
| jam | bigjools: generally not that I'm aware of | 17:35 |
| jam | you can see the revs, but not the URL | 17:35 |
| bigjools | ok - I'll file a bug, cheers | 17:35 |
| === deryck[lunch] is now known as deryck | ||
| parthm | jam: https://code.launchpad.net/~parthm/bzr/603461-invalidpattern-python25/+merge/29587 .. i have tested it with Python 2.5 | 17:41 |
| parthm | i am assuming 2.6.2 works but I don't have that installed to try it. | 17:42 |
| parthm | looks like the mp is merged. its late here. got to go ... bye. | 19:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!