| lifeless | hi poolie | 00:01 |
|---|---|---|
| awilkins | Hey, how come there's a VCS flamewar going on on Slashdot and no-one mentioned Bazaar so far ? http://bsd.slashdot.org/article.pl?sid=08/06/04/1749233 | 00:04 |
| lifeless | because we actually do stuff? | 00:06 |
| awilkins | :-P | 00:07 |
| RAOF | Heh. Begins switch to subversion. | 00:09 |
| awilkins | It is a step up from CVS, I suppose (although someone points out all the core devs use Perforce | 00:10 |
| lifeless | its worse than cvs in many ways | 00:10 |
| lifeless | its user model particularly | 00:10 |
| lifeless | however, it scales better than cvs | 00:10 |
| RAOF | But it's easier to work with svn than cvs in a dvcs, I believe. So it's a step up in that respect :) | 00:11 |
| lifeless | RAOF: not at all | 00:11 |
| lifeless | cvs these days has atomic changesets believe it or not | 00:11 |
| RAOF | lifeless: So my lack of exposure to bzr-cvs is due to my lack of exposure to cvs? | 00:12 |
| lifeless | no, its due to old cvs data still being a pillock ;) | 00:12 |
| RAOF | Right :) | 00:12 |
| lifeless | bzr cvsps-import does exist and do a decent enough job though | 00:12 |
| lifeless | (my point being that you could just cleanup the tree and go from there) | 00:13 |
| lifeless | oh, also don't forget cvsup - distributed cvs ;) | 00:13 |
| lifeless | poolie: call over ? | 00:13 |
| jam | lifeless: not quite yet | 00:14 |
| lifeless | bbiab | 00:14 |
| === mw is now known as mw|out | ||
| lifeless | -> doctors, back, well, later | 00:54 |
| Zelut | I would like to create a bzr trunk on a private server to backup my home folder. Can anyone point me to some docs on how I might do that? | 01:29 |
| kumi_ | Zelut: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#branching-a-project | 01:32 |
| bob2 | I don't think bzr is a very good solution for backing up your whole home dir | 01:33 |
| Zelut | bob2: well mainly what I'm looking for is archiving and tracking my .folders, and upon a fresh install just being able to branch my ~ and be done. | 01:34 |
| === BasicTheProgram is now known as Basic | ||
| bob2 | storing all your config files and documents etc works well, though | 01:34 |
| Zelut | bob2: seems simpler to branch that and get my .ssh, .gnupg, etc than manual backup/restore each time. | 01:34 |
| bob2 | I'd be weary of putting ssh and ngupg private keys in, but I do version all my dotfiles | 01:36 |
| Zelut | bob2: kind of like /etc/skel I guess, but just requires branching. | 01:36 |
| bob2 | er, wary | 01:36 |
| Zelut | I've been using bzr with LP but I'm unsure how to create a trunk on my own machine is the main problem. | 01:38 |
| mwhudson | Zelut: bzr init path/to/branch | 01:39 |
| Zelut | mwhudson: lets say I've got a folder locally that I want to push to a remote server and then be able to branch from remote in the future, what else do I need? | 01:40 |
| mwhudson | bzr init in the folder | 01:40 |
| mwhudson | bzr add to add the contents of the folder | 01:41 |
| mwhudson | bzr commit to record these files | 01:41 |
| mwhudson | bzr push to the server | 01:41 |
| mwhudson | that's it | 01:41 |
| Zelut | I swear I had done that before but all I have on remote is .bzr with no contents. | 01:41 |
| bob2 | that is indeed what push does | 01:42 |
| bob2 | unless it is pushing to a local directory | 01:42 |
| bob2 | you can a) leave it, since you can still branch from that remote one fine, b) manually 'bzr co' in the remote dir after each push or c) install the 'up-afte-rpush' plugin that does b automatically | 01:42 |
| Zelut | so I could branch from remote and get those files, even though they are not listed there? | 01:43 |
| bob2 | (https://launchpad.net/bzr-push-and-update) | 01:43 |
| bob2 | yup | 01:43 |
| Zelut | interesting. I figured I had done something wrong because I didn't see anything on remote. | 01:44 |
| Zelut | well how 'bout that. bzr co and its all there. bzr is some magical voodoo :) | 01:45 |
| Zelut | is there a preferred method of defining bzr whoami? .bashrc or..? | 01:51 |
| bob2 | using bzr whoami | 01:52 |
| Zelut | I mean, does 'bzr whoami joe hacker <email@server.org>' define it long-term or per-session? | 01:53 |
| bob2 | it writes it to ~/.bazaar/bazaar.conf (so per-machine) | 01:53 |
| Zelut | perfect. | 01:54 |
| poolie | spiv: if mhammond comes up here in the 16th do you think you'll be free? | 01:59 |
| spiv | poolie: yes | 02:02 |
| jml | poolie: has there been a change in plans? | 02:11 |
| poolie | jml, he can't get a meeting room at the hotel that week | 02:13 |
| poolie | so we can either meet at my house or postpone it | 02:14 |
| jml | ahh ok. | 02:14 |
| poolie | jml, were you wanting to come for most of that time | 02:14 |
| jml | poolie: yeah, I was. | 02:14 |
| poolie | spiv, jml, how would the week of the 23rd be? | 02:15 |
| jml | poolie: pretty god. | 02:15 |
| jml | good. | 02:15 |
| * jml smiles | 02:15 | |
| spiv | poolie: that's fine too | 02:18 |
| lifeless | back | 02:44 |
| emgent | hi lifeless :) | 02:44 |
| lifeless | hi | 02:46 |
| poolie | oh you're back already? time flies | 02:48 |
| lifeless | got lucky, only 10 minute wait | 02:49 |
| jml | that is lucky | 02:54 |
| jml | in fact, if you had witnesses, I'd suggest sending an email to the Guinness Book of Records :) | 02:55 |
| lifeless | for that doctor its amazing | 03:12 |
| lifeless | usually 2-3 hours | 03:12 |
| === thumper_laptop is now known as thumper | ||
| mneptok | lifeless: yes, please do (continued from -ops) | 03:31 |
| mneptok | O:) | 03:31 |
| lifeless | terrible man | 03:31 |
| mneptok | lifeless: although my personal motto is "non universim sed singulatem fretus," which has a far more lapidary tone. | 03:32 |
| lifeless | Sempre utor ubi-bracae perhaps | 03:33 |
| lifeless | also mneptok whats with the no-idling attitude? | 03:41 |
| mneptok | lifeless: channel rules | 03:51 |
| mneptok | lifeless: i have no idea what caused their creation, though. | 03:52 |
| abentley | lifeless: Any thoughts on whether it is kosher to mutilate the in-memory inventory of a DirStateRevisionTree? | 03:54 |
| abentley | I.e. to feed it to apply_inventory_delta? | 03:55 |
| lifeless | mmm | 03:56 |
| lifeless | so what we do is try to either modify the dirstate, or the inventory, but never both | 03:56 |
| lifeless | the inventory is re-flattened on unlock() if it has been modified (as checked by a flag in WorkingTree4) | 03:56 |
| lifeless | thats for the wt; uhm for a rev tree | 03:57 |
| lifeless | the in memory inventory is cached | 03:57 |
| lifeless | if you modify it, other callers asking for it will get the same modified inventory. This could be bad. | 03:57 |
| abentley | Half of igc's branch speed gain comes from using the existing InventoryEntry objects, rather than re-calculating the data from the TreeTransform and working tree. | 03:59 |
| abentley | Is there a way to do this safely? | 04:00 |
| lifeless | this is new clone ? | 04:00 |
| lifeless | or build tree? | 04:01 |
| abentley | This is build_tree. | 04:01 |
| lifeless | where is the dirstate rev tree coming into the picture? (I would have thought we grabbed a repository inventory ...) | 04:01 |
| abentley | The dirstate rev tree is the basis tree of the branch we are branching from. | 04:02 |
| abentley | When that revision isn't available as a basis tree, we do use a repository-backed RevisionTree. | 04:03 |
| abentley | If the source branch has a working tree that we can use, we use it to retrieve files from disk instead of the repo, which I've benchmarked as faster. | 04:05 |
| lifeless | ok | 04:06 |
| lifeless | so what do we need from the inventory - do we have an iterator we can use without upcasting from dirstate to a full inventory in the first place ? | 04:06 |
| lifeless | (making an inventory is slow in the first place) | 04:06 |
| lifeless | I realise I'm not directly answering the question. To directly answer it - add a private method to detach the inventory from the dirstate rev tree, then you own it can do $whatever you want to. | 04:07 |
| abentley | We are using iter_entries_by_dir which I don't believe creates a new inventory. | 04:07 |
| abentley | But if the cost of generating an inventory is in constructing the objects, then it's just as expensive. | 04:08 |
| abentley | Which is an unavoidable cost. | 04:09 |
| abentley | Given the input requirements of apply_inventory_delta. | 04:09 |
| igc | abentley, lifeless: the meta-question I had while profiling local branch creation was ... | 04:11 |
| lifeless | the major cost when I looked deeply at inventories was simply creating xK objects and stitching them together | 04:11 |
| igc | given a pristine local mirror, can you reuse the source dirstate to get the target one fast | 04:11 |
| igc | both apply_inventory_delta and set_parent_trees suck when run on an OOo tree | 04:12 |
| abentley | igc: pristine shouldn't matter. | 04:12 |
| lifeless | in principle you can copy the dirstate basis column to an output dirstate with a iterator and filter (to remove renamed/deleted/added rows) duplicating entries to create current-disk values | 04:12 |
| lifeless | igc: apply_inventory_delta should be good because it generally has to deal in 10's of objects not 10's of K of objects | 04:13 |
| igc | lifeless: on branch, the delta is the whole 100K entries | 04:14 |
| abentley | lifeless: apply_inventory_delta is used by build_tree when creating inventories from scratch. | 04:14 |
| lifeless | yes, I can see that. to me this comes back to 'python is slow, whats the best way to work around it' | 04:15 |
| abentley | subprocess.cmd('cp -a') | 04:15 |
| lifeless | some benchmarks might be good to check I actually drew the right conclusions (e.g. create a 100K inventory 50 times) | 04:15 |
| lifeless | abentley: I mean of the python primitives we have available' | 04:16 |
| * igc lunch | 04:18 | |
| abentley | I can tell you that when building emacs, WorkingTree4._get_inventory is 2% of total runtime, and apply_inventory_delta is 3%. | 04:19 |
| abentley | That's according to kcachegrind, of course. | 04:19 |
| lifeless | righto, step 1 - gather stats :P | 04:19 |
| lifeless | how big is emacs btw ? | 04:19 |
| abentley | 400M | 04:20 |
| abentley | Sorry, 105M | 04:20 |
| abentley | With my current patch, actually reading and writing the tree files dominates. | 04:23 |
| igc | that's good | 04:23 |
| igc | I was seeing 20-25% on the iter_changes over the accelerator tree | 04:24 |
| abentley | That's bad. I haven't changed anything that should have affected that. | 04:26 |
| igc | abentley: there's a mozilla repo in http://people.ubuntu.com/~ianc/benchmarks/repos/bzr/ that I was profiling against fwiw | 04:29 |
| igc | it's a good size without being crazy | 04:29 |
| abentley | igc: Thanks. I'm pulling that down. | 04:38 |
| abentley | I also worry that we might be optimizing for the wrong case. We tend to benchmark against hot cache. | 04:38 |
| abentley | But when branching, the branch source is likely to be cold cache. | 04:39 |
| lifeless | I would expect branch source and repository to both be cold | 04:43 |
| lifeless | abentley: you know you can drop caches right? | 04:43 |
| abentley | Yep. | 04:43 |
| igc | abentley: I agree that cold cache is the more important time | 04:59 |
| abentley | igc: Which have you been testing? | 05:00 |
| igc | hot cache is important though: it's what most people benchmark the tools on, and it highlights what we have most control over | 05:00 |
| igc | io patterns aside | 05:01 |
| igc | I've been using hot cache | 05:01 |
| abentley | What would cause our extensions to get compiled with -Wall? | 05:12 |
| Pieter | CFLAGS=-Wall | 05:17 |
| abentley | Pieter: It's not set. | 05:18 |
| jamesh | abentley: see /usr/include/pythonX.Y/config/Makefile | 05:20 |
| jamesh | distutils gets some flags from there | 05:20 |
| abentley | jamesh: Thanks. | 05:20 |
| jamesh | including -fno-strict-aliasing and other necessary ones | 05:20 |
| abentley | Turned out that wasn't the problem after all. | 05:20 |
| abentley | It was the lack of libc6-dev... | 05:21 |
| jamesh | actually, that should have been /usr/lib/pythonX.Y/config/Makefile | 05:21 |
| igc | Pieter: apologies for not getting to your fastimport/export questions/improvements - knee deep in the stacked branches reviews right now. Will do soon though. | 05:44 |
| lifeless | spiv: ping | 05:54 |
| spiv | lifeless: pong | 05:57 |
| lifeless | oh, ringing you :P | 05:57 |
| spiv | lifeless: oops, my cheek mashed the "hang up" button | 06:36 |
| igc | lifeless, poolie: all the stacked branches reviews/tweaks sent to the ML now | 06:37 |
| igc | ml: see test_branch_shallow_branch_also_shallow_same_reference() in the patch | 06:41 |
| igc | jml^^ | 06:41 |
| jml | igc: has this changed from lifeless's branch of two weeks ago, or is this a difference between API and UI? | 06:42 |
| beuno | mwhudson__, I know your day is about to finish, so these are the benchmarks against loggerhead trunk, your zpt branch, and my zpt branch, for the same 36k diff: trunk, real 1m38.033s, 400mb+ RES mem. Your zpt, real 0m35.243s, 220mb RES mem. My zpt, real 0m23.116s, 120mb RES mem. | 06:44 |
| beuno | so it's more like a 8x improvement to the current trunk | 06:45 |
| beuno | I can still shave a few seconds/mb off of it once I finish refactoring some un-needed operations, and it's missing tests. But it's looking good :) | 06:46 |
| igc | jml: it doesn't look like the UI controls this so I'm guessing it done under the API - will dig | 06:47 |
| * gour just read latest from bzr ml | 06:47 | |
| jml | igc: the patch I sent you for clone() addressed just this behaviour. | 06:48 |
| gour | having gnome on bzr, won't be bad... | 06:48 |
| jml | igc: it's possible that I'm confusing things, given my relatively shallow (no pun intended) knowledge | 06:48 |
| igc | jml: I can't apply your patch yet sorry - I think it needs abentley's policy stuff first? | 06:48 |
| jml | igc: yeah, that makes sense. I was working against abentley's branch. | 06:49 |
| jml | igc: I've sent it to him to apply. | 06:49 |
| Pieter | gour: I wonder how they decide | 06:50 |
| jml | igc: if he bounces me, then I'll redo it for bzr.dev once your patches have landed. | 06:50 |
| * beuno is off to bed | 06:50 | |
| gour | Pieter: me too, but it's better that bzr become ready if something can be done with 1.6 release taking into consideration their needs | 06:51 |
| gour | see http://guadec.expectnation.com/guadec08/public/schedule/detail/81 | 06:52 |
| abentley | jml: That patch seems like it could do serious harm. | 06:52 |
| Pieter | seems a bit odd to rush a feature so that some party may perhaps choose bazaar | 06:53 |
| jml | abentley: can you please elaborate? | 06:54 |
| abentley | jml: If I branch, I expect to have everything I need. | 06:54 |
| lifeless | Pieter: I'm not rushing the feature - I've been hacking towards all the bits coming together for months | 06:55 |
| abentley | If I push, the resources I have locally may not be available to all users. | 06:55 |
| lifeless | Pieter: I'm trying to ensure its not stuck in trunk with 3 weeks to go at a point where it may be extremely relevant for discussion | 06:55 |
| gour | lifeless: sure. if stacked branches go into 1.6 and everything can be polished a bit, i do not object waiting for 1.6 some week more | 06:57 |
| lifeless | Pieter: also, to invert things slightly, it would be strange not to work on the things that our users seem to want most :P | 06:58 |
| jml | abentley: are we talking about my patch or the UI2 patch? | 06:59 |
| gour | otoh, having big(ger) party using bzr is very good for bzr 'cause new workflows and/or user-cases are explored leading to bzr improvement in general | 06:59 |
| abentley | jml: Your patch. | 06:59 |
| gour | s/bzr impr./bzr's impr. | 06:59 |
| abentley | It causes stacking without user intervention, no? | 07:00 |
| jml | abentley: it preserves stacking without the users intervention | 07:00 |
| abentley | Tomato, potato. | 07:00 |
| lifeless | jml: preserving stacking is surprising, it doesn't fit our current behavioural model | 07:01 |
| jml | abentley: ok. I don't pretend to have a deep understanding here but it seems like a good idea for 'BzrDir.clone' to clone | 07:02 |
| jml | lifeless: given that I wrote the patch based on your guidelines I'm more than happy to withdraw support for it if you no longer think it's a good idea, conditional on me understanding why. | 07:03 |
| lifeless | oh - clone() should clone() for sure | 07:03 |
| lifeless | abentley: bzr branch uses sprout | 07:03 |
| abentley | lifeless: push uses clone. | 07:03 |
| lifeless | abentley: yes; hmm | 07:04 |
| lifeless | so the case that identified this was 'how does launchpads hosting service clone a shallow branch most appropriately' | 07:04 |
| lifeless | (without rewriting clone()) | 07:04 |
| abentley | lifeless: paramaterize clone to preserve stacking? | 07:05 |
| abentley | lifeless: Alternatively, does push *need* to use clone? | 07:06 |
| lifeless | well clone fits push much better than sprout IMO | 07:07 |
| lifeless | actually, this is high up the merge stck | 07:07 |
| abentley | Neither of them is exact | 07:07 |
| lifeless | I'm going to head-down and finish the current patch | 07:07 |
| lifeless | then I will have many more cycles to think | 07:07 |
| abentley | lifeless: fairy nuff. | 07:07 |
| abentley | jml: I can adjust the patch so the behaviour is optional. Does that appeal? | 07:08 |
| jml | abentley: it fits my use case, certainly | 07:09 |
| jml | abentley: the deeper bzr model issues I can leave to the experts :) | 07:09 |
| abentley | done. | 07:09 |
| jml | thanks. | 07:09 |
| abentley | jml: Your patch's stacked_on selection will be overridden if there is a configuration directive. Is that what you expected? | 07:22 |
| jml | abentley: no, it isn't. | 07:23 |
| abentley | i.e. if the user has a .bzrdir/config with a default_stacked_on set, your patch has no effect. | 07:23 |
| abentley | Okay then, I think we can simplify the patch. | 07:24 |
| lifeless | abentley: what jml wants is to be able to do - in the puller: | 07:25 |
| lifeless | if (we dont have the branch) | 07:25 |
| lifeless | local_branch = remote_branch.bzrdir.clone(options) | 07:25 |
| lifeless | and thats about it | 07:25 |
| abentley | lifeless: Yeah, I have a fairly good idea of the use case. I just wasn't sure whether that was a deliberate choice. | 07:27 |
| lifeless | abentley: :) | 07:27 |
| abentley | jml: Some examples of how BzrDir.clone doesn't clone: | 07:42 |
| abentley | 1. if the target has a shared repository, it always uses it | 07:42 |
| abentley | 2. if the source is in a shared repository and the target isn't, it creates a target as a standalone branch | 07:42 |
| abentley | 3. it doesn't create remote working trees | 07:42 |
| abentley | Perhaps clone is simply misnamed. | 07:42 |
| jml | abentley: hmm. | 07:42 |
| jml | abentley: the evidence is certainly mounting | 07:43 |
| abentley | jml: As another example, when you branch a subversion branch, bzr-svn doesn't create a Subversion repository. | 07:47 |
| abentley | It's really more like a mimeograph than a clone. | 07:48 |
| lifeless | branch uses sprout though | 07:48 |
| lifeless | so that other example isn't one ;) | 07:48 |
| abentley | lifeless: Sorry, "push from" | 07:49 |
| lifeless | abentley: can you actually push from a svn branch though? I didn't think they existed on disk, only conceptual branch references | 07:50 |
| abentley | lifeless: I haven't investigated. But I would assume push -d will specify a subversion branch. | 07:52 |
| lifeless | oh interesting | 07:52 |
| poolie | ok i'm starting to merge the external reference patch | 08:09 |
| chandlerc | what would cause a NotBranchError when using bzr-svn on a previously working repository? | 08:26 |
| * igc pick up kids | 08:26 | |
| lifeless | i'm callin it a week | 08:28 |
| lifeless | 5:30 time to crack a beer I think | 08:28 |
| poolie | cheerio lifeless | 08:29 |
| lifeless | might see you online :P | 08:29 |
| lifeless | otherwise tuesday | 08:29 |
| poolie | once i finish cleaning this up | 08:29 |
| poolie | btw mark is confirmed for the week of the 16th | 08:29 |
| poolie | uh | 08:29 |
| poolie | if you want to reply on tuesday to my mail re scenarios that would be cool | 08:30 |
| poolie | if only to say +1 | 08:30 |
| lifeless | sure | 08:30 |
| poolie | igc: i think you forgot the attachment? | 08:47 |
| igc | lifeless: if you're still around, abentley has suggested using a path in branch.conf vs a new branch format | 08:47 |
| igc | is that the plan for making stacked branches production? | 08:48 |
| igc | poolie: thanks. fixed. | 08:49 |
| igc | lifeless: abentley had a bunch of other good feedback as well that I found today (post my review overnight). I think we should include most/all of his suggestions. | 08:52 |
| lifeless | igc: if I understand the proposal correctly, its a bad idea, it will break, badly | 09:00 |
| lifeless | its definitely not the plan - a new branch and repository format is required | 09:01 |
| uws | Hi all. | 09:02 |
| uws | Does anyone happen to know whether the Fedora Core 8 subversion packages contain the necessary patches for bzrsvn to work? | 09:02 |
| lifeless | igc: however abently proposed using a branch.conf key rather than a new *file* for storing where things are stacked | 09:02 |
| lifeless | igc: and that was a good idea | 09:02 |
| lifeless | uws: the bzr-svn test suite can detect them | 09:02 |
| igc | lifeless: ah - ok. Here was the thread: https://lists.ubuntu.com/archives/bazaar/2008q2/040079.html | 09:03 |
| lifeless | uws: install it, run bzr selftest svn | 09:03 |
| lifeless | igc: I'm really just passing through | 09:03 |
| lifeless | igc: this can wait till tuesday | 09:03 |
| igc | lifeless: enjoy your beer. I'm off to cook dinner. Have a good weekend all | 09:04 |
| uws | lifeless: Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details. | 09:05 |
| uws | lifeless: Too bad :( | 09:05 |
| uws | lifeless: I'll have to update/compile svn myself. Would you suggest the latest stable 1.4 release + the patch, or svn trunk instead? | 09:05 |
| gour | bzr is quite ok at http://live.gnome.org/DistributedSCM | 09:08 |
| gour | uws: svn-1.5rc9? | 09:09 |
| uws | gour: http://bzr-mirror.gnome.org/ | 09:18 |
| gour | uws: ohh, nice. it means it's a serious candidate | 09:19 |
| lifeless | uws: there is a faq about this, bazaar-vcs.org/svn I think | 09:19 |
| uws | lifeless: you mean http://bazaar-vcs.org/BzrForeignBranches/Subversion?highlight=%28bzr-svn%29#python-subversion-1-5 ? | 09:20 |
| uws | lifeless: It only lists the patch, but doesn't suggest which one to use | 09:20 |
| Jc2k | uws, gour: bzr-mirror.gnome.org is my baby if you have any questions about GNOME and bzr... | 09:25 |
| uws | Jc2k: Ah. haven't used it personally yet | 09:27 |
| uws | though I use bzr mostly, my gnome development happens using svn for now | 09:27 |
| gour | Jc2k: i do not use gnome myself (only xmonad + xmobar), except some gnome apps, but would like to see gnome adopts bzr | 09:27 |
| uws | dunno what the jhbuild support for this is | 09:27 |
| uws | gour: /me too :) | 09:27 |
| Jc2k | uws: thats my other project ;) | 09:28 |
| * gour hopes that this overly-complex-easy-to-shoot-oneself-in-the-foot VCS won't prevail | 09:28 | |
| uws | Jc2k: rock on :) | 09:28 |
| Jc2k | git-mirror.gnome.org is also coming by the way.. | 09:28 |
| uws | i've never used git. it | 09:29 |
| uws | 's interface is horrible | 09:29 |
| uws | its* | 09:29 |
| Jc2k | agreed | 09:29 |
| Jc2k | i mirrored about half of GNOME in 2 days, then realised it was wrong | 09:29 |
| uws | i don't care about the kernel hackers' opinion that much | 09:29 |
| Jc2k | i have to start from scratch | 09:29 |
| Jc2k | so i have a few questions actually | 09:31 |
| Jc2k | there are a few thing the GNOME GIT people do, and are likely to whine about if they can't with Bzr | 09:31 |
| Jc2k | (regardless of whether they are good ideas or not) | 09:32 |
| Jc2k | is there an equivalent to git rebase --interactive | 09:32 |
| james_w | Jc2k: nope, it needs someone to spend some time on the rebase plugin | 09:33 |
| Jc2k | james_w: i guess its not something that a bazaar code newb such as myself can really approach, either? | 09:33 |
| james_w | Jc2k: actually, I think it should be possible. | 09:34 |
| Jc2k | oh? | 09:34 |
| james_w | I would hope that the rebase itself would be demonstrated by the existing code in the plugin, and it would just be a case of coding the interactive stuff, which hasn't got a lot to do with bzrlib | 09:35 |
| james_w | I may be being optimistic, but we would certainly help you if you wanted to give it a go. | 09:35 |
| Jc2k | i was wondering if it was maybe better as bzr-refactor as i don't think hacking apart your branch is really the same as rebasing, but yes.. am interested in giving it a go | 09:36 |
| bob2 | bzr-resequence? | 09:37 |
| james_w | Jc2k: I think "rebase --interactive" would be the way to go, as diverging from git here would probably just cause confusion. | 09:38 |
| Jc2k | ok | 09:39 |
| Jc2k | james_w: would a bzr-gitmode pluging be possible that emulated the git wc/repo/branches model? | 09:43 |
| bob2 | you could do it as a repo format | 09:44 |
| Jc2k | there was a suggestion that someone could make a bzr-loom without the stacked looms bit | 09:46 |
| james_w | Jc2k: yes, it would be possible. | 09:47 |
| james_w | Jc2k: bzr-git allows you to work with git using the bzr ui, but it would also be possible to write a plugin that gave multiple branches in one directory. | 09:47 |
| Jc2k | james_w: its the 2nd one that i'm after | 09:48 |
| Jc2k | oh, is there any way to pull a whole repo? | 09:51 |
| bob2 | multi-pull plugin | 09:51 |
| Jc2k | bob2: can that pull branches that i haven't already branched? | 09:53 |
| lifeless | jamesh: jhuild groks bzr yeah ? | 11:07 |
| jamesh | lifeless: I did some bzr support code way back, but I don't know if it is still in a working state or not | 11:07 |
| jamesh | if it isn't working, it should be trivial to fix | 11:08 |
| * AfC tried to get that to work, oh, 8-9 months ago, but I couldn't make it go. I'm not a regular jhbuild user, so it may have been something else. | 11:10 | |
| AfC | [the mapping or repository's type & href attributes to a Bazaar URL and the branch element being inside an autotools (which we don't use) one made it all a bit vague] | 11:12 |
| jamesh | AfC: the nesting of the elements actually matches the modularity of the code | 11:13 |
| jamesh | AfC: the autotools build rules can have various VCS backends plugged in to grab the code (including "download and extract the tarball" VCS) | 11:14 |
| jamesh | there are other sets of build rules (e.g. Python distutils) which use the same VCS backend code | 11:14 |
| AfC | Oh, I don't doubt its design makes sense, but I couldn't grok it is all. | 11:14 |
| Jc2k | AfC: i'm going to look at some "bzr-mirror and jhbuild" notes | 11:15 |
| AfC | Jc2k: yo dude | 11:15 |
| Jc2k | :) | 11:15 |
| AfC | Here, let me pastebin what I wrote | 11:15 |
| AfC | http://rafb.net/p/f3e70j67.html | 11:16 |
| AfC | Jc2k: (note this is slightly different from "I want to use bzr to work with GNOME modules currently living in Subversion"; I wanted to add java-gnome to the GNOME jhbuild modulesets but couldn't quite figure it out) | 11:17 |
| Jc2k | AfC: sorry, i think i phrased what i said badly - i'm going to add some notes to the bzr part of live.gnome.org about jhbuild and bzr | 11:19 |
| RainCT_school | Hi | 11:29 |
| lifeless | so, rebase -i - I think that a low entry point one that is a clone of gits should live in the rebase plugin | 11:30 |
| lifeless | james_w: bzr-git is not that complete fwiw | 11:31 |
| james_w | lifeless: hi. ah yeah, I know that, but I was just wondering what functionality they wanted. | 11:31 |
| lifeless | Jc2k: yes, multi pull can replicate a full set of branches | 11:42 |
| lifeless | Jc2k: I think its important to remember though 'the way git does it' is what contributes to the feeling you had that it wasn't the right thing when you played with it :P | 11:43 |
| lifeless | Jc2k: so we want to be somewhat careful about dropping git workflow in wholesale - providing plugins for git users that don't want to change is definitely possible though | 11:43 |
| Jc2k | lifeless: yeah, its more about eroding pro Git arguments by supplying plugins for their workflows | 11:44 |
| RainCT_school | what's the easiest way to configure bzr on a server so that it can be used over bzr-ssh://? | 11:52 |
| AfC | Jc2k: It was a shame to see that the imendio guys are using Git. So that means its probably too late for GTK, though if anyone respects letting others work together its them. | 11:53 |
| gour | RainCT_school: install it so that's in the path | 11:53 |
| AfC | RainCT_school: assuming you have Bazaar installed on the machine in question, there's not really anything further you need to do. It'll Just Workâ„¢ | 11:53 |
| spiv | RainCT_school: the URL prefix is bzr+ssh:// rather than bzr-ssh://, btw. | 11:54 |
| spiv | s/prefix/scheme/ to be precise I guess. | 11:55 |
| AfC | spiv: good catch | 11:55 |
| RainCT_school | Oh, OK. Commit privilegies just depend on the SSH configuration / system users then? | 11:56 |
| RainCT_school | spiv: yeh.. bad memory ^^ | 11:56 |
| spiv | RainCT_school: Right, ordinary filesystem permissions. | 11:56 |
| RainCT_school | great :) | 11:56 |
| RainCT_school | thanks | 11:56 |
| RainCT_school | well, gonna go. bye! | 11:57 |
| gour | AfC: gtk will move to git? | 11:57 |
| Jc2k | gour: a lot of GTK hackers are already using it, which means its harder to get them to bzr | 11:58 |
| gour | :-( | 11:58 |
| gour | one reason more to try get gnome | 11:59 |
| Jc2k | gour: but they are using it in an unoficial capacity, much like the other GNOME hackers like me and AfC are using bzr-svn | 11:59 |
| AfC | Jc2k: not exactly. They are using Git exclusively for their 3.0 work. Whether or not that ever makes it back to Subversion remains to be seen. | 11:59 |
| Jc2k | gour: GNOME will be providing some "experimental" hosting for bzr branches, though :) | 11:59 |
| AfC | Between them and the Cairo / Pango people, I'd say it's probably a lost cause. But we can keep trying. | 12:00 |
| * gour has hard time to understand why people love git...powerful? yes. but utterly complex model which stands on the way | 12:00 | |
| AfC | gour: because its fast, because it handles things like families of branches as single units, and because other projects they are familiar with use it. These things are viral. | 12:01 |
| AfC | s/its/it's/ | 12:02 |
| Jc2k | its not entirely a lost cause, git has no backing from a sysadmin. the git people need to provide a volunteer to ensure smooth operation of git.gnome.org. | 12:02 |
| AfC | gour: and, don't forget, these people are all power users. | 12:02 |
| AfC | Jc2k: at this point, with Imendio and Codethink and Collabora all hosting their own git repos, someone hosting a git.gnome.org is somewhat less relevant. Yes, Olav is on our side, but he's a sysadmin, not a hacker. | 12:04 |
| gour | i understand that...but, e.g. families of branches are just one reason why i prefer bzr (coming from darcs) | 12:04 |
| Jc2k | AfC: With a bzr-rebase --interactive, codethink can be turned. | 12:04 |
| AfC | Jc2k: :) I forced Rob to use bzr to make some fixes to java-gnome. That got him started, at least. | 12:05 |
| Jc2k | AfC: :p, Rob said he'd be willing to give bzr more of a look with rebasing. | 12:05 |
| AfC | Fact is that's just the way a lot of people look at distributed version control. It's getting on towards pointless to tell them that they're wrong. I understand and accept the arguments made by the bzr hackers about history loss, but most people don't seem to care that much because it hasn't burned them so far as they can see. | 12:06 |
| gour | right, no change until getting burnt | 12:08 |
| gour | same here...i had few serious issues with darcs | 12:08 |
| lifeless | AfC: I understand why git users rebase now better than I used to. | 13:17 |
| lifeless | AfC: its because their log is broken. | 13:17 |
| lifeless | (it sorts by date not by branch, so if you imagine 10 branches, each that last a week, all merging to mainline one after another, | 13:19 |
| lifeless | if they have 10 commits each | 13:19 |
| lifeless | and spread equally over that week | 13:20 |
| lifeless | then git log does: | 13:20 |
| lifeless | branch1-commit10 | 13:20 |
| lifeless | branch2-commit10 | 13:20 |
| lifeless | .. | 13:20 |
| lifeless | branch10-commit10 | 13:20 |
| lifeless | branch1-commit9 | 13:20 |
| lifeless | ... | 13:20 |
| lifeless | branch10-commit9 | 13:20 |
| lifeless | ... | 13:20 |
| AfC | Ouch | 13:21 |
| lifeless | now imagine trying to understand what has happened when you see that output | 13:21 |
| AfC | [of course, I am on record as being terribly unfond of `bzr log` but mostly `bzr viz` makes up for it] | 13:21 |
| jamesh | lifeless: apparently bisection techniques are easier with linear history too | 13:22 |
| AfC | lifeless: so, from a marketing standpoint, can you just say "bzr doesn't need rebase because our logging works right"? | 13:22 |
| lifeless | jamesh: its easier if you don't think about it :) | 13:22 |
| lifeless | AfC: well, I can say 'bzr doesn't provide the same anti-social pressure that makes rebase so important to git users' | 13:22 |
| AfC | lifeless: (that would be something really concrete for the compare and contrast crowd) | 13:22 |
| lifeless | or even remove the word anti- | 13:23 |
| jamesh | I think the only time I've really used the bzr-rebase plugin was to move some commits that had been made to the wrong branch | 13:24 |
| jamesh | basically a cherry picking operation | 13:24 |
| lifeless | to enlarge on the social pressure | 13:26 |
| lifeless | you want every commit to be as stand-alone as possible | 13:26 |
| lifeless | small tweaks that are part of a bigger picture become unhelpful unless they are really well documented | 13:27 |
| lifeless | you may also want the dates of each commit to be close together as this be more likely to group the commits in log | 13:27 |
| lifeless | and this fits quite well I think, wit what I see git using projects asking for | 13:29 |
| pbor | personally I'd very much like rebase in combination to some way of "rewriting history" | 13:30 |
| pbor | that is, I branch, work without minding much about about things on a branch (commits, trial and error, revert, etc) | 13:31 |
| pbor | then before merging to the master branch, rebase to the current head and rework the "branch" as a logical series of changes | 13:31 |
| lifeless | thats largely the quilt workflow | 13:32 |
| AfC | pbor: You might find that the loom thing that Robert and others supports that development style. | 13:32 |
| lifeless | and there is some user demand for loom to support this more directly | 13:32 |
| AfC | s/others/others are working on/ | 13:32 |
| pbor | which make history very good to read (not only the log, also the diffs) | 13:32 |
| AfC | I must admit I'm a bit vague on why one needs looms in an environment where people are already being encouraged to make lots of little inconsequential commits anyway | 13:33 |
| lifeless | loom is specificall designed for collaborative quilts, if I can coin a phrase | 13:33 |
| jamesh | it also helps create the illusion of infallibility :) | 13:33 |
| AfC | jamesh :) | 13:33 |
| AfC | That said, I must admit I am often hesitant to make micro commits in the face of needing to set the example to encouraging others to send me good quality patches with well written commit messages. | 13:34 |
| pbor | AfC: it is useful because I can work on a branch as I like, but then submittit as a logical and clean series of consecutive and evolutionary patches | 13:34 |
| jamesh | the testing angle is the biggest problem I have with rebase | 13:34 |
| AfC | jamesh: yeah, I buy that one now too | 13:35 |
| lifeless | AfC: so perhaps you don't need such good quality (individual commits) and well written (individual commit messages) | 13:35 |
| AfC | lifeless: I'm not sure about that | 13:35 |
| lifeless | AfC: and perhaps could instead want good quality (merges) and well written (merge commit messages) | 13:35 |
| lifeless | this is all the the bzr project *itself* looks for | 13:35 |
| AfC | tools like viz and gannotate make sense when the meta data they display has some relevance to the code in question. | 13:36 |
| lifeless | thats true | 13:36 |
| AfC | lifeless: [well, since I'm the poor shumck who does the merges, yes, I try to do that as best I can. | 13:37 |
| lifeless | the barrier for that is relatively low though, in large part because of the topological grouping of data | 13:37 |
| AfC | The point being made here, though, is sorta standing out in my current experience as a sore point] | 13:37 |
| AfC | Its almost like I wish for something to "roll up" a series of revisions into a single "commit". YES I realize that merges can fill that function, but there are lots of other merges that happen too. | 13:38 |
| lifeless | you know about log --line ? | 13:39 |
| AfC | (and I don't feel like being the only person who has to write good commit messages, which is why I am so completely frustrated with the fact that `bzr log --line` only prints left hand most revisions | 13:39 |
| AfC | Its almost enough to make me go use something else I hate it so much) | 13:39 |
| lifeless | AfC: so what I am saying is require that the *submission* contains the pre-written commit message, and make it a good one | 13:39 |
| AfC | lifeless: right, so that's what you guys do with bug bunny, but that's out of band to the VCS tool | 13:40 |
| AfC | which seems a serious oversight. | 13:40 |
| AfC | (ie, it's nice that you gents have it all nice and sorted, but it doesn't help anyone else who has the temerity not to use your PQM code management model) | 13:41 |
| AfC | (ie, everyone else trying to use bzr) | 13:41 |
| AfC | {shrug} these are my pain points. | 13:41 |
| AfC | I point these out only because a) they've been my pain points more or less since the beginning [that and no cherry picking], and b) they're my *only* pain points to what is otherwise an excellent experience. | 13:42 |
| pickscrape | I had an idea the other day for a log format that showed only the 'leaves'. I wonder how useful that would be. | 13:43 |
| AfC | lifeless: I have more or less come around to abandoning revision commit messages and asking people to edit a ChangeLog file instead. I was so happy not having to have people do that over the last 2 years, but... | 13:43 |
| AfC | pickscrape: (that would seem to assume that all of the mainline commits are merges, which may not be accurate either) | 13:44 |
| lifeless | AfC: so, I have been mulling having a editable merge-message in branches | 13:44 |
| lifeless | AfC: for precisely this reason | 13:44 |
| AfC | lifeless: that's an interesting notion | 13:44 |
| pickscrape | Any mainline commit that is not a merge would be considered a leaf. | 13:44 |
| AfC | pickscrape: (ah) | 13:44 |
| pickscrape | In fact, the point is only show non-merge commits | 13:44 |
| AfC | pickscrape: well I'd love that personally, because then my projects would look like they were written by the people who wrote them, and not all "Andrew Cowie" | 13:45 |
| pickscrape | It's like --short, but where you have a merge, substitute it with the commits that made up the merge | 13:45 |
| pickscrape | Grossly simplified of course, but that's the idea | 13:45 |
| lifeless | AfC: log should be taught to honour --author | 13:45 |
| lifeless | AfC: vs committer, we do differentiate; hmm is there a bug on that | 13:45 |
| uws | lifeless: It seems log shows the author | 13:45 |
| AfC | pickscrape: [though along the way I got into the habit of also making real changes during merges until I finally learned that this wasn't helping and Robert showed me a few other ways to do it] | 13:46 |
| pickscrape | Hmm, changes made during the merge would be a problem with such a format | 13:46 |
| AfC | lifeless: it's not the author vs committer thing, it's the fact that the only revisions shown by `bzr log --line` of, say, bzr.dev were all written by some ninja named Canonical Patch Queue Manager. Dunno who that guy is, but man are they ever slick. | 13:47 |
| AfC | pickscrape: hence my just wanting *all* revisions in single line format, not just left hand most | 13:47 |
| uws | AfC: Btw, it's "bzr vis", not "bzr viz", you heretic. | 13:48 |
| AfC | uws: WORKSFORME | 13:48 |
| lifeless | AfC: that is precisely commiter vs authro | 13:48 |
| lifeless | AfC: pqm does not yet do --author for us, when it does, the output you are talking about will change | 13:49 |
| lifeless | (for new commits since that point) | 13:49 |
| pickscrape | I was meaning to ask about that | 13:49 |
| AfC | lifeless: what happens when there are 13 authors who contributed 450 revisions that collectively roll up to a single left-hand-most merge? Why aren't they being shown? A single --author has nothing to do with this | 13:49 |
| uws | AfC: American spelling degeneration ;P | 13:49 |
| pickscrape | If you use --author, does that credit *all* lines to that author, even if the branch being merged contained work from more than one person? | 13:49 |
| AfC | uws: ah. I didn't realize they had added "vis" as a short form. | 13:50 |
| lifeless | pickscrape: it credits the commit, in a social sense. bzr always knows where lines come grom | 13:50 |
| AfC | uws: that's good of them | 13:50 |
| lifeless | *from* | 13:50 |
| pickscrape | lifeless: sweet | 13:50 |
| pickscrape | This is one of the things about svk that we struggle with the most. The merger gets credit for everything. | 13:50 |
| pickscrape | svn's limitation really | 13:51 |
| lifeless | yup | 13:51 |
| AfC | pickscrape: which is, outside of `bzr gannotate`, the impression created by Bazaar. | 13:51 |
| AfC | (unless they're doing a shared central model and checkouts, of course, then lots of people are committing to left-hand edge. I suppose I should allow for that) | 13:52 |
| pickscrape | AfC: I think lifeless has said that they're going to get PQM setting --author, which fixes that problem | 13:52 |
| AfC | Bah | 13:52 |
| pickscrape | Actually it was on a recent blog post too | 13:52 |
| AfC | That's what I'm talking about. | 13:52 |
| AfC | I have no intention of using Canonical's Patch Queue Manager bot. | 13:52 |
| AfC | and most other people I have interacted with don't plan to adopt it either. | 13:53 |
| lifeless | its not canonicals | 13:53 |
| lifeless | though we are paying the maintainers these days | 13:53 |
| AfC | One of Bazaar's hallmark's is the support of multiple workflows. | 13:53 |
| pickscrape | But it's PQM that causes the perceived single-commitor problem with the bzr source | 13:53 |
| AfC | This is lovely. | 13:53 |
| AfC | But when I keep hearing that "really, to make it work you need to use PQM" I go from being quite bullish about Bazaar to being slightly off put. | 13:53 |
| lifeless | and yes, there is no need to adopt it, it only fits some quite specific needs (primarily - run 10's of minutes long tests during merge commits( | 13:54 |
| AfC | pickscrape: no, it's any project where the mainline is maintained by a gatekeeper. | 13:54 |
| lifeless | AfC: tell me who says that and I'll biatch-slap them the next time I meet them | 13:54 |
| AfC | You know, say, the linux kernel, or any other such star model. | 13:54 |
| pickscrape | AfC: can they not use --author? | 13:55 |
| AfC | lifeless: :) | 13:55 |
| AfC | pickscrape: If I am merging a branch with revisions from 2-10 unique individuals, who is the --author? | 13:55 |
| AfC | (even assuming `bzr log --line` were to start reporting such data) | 13:55 |
| AfC | YES, I realize that what I need to do is write a custom logger, but the reason I am fighting this so steadily is that I believe the left hand bias in Bazaar is wrong and does a disservice to the authors of all the subordinate revisions. | 13:56 |
| pickscrape | Well, the merger is the author of changes made during the merge that didn't come from the merged revisions. How else to do it though, short of having multiple 'author' values for each commit? | 13:56 |
| AfC | pickscrape: what you said earlier: don't only output left hand edge revisions. Output all revisions and a single summary line. After all, `bzr vis` can handle it, why can't `bzr log`? | 13:57 |
| pickscrape | It does doesn't it? | 13:58 |
| lifeless | night guys | 13:58 |
| AfC | Answer, because of the bias embedded in the command that only left hand revisions are significant. I understand the original argument in favour of this. I just think it is wrong | 13:58 |
| pickscrape | So you want something like --short which outputs the same revisions as --long? | 13:58 |
| AfC | pickscrape: --short only does left hand edge as well. I want something like `bzr log` that presents single lines. | 13:59 |
| pickscrape | Yeah, what I said :) | 13:59 |
| AfC | pickscrape: in order to a) see all the history and b) have credit clearly attributed to the people that did the work | 13:59 |
| pickscrape | Doesn't sound too difficult | 13:59 |
| * gour shares AfC's sentiments | 13:59 | |
| pickscrape | What would you call it though? | 14:00 |
| pickscrape | 'brief'? | 14:00 |
| AfC | Alas, I am not a bzr hacker, and in any case would never get such a patch past the bias I have described. Because until the core hackers agree that the current behaviour is doing a disservice to people, they won't change it / accept a change to it. | 14:00 |
| AfC |  {shrug} it's their code | 14:00 |
| AfC | pickscrape: --line !!!!!! | 14:00 |
| lifeless | meh | 14:00 |
| pickscrape | --line already exists | 14:00 |
| lifeless | we have a long history of changing our opinion on new information | 14:01 |
| pickscrape | Would you want the right hand revisions to be indented, or the whole thing flat? | 14:01 |
| AfC | lifeless: Indeed. That's why I am attempting to present a case that this should change | 14:01 |
| lifeless | the most *effective* way to do this is to write a plugin that does the thing you want, and when folk use it on mass because its so much better, well -> it gets into mainline | 14:01 |
| AfC | lifeless: but fully accepting that it won't change unless you want it to | 14:01 |
| lifeless | AfC: I don't think its better, I think it is likely to have nearly all the negative connotations of git's log; but I may not be understanding what you want - so why not actually just do it? | 14:02 |
| lifeless | oops :P | 14:03 |
| lifeless | mind you, 11pm at night | 14:03 |
| pickscrape | :) | 14:04 |
| sabdfl | morning folks | 14:52 |
| === mw|out is now known as mw | ||
| emgent | morning sabdfl | 15:15 |
| sabdfl | morning emgent | 15:16 |
| sabdfl | i have an issue with bzr check on a large tree | 15:16 |
| sabdfl | it makes it through the first part fine | 15:16 |
| sabdfl | then gets stuck | 15:16 |
| sabdfl | checking versionedfile 0/8616 | 15:16 |
| sabdfl | any suggestions? | 15:16 |
| jam | lifeless, AfC: 'bzr log' *does* honor --author | 15:33 |
| === kiko-afk is now known as kiko | ||
| jam | sabdfl: if you do ^| (ctrl+shift+\) it should break you into a debugger, and you could try to look at what it is currently doing | 15:38 |
| jam | use 'bt' to get a backtrace | 15:38 |
| jam | 'c' to continue | 15:38 |
| jam | you could paste the backtrace | 15:38 |
| jam | sabdfl: is the "throbber" ticking, or nothing at all? | 15:39 |
| jam | you could also try "strace -P PID" etc to see if there is actually stuff happening. | 15:39 |
| dato | (-p PID) | 15:48 |
| Pieter | is there a way to apply git/mercurial like patches (with commit log and author information)? | 15:51 |
| === abadger19991 is now known as abadger1999 | ||
| Ng | could bzr be slightly modified so when you do a status, it tells you that it's not playing with a subdir because it's a branch of its own? atm they just show up in "unknown" | 16:52 |
| abentley | Ng: If you use status --short, it's show up specially. | 17:16 |
| Ng | abentley: kinda seems the same as properly unknown stuff - a ? | 17:17 |
| abentley | It doesn't append + to the filename? | 17:17 |
| abentley | Strange. I thought it used to. | 17:18 |
| Ng | not afaics | 17:20 |
| jam | abentley: I believe you have to be in subtree format, otherwise we don't *detect* that directories are subtrees | 17:24 |
| pickscrape | If I have a change I want to contribute to bzr-gtk via the new review feature, do I need to register a branch against bzr-gtk and push to it, or is there some other way? | 18:44 |
| beuno | pickscrape, same as with bzr, there is a bzr-gtk mailing list where you send merge-directives | 18:44 |
| pickscrape | oic | 18:45 |
| beuno | (bundles, patches, not sure what the term is currently) | 18:45 |
| pickscrape | Will it matter if I'm not subscribed to that mailing list? | 18:47 |
| beuno | well, you could subscribe and set it so you don't get emails | 18:48 |
| pickscrape | didn't know you could do that :) | 18:48 |
| beuno | yeap yeap, mailman setting | 18:48 |
| pickscrape | Hmm, apparently "lists.canonical.com uses an invalid security certificate" | 18:49 |
| jam | pickscrape: I believe it is signed with lists.ubuntu.com or something like that | 18:58 |
| pickscrape | eek! the bzr-gtk code is riddled with trailing whitespace... :) | 19:03 |
| * gour wonders what editor did it | 19:05 | |
| pickscrape | Shelve to the rescue | 19:06 |
| ekimus | hmmm why do I get this: "bzr: ERROR: Transport operation not possible: http does not support mkdir()" it happens when I want to push to an empty branch on launchpad.... | 19:11 |
| beuno | ekimus, you should set: bzr launchpad-login username | 19:12 |
| beuno | then, you will have to use --use-existing-dir with push | 19:13 |
| ekimus | *lol* happens when you start working on a new host :) | 19:13 |
| beuno | and you're on you way | 19:13 |
| beuno | *your | 19:13 |
| pickscrape | beuno: thanks for your help on sending to bzr-gtk | 19:13 |
| beuno | (the --use-existing-dir switch is just for this time, since the http failure creates the branch dir) | 19:14 |
| beuno | pickscrape, my pleasure :) | 19:14 |
| jam | ekimus: you need to 'bzr launchpad-login" | 19:18 |
| jam | beuno: why do you have to "--use-existing-dir" ? | 19:18 |
| pickscrape | I've had to do that too. | 19:19 |
| beuno | jam, for some reason, LP creates the dir when you try http | 19:19 |
| beuno | I think I go through this half a dozen times a day (the lp-login bit), so I really hope 1.5/1.6 can get upgraded into hardy 8.04.1/2 | 19:20 |
| beuno | (1.4 or 1.5 LP plugin does a better job at explaining how to solve it) | 19:21 |
| jam | beuno: except it doesn't tell you to use '--use-existing-dir' :) | 19:21 |
| beuno | jam, heh, right | 19:22 |
| beuno | but I think the bzr error doe | 19:22 |
| beuno | *does | 19:22 |
| beuno | so most users may figure out that last bit by their own | 19:22 |
| beuno | or that may wishful thinking :) | 19:22 |
| pickscrape | Yes, I figured it out. I thought it was a bit weird though, and hoped that I wasn't breaking anything... :) | 19:23 |
| jam | beuno: so i just upgraded my public repo to packs, and now Launchpad has decided it wants all of my bandwidth | 19:23 |
| jam | I'm glad I don't have a strict upload cap | 19:23 |
| jam | though who knows, maybe I do and just never hit it :) | 19:23 |
| jam | I have 169 branches owned by me registered in launchpad. I have a feeling at least 150 of those are mirrored | 19:24 |
| jam | and all of it will take ~50-70 MB to transfer | 19:24 |
| beuno | oh, that's quite a lot | 19:24 |
| beuno | you're canonical, can't you just ssh and upgrade? :p | 19:25 |
| jam | beuno: mirrored branches aren't hosted on the ssh side | 19:25 |
| jam | and I don't think they give direct access to that stuff anyway | 19:25 |
| beuno | and you're upgrading the mirrored branches? | 19:26 |
| statik | hi! i tried upgrading a large shared repository to rich-root-packs, and I got a KnitCorrupt error. i thought i'd check in here before doing anything with it | 19:26 |
| jam | I'm upgrading my public repo, which chains down to everything LP is mirroring for me | 19:26 |
| jam | statik: something about missing a revision? | 19:26 |
| jam | or something else | 19:26 |
| beuno | jam, ah, good thing it's friday. "leave it, check back monday" :) | 19:26 |
| statik | jam: sha-1 of reconstructed text does not match expected, for a version that looks like it was Arch | 19:26 |
| statik | (this is a my launchpad shared repo) | 19:27 |
| jam | statik: you might be hitting what mpt ran into a while ago, does this happen to be something you got from devpad/rocketfuel? | 19:27 |
| statik | jam: yes indeed | 19:27 |
| jam | statik: abentley was helping mpt with that yesterday | 19:27 |
| jam | best to find out their solution | 19:27 |
| jam | I believe there is something weird in one of the inventory texts | 19:28 |
| jam | (oh, and spiv helped before that) | 19:28 |
| statik | jam: cool, thanks for the tip | 19:28 |
| jam | statik: why 'rich-root-pack' rather than '--pack-0.92' ? | 19:28 |
| jam | out of curiousity | 19:28 |
| abentley | statik: We went back to a known-good revision and recommitted the changes as one big commit. | 19:29 |
| statik | abentley: oic | 19:29 |
| radix | btw, is there a blueprint or something where I can follow the status of Stacked Branches? | 19:29 |
| abentley | statik: However, you may not have the same issue he had. | 19:29 |
| statik | i'm just doing an upgrade, this looks like a very old revision | 19:29 |
| statik | I'll pastebin the traceback | 19:29 |
| jam | hmm... it seems like it is going to take 15GB of transfer before Launchpad is going to be happy with my mirrored branches. | 19:30 |
| jam | Or 5 days of solid transfer at my 30kB/s upload cap | 19:30 |
| jam | I think I need to find a different solution | 19:30 |
| abentley | static: Yes, so you've probably got an instance of 234748 | 19:30 |
| abentley | statik: ^^^ | 19:31 |
| abentley | statik: Bug 234748 causes false reports of corruption. | 19:31 |
| ubottu | Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Fix released] https://launchpad.net/bugs/234748 | 19:31 |
| abentley | bzr.dev has a fix. bzr 1.2 was unaffected. | 19:32 |
| statik | abentley: I was hoping this was the same issue that had already been solved, great! is it appropriate to update my bzr.dev checkout and run upgrade again? | 19:32 |
| statik | I'm running bzr.dev now, but about 14 revisions old | 19:32 |
| beuno | jam, how do you know that in advance? | 19:32 |
| jam | beuno: 150 branches, approximately 90 MB each | 19:33 |
| jam | I imagine the older ones will be smaller | 19:33 |
| abentley | statik: I would update your bzr.dev and run check first. | 19:33 |
| jam | but the total size of packs + indices is 97MB for that repo. | 19:33 |
| statik | abentley: excellent, i'll do that. thanks for the help! | 19:33 |
| abentley | statik: np | 19:33 |
| jam | Anyone here know how to use "tc" well? | 19:34 |
| jam | I'd rather have 10 days of 50% capacity than 5 days of 100% | 19:34 |
| beuno | jam, if you have another server to ssh to, it may make sense to do it from there | 19:34 |
| jam | beuno: do what from there? Remember this is Launchpad *pulling* my branches, not me pushing | 19:35 |
| jam | And you can't pre-push to the same location | 19:35 |
| jam | because mirrored branches don't share disk space with hosted branches | 19:35 |
| jam | I would complain in bzrlp, but they are all gone for the weekend. :) | 19:35 |
| beuno | jam, ah, right. You'd have to move what you have to the server, which defeats the point | 19:36 |
| statik | abentley: I was running upgraded for a shared repo, but it looks like check needs to run in a branch. does it matter which branch I run check in? | 19:36 |
| abentley | statik: Just make sure it's a branch of whatever triggered the error. | 19:37 |
| statik | abentley: ok. wow, check gives me File "/home/emurphy/src/bzr.dev/bzrlib/repository.py", line 1570, in iter_reverse_revision_history | 19:38 |
| statik | parents = graph.get_parent_map([next_id])[next_id] | 19:38 |
| statik | KeyError: 'launchpad@pqm.canonical.com-20080606133605-f13slt1fhp14unnw' | 19:38 |
| abentley | statik: That's not necessarily a bad thing, but I need to finish up what I'm doing. Can I get back to you? | 19:40 |
| statik | abentley: sure thing. thanks for your assistance on this. | 19:40 |
| jam | statik: that looks like you have a ghost in your mainline | 19:52 |
| statik | jam: it's over my head, this is the same launchpad repo I've been using on this box for over a year | 19:52 |
| jam | statik: give me a sec, but I'm betting you haven't done "bzr log --long --no-aliases" on it | 19:53 |
| statik | jam: should I be moving my .bzr.backup directory back? | 19:53 |
| jam | statik: Isn't it called "backup.bzr" ? | 19:53 |
| statik | heck no I don't run log on big repositories, it takes too long :) | 19:53 |
| jam | Or is this older than that | 19:53 |
| jam | statik: if this is the converted repo, it is likely to be broken, with stuff missing, yes | 19:53 |
| statik | jam: my mistake, I have two of them, looks like I forgot to delete the backup when I upgraded to packs a while back | 19:53 |
| jam | if the 'upgrade' did not complete | 19:54 |
| statik | jam: no, this is the source tree for launchpad itself | 19:54 |
| statik | not the conversion | 19:54 |
| jam | statik: it is the one you tried to 'upgrade --rich-root-pack' and it failed mid-way, right? | 19:54 |
| statik | jam: right | 19:54 |
| jam | so that is probably broken, I would copy bzr.backup back into place, and then run bzr check to make sure everything is working | 19:55 |
| statik | ok, trying that now | 19:55 |
| jam | keep copies of stuff when possible | 19:55 |
| statik | definitely | 19:55 |
| pickscrape | What are ghosts anyway? I keep hearing about them, but don't know what they are. | 19:55 |
| jam | statik: I do have a script here: http://launchpadlibrarian.net/15061264/copy_all_revisions.py | 19:56 |
| jam | In case we need to fill in any gaps | 19:56 |
| jam | pickscrape: revisions which are referenced, but not present | 19:56 |
| jam | so a node can say "I have parents XXX and YYY" but the repository may not contain "YYY" | 19:56 |
| statik | cool, check is getting a lot farther than before | 19:56 |
| pickscrape | oic | 19:56 |
| pickscrape | So basically a repo can't by definition 'contain' a ghost | 19:57 |
| Pilky | statik: hey, how are you finding BazaarX | 19:57 |
| statik | Pilky: it looked nice when i ran it yesterday, but I didn't manage to get it to do anything yet (only played for 5 minutes) | 19:58 |
| Pilky | cool, well let me know if you have any suggestions or anything :) | 19:59 |
| statik | Pilky: I'm pulling the latest now and trying to run it again while I wait for my 38K revisions to finish checking :) | 20:00 |
| jam | pickscrape: if you want to look at it that way, it "has" a "ghost" because it doesn't "have" the revision. | 20:00 |
| Pilky | heh | 20:00 |
| statik | pilky, i'm a bit confused about what to do at first. I see the + button, but not sure what the dialog means | 20:01 |
| statik | is this asking me to tell it about a branch that I already have? | 20:01 |
| Pilky | well, if a branch already exists it just adds it, otherwise it will create a new one in the selected directory | 20:02 |
| Pilky | same if you choose repository | 20:02 |
| Pilky | when creating a branch you select which repository you want it to appear in, or if you just want it to be a standalone branch | 20:02 |
| statik | Pilky: cool, that makes sense. When I type a name, select branch, and point it to my standalone branch of bazaarx, the add button doesn't do anything | 20:02 |
| statik | do I put a human readable name in the Name field, or a path? | 20:03 |
| pickscrape | jam: in the same way that something can have a hole in it :) | 20:03 |
| Pilky | human readable name in the name field | 20:03 |
| jam | pickscrape: pretty much | 20:03 |
| statik | Pilky: not sure then, clicking the add button doesn't do anything for me :( I'm running this via the "Build and Go" button in XCode, is there a way I can dig out some more info so you can tell what is happening? | 20:04 |
| Pilky | aha, just had an idea... where is bzr stored on your machine, /usr/bin or /usr/local/bin ? | 20:05 |
| Pilky | atm BazaarX is hard coded to look in /usr/local/bin | 20:06 |
| statik | oh, that might be the thing. I normally run bzr.dev linked into ~/bin | 20:06 |
| statik | I can add a symlink, no problem | 20:06 |
| Pilky | there'll be an option in the preferences of 0.1 to change that | 20:06 |
| statik | cool | 20:06 |
| radix | jam, statik: I've read your blog post which points to https://edge.launchpad.net/bzr/+milestone/1.6 , but I don't see anything about stacked branches there. I'm wondering what the status is and if it's going to be in 1.6 | 20:07 |
| jam | radix: we are reviewing the code changes right now, and will probably slip the final 1.6 release to make sure stacked branches are merged | 20:08 |
| statik | stacked branches are the future! the future is now! | 20:08 |
| radix | that's good to hear :) | 20:08 |
| radix | I'm *really* excited about it | 20:08 |
| radix | It means I'll be able to use Launchpad for my larger projects, finally | 20:08 |
| statik | radix: i have been doing my best to destroy launchpad with large branches and failing. I've uploaded over 30GB of branches in the last weeks | 20:09 |
| statik | please join me | 20:09 |
| radix | statik: awesome! | 20:09 |
| Pilky | statik: btw, you may occasionally notice the odd beachball when running things, at the moment we're designing it on the assumption that bzr will get faster so it's all done in the main thread atm | 20:09 |
| statik | awww, cmon. the world is parallel, multicore, etc. | 20:10 |
| statik | Pilky: seriously though, I do work on branches that are hundreds of megs, with many thousands of revisions, it's very likely that some operations will take longer than you want to block the main thread | 20:10 |
| Pilky | true | 20:11 |
| statik | Pilky: so now that I've told BazaarX about a standalone branch, what can I do with it? | 20:11 |
| statik | I still only see the big merge icon in the middle | 20:11 |
| Pilky | well, if you click on it, it will do a status on it | 20:11 |
| Pilky | blue is modified, green is added, grey is unknown, red is removed | 20:12 |
| Pilky | you can then commit/add by clicking on the toolbar items (no icons yet but they should be top left) | 20:12 |
| statik | huh, I'm not seeing anything happen when I click on it | 20:13 |
| Pilky | hmm.. | 20:13 |
| Pilky | is anything coming up in your run log in Xcode? | 20:14 |
| statik | I've restarted the whole app now that I added the symlink, added a second reference to my bazaarx branch, but still don't see anything | 20:14 |
| statik | ah, the run log. I was trying to find something like this earlier | 20:14 |
| statik | yes, Range or index out of bounds on NSCFSTring substringToIndex | 20:15 |
| Pilky | hmm | 20:15 |
| statik | I'm not that familiar with XCode, so no idea how to get a stack trace for that, but I'm willing to try if you can explain how to do it | 20:16 |
| Pilky | hmm, well you could put a breakpoint on substringToIndex but that would stop for every substringToIndex, not just the ones in my code | 20:18 |
| Pilky | I've got an idea what it could be though | 20:18 |
| Pilky | have you got any blank lines in your global ignore file? | 20:20 |
| Pilky | I'm forgetting a bit of error checking | 20:20 |
| statik | Pilky: no, it looks like it's totally standard, 8 lines of patterns | 20:21 |
| Pilky | hmm | 20:21 |
| tethridge | is it possible to just remove a specific revision after other commits have been made? | 20:21 |
| statik | tethridge: you have to uncommit all the way back | 20:22 |
| tethridge | damn | 20:22 |
| beuno | or branch from that revision | 20:22 |
| tethridge | I was hoping for some kind of undocumented bzr uncommit -r 3 | 20:22 |
| beuno | and commit everything else | 20:22 |
| beuno | (probably faster if it's a lotof commits) | 20:23 |
| statik | tethridge: I think that would leave a hole in the history or something like that | 20:23 |
| tethridge | I'm contributing to a project and I had submitted a patch, then started working on something else. | 20:24 |
| tethridge | then they wanted me to revise the patch | 20:24 |
| statik | tethridge: you should check out looms! they are perfect for that use case | 20:24 |
| tethridge | but to do so I'd have to branch at the revision I made the patch and then reapply the changes I made for the patch after I had done the other work. | 20:25 |
| tethridge | looms? | 20:25 |
| tethridge | link? | 20:25 |
| statik | https://launchpad.net/bzr-loom | 20:25 |
| statik | you can keep each patch that you submit in a separate "thread" | 20:25 |
| beuno | thekorn, or, feature branches. Branch everytime you're going to work on something different (I still haven't jumped on the looms wagon) | 20:25 |
| statik | when the code reviewers ask for a revision to the patch, you can drop back down to that thread and revise only your patch | 20:25 |
| tethridge | statik, looms sounds like the answer | 20:26 |
| tethridge | branching for each feature seems like a lot of waste if the project is large | 20:26 |
| tethridge | I assume that it makes a complete copy | 20:26 |
| beuno | tethridge, not if you're using a shared repo (which you should for this workflow) | 20:27 |
| beuno | but, looms is *the* way to go | 20:27 |
| statik | tethridge: no, branches are super lightweight if you use a shared repo, and you can even switch a single working tree between branches easily, it's just that looms make this specific use case a bit easier to manage than doing it with branches | 20:27 |
| Pilky | statik: just committed some changes to LP with better error checking, try getting the latest revision and seeing if that fixes your problem | 20:31 |
| statik | Pilky: glad to | 20:31 |
| Pilky | I really need to get into the habit of checking the length of a string before trying to get a substring of it, it seems to be my most common runtime error | 20:32 |
| statik | Pilky: I see files! this is great | 20:33 |
| Pilky | heh, cool | 20:33 |
| abentley | statik: jam got you sorted? | 20:33 |
| statik | abentley: yessir, looks like i was running check on the busted repo when i needed to have moved back the backup and started over | 20:33 |
| statik | thanks | 20:33 |
| abentley | np | 20:34 |
| jam | statik: can you help me out with some testing? | 20:34 |
| jam | I'm trying to set up rate limiting | 20:34 |
| jam | and want to make sure it is working | 20:34 |
| tethridge | any of you guys work for canonical? | 20:35 |
| tethridge | I have a quick off topic question if you do | 20:36 |
| jam | tethridge: I do, as does statik and abentley, but I don't know if they're talkative | 20:37 |
| statik | jam: on the phone, but happy to help testing something | 20:37 |
| tethridge | I've tried my question on launchpad answers, but it went unanswered | 20:37 |
| tethridge | I was just wondering if there had been any talk of providing landslide for a limited number of machines? | 20:37 |
| tethridge | I was thinking that it could be used by developers | 20:38 |
| statik | what is landslide? | 20:38 |
| beuno | landscape? | 20:38 |
| jam | tethridge: I think he means landscape | 20:38 |
| jam | radix would be the person to ask | 20:38 |
| tethridge | it would provide more users to help find issues without affecting the amount of paying users | 20:38 |
| radix | hello | 20:38 |
| tethridge | yes landscape | 20:38 |
| tethridge | I was just curious | 20:38 |
| * radix --> privmsg | 20:40 | |
| statik | btw jam, thanks for posting about fast-forward on your blog, that was useful to me | 20:46 |
| === mw is now known as mw|food | ||
| tethridge | I've seen that there is a plugin that allows a user to have a bzr branch of a subversion repository. The user uses bzr and the bzr plugin sends commands to subversion so that the user doesn't need to interact with subversion. Is there a plugin similar to this for clear case? | 21:49 |
| tethridge | so I'm guessing that there isn't a bzr-clearcase plugin that I haven't heard of | 22:13 |
| lifeless | hi | 22:14 |
| lifeless | I have heard rumours of folk doing a plugin inside companies using clearcase; I have not seen any code or heard of them making the plugin available :( | 22:15 |
| === mw|food is now known as mw | ||
| tethridge | we use a bastardized version of clearcase that really sucks | 22:16 |
| tethridge | it makes it such that viewing the history of a file is next to impossible because of the way they are constantly merging | 22:16 |
| tethridge | so basically I'm working without a history | 22:16 |
| tethridge | technically it exists, but it takes forever to find the actual changes to a specific file | 22:17 |
| bpeterson | What does this mean? TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x205c550>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. | 22:32 |
| beuno | bpeterson, many things. I believe that masks other potential problems. Can you try pushing/pulling again? | 22:33 |
| lifeless | bpeterson: it basically indicates an exception on the server which the client hasn't properly accomodated | 22:43 |
| lifeless | bpeterson: I believe the new client and server protocol in 1.6 will help this immensely | 22:43 |
| lifeless | bpeterson: if you check ~/.bzr.log on the server there is probably an exception logged | 22:43 |
| wolever | Here's my problem: I've been working out of my own bzr repository for a few days, and I want to push it up to an SVN server so other people can use it. Is there some way I can push the history from my repository into the SVN repository? | 22:44 |
| lifeless | if you made your branch with 'bzr branch svn-url' then doing 'bzr push' should work | 22:45 |
| wolever | The work I stared was pulled from another SVN repository (which I don't have +w to). | 22:46 |
| wolever | So that won't help me here. | 22:46 |
| wolever | I've checked out the new repository with `bzr co http://...`, but I don't know how to copy from one to the other (or even if that's the right thing to do) | 22:46 |
| radix | why not just publish the bzr branch? the SVN users from the first repo aren't going to get much benefit with respect to merging and stuff, if you create a completely separate SVN repository | 22:46 |
| wolever | radix: It would be lovely if I could, but "everyone else" (for some value of "everyone else") uses SVN | 22:48 |
| wolever | That, and I don't have access to the server (apart from `ssh://...` access) | 22:48 |
| radix | are you trying to fork the project, or somehow allow the original developers to get access to your branch and be able to merge it? | 22:48 |
| radix | if the latter, the best format for them will probably be a patch | 22:49 |
| wolever | I've forked a project, and now I want to give the people I'm working with access to what I'm doing | 22:49 |
| radix | ok | 22:49 |
| radix | I'm not sure if it's possible, but I guess you could create a new SVN repository ("svnadmin create" IIRC) and try pushing your branch to it | 22:50 |
| wolever | A patch won't work because the changes are significant and I'm not sure if the original project is still being developed. | 22:50 |
| jam | wolever, radix: Is it possible to 'svndump' a repo you don't have +w to? | 22:50 |
| radix | It's an "svnadmin" subcommand, which gives me the impression it requires local access | 22:50 |
| jam | radix: that was my guess | 22:50 |
| jam | and a general problem with a SVN repo | 22:51 |
| jam | if they aren't using it, nobody gets to | 22:51 |
| wolever | jam: I believe so... At least, I've used svnsync to do it | 22:51 |
| radix | ah, well | 22:51 |
| jam | wolever: right, you could svnsync their repo | 22:51 |
| jam | but I don't know how they would get your changes back | 22:51 |
| radix | ah, ok | 22:51 |
| jam | you could sync, 'bzr svn-push' into your mirror | 22:51 |
| jam | but then you have an SVN repo they can't *really* use | 22:51 |
| wolever | Ok, lemme try with svn-push | 22:51 |
| wolever | The problem with merging is that it complains that the two repos don't share a common base, and when I give it one, I get nothing but conflicts: | 22:52 |
| wolever | bzr co file:///svn/repo foo; cd foo; bzr merge -r 1..$HEAD /bzr/repo/ | 22:53 |
| wolever | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 22:54 |
| wolever | Err, and a `$ bzr svn-push file:///tmp/svn/` came before that | 22:54 |
| lifeless | wolever: indeed, they are separate repositories; svn repos have a UUID in them | 22:58 |
| wolever | Well, yes... It would make me very happy if there was something I could do about that, though | 22:58 |
| lifeless | given that you have forked, why not encourage the folk you are working with you use bzr? might give a better all-around result. You don't need any server access to publish your branch | 22:58 |
| lifeless | s/server a/special server a/ | 22:59 |
| wolever | lifeless: As I mentioned, I'd love it if I could do that, but as I'm sure you know, getting people to switch RCSs isn't that easy | 22:59 |
| wolever | What with everyone knowing how to use SVN, SVN's integration with $IDE... etc, etc | 23:00 |
| lifeless | true true | 23:03 |
| bpeterson | buno, lifeless: I get the SSH error when I'm pushing to code.python.org. It hangs, so I use ^C and get this exception. | 23:11 |
| lifeless | bpeterson: can you ssh into code.python.org and look in your ~/.bzr.log please | 23:13 |
| bpeterson | I will have to email the administrator | 23:18 |
| lifeless | oh | 23:19 |
| lifeless | you don't have ssh access? | 23:19 |
| bpeterson | I'm too new to be trusted. :) | 23:19 |
| lifeless | ! | 23:20 |
| lifeless | ok | 23:20 |
| lifeless | what are the last few lines before the exception in your local ~/.bzr.log | 23:20 |
| bpeterson | You know Barry Warsaw? | 23:20 |
| lifeless | yes indeed | 23:20 |
| bpeterson | where's the log again? | 23:23 |
| lifeless | ~/.bzr.log | 23:23 |
| lifeless | or run bzr --version and it will tell you | 23:23 |
| bpeterson | ah | 23:23 |
| bpeterson | http://bzr.pastebin.org/41171 | 23:27 |
| lifeless | ok | 23:29 |
| lifeless | its failing attempting to unlock() the remote repository | 23:29 |
| lifeless | which means it failed earlier and this is masking the real error | 23:30 |
| lifeless | I will wager, oh, a chocolate bar, that this is a permission error on the remote server | 23:30 |
| bpeterson | It works ~1/3 of the time | 23:31 |
| lifeless | oh | 23:31 |
| lifeless | probably not that then | 23:31 |
| lifeless | lets find the real error | 23:31 |
| beuno | that's why I recommended trying again | 23:31 |
| beuno | we get that sometimes at the office | 23:31 |
| beuno | :) | 23:31 |
| beuno | haven't been able to track it down yet | 23:32 |
| bpeterson | I've been doing this for about the past week, so you can be sure I've tried again and again. | 23:32 |
| lifeless | if you look at the bzrlib.branch module | 23:32 |
| lifeless | the line 1625 should be in a finally block | 23:32 |
| lifeless | disable that line - put a # and a pass line after it | 23:33 |
| lifeless | this will mean we need to break-lock after a successful push but should let us see the real error | 23:34 |
| bpeterson | Barry sent me the log: http://www.python.org/ftp/python/bzr.log | 23:35 |
| lifeless | I think we need to make the client code change I proposed | 23:37 |
| lifeless | there is too much noise from the protocol down-grade errors | 23:38 |
| bpeterson | Ok, I'll try that | 23:38 |
| lifeless | do you know a good python text indexer | 23:43 |
| lifeless | pylucence looks painful to ask people to build | 23:43 |
| bpeterson | the annoying thing is I don't get errors now | 23:48 |
| lifeless | at all ? | 23:50 |
| lifeless | on repeated pushes even ? | 23:50 |
| bpeterson | no, it happily says "pushed revision 39547" | 23:50 |
| bpeterson | I'm doing another push now | 23:51 |
| beuno | lifeless, my personal guess with these errors is Memory ones | 23:51 |
| beuno | the branches I've got them in, now that I've got my main server on bzr.dev, I get Memory errors sometimes | 23:52 |
| beuno | but people at work don't even tell me anymore when it happens, they just push/pull again | 23:53 |
| beuno | so I haven't been able to pin-point it | 23:53 |
| beuno | is it possible the server doesn't have enough memory at the moment, and it gets masked by the smart server? | 23:54 |
| beuno | (would explain the randomness of it) | 23:55 |
| bpeterson | would that show up in the server log? | 23:57 |
| beuno | I don't know enough about the smart server to know if it would :/ | 23:57 |
| * bpeterson has another successful push | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!