| lifeless | morning y'all | 00:16 |
|---|---|---|
| Verterok | moin | 00:17 |
| beuno | hey lifeless! feeling better? | 00:24 |
| lifeless | beuno: yes thanks | 00:36 |
| spiv | poolie: that fix of mine just landed | 00:44 |
| * igc out for a while - bbl | 00:52 | |
| poolie | spiv, great | 01:03 |
| lifeless | abadger1999: ping | 01:04 |
| lifeless | abadger1999: sorry | 01:04 |
| lifeless | abentley: ping; I have a bundle confusion thing; I'm debugging but perhaps you've seen it in the past and can advise | 01:05 |
| jml | spiv: which bug was that a fix for? | 01:05 |
| jml | spiv: because my attention is being drawn to bug 236380 in Launchpad, and I wonder if they are perhaps related. | 01:05 |
| jml | how can I get a list of changes to trunk filtered by whether they changed files in a particular directory? | 01:12 |
| jml | bzr log --short foo/bar does *something* | 01:12 |
| spiv | jml: I don't think my fix is related to that bug | 01:14 |
| jml | spiv: ok. thanks. | 01:14 |
| spiv | jml: I can reproduce 236380 with bzr.dev, btw | 01:17 |
| poolie | hello jml | 01:26 |
| jml | poolie: hi | 01:26 |
| * markh waves | 01:49 | |
| markh | I'm looking through the API docs, but I can't see a way to do iter_changes or changes_from non-recursively - ie, if I pass a directory name, I do *not* want children checked. Any clues? | 01:50 |
| lifeless | I'm not sure we have that | 01:51 |
| markh | eg, I'd like to know the dir has been "added", but I don't yet care about children | 01:51 |
| markh | for tortoise, I'd obviously like to avoid doing a full tree status if a user happens to browse to the root of a large working tree. | 01:52 |
| markh | I can see how to work around it for files - but it seems that to get the status of a single directory anywhere in a tree requiring me to do a full tree status update is going to kill in some cases. | 01:59 |
| markh | at least '--no-recurse' is listed as a todo ;) | 02:06 |
| brandon_rhodes | After numerous experiments (and learning to delete ~/.bazaar/subversion.conf after each one!), I have managed to make "bzr svn-import" import a project from my subversion repository (yay!) | 02:54 |
| brandon_rhodes | But it's treating my tags as branches | 02:54 |
| brandon_rhodes | Rather than giving the mainline trunk a list of actual tags that can be listed with "bzr tags" | 02:54 |
| brandon_rhodes | Is there anything that can be done about that? | 02:54 |
| brandon_rhodes | Or should I march boldly into the future without my old tags around as tags? :-) | 02:55 |
| bob2 | tag support is planned but not implemented yet, aiui | 02:55 |
| brandon_rhodes | Roger. I'm about to move a project to Launchpad and wanted to make sure I wasn't missing something first | 02:57 |
| brandon_rhodes | Thanks. | 02:58 |
| === lifeless changed the topic of #bzr to: launchpad bazaar hosting is shutdown for urgent maintenance | Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| pickscrape | What would I need to call in bzrlib to get a Tree of a branch at some given revision? | 03:12 |
| jamesh | pickscrape: branch.repository.revision_tree(rev_id) | 03:14 |
| pickscrape | Thanks. Could you point me at somewhere I could have looked that up myself? | 03:15 |
| pickscrape | I've looked around for a 'bzrlib for plugin developers' doc but couldn't find one. | 03:15 |
| lifeless | doc/developers/ has some stuff | 03:15 |
| pickscrape | Thanks | 03:15 |
| lifeless | sorry, doc/en/developers I think. | 03:16 |
| poolie | hm there is a document aimed at just that | 03:17 |
| poolie | pickscrape: http://bazaar-vcs.org/Integrating_with_Bazaar | 03:18 |
| poolie | i'm sure there are things plugin developers might want to know that aren't answered there though | 03:18 |
| poolie | so if you hit something please ask here or on the list | 03:18 |
| pickscrape | poolie: thanks for that! | 03:19 |
| pickscrape | It's a very rich API, which is great but a tad bewildering when you first look into it. :) | 03:19 |
| poolie | yeah | 03:19 |
| poolie | and it does change over time too | 03:20 |
| poolie | but we are pretty friendly, do ask | 03:20 |
| pickscrape | Yes, this is actually what's I'm doing (accounting for a removed method) | 03:20 |
| poolie | it's the best way to guide documentation improvements too | 03:20 |
| lifeless | yay 5 errors to go in bundle tests | 03:50 |
| markh | It seems the bzr tests fail to remove the test directory when the test fails (Permission denied: unable to remove testing dir tmpfq3hof) - is that known? | 03:52 |
| lifeless | markh: it is a bug indeed | 03:54 |
| markh | any idea if its already reported? | 03:54 |
| markh | save me searching :) | 03:54 |
| lifeless | I know it has been discussed/partially fixed etc in the past | 03:55 |
| markh | great, thanks | 03:56 |
| markh | lifeless or poolie: any idea if adding a 'recursive' param to iter_changes and changes_from would be controversial? ISTM it would have to be implemented in inventory.iter_entries_by_dir() and might not be that hard or deep. Should I give it a shot, or discuss the requirement itself on the mailing list first? | 03:59 |
| lifeless | markh: inventory.iter_changes* are largely deprecated | 03:59 |
| lifeless | markh: look at workingtree_4.py's iter_changes | 04:00 |
| lifeless | markh: and definitely discuss on the list; I mean - it seems to me you actually are looking at a single path rather than a dir? | 04:00 |
| markh | lifeless: I'm not sure what the last part of that means. The way TSVN works is that when a filename or directory name is requested, the status of all items in the parent are queried and cached. | 04:02 |
| markh | but actually that doesn't seem relevant - even if we just fetch one item at a time, I don't want to recurse when the status of a directory is requested. | 04:03 |
| lifeless | markh: to a large extent this depends on the definition of 'status' for a directory | 04:04 |
| lifeless | markh: say you are putting an emblem on altered directories | 04:04 |
| lifeless | should a directory with an altered child get an emblem ? | 04:04 |
| markh | well, its more like "get the full status of a dir in the backgroumd, but the "immediate" status in the foreground" | 04:04 |
| markh | we will manage the background part, but do need a way to say "give me the 'immediate' status of the folder itself, not of its children" | 04:06 |
| markh | if we want to show *any* emblem before the full recursive status is calculated | 04:06 |
| markh | which we do | 04:06 |
| markh | (and the fact the status command has a comment indicating 'no recurse' is a todo item gave me hope the requirement itself is kinda 'obvious') | 04:08 |
| lifeless | I am behind on a deadline due to being sick for a week | 04:09 |
| markh | no worries - I hope you are better - thanks for the comments and I'll take it to the list | 04:09 |
| lifeless | so can't really offer good interactive discussion on this; it certainly doesn't need to block on me - the pointer already given, to the fast-path iter_changes function should give you an idea of the code that you'd need to modify | 04:10 |
| lifeless | nice: | 04:17 |
| lifeless | time bzr log megarepo/pool/main/p/pyvorbis/ | 04:17 |
| lifeless | real 0m1.274s | 04:17 |
| lifeless | user 0m0.150s | 04:17 |
| lifeless | sys 0m0.050s | 04:17 |
| lifeless | cold cache | 04:17 |
| lifeless | real 0m0.178s | 04:18 |
| lifeless | user 0m0.150s | 04:18 |
| lifeless | sys 0m0.020s | 04:18 |
| lifeless | hot cache | 04:18 |
| pickscrape | lifeless: what's the context of those timings? | 04:25 |
| lifeless | pickscrape: http://www.advogato.org/person/robertc/diary/83.html | 04:27 |
| lifeless | robertc@manganese:~$ du -sh megarepo/.bzr/ | 04:27 |
| lifeless | 22G megarepo/.bzr/ | 04:27 |
| lifeless | its a single repository with ~all of ubuntu | 04:27 |
| poolie | pickscrape: for curiousity what are you working on? | 04:27 |
| pickscrape | Ah yes, I did read that blog post. Very nice :) | 04:27 |
| pickscrape | poolie: getting diffstat working again | 04:28 |
| poolie | oh yay | 04:28 |
| pickscrape | Probably a 5 minute job for someone well versed in bzrlib, but good learning material for me :) | 04:28 |
| jml | I was just reminded how neat 'merge --uncommitted' is, so I blogged about it: http://mumak.net/2008/06/02/neat-bazaar-feature/ | 04:29 |
| poolie | jml, we should add you to planet bazaar hey? | 04:30 |
| jml | poolie: oh yeah maybe | 04:30 |
| poolie | pickscrape: that would be great to have | 04:30 |
| poolie | actually it might be nice to have it builtin, at least if it just adds new options to diff, status, send, etc | 04:31 |
| pickscrape | poolie: that's what I was hoping to do to it next | 04:31 |
| pickscrape | I actually don't think it needs to add any new command at all | 04:31 |
| poolie | great | 04:32 |
| pickscrape | Do you know if Michael Ellerman (its origina author) is still around? | 04:33 |
| poolie | i haven't seen him for a while | 04:33 |
| pickscrape | It's not been touched since 2006, so I have the impression that it's basically unmaintained at this point. | 04:34 |
| poolie | i think you're right | 04:34 |
| pickscrape | That being the case I was thinking of hosting it on launchpad (once I've got it working), but I'm unsure of the etiquette with regard to picking up things like this. | 04:35 |
| poolie | i think just go ahead and publish it | 04:36 |
| poolie | after all he can always merge back if you want | 04:36 |
| pickscrape | Yes | 04:36 |
| pickscrape | ok, I'll do that. | 04:36 |
| poolie | markh: i think that 'permission denied' might be windows-specific? | 04:38 |
| poolie | does it happen with all failing tests? | 04:38 |
| markh | yes, I've no doubt its windows specific, and best I can tell, all tests | 04:38 |
| poolie | could you maybe put a breakpoint at the place it is raised so we can work out what specifically is going wrong? | 04:39 |
| markh | actually, not all tests now it has finished :) No transport tests | 04:39 |
| markh | ok, I'll see how I go | 04:39 |
| markh | likely to be a handle to that dir is open, so the trick might be finding it. I'll see what I can find. | 04:40 |
| poolie | i think that would be it | 04:42 |
| beuno | mwhudson, around? I have good news :) | 04:45 |
| poolie | beuno: he has a public holiday toda, but you can tell me :) | 04:46 |
| beuno | poolie, well, let me get you the URL. I got Loggerhear to *not* request all diffs for each revision, and you can request each diff via ajax, cutting by 4 the time/memory needed for each diff :) | 04:47 |
| poolie | nice | 04:48 |
| beuno | so, with the new templating system, and diffs being cheaper, it should be feasable to run it without it explodind a dozen times a day :) | 04:49 |
| beuno | s/explodind/exploding | 04:50 |
| beuno | I still think we should throw away the current code :) | 04:51 |
| * mwhudson is here but worrying about loggerhead definitely seems like work | 04:55 | |
| beuno | mwhudson, :) | 04:55 |
| poolie | beuno: ok with me, as long as you agree with mwhudson and other folks that it's the best thing to do | 04:55 |
| beuno | let me try and get this port open so you can peak | 04:55 |
| poolie | and what specifically to do instead | 04:55 |
| poolie | and hopefully it'll be something that's both easy for users to deploy and works in well as part of lp | 04:55 |
| poolie | hello keir | 04:56 |
| keir | hey martin | 04:56 |
| mwhudson | tbh, the main concern i have with beuno's ideas is the requiring javascript stuff | 04:56 |
| keir | so i guess launchpad bzr is down :( | 04:56 |
| keir | i was here to ask about that | 04:57 |
| mwhudson | keir: will be back very soon | 04:57 |
| poolie | keir, yes, jml is working on it, should be back soon | 04:57 |
| keir | cool | 04:57 |
| keir | i was thinking i was doing something wrong :) | 04:57 |
| mwhudson | i think a gmail-for-bzr could be really really cool though :) | 04:57 |
| keir | woot! did i hear gmail+bzr? | 04:57 |
| poolie | well, i think we need to have some kind of reasonable fallback if they don't have js (enabled) | 04:57 |
| poolie | i think he meant gmail-style interface | 04:58 |
| mwhudson | yes | 04:59 |
| beuno | mwhudson, http://intranet.pentacorp.net:8080/bazaar/bzr_dev/revision/pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc?start_revid=pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc | 04:59 |
| beuno | mwhudson, well, the way I'm doing things now, we can fall back to an html-only version pretty easily | 04:59 |
| mwhudson | beuno: seems to work | 05:00 |
| mwhudson | some kind of progress report would be a good idea | 05:01 |
| beuno | I haven't done extensive benchmarking, but a 8k diff uses very little memory, and, even more important, now, it's optional :) | 05:01 |
| mwhudson | (maybe just a spinning gif) | 05:01 |
| beuno | mwhudson, right, there are *tons* of improvements to do on top of that | 05:01 |
| beuno | because of the way loggerhead works, it's getting the diff for those files anyway, I'm just not parsing them | 05:01 |
| poolie | beuno: sweet | 05:02 |
| beuno | :) | 05:02 |
| poolie | is that tested at all? | 05:02 |
| poolie | we should think about that too | 05:02 |
| poolie | and when i say 'we' i mean 'you' :-) :-) | 05:02 |
| beuno | poolie, test what, sorry? | 05:02 |
| poolie | well | 05:02 |
| poolie | actually i don't know if it has any automatic tests at present | 05:03 |
| poolie | but it would be nice to get some | 05:03 |
| poolie | including that the js works as expected | 05:03 |
| mwhudson | loggerhead has some _very_ basic tests currently | 05:03 |
| beuno | mwhudson, I haven't figured out how to run them :) | 05:03 |
| mwhudson | beuno: nosetests | 05:03 |
| mwhudson | or py.test | 05:03 |
| beuno | mwhudson, I'll take a look at that (we should document that :p) | 05:04 |
| jml | poolie: the corporate 'we' :) | 05:04 |
| === lifeless changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| beuno | cool, tests kinda of work! | 05:05 |
| beuno | mwhudson, so, getting diffs individually seem to be *way* cheaper | 05:06 |
| mwhudson | beuno: interesting | 05:06 |
| mwhudson | i think it's all in the rendering probably | 05:06 |
| beuno | I'm using the zpt branch | 05:06 |
| mwhudson | oh cool | 05:07 |
| mwhudson | you got that working in the end? | 05:07 |
| beuno | so, it we combine zpt + not rendering everything + individual diffs, it should be a big improvement peformance-wise | 05:07 |
| beuno | yeap | 05:07 |
| beuno | I pulled your branch, and tweaked a little | 05:07 |
| beuno | I'm going to add a progress while it's fetching the diff | 05:08 |
| beuno | and then update the branch to use the new methods (it still has the deprecated ones) | 05:08 |
| beuno | clean up, and push | 05:08 |
| beuno | and the font seems to be smaller for some add reason. Css is ignoring me today | 05:09 |
| beuno | s/add/odd | 05:09 |
| beuno | poolie, I'm not sure how we can test javascript. Especially since each browser renders it differently | 05:10 |
| beuno | I am using a very popular js library, so it's almost guaranteed to work on all popular browsers | 05:11 |
| mwhudson | 'selenium' is one answer | 05:11 |
| markh | poolie: I noticed my debugger changes the behaviour, which made me think "gc" - and sure enough, a gc.collect() before the osutils.rmtree(dirname) in tests._rmtree_temp_dir() seems to solve the problem. Apart from the problem that a number of tests are still failing ;) | 05:12 |
| beuno | mwhudson, looks good, I'll look into it | 05:14 |
| beuno | and stop bothering you on a holiday :) | 05:15 |
| jml | some of the JS could be unittested with spidermonkey & integrated into the main suite using subunit. | 05:15 |
| jml | but I don't think very much could. | 05:16 |
| abentley | lifeless: pong | 05:45 |
| lifeless | abentley: I mailed the list | 05:45 |
| lifeless | abentley: I think there is a conceptual bug in the mpdiff interface/output | 05:45 |
| abentley | lifeless: I believe the bundle specifies what the parents are, but I can double-check that. | 05:50 |
| lifeless | abentley: even if it does I think that the lower level api will break because each individual text can have hit different orderings or different ghost texts | 05:51 |
| abentley | The orderings used are the orderings specified in the bundle. | 05:54 |
| beuno | mwhudson, loader added: http://intranet.pentacorp.net:8080/bazaar/bzr_dev/revision/pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc?start_revid=pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc | 05:54 |
| mwhudson | beuno: sweet | 05:55 |
| mwhudson | a 'view all' might be appropriate i guess | 05:55 |
| beuno | mwhudson, yeah, I'm not putting too much work into the interface considering I'm going to be implementing the new theme next week | 05:56 |
| lifeless | abentley: looking at mpdiffs, I just don't see were the text parent ids are grabbed - the diffs list contains MultiParent.from_lines output only | 05:56 |
| beuno | mwhudson, I have to do major code cleanup now, and change the way loggerhead builds that page, so it doesn't still internally get the diffs and discard them | 05:57 |
| abentley | mpdiffs don't list the parents. The bundles list the parents. | 05:57 |
| mwhudson | beuno: fair enough | 05:57 |
| beuno | and, well, tests and such would be nice | 05:58 |
| abentley | lifeless: The metadata entries for a record include a "parents" entry, and this is what should be used when applying the mpdiff. | 06:02 |
| lifeless | yay only reconcile to go | 06:05 |
| lifeless | abentley: I'm concerned about a mismatch between the actual used parents in the knit and that record | 06:05 |
| lifeless | concretely, looking at add_mp_records, ghosts will be present in the record | 06:06 |
| lifeless | but ghosts are filtered out of the diff generation | 06:06 |
| abentley | Where are they filtered out? | 06:08 |
| lifeless | bzrlib/versionedfile.py line 266 | 06:08 |
| lifeless | parents = [lines[p] for p in parent_map[version_id] if p in knit_versions] | 06:09 |
| abentley | lifeless: I think I agree. Whatever parents were used to generate the mpdiff should match the parents in the metadata. | 06:13 |
| jml | beuno: btw, your branch should be working now. | 06:13 |
| beuno | jml, ah, let's see.... | 06:13 |
| beuno | jml, the problem was with all knit branches? | 06:14 |
| jml | beuno: not all. just many. | 06:15 |
| jml | beuno: anything that needed to write an escaped path to disk. | 06:15 |
| beuno | jml, works perfect, thanks | 06:16 |
| jml | beuno: my pleasure. | 06:16 |
| === BasicPRO is now known as BasicOSX | ||
| mwhudson | does upgrade work over bzr+ssh yet? | 06:27 |
| lifeless | no | 06:29 |
| beuno | mwhudson, bzr branch lp:~beuno/loggerhead/zpt.ajax | 07:44 |
| beuno | and I'm off to bed | 07:44 |
| beuno | it still needs cleaning up, and a lot of work to do on top of it, so I'll keep working on that branch from now on | 07:45 |
| beuno | I replaced the deprecated methods, and updated the templates with the latest from your branch | 07:45 |
| poolie | ok i'm preparing a beta... | 08:39 |
| Frank_Heinen | Hi, can someone help me with a problem I got with a branch. I accidentally removed a file manually. Now I'd like to get the latest version of the branch again without checking out again, is this possible (getting back to the original branch again)? bzr update doesn't work, it mentions it is allready up to date. | 08:42 |
| Peng | Frank_Heinen: What? Do you want bzr revert? | 08:49 |
| tca | Is http://pastebin.org/39994 a safe workaround for https://bugs.launchpad.net/bzr/+bug/235055 ? | 09:04 |
| ubottu | Launchpad bug 235055 in bzr "bzr log fails with KeyError in graph.get_parent_map" [Undecided,Confirmed] | 09:04 |
| poolie | hi tca | 09:05 |
| tca | hello | 09:05 |
| TFKyle | tca: might want to do the graph.get_parent_map call outside of the try block so you couldn't get any exceptions from it, but probably isn't needed | 09:07 |
| poolie | tca, i _think_ so | 09:07 |
| poolie | tca, could you send it to bazaar@lists.canonical.com quoting that bug number? | 09:07 |
| poolie | it does look like this is the case that comment was looking for | 09:08 |
| poolie | it may be something unusal in the history coming from arch | 09:08 |
| * tca subscribing to the list | 09:09 | |
| tca | Yes, I think lots of weird stuff happened in arch ;-) | 09:11 |
| awilkins | Frank_Heinen: bzr revert <my_file> | 09:18 |
| Frank_Heinen | Peng: Awilkins: tanks, lets try. | 09:23 |
| Frank_Heinen | Peng: Alwilkuns: It works! :-) Stupid that I didn't see this.... | 09:26 |
| jrydberg | lifeless: ping? | 09:33 |
| === pmezard_ is now known as pmezard | ||
| poolie | jrydberg: he's feeling tired, probably won't be back for 12h | 10:10 |
| poolie | ie tomorrow morning | 10:10 |
| jrydberg | i see. | 10:13 |
| jrydberg | thanks! | 10:13 |
| jdub | hey duderinos | 10:23 |
| jdub | what are the chances of having bzr-svn in the bzr ppa? | 10:24 |
| jdub | i can't follow bzr easily without it :| | 10:25 |
| mwhudson | bzr get lp:bzr-svn ~/.bazaar/plugins/svn | 10:26 |
| mwhudson | releases are for weenies :) | 10:26 |
| awilkins | Anyone here working on the xmlrpc server? | 11:43 |
| === kiko is now known as kiko-afk | ||
| === _[PUPPETS]Gonzo is now known as [PUPPETS]Gonzo | ||
| semslie | hi. I'm in a situation where I've updated, which has converted some commits to a pending merge. I'd prefer to go back and rebase now. Is it possible for me to convert those commits involved with the pending merge back into commits and basically rollback to before the update? | 13:07 |
| james_w | semslie: I'm not sure of a way to get back to what you had before, I can talk you through getting back to an equivalent. | 13:12 |
| james_w | semslie: I'm not sure if "bzr revert" will do what you want though, I think it may do the opposite of what you want, so I'm wary of telling you to try it. | 13:12 |
| semslie | james_w: fortunately I've got a backup | 13:13 |
| luks | I'd unbind the checkout, commit the pending merges, then lookup the revid of the merged revision and branch of that | 13:13 |
| semslie | luks: thanks, I'll give that a try | 13:13 |
| james_w | luks: exactly | 13:13 |
| luks | after that you should have the branch you had before and you can use rebase on those revisions | 13:13 |
| james_w | though "pull --overwrite" instead of "branch" will save you a temporary branch. | 13:14 |
| james_w | and I was wrong before, that will get you back to what you had. | 13:14 |
| luks | I just don't like destructive operations | 13:14 |
| luks | having two branches feels safer to me | 13:14 |
| semslie | james_w: when you say you were wrong before, do you mean that "bzr revert" wont delete the pending merge, but rather get me back to where I was before the commit? | 13:15 |
| luks | no, revert will get rid of your local commits | 13:15 |
| luks | they are still in the repository, but not so easy to look up | 13:16 |
| semslie | luks: right, I'll avoid that then | 13:16 |
| james_w | semslie: no, I meant that I was wrong when I said that I wasn't sure whether I could get you back to what you had before. I was going to suggest luks' method, but that will get you back to what you had before. | 13:16 |
| semslie | okay, I'll try that | 13:16 |
| semslie | ftr I'm merging a fairly complicated branch back into a subversion rep that I've diverged from. It now makes sense that update did what it did, but I think what I was looking for was rebase | 13:18 |
| semslie | rebasing seems to have worked nicely. nearly there now. Thanks for the advise! | 13:34 |
| abentley | lifeless: I don't think the mpdiff ghotst bug is a conceptual bug. It's just a bug bug. | 14:07 |
| visik7 | can I commit a filechange on a revision ? | 14:20 |
| bob2 | you only want to commit the changes made to a paricular file? | 14:22 |
| visik7 | the problem is that I've a working copy at a revision xy and the deploied app to a revision older | 14:25 |
| visik7 | now I want to submit some modification to the deploied app | 14:25 |
| visik7 | maybe I need to branch and revert | 14:27 |
| vila | visik7: may you need two branches | 14:32 |
| vila | be even | 14:32 |
| visik7 | another question | 14:33 |
| visik7 | I've a shared repo | 14:33 |
| visik7 | at the beginning I've commited on it a lot of files | 14:33 |
| visik7 | now I deleted those files from the working tree | 14:33 |
| visik7 | and I don't want them anymore | 14:34 |
| visik7 | but the shared repo still has it | 14:34 |
| visik7 | has them | 14:34 |
| visik7 | I can't find any command on how to manage a shared repo | 14:34 |
| bob2 | that is unrelated to using a shared repository or not - bzr doesn't currently have an (easy) way to purge things from history | 14:36 |
| visik7 | but it's 1gb of useless data | 14:36 |
| visik7 | :( | 14:36 |
| visik7 | and a way to purge a repo from a revision to the beginning ? I mean I've the problem at revision 7 | 14:40 |
| visik7 | a way to remove from 1 to 7 | 14:40 |
| andrea-bs | I don't know if this is the best way, but you can make an another branch, "bzr revert -r1" the original branch, copy all needed files to the new branch and commit, "bzr revert -r 2", copy and commit, ... | 14:44 |
| === mw|out is now known as mw | ||
| awilkins | visik7: Export r 8 ; initialize it, then merge revisions 9.. with it | 15:11 |
| visik7 | my current revision is at 37 | 15:18 |
| visik7 | it's ok to do it ? | 15:19 |
| mtaylor | visik7: try bzr pack | 15:24 |
| visik7 | they are png | 15:25 |
| === asabil is now known as asabil_ | ||
| Pieter | Hmm, creating a bidirectional git-bzr thing should be really easy | 15:40 |
| Pieter | I might even try it someday | 15:40 |
| jelmer | Pieter, there already is something like that | 15:41 |
| jelmer | Pieter, http://launchpad.net/bzr-git | 15:41 |
| Pieter | but that won't write to git, right? | 15:41 |
| jelmer | Pieter, not yet, no | 15:41 |
| jelmer | Pieter, or is what you're intending to do different from a bzr plugin? | 15:41 |
| Pieter | I was thinking about using fast-import/export | 15:42 |
| Pieter | You'd just need to extend git-fast-export and bzr fast-import to import/export marks files | 15:42 |
| Pieter | and then you can go both ways incrementally | 15:42 |
| dato | I'm planning to add incremental support to bzr-fast-export | 15:43 |
| dato | it already exports a marks file | 15:43 |
| Pieter | bzr-fast-export already has a --import-marks thing | 15:43 |
| jelmer | Pieter, that won't work because you'd break referential integrity | 15:44 |
| dato | Pieter: I know, I wrote it :) | 15:44 |
| Pieter | jelmer: you'll have to maintain the marks files, then it should be ok | 15:45 |
| dato | (though I'm not planning in bidirectional, no) | 15:45 |
| dato | (just incremental bzr -> git) | 15:45 |
| Pieter | that already works | 15:45 |
| semslie | I'm constantly getting an AssertonError when pushing from a rebased bzr branch to a subversion repository: assert self._new_revision_id is None or self._new_revision_id == revid | 15:49 |
| semslie | has anyone else had experience with this? | 15:49 |
| Jc2k | semslie: do you mean you pushed once, rebased and pushed again> | 15:50 |
| semslie | Jc2k: no, but after I branched the subversion branch diverged from the bzr one. Rather than merge and loose my changelog in a single subversion commit, I rebased off the new subversion head and tried to svn-push | 15:51 |
| semslie | interestingly, the commit that should have been last (at the bzr head) was the only one that got committed to svn before it crashed | 15:53 |
| semslie | I wonder if it has somehow gotten turned around? | 15:53 |
| jelmer | semslie, hi | 15:54 |
| jelmer | semslie, there is an open bug report about this | 15:55 |
| semslie | jelmer: thanks. I'll take a look in launchpad | 15:55 |
| semslie | jelmer: is that a bug against bzr or bzr-svn? | 15:56 |
| jelmer | semslie, bzr-svn | 15:56 |
| semslie | thanks | 15:56 |
| === kiko-afk is now known as kiko | ||
| PeakerWork | hey, I used "bzr commit --local" when I had some connectivity problems, then I used "bzr commit" and it failed cause it is out of date. So I used "bzr update" (when I have some local changes) and it gave me a bazillion merge conflicts! Nothing needs merging, only I have changes, the remote tree was untouched the whole time | 16:21 |
| PeakerWork | why is that? | 16:21 |
| PeakerWork | I removed all the .THIS/.OTHER files (I took the .OTHER.moved files) and now I have lots of "Conflict adding file raytrace/Plane.hs.BASE. Moved existing file to raytrace/Plane.hs.BASE.moved." conflict messages and I can't get rid of them | 16:22 |
| PeakerWork | is this a bug or did I do something wrong? | 16:22 |
| PeakerWork | Its pretty terrible :( only revert worked to get rid of the conflicts so I manually re-applied the ~1~ backup files, and all directory tree changes had to be manually re-done.. | 16:25 |
| james_w | PeakerWork: hi, it sounds like the file ids ended up different between the remote and local branches. | 16:28 |
| PeakerWork | I think it happened to me before -- whenever I commit --local, later updates are trouble | 16:29 |
| james_w | if nothing happened on the remote side what did you do locally? was it just edit and commit, or did you add and remove any files? | 16:29 |
| PeakerWork | does bzr have tests for "commit --local" followed by updates? | 16:29 |
| PeakerWork | I renamed/moved some files, I don't think I added/removed anything | 16:30 |
| Keybuk | I'm clearly missing something, because one of my most common "other branch" operations is damned hard to do with bzr | 16:31 |
| james_w | it does have tests, yes | 16:31 |
| james_w | PeakerWork: it may be the renames then, did you use "bzr mv"? | 16:31 |
| Keybuk | the operation is "what changed in this branch when compared to the mainline?" | 16:31 |
| PeakerWork | james_w, I think I consistently get merge conflicts for all modifications made with --local when I try to update later | 16:31 |
| PeakerWork | james_w, Yeah I did | 16:31 |
| james_w | Keybuk: hi. what changed as in diff, or revisions? | 16:31 |
| Keybuk | james_w: diff | 16:32 |
| james_w | Keybuk: "bzr diff -r ancestor:submit:" might be what you are looking for | 16:33 |
| james_w | or it may give you something completely different. | 16:33 |
| Keybuk | bzr: ERROR: Not a branch: "/home/scott/tmp/sadmac/submit:/". | 16:33 |
| james_w | oh wow | 16:34 |
| james_w | does "bzr diff -r submit: work? | 16:34 |
| LarstiQ | or bzr diff --new path/to/branch | 16:34 |
| Keybuk | james_w: nope, it uses a totally random path | 16:34 |
| Keybuk | (also this appears to be require me to checkout the branch I want to look at ... which sucks) | 16:34 |
| Keybuk | if I'm in my upstart branch | 16:35 |
| Keybuk | and somebody gives me the URL to their branch of changes | 16:35 |
| Keybuk | which is branched off my upstart branch, though probably an earlier revision | 16:35 |
| Keybuk | what's the recipe for that? | 16:35 |
| LarstiQ | bzr diff --new http://bazaar-vcs.org/bzr/bzr.dev | 16:35 |
| LarstiQ | works for me? | 16:35 |
| james_w | hi LarstiQ | 16:36 |
| LarstiQ | I can imagine cases where that is not the most readable diff. | 16:36 |
| Keybuk | LarstiQ: shows the reversal of changes in local branch ? | 16:36 |
| LarstiQ | Keybuk: diffs the other branch with the current one, you can also do --old | 16:36 |
| LarstiQ | that's just for left and right | 16:37 |
| james_w | Keybuk: there's another possibility, "bzr merge --preview URI" | 16:37 |
| Keybuk | LarstiQ: which isn't what I want ... I want to see what _they_ changed | 16:37 |
| Keybuk | not what I changed since | 16:37 |
| Keybuk | james_w: has random side-effects like setting the submit branch | 16:37 |
| LarstiQ | Keybuk: aha | 16:37 |
| Keybuk | aha! | 16:37 |
| Keybuk | james_w: you were onto the right idea originally | 16:37 |
| Keybuk | bzr diff -r ancestor:. OTHER_BRANCH | 16:37 |
| Keybuk | :p | 16:37 |
| LarstiQ | if you are in their branch that is? | 16:38 |
| james_w | Keybuk: yeah, it should definitely be something that is possible. I think that "merge --preview" would be the suggested way to ask what they changed, but I'm not sure what to do about the submit branch thing. | 16:38 |
| Keybuk | also merge --preview doesn't work with difftools, so I can't use meld to see it ;) | 16:39 |
| james_w | if you haven't got a submit branch set then that may be why "-r submit:" didn't work. | 16:39 |
| Keybuk | it's not me who needs to set that, no? :p | 16:39 |
| LarstiQ | james_w: hey :) | 16:39 |
| Keybuk | it's if _they_ haven't got a submit branch? :P | 16:39 |
| james_w | you did ask for your differences to the mainline first though, which I think is a "diff -r ancestor:" operation. | 16:39 |
| james_w | Keybuk: maybe you would like to post to the list so that we can get some discussion on this, it should definitely be something that is easy to do. | 16:40 |
| PeakerWork | james_w, does it sound like a bug though? | 16:41 |
| Keybuk | what's the address? | 16:41 |
| james_w | Keybuk: bazaar@lists.canonical.com | 16:41 |
| james_w | PeakerWork: it does sound like one, though there may have been something that I missed. | 16:42 |
| james_w | PeakerWork: is it a public project? | 16:42 |
| james_w | PeakerWork: or better yet, can you isolate a test case on a couple of dummy branches? | 16:42 |
| PeakerWork | james_w, I'll try that at home yeah | 16:43 |
| james_w | PeakerWork: thanks. You can file a bug either way, but a simple test case will probably get it looked at far quicker. | 16:43 |
| schierbeck | abentley: hey dude | 16:53 |
| abentley | schierbeck: Hey there. | 16:54 |
| schierbeck | abentley: it's nice to see the branch review functionality coming to lp -- do you have any idea when it will match the functionality of bundle buggy? | 16:54 |
| schierbeck | i'm thinking of starting to use it in bzr-gtk | 16:55 |
| abentley | schierbeck: They're never going to have the same feature set. | 16:55 |
| Keybuk | Your mail to 'bazaar' with the subject | 16:57 |
| Keybuk | Two things that bzr makes hard :-( | 16:57 |
| Keybuk | Is being held until the list moderator can review it for approval. | 16:57 |
| Keybuk | :-( | 16:57 |
| Keybuk | FAIL | 16:57 |
| pickscrape | It's because you're not subscribed I think. | 16:58 |
| schierbeck | abentley: in what way do you mean? i'm thinking: when will it allow users of bundle buggy to switch to lp without changing workflow | 16:58 |
| schierbeck | i.e. reviewing over email must be supported | 16:58 |
| abentley | schierbeck: I don't know. What's important to you? | 16:59 |
| schierbeck | abentley: i know jelmer must have email support if he's to switch over -- personally, i only really need better integration with the code browser | 16:59 |
| schierbeck | so i can see a full diff | 17:00 |
| abentley | Email integration is what I'm working on right now. | 17:00 |
| abentley | I'm not sure when we'll add the ability to view a diff. | 17:00 |
| jelmer | schierbeck, abentley: Voting support is another thing I think launchpads merge request integration doesn't have atm | 17:00 |
| schierbeck | jelmer, abentley: as far as i know it's just been introduced | 17:01 |
| jelmer | schierbeck: Also, is there any reason to switch to launchpad from bundlebuggy once these things have been resolved in launchpad? | 17:01 |
| abentley | jelmer: No, it has voting. | 17:01 |
| jelmer | schierbeck, I prefer using free over non-free software when possible | 17:02 |
| schierbeck | jelmer: that's true, but if we disregard that very valid point, having the bugs, branches and review proposals in one place offers a very real benefit, at least for me | 17:02 |
| schierbeck | i feel it would be a good idea to start linking bug reports to hosted branches, and using lp to request code reviews would mean that i would have one single location from which i could view the status of my work | 17:04 |
| jelmer | The linking between bug reports and hosted branches should already be happening if you use --fixes | 17:05 |
| abentley | schierbeck: So, that requires actually having branches. BB doesn't require that, which gives you a lower barrier to entry. | 17:05 |
| schierbeck | abentley: that's true, but support for patches/bundles in lp merge proposals would be possible | 17:06 |
| abentley | That's true. What's actually been proposed is that you could use a bundle to create a branch. | 17:10 |
| === yacc_ is now known as yacc | ||
| semslie | jelmer: I've dug around a bit and it seems like the first revision to be pushed is off by one. So todo in branch.py line 360 is missing the first revision that needs to be pushed. Not sure if this helps, but I am rebasing before I push | 17:18 |
| schierbeck | abentley: that would be cool too, but i think the best solution would be to allow uploading bundles when making a merge proposal | 17:41 |
| abentley | schierbeck: Well, supporting bundles as first-class objects rather than just a way of getting branches isn't on the radar, so please file a bug to help put it there. | 17:45 |
| schierbeck | abentley: sure | 17:46 |
| schierbeck | abentley: but would it technically be the same, if the internal representation is in fact a branch | 17:46 |
| schierbeck | it would just be anonymous to the lp user | 17:46 |
| abentley | I don't know what you mean by "anonymous to the lp user". | 17:47 |
| schierbeck | abentley: i mean that all they see is a file chooser dialog, they don't need to first create the branch from a bundle, then point to it from the merge proposal | 17:48 |
| schierbeck | many changes are small, and figuring out a unique name for it is perhaps overkill | 17:48 |
| abentley | schierbeck: So you're saying accepting a bundle should create a branch without a name? | 17:49 |
| schierbeck | abentley: yeah, if done from the merge proposal form | 17:50 |
| abentley | I highly doubt that will fly. | 17:50 |
| schierbeck | the internal name could correspond to the merge proposal id | 17:50 |
| schierbeck | abentley: why wouldn't it? | 17:50 |
| abentley | If a branch doesn't have a name, it's hard to access it. | 17:51 |
| === kiko is now known as kiko-fud | ||
| schierbeck | abentley: since they'd be read-only, they could be exposed through the review interface | 17:52 |
| schierbeck | i'm not familiar with the url scheme, but something like /merge-proposals/<id>/branch | 17:52 |
| abentley | Concretely, you're not going to be able to get a diff of a branch that doesn't have a name through the code browser. | 17:53 |
| abentley | Because you won't be able to construct a URL for that. | 17:53 |
| === yacc_ is now known as yacc | ||
| jelmer | abentley, I'm trying to track down an error in bundlebuggy | 18:18 |
| jelmer | "freeze" for emails is used to store them somewhere else for reprocessing? | 18:18 |
| jelmer | one of the emails is raising UnicodeDecodeError and that is causing bundlebuggy to reprocess it over and over again | 18:19 |
| jelmer | since UnicodeDecodeError isn't handled in MailQueue.handle() | 18:20 |
| abentley | freeze is used for emails that have permanent failures. | 18:21 |
| abentley | While UnicodeDecodeError is permanent, it shouldn't be happening at all. | 18:22 |
| jelmer | I've made it print a traceback next time this happens | 18:27 |
| nevans | has anyone ever had a problem committing to a bound branch, even though unbinding, committing, and pushing works just fine? | 18:31 |
| jelmer | nevans, what sort of problems? | 18:31 |
| nevans | FWIW, I have this problems with a couple of subversion branches (using bzr-svn 0.4.9) | 18:31 |
| nevans | commit tells me to update and try again, and update tells me that I'm up to date | 18:32 |
| semslie | jelmer: hi again. I've got an idea why I might be seeing #230863 (AssertionError on push -r x) | 18:33 |
| jelmer | semslie, ok | 18:33 |
| jelmer | semslie, what do you think is causing it? | 18:34 |
| semslie | jelmer: it looks like it is following the branch when choosing the next revision id, but there are revisions in the repository that are newer than in the branch, so we are choosing something that collides with something elsewhere in the repository. | 18:35 |
| jelmer | semslie: any chance you can write up a script that reproduces this? | 18:36 |
| jelmer | that would be a huge help | 18:36 |
| jelmer | and would be useful to make sure this doesn't regress | 18:36 |
| jelmer | oncewe fix it | 18:36 |
| semslie | jelmer: sure | 18:37 |
| jelmer | nevans, what does "bzr missing" say? | 18:39 |
| nevans | I'll try to reproduce it... I've got everything committed now. ;-) | 18:39 |
| === kiko-fud is now known as kiko | ||
| jelmer | nevans, thanks | 18:56 |
| abentley | jelmer: You should already have a traceback in the message it sends you. | 19:06 |
| jelmer | ah, I didn't actually bother to look at those | 19:07 |
| jelmer | abentley, http://pastebin.ubuntu.com/16447/ | 19:07 |
| abentley | Well, that's cute. | 19:08 |
| abentley | The message claims to be utf-8, but ain't? | 19:08 |
| abentley | Well, for this purpose, 'replace' should be fine. | 19:09 |
| === tchan1 is now known as tchan | ||
| antoranz | Hi, Guys! | 19:29 |
| semslie | jelmer: a friend and I have started a test script, and confirmed that when the head revision is on the target branch then a the push is successful | 19:31 |
| jelmer | semslie: can you attach that script to the bug report? | 19:31 |
| semslie | jelmer: sure, as soon as its finished I'll do that | 19:32 |
| === bigdo3 is now known as bigdog | ||
| semslie | jelmer: adding something to the target branch fixed the problem in practice, but we are finding that creating a new repository, then making some revisions such that the last revision is not to the target branch is not producing the error on our script. I'll post it if I can get it to reproduce the problem | 19:49 |
| jelmer | semslie, ah, ok - thanks | 19:49 |
| === andrea-bs_ is now known as andrea-bs | ||
| jelmer | beuno, bundlebuggy is up again | 20:28 |
| beuno | jelmer, you rock :) | 20:28 |
| jam | jelmer: so why have you decided to switch from pyrex back into plain 'C' wrappers, and why not just use the latest svn-1.5 bindings? | 20:55 |
| jam | Just curious on your rationale | 20:55 |
| * fullermd has given up believing that svn 1.5 exists. | 20:55 | |
| dato | can I expect the listing in TreeDelta.renamed to be comprehensive on directory renames? | 20:55 |
| dato | hm | 20:56 |
| jam | dato: define "comprehensive" | 20:56 |
| jam | I believe it just lists the directories | 20:56 |
| jam | not their children | 20:56 |
| jam | unless they have *also* been renamed underneath | 20:56 |
| dato | well, I'm confused, because in one bzr-export-case, I get both 'dir1 -> dir2', and then a full list of their children | 20:56 |
| dato | I get | 20:56 |
| dato | dir1 -> dir2 | 20:56 |
| dato | dir1/fileA -> dir2/fileA | 20:56 |
| dato | etc | 20:56 |
| jam | dato: I don't really know what your 'bzr-export-case' is, but generally you don't get that | 20:57 |
| jam | I'm not sure how you could | 20:57 |
| dato | let me see if I can reproduce from a python prompt | 20:58 |
| jam | I need to clean out my spam folder more often.... 15.3k spam messages | 20:58 |
| dato | ah, you are right jam | 20:59 |
| dato | i was just blind; fileA gets renamed too | 21:00 |
| jam | what do you mean 'gets renamed too', shows up in the TreeDelta.renamed? Or just that it was physically moved? | 21:00 |
| dato | yes, that it was dir1/fileA -> dir2/fileB | 21:01 |
| dato | and dir1 -> dir2 | 21:01 |
| jam | right, *that* will show up | 21:01 |
| jam | because we check if the 'parent' or the 'name' has changed | 21:01 |
| dato | now I'm not sure how to make git-fast-import happy about this | 21:01 |
| jam | dato: yeah, because IIRC it *doesn't* handle directory renames | 21:02 |
| jam | so, I think you have to iterate the children and give them new homes | 21:02 |
| jam | if kind == 'directory': iterate_children | 21:02 |
| jam | something like that | 21:02 |
| pygi | poolie, around? :) | 21:03 |
| dato | jam: no, I think it handles them just fine, except this degenerate case in which fileA is the only file in dir1 | 21:04 |
| jam | pygi: poolie is sleeping for a little while longer | 21:04 |
| pygi | jam, oki ^_^ | 21:04 |
| jam | I think he'll be around in maybe 2hrs or so | 21:04 |
| jam | can I help? | 21:04 |
| dato | jam: so if I rename the directory first, the file rename fails; and if I rename the file first, the dir rename fails because the dir is empty so it does not exist for git | 21:04 |
| pygi | jam, lemme pm you :) | 21:05 |
| jam | dato: so do you need to track that the directory was renamed, and then rename the new location? | 21:05 |
| dato | I guess | 21:05 |
| jam | that's... crummy | 21:05 |
| === emgent_ is now known as emgent | ||
| jam | "I caught you naked bazaar-commits-owner" | 21:06 |
| jam | uh-oh, what has poolie been doing | 21:06 |
| jam | At least it is obviously spam when it comes through the bazaar mailing list owner like that | 21:07 |
| === acuster is now known as noone | ||
| === noone is now known as acuster | ||
| fdv | jelmer: you mentioned something a few days ago about some memory leaks in the python-subversion bindings being fixed. If I recall correctly, this was not ported fully to hardy, but fixed someplace else. I'm not sure which packages are actually fixed (or having problems), is this something that's available anywhere? | 21:52 |
| Jc2k | fdv: subversion 1.5 has the fixes | 22:04 |
| fdv | Jc2k: | 22:05 |
| fdv | whoops | 22:05 |
| fdv | Jc2k: they're nowhere else? | 22:05 |
| Jc2k | afaik that means you have some compiling to do :) | 22:05 |
| fdv | well, compiling is no problem | 22:05 |
| Jc2k | 1.5 hit rc8 | 22:05 |
| Jc2k | afaik that is their gold release | 22:06 |
| Jc2k | if all goes well | 22:06 |
| fdv | one can always hope | 22:06 |
| fdv | then maybe I won't care so much for the python bindings anymore | 22:07 |
| fdv | svnmerge is very cumbersome, and being able to use a bazaar mirror would likely be progress | 22:08 |
| fdv | but when I try to import the repo, memory is soon exhausted | 22:09 |
| fdv | so basically, I need a bzr mirror while waiting for decent functionality in svn 1.5, but now I also need svn 1.5 to get a bzr mirror working :p | 22:10 |
| Jc2k | fdv: pretty much ;D | 22:12 |
| Jc2k | fdv: your branch much be special in some way... | 22:13 |
| fdv | maybe | 22:13 |
| Jc2k | i converted 20gb worth of SVN without breaking the hardy python-subversion, 200 modules. A few weighed around 2gb | 22:14 |
| fdv | it's rather big, with lots of history (also from aeons of CVS) and I think they've omitted some conventions | 22:14 |
| fdv | hm | 22:14 |
| Jc2k | how many revisions? | 22:14 |
| Jc2k | evolution had about 23,000 | 22:14 |
| fdv | ~150k | 22:15 |
| Jc2k | yeah, that would explain it | 22:15 |
| fdv | but I think that's only the svn revs | 22:15 |
| Jc2k | :P | 22:15 |
| Jc2k | evo only had 23,000 svn revs but still took 2gb of space on disk - maybe binary data? | 22:15 |
| Jc2k | fdv: are there lots of branches? | 22:16 |
| fdv | probably | 22:16 |
| fdv | yep | 22:16 |
| fdv | plenty :p | 22:16 |
| Jc2k | bugger :) | 22:16 |
| fdv | yep :) | 22:16 |
| Jc2k | do you need them all :D | 22:17 |
| fdv | the svn-import doesn't rise above 0/n | 22:17 |
| fdv | well, not at all | 22:17 |
| fdv | I only need trunk | 22:17 |
| Jc2k | when i did the initial GNOME mirror i only mirrored trunk of each module | 22:17 |
| fdv | but afaics, svn-import won't work with branches | 22:17 |
| Jc2k | and then used svn-import to top them up | 22:17 |
| fdv | how'd that work? | 22:17 |
| Jc2k | http://live.gnome.org/JohnCarr/Bazaar | 22:18 |
| Jc2k | that script creates a repository called $MODULE and then branches trunk of the SVN repo into $MODULE/trunk | 22:18 |
| Jc2k | it used bzr pull to fetch 1000 revs at a time, dodging the leaking | 22:19 |
| fdv | ah :) | 22:19 |
| fdv | neat trick | 22:19 |
| Jc2k | then when i'd done, i discovered svn-import | 22:20 |
| Jc2k | :p | 22:20 |
| Jc2k | so ran that on my mirror of trunk and it figured out what i was missing and started topping stuff up | 22:20 |
| Jc2k | it was pretty good about recovering from errors, too | 22:20 |
| fdv | but that requires the whole repo, right? | 22:20 |
| fdv | I'm not sure I have understood this completely | 22:21 |
| sabdfl | poolie: 1.6rc1 today? | 22:21 |
| Jc2k | fdv: so svn-import works out what the branches are and then makes a bzr repository dir with multiple branch dirs | 22:22 |
| Jc2k | fdv: my bash script does that too, but only for trunk rather than all the branches | 22:22 |
| fdv | right | 22:22 |
| Jc2k | fdv: you could pull the import branches by hand... | 22:22 |
| fdv | I'll certainly give it a shot | 22:22 |
| fdv | well, they're not interesting, really | 22:22 |
| Jc2k | *important branches, even | 22:23 |
| fdv | I just want a non-central repo I can commit to frequently | 22:23 |
| fdv | :) | 22:23 |
| Jc2k | fdv: the page i linked to also has my python script for updating the mirror on svn commit | 22:24 |
| Jc2k | though its a tad specific to the GNOME svn-commits mailing list | 22:24 |
| fdv | I saw it, looks neat :) | 22:24 |
| fdv | well, that could probably be tweaked, I guess | 22:25 |
| === abentle1 is now known as abentley | ||
| beuno | jelmer, btw, BB still won't let me vote via email, just through the web interface. I don't mind at all, but if you happen to trip over the DB and see something funny... :) | 22:25 |
| jam | sabdfl: 1.6beta1 was today, 1.6rc1 is this Fri | 22:35 |
| jam | Jc2k: well, starting with your script might be a good start, depending on if 'svn-import' is smart enough to work in 1k revision batches like yours is | 22:36 |
| Jc2k | jam: it doesn't, i know from locking up my server ;D | 22:37 |
| pickscrape | Is there any chance someone well versed in bzrlib could give me some feedback on the diffstat patch I posted to the mailing list? | 22:37 |
| pickscrape | Since it's my first work using bzrlib I'm uncertain as to whether I've made any monumental screwups or not. :) | 22:38 |
| jam | pickscrape: this is the 'make it work with 1.5' ? | 22:38 |
| pickscrape | jam: yes | 22:38 |
| jam | pickscrape: giving you feedback on the list | 22:44 |
| pickscrape | jam: thanks | 22:45 |
| jam | pickscrape: basic summary, lock your objects, and reuse them as much as possible | 22:51 |
| jam | I sent a modified form to the list | 22:51 |
| jam | I think its right, but you should certainly test it to make sure | 22:51 |
| pickscrape | jam: thanks for that, much appreciated :) | 22:51 |
| poolie | sabdfl: no 1.6rc1 is for friday, beta1 was monday | 22:52 |
| jam | hi poolie, we on for a call in 10min or so? | 22:52 |
| fdv | Jc2k: the last pull in the script, from FINAL_REP, what's the exact purpose of that? | 22:54 |
| jelmer | beuno: I'll have a look at it next time I deal with bundlebuggy | 22:54 |
| fdv | is it so that the bzr repo there is set to "point" to the central svn repo? | 22:55 |
| Jc2k | fdv: in my case i was converting a local rsync'd copy of svn.gnome.org | 22:55 |
| pickscrape | jam: some very useful pointers there: thanks. I didn't actually know about locking at all. | 22:55 |
| Jc2k | so the FINAL_REP just points it at the http://svn.gnome.org/ instead of my local rsync'd copy | 22:55 |
| jam | pickscrape: a lot of api's do it 'automagically' for you, but if you hold the lock, you get more caching | 22:55 |
| pickscrape | The method of parsing diff output is how the inherited code did it (__diff was also inherited), but these are things I could look at next. | 22:55 |
| fdv | right, then I got i correctly (I think) :) | 22:55 |
| jam | especially helpful for multiple 'as_revision_id()' lookups | 22:55 |
| jam | etc | 22:55 |
| fdv | Jc2k: thanks! | 22:55 |
| pickscrape | The first priority was to just get it working with the current version of bzr :) | 22:56 |
| beuno | jelmer, I keep getting emails telling me I'm not allowed to vote. It must be processing my votes through the web interface. Anyway, don't worry about it, just thought I'd mention it | 22:58 |
| lifeless | abentley: agreed; I hadn't fully got the layerings straight in my head | 23:32 |
| timelyx | hrm | 23:37 |
| timelyx | is "versionedfiles" a technical term? | 23:37 |
| lifeless | timelyx: bzrlib.versionedfile is a module in the bzr code base | 23:42 |
| lifeless | timelyx: versionedfiles is an upgraded api I am working on | 23:42 |
| timelyx | ok, and it's spelled in lowercase? | 23:43 |
| timelyx | would it be wrong for me to stick it in ``ticks`` ? | 23:43 |
| lifeless | timelyx: context? | 23:45 |
| timelyx | * New annotate merge (--merge-type=weave) implementation is fast on | 23:45 |
| timelyx | - versionedfiles withough cached annotations, e.g. pack-0.92. | 23:45 |
| timelyx | + versionedfiles without cached annotations, e.g. pack-0.92. | 23:45 |
| timelyx | (Aaron Bentley) | 23:45 |
| lifeless | ah, that is versionedfile pluralised | 23:45 |
| timelyx | grr | 23:45 |
| timelyx | that's just wrong then | 23:46 |
| timelyx | can i do ``versionedfile``s? | 23:46 |
| timelyx | or /something/ | 23:46 |
| timelyx | because your thing really makes what was written there amazingly ambiguous | 23:46 |
| timelyx | or just plain wrong, your choice :) | 23:46 |
| lifeless | I'm looking for a better name | 23:46 |
| timelyx | yeah, i saw | 23:46 |
| lifeless | I wouldn't go change all the existing things just yet :P | 23:46 |
| timelyx | anyway... suggestions? versionedfile's ? | 23:46 |
| timelyx | i'm fixing spelling, as you can see, that line's going to change either way | 23:47 |
| lifeless | versionedfiles is appropriate plural of versionedfile. versionedfile's would indicate ownership | 23:47 |
| timelyx | yeah, but people write url's and stuff | 23:47 |
| lifeless | they are wrong | 23:47 |
| timelyx | it's not right, but it is common :/ | 23:47 |
| timelyx | rather, it isn't right :( | 23:47 |
| * timelyx cries | 23:48 | |
| timelyx | anyway, would ''versionedfile''s be bad? | 23:48 |
| timelyx | or however that magic markup workls | 23:49 |
| lifeless | I think it is fine as it is, given the context and detail present | 23:50 |
| timelyx | ok | 23:50 |
| timelyx | * Add scenarios as a public attribute on the TestAdapter classes to allow | 23:51 |
| timelyx | modification of the generated scenarios before adaption and easier | 23:51 |
| timelyx | testing. (Robert Collins) | 23:51 |
| timelyx | +XXX this doesn't make sense | 23:51 |
| timelyx | "adaption" is generally not considered much of a word | 23:51 |
| lifeless | if you wish to refer to the class name more precisely it is ``bzrlib.versionedfile.VersionedFile``, and I would probably phrase it as 'on $above implementations' rather than using the plural ABC. But its not a problem as it is :) | 23:51 |
| timelyx | the tail of that "sentence" doesn't work (before X and easier Y) | 23:52 |
| lifeless | to allow (modification of the generated scenarions before adaption) and (easier testing) | 23:52 |
| lifeless | AFAIK its ok english | 23:52 |
| lifeless | also | 23:53 |
| lifeless | http://dictionary.reference.com/search?q=adaption | 23:53 |
| timelyx | yeah, i know... it's just that things like: http://www.merriam-webster.com/dictionary/adaption | 23:55 |
| timelyx | basically say "not common, use X" | 23:55 |
| lifeless | it would be a boring world if we only used the most common ways to say something | 23:55 |
| Marco | Hello | 23:56 |
| Marco | I'm doing bzr up on a branch I checked out from a launchpad project | 23:57 |
| Marco | and it insists that it's up to date at revision 332 even though the most recent revision is 335 | 23:57 |
| lifeless | Marco: bzr info | 23:57 |
| lifeless | Marco: if it does not say 'checkout of' then you made a new branch (e.g. bzr branch) rather than a checkout (e.g. bzr checkout) | 23:57 |
| Marco | is there a way to "convert" a new branch into a checkout? | 23:58 |
| Marco | I haven't made any changes | 23:58 |
| thumper | if someone was looking to switch from CVS to Bazaar, what is the currently accepted "best converstion tool"? | 23:58 |
| lifeless | Marco: you can convert it to a checkout with 'bzr reconfigure --checkout' | 23:58 |
| timelyx | lifeless: if i reordered it as to allow easier testing and modification... | 23:58 |
| timelyx | would you object? | 23:58 |
| lifeless | timelyx: generally I think we shouldn't alter NEWS that has been issued | 23:59 |
| timelyx | ok | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!