[00:55] <lifeless> EdWyse_Office: depends on where its happening
[00:55] <lifeless> EdWyse_Office: where is it happening
[01:01] <EdWyse_Office> on a commit
[01:01] <lifeless> there are two likely possibilities
[01:02] <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:03] <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:04] <EdWyse_Office> This user has been using this version since the start.
[01:06] <lifeless> ok
[01:07] <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:08] <EdWyse_Office> There's nothing you couldn't see by visiting our web site anyway.. hehe.
[01:09] <EdWyse_Office> well that's much better. I got it down to one file causing the problem.
[01:12] <EdWyse_Office> So you're asking for .bzr/branch-lock/dirstate, correct?
[01:12] <lifeless> .bzr/checkout/dirstate
[01:13] <EdWyse_Office> oops, yeah, that's what I meant. :D
[01:17] <EdWyse_Office> Ah, I see... so if the file in question isn't even in dirstate, that might be my problem.
[01:22] <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:28] <lifeless> hi spiv
[01:42] <spiv> Hey lifeless.
[01:52] <chadrik> hi all, i've got a couple of quick questions about bzr. anyone here want to field them?
[02:02] <spm> chadrik: your best bet is to just ask them. if someone is willing and able to answer they will.
[02:07] <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:08] <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:09] <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:10] <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:11] <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:12] <chadrik> i imagine this is quite a bit of work
[02:12] <spiv> It is.
[02:13] <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:14] <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:15] <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:16] <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:17] <chadrik> spiv: where can i find the bug?
[02:27] <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:36] <rubbs> chadrik: IIRC this is the bug you're looking for: https://bugs.launchpad.net/bzr/+bug/109114
[02:36] <chadrik> rubbs: thanks
[02:37] <rubbs> np, it could be wrong, but I think that is the onw spiv was talking about
[02:39] <chadrik> looking now. def looks like the one
[02:40] <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:41] <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:43] <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:44] <chadrik> have you heard of dulwich?  it's a pure-python implementation of the git object model
[02:45] <chadrik> my goal would be to use it to drive the new storage model
[02:46] <lifeless> git has the same problem chadrik
[02:46] <lifeless> bzr's core is plenty sufficient to implement sharding of large files on
[02:47] <chadrik> lifeless: do you mean the memory consumption?
[02:47] <lifeless> yes
[02:48] <chadrik> my use case is pretty specific since i will be working almost entirely with non-mergable binary files
[02:49] <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:51] <chadrik> specifically, my use case is this: provide many users read-only access to large binary files on a local file system
[04:43] <lifeless> poolie: ring whenever
[05:33] <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:34] <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:35] <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:36] <parthm> cpsmusic: the branch page ( https://code.launchpad.net/~cpsmusic/pencil/audio ) says "This branch has not been pushed to yet."
[05:37] <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:38] <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:39] <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:40] <cpsmusic> Ah, I see
[05:40] <cpsmusic> I thought that once I made the branch I'd have to checkout from it.
[05:43] <spiv> The "Register a branch" link is an attractive nuisance for branches you are making yourself :(
[05:46] <spiv> You don't need to register it in advance at all, you can just push to create the branch on Launchpad.
[05:47] <maco> git user?
[05:47] <spiv> SVN, apparently.
[05:47] <spiv> Are you thinking it's confusing vs. how github operates?
[05:48] <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:50] <spiv> Ah right.
[05:51] <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:52] <lifeless> yes, don't use it in fact,.
[05:52] <lifeless> its something we want to delete
[05:53] <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:54] <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:55] <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:56] <parthm> ^ s/space used/size of .bzr/
[05:57] <lifeless> parthm: ?
[05:57] <parthm> lifeless: hi
[05:59] <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
[06:00] <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:01] <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:02] <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:04] <parthm> lifeless: thanks
[06:05] <lifeless> hmm
[06:06] <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:07] <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:08] <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:09] <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:10] <lifeless> parthm: 'bzr help other-formats' should list rich-root-packs and other things like that
[06:11] <parthm> lifeless: oh. ok.
[06:12] <parthm> separate inode-data and content-data would have been really cool.
[07:43] <vila> hi all
[07:43] <vila> parthm: where are you  ?
[08:02] <swathanthran> bzr documentation site is down?
[08:02] <lifeless> shouldn't be
[08:04] <swathanthran> oh ok, pdnsd was down here
[09:27] <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:28] <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:29] <mwhudson> this seems mostly sane...
[09:30] <detritux> it's writeable by root only
[09:50] <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:51] <detritux> cheers
[09:55] <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:56] <vila> I so love people asking questions in write-only mode :)
[09:56] <mwhudson> yay
[11:22] <Kennef> hi
[11:29] <Kennef> I have a problem installing bzr, could someone help me ?
[11:30] <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
[12:50] <Kennef> nobody ?
[12:57] <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
[13:01] <Kennef> ok sorry for that
[13:02] <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:04] <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:43] <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:58] <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
[16:34] <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:35] <parthm> thrope: bzr update -r
[16:36] <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:37] <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:38] <parthm> thrope: bzr supports 2.4 so i would assume loggerhead would support it too.
[16:39] <thrope> ill file a bug then
[16:44] <jam> hey parthm
[16:45] <parthm> jam: hi
[16:46] <parthm> jam: i was able to reproduce bug #603461 ... its python2.5 specific. i will look into fixing it.
[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:47] <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:48] <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:49] <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:50] <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:54] <thrope> jam: fair enough - have to look at upgrading python then... th
[17:03] <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:09] <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:18] <bigjools> hi all - can you make bzr reveal the location of the uncommitted branch you've merged?
[17:28] <jam> parthm: there is something special about message
[17:29] <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:30] <bigjools> so in a shared account, I can see where someone merged from if there's uncommitted changes
[17:35] <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:41] <parthm> jam: https://code.launchpad.net/~parthm/bzr/603461-invalidpattern-python25/+merge/29587 .. i have tested it with Python 2.5
[17:42] <parthm> i am assuming 2.6.2 works but I don't have that installed to try it.
[19:11] <parthm> looks like the mp is merged. its late here. got to go ... bye.