| mwhudson | jam: i wonder if we should just add ~bzr to ~loggerhead-team ? | 00:11 |
|---|---|---|
| mwhudson | dunno what implications that would have for mail spam | 00:11 |
| spiv | It's great having so many contributors, but why are so many of them named Martin? | 00:13 |
| mwhudson | or at the very least M* | 00:15 |
| mwhudson | jelmer: hey | 00:25 |
| mwhudson | jelmer: want to fix https://bugs.edge.launchpad.net/bzr-svn/+bug/525571 ? | 00:25 |
| ubottu | Ubuntu bug 525571 in bzr-svn "bzr svn-import fails when invoked concurrently" [Medium,Triaged] | 00:25 |
| * mwhudson adds affects launchpad-code | 00:26 | |
| poolie | good morning | 01:02 |
| lifeless | poolie: hey | 01:33 |
| lifeless | poolie: its like a bombshell went off here :P | 01:33 |
| poolie | oh, meaning your house, not the channel :) | 01:34 |
| lifeless | yes! | 01:34 |
| mlh | you packing ... or unpacking? | 01:35 |
| spiv | I believe his home repository is being packed *and* garbage-collected. | 01:35 |
| fullermd | Both of them are such a pain. That's why I have stuff still packed from a decade+ ago. | 01:35 |
| mlh | eek. indeed. | 01:36 |
| mlh | same. | 01:36 |
| mkanat | spm: The fix for bug 513044 is committed now, so you might want to update codebrowse. | 01:36 |
| ubottu | Launchpad bug 513044 in loggerhead "loggerhead (codebrowse) hangs occasionally on launchpad" [Critical,Fix committed] https://launchpad.net/bugs/513044 | 01:36 |
| poolie | spiv :) | 01:38 |
| spm | mkanat: I shall draw the attention of those who can make that call :-) | 01:39 |
| mkanat | spm: Okay. :-) | 01:39 |
| igc | hi poolie, spiv, spm, mkanat, lifeless, fullermd | 01:40 |
| spm | hey there igc! | 01:41 |
| mkanat | Hey igc. :-) | 01:41 |
| * fullermd waves at igc. | 01:41 | |
| igc | mkanat: thanks for the patch for 513044 | 01:45 |
| mkanat | igc: Yeah, welcome. :-) | 01:45 |
| igc | mkanat: well done on tracking that down! | 01:45 |
| mkanat | igc: Thanks. It was several months of work, and yesterday alone, seven hours of log anaylsis. | 01:46 |
| igc | mkanat: btw, the production branch is lp:~loggerhead-pqm/loggerhead/devel, not the trunk per se | 01:47 |
| mkanat | igc: Ah, okay. | 01:47 |
| igc | mkanat: so I'll find out from mwhudson and/or lifeless as to how best get it merged there | 01:47 |
| mkanat | igc: Okay. | 01:48 |
| mkanat | igc: Next I'm on to bug 420738. | 01:50 |
| ubottu | Launchpad bug 420738 in loggerhead "LRUCache.cleanup raises KeyError" [Critical,Confirmed] https://launchpad.net/bugs/420738 | 01:50 |
| igc | mkanat: cool | 01:50 |
| mkanat | Why does loggerhead possibly instantiate the graph_cache in four or five places? | 01:57 |
| igc | mkanat: I haven't looked into the caching yet but jam has studied it in some detail. Try and catch him to chat about his plans for making it better | 01:58 |
| mkanat | Okay. | 01:58 |
| chrispitzer | do I want to roll back to a commit someone else made. it's 21.1.191 ... how do I do that...? | 02:20 |
| chrispitzer | i think I should be able to just "bzr checkout -r 21.1.191" ...but that doesn't work... | 02:21 |
| chrispitzer | s/do/so/ | 02:21 |
| fullermd | What do you mean by "roll back"? | 02:25 |
| fullermd | Do you want to just make a new rev reversing the change, or do you want to excise it totally from the history? | 02:26 |
| spiv | chrispitzer: depending on exactly what you mean by "roll back" you probably want either "bzr revert -r ..." or "bzr update -r ..." | 02:26 |
| spiv | fullermd: it could also mean "give me a working tree at that rev so I can look at it etc" | 02:26 |
| fullermd | Oh, I missed the "to". | 02:26 |
| fullermd | Yes, 'update -r' is probably the answer. | 02:27 |
| chrispitzer | spiv: thanks | 02:27 |
| mkanat | Does bzr or loggerhead already have some sort of ReadWriteLock implementation? | 02:29 |
| poolie | in memory or on disk? | 02:35 |
| mkanat | poolie: In memory. | 02:35 |
| mkanat | poolie: Like a threading.Lock sort of lock. | 02:35 |
| poolie | between threads? | 02:35 |
| poolie | not in bzrlib afaik | 02:36 |
| poolie | could look at countedloc | 02:36 |
| poolie | lock* | 02:36 |
| mkanat | poolie: Yeah, in bzrlib. | 02:36 |
| mkanat | poolie: Oh, that looks like it might do what I need. | 02:37 |
| poolie | you'll need to tell it to stack on a threading lock | 02:38 |
| mkanat | poolie: Yeah. | 02:38 |
| poolie | probabyl not hard | 02:38 |
| mkanat | poolie: Thanks. :-) | 02:38 |
| lifeless | home server powered off; internet going soon. noooo. | 02:42 |
| igc | have a good trip lifeless | 02:43 |
| * fullermd steals all the internet and holds it for ransom. | 02:43 | |
| * igc out for a few hours | 02:43 | |
| lifeless | igc: thanks | 02:43 |
| lifeless | fullermd: just hold onto the porn for me | 02:43 |
| mkanat | poolie: Okay, yeah, counted_lock isn't going to do what I need. :-( | 02:44 |
| mkanat | poolie: It requires underlying locks that can already do read/write locks. | 02:45 |
| lifeless | mkanat: wht do you need ? | 02:45 |
| mkanat | lifeless: I need a ReadWriteLock for threads. | 02:45 |
| mkanat | lifeless: I need to synchronize access to an lru_cache. | 02:45 |
| lifeless | to avoid confusion | 02:45 |
| lifeless | I'd like you to describe that that means to you | 02:45 |
| mkanat | lifeless: Infinite numbers of threads can read the data structure at once, but only one can write, and if one is writing, none can read. | 02:46 |
| lifeless | mkanat: reading mutates it | 02:46 |
| mkanat | lifeless: Oh really? | 02:46 |
| mkanat | Well, that sucks for me. | 02:46 |
| lifeless | mkanat: I'm not at all sure that reading is safe across N threads | 02:46 |
| lifeless | mkanat: yes, its a lrU cache | 02:46 |
| mkanat | Ah, right. | 02:46 |
| mkanat | Okay. Well, I guess I can put a dumb lock on it and see how bad performance gets. | 02:49 |
| mwhudson | it'll probably be ok, i don't think anything should hold the lock for too long | 02:50 |
| lifeless | mkanat: we have a similar situation in chk_map | 02:50 |
| lifeless | mkanat: I would copy what we do there, for protecting the lru cache it has | 02:50 |
| mkanat | mwhudson: Yeah, but actually acquiring and releasing locks takes time. | 02:50 |
| lifeless | mkanat: no time at all compared to python :P | 02:50 |
| mkanat | lifeless: Okay, I'll take a look. | 02:51 |
| lifeless | seriously, python's write-on-read behaviour is hugely destructive of performance | 02:51 |
| mwhudson | mkanat: btw, https://code.edge.launchpad.net/~vcs-imports/bugzilla/main is a cvs import and still lp:bugzilla | 02:51 |
| mwhudson | mkanat: that's a bit stale, right? | 02:51 |
| lifeless | I wouldn't worry at all about using locks; the python locking primitive on linux hits the futex code paths | 02:51 |
| mkanat | mwhudson: Yeah, but if we replaced it, it would break file ids. | 02:51 |
| mkanat | mwhudson: For anybody who checked out from it. | 02:52 |
| mwhudson | mkanat: yeah | 02:52 |
| Kilroo | I'm having an interesting time trying to figure out what DVCS is going to be the best choice for me to push for at work. | 02:57 |
| spiv | It seems "no valid commands given" is the new way PQM mails me to say "success". | 03:01 |
| mkanat | lifeless: Oh, I see, you used threading.local(). | 03:01 |
| mkanat | lifeless: That wouldn't work for us; we definitely need threads to share the cache. I'll just use an RLock. | 03:02 |
| Kilroo | Based on my research up to this point, it's starting to look like it comes down to a face-off between the superiority of HgEclipse to either of the Eclipse plugins for bzr against bzr-svn's advantages over HgSubversion...and if I could get the powers that be to reconsider whether svn is the best choice, that might make mercurial the unchallenged frontrunner. | 03:02 |
| lifeless | mkanat: oh I forgot we did that ;P | 03:02 |
| Kilroo | ...I really oughta learn python and java and try to contribute to bzr-eclipse. | 03:02 |
| spiv | Kilroo: that'd be wonderful :) | 03:03 |
| Kilroo | spiv: Indeed it would, unfortunately it is not something I consider especially likely to happen. I don't get to work on projects I like often enough at work to have the programming energy to feel like doing any more once I get home. | 03:04 |
| Kilroo | If I did, I would have actually attempted to get Lua web applications to work on Google App Engine via LuaJ by now. | 03:05 |
| Kilroo | It's a shame Codebeamer picked Hg over bzr in that respect. Apparently they pretty much decided HgEclipse wasn't good enough yet and they were gonna do something about it. | 03:09 |
| Kilroo | Based on what I've read, that seems to have taken Mercurial's Eclipse plugin from -arguably- the best (out of hg, bzr, and git) to almost -inarguably- the best, and they seem to be planning on both improving it further and adding a Mylyn team support plugin for it by...I think the end of June. | 03:09 |
| Kilroo | bzr is still my favorite of the three, but the fact that bzr makes you jump through the fewest hoops to work with subversion is the only one of its advantages that I currently see as beinga significant factor in the ease of adoption by the rest of the team. | 03:11 |
| Kilroo | I'm gonna stop yacking about it now though. | 03:11 |
| Kilroo | At least here. | 03:13 |
| mkanat | igc: Okay, I just submitted an MP that should do it. | 03:53 |
| mkanat | igc: That would close the last Critical bug in Loggerhead; would be nice. :-) | 03:53 |
| jbowtie | Is there doco for PQM anywhere? I see odd mentions of it but no actual details. | 03:57 |
| jbowtie | Sorry, lapsed into slang - by "doco" I mean "documentation". | 03:59 |
| spiv | jbowtie: I don't know of any beyond what is in the tarball. The README file gives a terse overview. | 04:01 |
| spiv | jbowtie: you may also be interested in the bzr-pqm plugin for bzr, which adds a "bzr pqm-submit" command. | 04:02 |
| jbowtie | spiv: I'll have a look in there, then. I want to figure out whether or not I want to try setting one up for my project or not, but I'm not even sure what it does. | 04:04 |
| spiv | jbowtie: it automates "checkout $trunk; merge $proposed_branch; run pre-commit checks (e.g. test suite); commit" | 04:10 |
| spiv | jbowtie: so for Bazaar, none of the developers has direct access to the trunk or release branches. Instead we instruct PQM (currently via the email interface) to merge changes on our behalf, and it will run our test suite and only allow commit changes that pass the test suite. | 04:11 |
| jbowtie | spiv: OK, that's helpful to know. It does sound like the sort of thing I'd want to hook to our continuous integration server. | 04:17 |
| spiv | Yeah, we find it very useful. It's great to be able to trust that trunk is very likely to be in a sound, probably even releaseable, state. (Depending on the effectiveness of your test suite, of course.) | 04:19 |
| spiv | The other common approach is to use something like buildbot to find out after the commit happened that something broke. You can combine the two approaches as well (e.g. pre-commit test on one platform, post-commit monitor the buildbot for all the other interesting platforms.) | 04:21 |
| GungaDin | Is there a way to create a branch and push it at the same time? | 04:57 |
| spiv | Do you mean create locally or create remotely? | 04:59 |
| GungaDin | create remotely so I can check it out locally | 04:59 |
| GungaDin | 'cuz right now I branch locally, push, delete and checkout | 04:59 |
| spiv | You could branch remotely: "bzr branch local_branch remote_url", then check that out. | 05:00 |
| GungaDin | ah cool | 05:00 |
| GungaDin | thx | 05:00 |
| spiv | Or convert the branch you made locally into a bound branch/checkout rather than delete it and recreate it as a checkout. | 05:01 |
| spiv | e.g. bzr reconfigure --checkout | 05:01 |
| GungaDin | cool | 05:03 |
| GungaDin | thx | 05:03 |
| igc | back | 06:33 |
| eydaimon | how I can see what files are kept under control? | 07:10 |
| mwhudson | eydaimon: not sure what you mean, maybe bzr ls --versioned --recursive ? | 07:11 |
| eydaimon | yes, that works, thank you | 07:13 |
| eydaimon | (mercurial has hg locate) | 07:13 |
| vila | hi all | 07:25 |
| * fullermd waves vila around. | 07:32 | |
| vila | _0/ | 07:32 |
| parthm | trunk seems to be missing tag for 2.2b2. should the tag be in place? | 09:08 |
| parthm | as per NEWS 2.2b2 was on 2010-04-16 | 09:09 |
| cbz | dash: do you find you have to do a rebase rather than a pull in order to avoid blatting svn's history/blame? | 10:06 |
| === mrevell is now known as mrevellunch | ||
| millun | what should i do to export stuff ? | 13:49 |
| millun | branch? | 13:49 |
| === mrevellunch is now known as mrevell | ||
| LeoNerd | Or bzr export perhaps? | 14:01 |
| === radoe_ is now known as radoe | ||
| === vds1 is now known as vds | ||
| jannn | Hey. Is it somehow possible to clone a complete repository with all its branches without having to find out / specify each branch individualy? | 16:18 |
| maxb | no (bug 316729) | 16:20 |
| ubottu | Launchpad bug 316729 in bzr "bzr clone should be able to clone a repo, not just be an alias to branch" [Wishlist,Confirmed] https://launchpad.net/bugs/316729 | 16:20 |
| fullermd | Not as such. I think there are some plugins that automate the find/specify-individually process, but that just hides it from you. | 16:20 |
| mkanat | jannn: Although you could use rsync. | 16:20 |
| fullermd | Of course there are options like rsync/cp/tar/etc. | 16:20 |
| mkanat | jannn: But that might be troublesome if it changes mid-stream. | 16:20 |
| jannn | ok, thanks for the comprehensive answers :) | 16:22 |
| laurenty | hey guys | 16:51 |
| laurenty | coming from svn, bzr looks really cool, but also kinda confusing... | 16:52 |
| LeoNerd | Really? It's supposed to look-and-feel really really similar | 16:54 |
| LeoNerd | bzr co URL; bzr di -r123; bzr ci -m "Here are my changes"; ... | 16:54 |
| maxb | laurenty: Any elements in particular you're having trouble with? | 17:13 |
| maxb | LeoNerd: Yesssss.... but only if you stick exclusively to the bound-branch workflow, and even then, branching is quite different | 17:13 |
| === beuno is now known as beuno-lunch | ||
| laurenty | LeoNerd: yes a lot of the stuff is very similar, but the distributed repository stuff can get confusing when you're used to having a central repo | 17:33 |
| LeoNerd | Ahyes | 17:33 |
| laurenty | maxb: pull, push, bind, merge... | 17:34 |
| laurenty | svn had merge that was it | 17:34 |
| maxb | Perhaps you should start with some tutorials: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/index.html | 17:35 |
| === beuno-lunch is now known as beuno | ||
| laurenty | maxb: I read the 5 minute version, I'll have to spend some time with the full tutorial | 18:08 |
| vila | and some basic vocabulary: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 18:08 |
| rephormat | greetings fellow coders | 18:52 |
| rephormat | How is everyone doing this afternoon? | 18:52 |
| === nlisgo_ is now known as nlisgo | ||
| damiro | can anyone help me with the following error message: "aborting commit write group: MemoryError()" and next line was "bzr: out of memory". this happened on a local initial commit with many files. the project is about 2 GB with some larger binary files. | 21:06 |
| ikus060 | Hi, I'm evaluating Bazaar and have a quick question. I'm wondering is the .bzr directory will grow as I add more file in the repository and if yes, how much ? | 21:11 |
| ikus060 | I'm concern because with SVN, the .svn directory contain a copy of the original file. So it's double the space required on the disk. | 21:13 |
| damiro | hi.. i'm also new to bzr. but afaik the directory will grow on commits | 21:13 |
| damiro | for each change a delta will be stored | 21:15 |
| ikus060 | the delta is stored locally in .bzr directory ? | 21:16 |
| damiro | look at http://doc.bazaar.canonical.com/bzr-0.9/tutorial.html | 21:17 |
| damiro | chapter "creating branch" | 21:18 |
| ikus060 | damiro : I know how to create a branch. It's not the point. I'm questioning the internal of bazaar | 21:18 |
| ikus060 | whats does .bzr directory contains ? | 21:19 |
| rephormat | What do you mean what does it contain? | 21:21 |
| damiro | hmmm. it seems to be the only place that will be used for all data | 21:21 |
| damiro | but i'm not sure about that | 21:21 |
| damiro | i seems we are currently the only ones who are active here... | 21:33 |
| damiro | i found this: http://ddaa.net/blog/bzr/repository-branch-tree | 21:33 |
| rephormat | nice find damiro | 21:36 |
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| === nlisgo_ is now known as nlisgo | ||
| ikus060 | Hi, I want to know is bazaar can handle a 20Gig repository | 22:54 |
| Peng | Um. Maybe. Having a good 20 GB of RAM would help. | 22:55 |
| ikus060 | What ?! | 22:56 |
| Peng | Bazaar likes to hold entire copies of things in memory. | 22:57 |
| ikus060 | ouch | 22:57 |
| mkanat | Peng: Sometimes three or four copies of them. | 22:57 |
| Peng | Yah. | 22:57 |
| Peng | You should need your largest file * 2 or 3. | 22:57 |
| Peng | mkanat: Recent releases with 2a repos are better than that. | 22:57 |
| mkanat | Peng: For most things, yeah. I think annotate is still bad. | 22:58 |
| Peng | A 20 GB repository created by tons of branches with small files should be fine, though, except maybe if it needs to do a large pack (or, god forbid, reconcile). | 22:58 |
| Peng | mkanat: Eh. Who uses that? :P | 22:58 |
| ikus060 | Peng : Do you have another VCS to recommend me If I want to manage a big repository of 20Gig | 22:58 |
| mkanat | Peng: Hahahaha. This funny little program called "loggerhead", mostly. :-) | 22:58 |
| ikus060 | As an example. One branch is 20Gig | 22:59 |
| Peng | :D | 22:59 |
| mkanat | ikus060: What's so large? Do you have a lot of binary files in it? | 22:59 |
| Peng | ikus060: Sorry, I don't. The awful, obtuse proprietary ones are the best at it, but I don't know a thing abotu them. | 23:00 |
| ikus060 | mkanat : I have a lot of stuff including binary, xml, text, java and others | 23:00 |
| mkanat | ikus060: In some ways, bzr is going to be really good for you, because you're going to get a lot of disk-space savings from the repository system. | 23:00 |
| mkanat | ikus060: I think that in terms of handling large binary objects, though, bzr still needs improvement, last time I heard anything about it. | 23:01 |
| ikus060 | mkanat : ok .. but I will run out of memory ? | 23:01 |
| mkanat | ikus060: Well, what's the largest single file? | 23:01 |
| mkanat | ikus060: (In the whole branch's history, not just in the current tip.) | 23:01 |
| ikus060 | the largest file is binary 12Gig | 23:01 |
| mkanat | ikus060: Yes, you will run out of memory. | 23:01 |
| ikus060 | :S | 23:01 |
| mkanat | ikus060: But I do have to ask--why are you storing a 12G binary in your VCS? | 23:02 |
| ikus060 | will have a look at Git than | 23:02 |
| ikus060 | mkanat : You should ask my CBC | 23:03 |
| mkanat | ikus060: You do realize that in most VCSes, every time you revision that 12G binary, your repository will grow by 12G? | 23:03 |
| rephormat | eww... | 23:03 |
| mkanat | Unless they have a binary delta algorithm and store binary deltas. | 23:03 |
| ikus060 | mkanat : we currectly use ClearCase (IBM product) | 23:03 |
| ikus060 | ans it's not a problem | 23:03 |
| ikus060 | *and | 23:04 |
| xnox | I'm a bit crazy tonight. I just had a thought. Brisbane-core is nice and all that but git-blobs are still more efficient spacewise. Does it make sence to create yet another git native format based on git-blobs with additional revprops and file-ids we use? | 23:04 |
| xnox | Or will that not fit into bzr model? | 23:04 |
| Peng | xnox: See what bzr-git + dulwich do. | 23:04 |
| Peng | xnox: I don't think git is always more efficient. | 23:04 |
| Peng | 90% of the time, but... :D | 23:04 |
| xnox | Peng, I use that but it still feels slow. Cause I think there is still roundtrip to foreign | 23:05 |
| xnox | Peng, well have you tried branching lp:gcc or lp:emacs? | 23:05 |
| Peng | xnox: God no. | 23:05 |
| xnox | Peng, well downloading packs is fine | 23:05 |
| Peng | Actually, I think I have emacs somewhere. | 23:05 |
| xnox | but it takes ages to build working tree | 23:05 |
| xnox | (well in lp:gcc anyhow) | 23:06 |
| xnox | where is git-svn clone is two eye blinks to get working tree | 23:06 |
| Peng | Would git's format help with that? | 23:06 |
| xnox | I don't know. I would think so. Although I think the bottleneck is the inventory / file-ids extraction | 23:06 |
| xnox | cause during lp:gcc tree checkout it was looping at 100% CPU and generating inventory / file-id list | 23:07 |
| xnox | maybe that's why git is fast since it doesn't track file-ids at all | 23:07 |
| Peng | I imagine there are lots of reasons git is fast. | 23:08 |
| Peng | Which mostly center around it being written in C by really clever people/ | 23:08 |
| xnox | Peng, well kernel hackers are out-of this world people ;-) who really do know their C =) | 23:09 |
| Peng | And who really know how to get the best performance on Linux. | 23:10 |
| damiro | can anyone help me with the following error message: "aborting commit write group: MemoryError()" and next line was "bzr: out of memory". this happened on a local initial commit with many files. the project is about 2 GB with some larger binary files. | 23:10 |
| Peng | damiro: There's not much to say. How much RAM do you have? What version of bzr? What repo format? | 23:10 |
| damiro | on a winxp32 box 4GB ram, version is latest stable, format is default | 23:11 |
| Peng | damiro: Which version is that? | 23:13 |
| xnox | damiro, there was a bug about that. And a switch / flag to limit the memory usage | 23:13 |
| damiro | v2.1.1, i don't used any flags like this | 23:14 |
| xnox | Bug #109114 | 23:16 |
| ubottu | Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Confirmed] https://launchpad.net/bugs/109114 | 23:16 |
| damiro | ahhh... thanks :-) | 23:17 |
| xnox | damiro, your welcome although it doesn't solve the problem =) | 23:18 |
| xnox | I would suggest to use multiple commits to get your tree | 23:18 |
| xnox | and then create a new branch and do | 23:18 |
| xnox | $ bzr merge --force ../incremental-commits-branch | 23:19 |
| xnox | that way in this new branch you will have just revno 1 - [merge] initial commit | 23:19 |
| xnox | this way your history will look clean ;-) | 23:19 |
| damiro | ok, sounds good. i will try it out. | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!