[00:55] EdWyse_Office: depends on where its happening [00:55] EdWyse_Office: where is it happening [01:01] on a commit [01:01] there are two likely possibilities [01:02] Good morning. [01:02] a) your dirstate is already damaged, so we need to replace it. [01:02] b) you've found a new bug: congratulations. [01:02] EdWyse_Office: what bzr version do you have? [01:02] 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] hehe [01:02] thanks [01:03] 2.0.3 [01:03] 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:04] This user has been using this version since the start. [01:06] ok [01:07] uhm [01:07] I'm leaning toward bug now... I've committed directories one-at-a-time and am succeeding (so far). [01:07] 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] I hate windows. (ugh) [01:07] this would disclose file paths to the devs, but not file content. [01:08] There's nothing you couldn't see by visiting our web site anyway.. hehe. [01:09] well that's much better. I got it down to one file causing the problem. [01:12] So you're asking for .bzr/branch-lock/dirstate, correct? [01:12] .bzr/checkout/dirstate [01:13] oops, yeah, that's what I meant. :D [01:17] Ah, I see... so if the file in question isn't even in dirstate, that might be my problem. [01:22] well [01:22] you are getting an error that is opaque [01:22] so we should fix it [01:22] dirstate + the command that fails + a 'bzr st' -> enough data for an engineer to fix, I think. [01:28] hi spiv [01:42] Hey lifeless. [01:52] hi all, i've got a couple of quick questions about bzr. anyone here want to field them? [02:02] chadrik: your best bet is to just ask them. if someone is willing and able to answer they will. [02:07] 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:08] It's amazing how three people have come and asked that question today. [02:08] 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:09] haha [02:09] chadrik: bzr is also currently rather wasteful, last time I checked. [02:09] so, i come to bzr with the hopes of finding a middle ground [02:09] chadrik: It's something that should hopefully be improved in the future. [02:10] 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:11] hg has similar problems. [02:11] I think lifeless or jam was talking about doing something about it. Or maybe it was somebody else; I forget. [02:11] 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:12] i imagine this is quite a bit of work [02:12] It is. [02:13] There's a bug about the excessive memory consumption when dealing with large files. [02:13] but it is designed to be able to use different models? is this correct? [02:13] so it would be feasible to implement a model designed specifically to handle large files? [02:14] 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] Definitely; see the bug for some discussion. [02:14] for me, the memory thing is only part of the problem. [02:15] (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] 90% of what i need to version control are large binary files, many over 1GB [02:16] before i go further with this, let me ask a couple of basic questions [02:16] does bzr currently use deltas for large files? [02:17] spiv: where can i find the bug? [02:27] 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:36] chadrik: IIRC this is the bug you're looking for: https://bugs.launchpad.net/bzr/+bug/109114 [02:36] 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] rubbs: thanks [02:37] np, it could be wrong, but I think that is the onw spiv was talking about [02:39] looking now. def looks like the one [02:40] 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] I lurk here so I don't get left too far behind ;) [02:41] i've come to realize that what i need is just too specific to expect to find it natively in a dcvs. [02:41] i guess i'll look into what is necessary to implement a new storage model [02:43] 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:44] have you heard of dulwich? it's a pure-python implementation of the git object model [02:45] my goal would be to use it to drive the new storage model [02:46] git has the same problem chadrik [02:46] bzr's core is plenty sufficient to implement sharding of large files on [02:47] lifeless: do you mean the memory consumption? [02:47] yes [02:48] my use case is pretty specific since i will be working almost entirely with non-mergable binary files [02:49] 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] merging is simply a matter of choosing A or B [02:49] 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:51] specifically, my use case is this: provide many users read-only access to large binary files on a local file system [04:43] poolie: ring whenever === mtaylor is now known as Trouble === Trouble is now known as mtaylor [05:33] Hi [05:33] I'm new to Bazaar [05:33] But I've worked with SVN [05:33] I have a question [05:33] I've setup up a branch of a project on Launchpad [05:34] But I can't figure out how to check it out [05:34] I keep getting an error msg saying [05:34] bzr: ERROR: Not a branch: [05:34] cpsmusic: what is the command you are using? [05:35] the branch is at [05:35] lp:~cpsmusic/pencil/audio [05:35] I've tried [05:35] bzr branch lp:~cpsmusic/pencil/audio [05:35] also [05:35] bzr checkout lp:~cpsmusic/pencil/audio [05:36] cpsmusic: the branch page ( https://code.launchpad.net/~cpsmusic/pencil/audio ) says "This branch has not been pushed to yet." [05:37] yep I saw that [05:37] what does it mean [05:37] looks like you created the branch with the webui (?). you will need to push it up. [05:37] i thought pushing was like committing changes [05:37] ah [05:37] if its new content, you should be able to bzr init; and bzr push lp:~cpsmusic/pencil/audio [05:38] 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] it's a branch of project that's already on Launchpad [05:38] I used the web pages [05:39] 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] I used "Register a branch" on Pencil's Code page [05:40] Ah, I see [05:40] I thought that once I made the branch I'd have to checkout from it. [05:43] The "Register a branch" link is an attractive nuisance for branches you are making yourself :( [05:46] You don't need to register it in advance at all, you can just push to create the branch on Launchpad. [05:47] git user? [05:47] SVN, apparently. [05:47] Are you thinking it's confusing vs. how github operates? [05:48] 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:50] Ah right. [05:51] the thing I found confusing was that once "Registered a branch" I thought there would be a complete branch [05:51] It's actually just a placeholder until the first lot of code is pushed into it - is that right? [05:52] yes, don't use it in fact,. [05:52] its something we want to delete [05:53] 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:54] I'm new to Launchpad and Bazaar - it was the first thing I saw [05:54] and I was told to make a branch there by one of Pencil's devs [05:54] yeah [05:54] its confusing [05:54] thats why we want ot remove it ;) [05:54] 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:55] 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:56] ^ s/space used/size of .bzr/ [05:57] parthm: ? [05:57] lifeless: hi [05:59] 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] what do you mean by space usage goes up [05:59] Don't commits just always store fulltexts of every file touched? [05:59] fullermd: yes, because snapshot based. [05:59] should just store a diff [05:59] lifeless: see his paste; 'du -hs .bzr' goes up [06:00] oh [06:00] parthm: do a bzr pack [06:00] lifeless: for a 100mb file the mv makes .bzr go from 100mb to 200mb [06:00] Yes, but I mean physically storing fulltexts, not delta compressed 'till pack. [06:00] fullermd: yes, exactly. [06:00] the file doesn't compress as its /dev/urandom data. [06:00] parthm: every time a file changes we store the file under (fileid, revisionid) in our tuple space. [06:00] * parthm runs pack command. [06:01] lifeless: i haven't changed the file. its just a mv. http://pastebin.com/G5vqByFM [06:01] lifeless: where "changes" includes metadata changes, I presume? [06:01] yes [06:02] spiv: a refactoring I considered, but deferred in the 2a work was to separate 'inode data' and 'content data' [06:02] lifeless: neat. pack brings the size down to 101MB again http://pastebin.com/2Gv4NFHh [06:02] 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:04] lifeless: thanks [06:05] hmm [06:06] spiv: do 'bzr help other-formats' for me [06:06] spiv: what do you see? [06:06] * lifeless hates regressions [06:06] lifeless: no formats [06:07] Which does indeed sound like a regression. [06:07] spiv, lifeless: so should the .bzr size not be going up in the first place? [06:08] lifeless: separating out the inode data does sound attractive. Why was that deferred, just lack of tuits? [06:08] spiv: yeah [06:08] Yeah, I'm not surprised :) [06:08] spiv: which was accurately judged in hindsight. [06:08] Agreed :) [06:08] parthm: it should because you changed the inventory entry for the file. And that means it stores a copy of the file. [06:09] parthm: then, when you pack they are identical and it just references a single compressed version [06:09] lifeless: ok. that makes sense. i was wonder what regression you were referring to. [06:10] parthm: 'bzr help other-formats' should list rich-root-packs and other things like that [06:11] lifeless: oh. ok. [06:12] separate inode-data and content-data would have been really cool. [07:43] hi all [07:43] parthm: where are you ? [08:02] bzr documentation site is down? [08:02] shouldn't be [08:04] oh ok, pdnsd was down here [09:27] 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:28] -rw-r--r-- 1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt [09:28] chmod +w CMakeLists.txt [09:28] -rw-r--r-- 1 ugo ugo 2426 2010-07-09 08:57 CMakeLists.txt [09:28] any idea? [09:28] well, that's writeable by you now [09:28] but not by people only in the 'ugo' group or random others [09:29] this seems mostly sane... [09:30] it's writeable by root only [09:50] 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:51] cheers [09:55] 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:56] I so love people asking questions in write-only mode :) [09:56] yay [11:22] hi [11:29] I have a problem installing bzr, could someone help me ? [11:30] I install it correctly on my Ubuntu [11:30] and then when I launch it, it segfaults [11:30] I have absolutely no idea of what the problem could come from [12:50] nobody ? [12:57] 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 [13:01] ok sorry for that [13:02] 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] 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:04] and the crash has nothing special, I just "bzr-explorer" in my shell and it answers me "segmentation fault" [13:04] :/ [13:04] (being right back, my boss pays me meal) [13:04] I am unfamiliar with bzr-explorer, try checking whether plain bzr works [13:43] 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:58] 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] spiv: I will do that, thank you for the advice === khmarbaise_ is now known as khmarbaise [16:34] how do I get my working tree to be at an earlier revision? [16:34] bzr checkout -r 423 gives an error file exists [16:35] thrope: bzr update -r [16:36] cool thanks [16:36] jam: ping [16:36] any loggerhead folks here? commit 424 breaks support for python2.4 (uses defaultdict) [16:37] 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:38] thrope: bzr supports 2.4 so i would assume loggerhead would support it too. === deryck is now known as deryck[lunch] [16:39] ill file a bug then [16:44] hey parthm [16:45] jam: hi [16:46] jam: i was able to reproduce bug #603461 ... its python2.5 specific. i will look into fixing it. [16:46] 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] parthm: thanks [16:46] also, we should watch out for the "unprintable" exception [16:46] We might want to use "assertNotContainsRe" [16:46] as we want to make sure the exception can be printed [16:46] jam: ok. [16:47] parthm: are you working on that now? [16:47] I would like to get it into the 2.2b4 code if possible [16:47] which I want to release today [16:48] 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] jam: yes. i can look into it now. i don't think it will be a big fix. [16:49] 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] so if someone wants to put in the effort for 2.4 compat, we would probably take it [16:49] but it isn't a strict focus like it is for bzr [16:49] parthm: test_errors is generally just formatting tests [16:49] fairly low-level testing [16:50] it catches stuff like parameters that aren't passed correctly, etc [16:50] jam: sounds fine. i will add that also. [16:50] jam: ok. [16:54] jam: fair enough - have to look at upgrading python then... th [17:03] 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:09] 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:18] hi all - can you make bzr reveal the location of the uncommitted branch you've merged? [17:28] parthm: there is something special about message [17:29] but I see you found that ): [17:29] :) [17:29] bigjools: 'uncommitted branch you merged" ? [17:29] the location you just merged from? [17:29] jam: yes [17:30] so in a shared account, I can see where someone merged from if there's uncommitted changes [17:35] bigjools: generally not that I'm aware of [17:35] you can see the revs, but not the URL [17:35] ok - I'll file a bug, cheers === deryck[lunch] is now known as deryck [17:41] jam: https://code.launchpad.net/~parthm/bzr/603461-invalidpattern-python25/+merge/29587 .. i have tested it with Python 2.5 [17:42] i am assuming 2.6.2 works but I don't have that installed to try it. [19:11] looks like the mp is merged. its late here. got to go ... bye.