| === spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | Hooray for jelmer | ||
| spiv | poolie: btw, remembering a conversation from Thursday, removing say the old CHK1 and CHK2 formats would cut about 30s (of 10m) from selftest (forking on 4 cores). | 01:38 |
|---|---|---|
| lifeless | spiv: I had a branch to drop a bunch of formats way back... doit | 01:38 |
| spiv | poolie: and also, the subunit tools failed to help me determine that :( | 01:38 |
| lifeless | spiv: they did? | 01:38 |
| lifeless | spiv: there was a timing bug with --parallel that mgz fixed | 01:39 |
| spiv | lifeless: yeah, I need to dig, but e.g. the obvious subunit-filter --match invocation seemed to drop way more tests than is reasonable. | 01:39 |
| poolie | spiv, i kind of suspect they will become buggy once they're moved out | 01:39 |
| poolie | thanks for the data | 01:39 |
| spiv | poolie: well, they are old dev formats: I was thinking of deleting them entirely. | 01:40 |
| poolie | there are options: do nothing; just delete them; move them to a plugin; leave them in but untested by default | 01:40 |
| poolie | i think that's best too | 01:40 |
| lifeless | exactly, nuke and forget | 01:40 |
| spiv | I think I'd be against in-but-untested. | 01:40 |
| poolie | i don't think splitting to a plugin will be worth the current and ongoing work | 01:40 |
| poolie | make sure it's in whatsnew | 01:40 |
| poolie | and maybe post to the blog | 01:41 |
| spiv | Right: we have old releases for anyone sufficiently desperate. | 01:41 |
| poolie | with clear text about them only being dev formats | 01:41 |
| lifeless | we've done this before with less drama :) | 01:52 |
| lifeless | just noting | 01:52 |
| init | hello | 05:04 |
| init | question: is it possible to get CIA working with bzr_access? | 05:04 |
| poolie | i think so; not sure | 06:50 |
| poolie | a link to a zip holding an MS Write file | 07:45 |
| poolie | :? | 07:45 |
| poolie | spiv, i'm thinking of doing a 2.2.2 this week | 07:55 |
| poolie | night all | 08:15 |
| peitschie_ | night poolie | 08:18 |
| === beaumonta is now known as abeaumont_ | ||
| === jelmer is now known as Guest24864 | ||
| === Guest24864 is now known as jelmer | ||
| zyga | lifeless, ping | 15:11 |
| zyga | lifeless, could you please review my merge of testtools.TestCase, testscenarios.TestWithScenarios and django.test.TestCase (+TransactionTestCase) | 15:12 |
| dstuart | Quick question, I have two separate active subversion instances that I wish to use bzr to merge the changes into one consolidated branch and then push back to only one of the subversion servers. Is this possible? | 15:22 |
| === nailuj24_ is now known as nailuj24 | ||
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| lifeless | zyga: link ? | 16:39 |
| zyga | lifeless, just a second | 16:40 |
| zyga | lifeless, https://code.launchpad.net/~zkrynicki/django-testscenarios/0.2/+merge/41474 | 16:41 |
| zyga | lifeless, you can just look at the part relevant to init.py where the code actually lives\\ | 16:41 |
| zyga | lifeless, and disregard everything else | 16:41 |
| zyga | lifeless, http://bazaar.launchpad.net/~zkrynicki/django-testscenarios/0.2/annotate/head%3A/django_testscenarios/__init__.py | 16:43 |
| lifeless | zyga: cool stuff, I've added what comments I have to it. | 16:45 |
| zyga | lifeless, thanks :) | 16:46 |
| === jelmer is now known as Guest34932 | ||
| === Guest34932 is now known as jelmer | ||
| zyga | lifeless, actually there is no redundancy there, django cheated a little bit in how it setups testing environment | 16:50 |
| zyga | lifeless, that made it not work with trivial inheritance | 16:50 |
| zyga | lifeless, or perhaps I misunderstood you somehow | 16:51 |
| lifeless | zyga: Well, I saw that the methods are different | 16:51 |
| lifeless | but they are about 80% the same | 16:51 |
| zyga | lifeless, you mean the if scenarios part? | 16:52 |
| lifeless | yah | 16:52 |
| lifeless | if you ever need to change it, you've got two places to do it | 16:52 |
| zyga | I see what you mean, I did not find any way to make it shorter that would still work with django, there's a nasty interplay of __calL__ and run() that happens otherwise | 16:54 |
| lifeless | yeah | 16:54 |
| lifeless | I could tell :) | 16:54 |
| sladen | bzr commit locally tells me that it can't lock a remote lockfile | 16:54 |
| lifeless | testtools has a nice thing called RunTest which could in principle handle the scenarios glue for you - and the django transaction stuff, but its likely a little complex to get established | 16:54 |
| sladen | lifeless tells me this is because I don't have a full branch | 16:55 |
| sladen | so two questions (a) what's the workaround to turn whatever I have into something that I can commit to | 16:55 |
| sladen | and (b) what would be the best jargon to file a bug that users should not need to know the difference and it should always "just work" | 16:56 |
| jam | sladen: if you did "bzr co --lightweight" you explicitly asked for something that did not have a branch of its own (--lightweight) | 16:59 |
| jam | bzr reconfigure --standalone ? will probably get you a full branch locally | 17:00 |
| jam | probably you'll want to check "bzr help reconfigure" as there are a few options | 17:00 |
| sladen | jam: don't recall having done --lightwieght at any point, hence puzzled | 17:02 |
| sladen | jam: bzr: ERROR: ... is already standalone. | 17:03 |
| lifeless | sladen: I said 'you hav a checkout of some sort' - I don't have a crystal ball to infer lightweight or not | 17:03 |
| lifeless | sladen: I contrasted that with 'struely independent branch' | 17:03 |
| lifeless | sladen: truely independent is not a synonym for full. | 17:04 |
| lifeless | sladen: did you do 'bzr co' | 17:04 |
| jam | sladen: sorry, "checkout" implies that commiting here will commit there | 17:04 |
| jam | if you have a non lightweight checkout, then you can "bzr unbind". | 17:04 |
| lifeless | sladen: As for a bug, there is already a general thing to overhaul the user experience vis-a-vis workflow and defaults, I don't think a point item will help | 17:05 |
| sladen | jam: bzr unbind worked | 17:05 |
| lifeless | this is almost certainly another of the 'git is different to the rest of the world' issues. | 17:05 |
| sladen | lifeless: I think the users need to stop thinking that bzr is git, and the developers need to stop thinking that every usability/weird design issue is down to "not git" :) | 17:06 |
| lifeless | sladen: they don't think that. | 17:07 |
| lifeless | this area needs improvement. | 17:07 |
| lifeless | The specific expectation that checkout would be anything other than what it was for 30 years of non-D VCS is a bitkeeper inherited behaviour in git | 17:08 |
| sladen | lifeless: for me, that is the difference between VCS and DVCS | 17:10 |
| sladen | that things "just work" locally when in the past you got all sorts of conflicts, edit-wars, I-commited-last-damnit that VCS gets you | 17:11 |
| Tak | so if you do: git checkout git://github.com/foo/bar , it just works? ;-) | 17:13 |
| sladen | Tak: is "just works" in that case committing the change /and/ pushing it back to github ? | 17:14 |
| lifeless | sladen: if you're using bzr, yes. | 17:14 |
| sladen | `*sudder* | 17:15 |
| sladen | shudder | 17:15 |
| lifeless | thats exactly what bzr checkout git://github.com/foo/bar does | 17:15 |
| sladen | that seems awefully SVN and un DVCS-like, but I dare say it's been doing that for five years | 17:16 |
| sladen | jam: lifeless: Tak: thank you for the bzr unbind hint | 17:17 |
| === deryck is now known as deryck[lunch] | ||
| Tak | well, if you want "dvcs-like" behavior, you read the manual and use the branch command instead, just like new git users have to read the manual and find out that they have no idea what the checkout command is supposed to do | 17:19 |
| lifeless | sladen: so there are two reasons checkout does what it does | 17:20 |
| lifeless | sladen: firstly, centralised -workflow- is actually very useful. Rebasing-on-push is a rather terrible idea, if you accept (as I think most folk do) that rebase turns tested code into untested code. | 17:20 |
| lifeless | sladen: secondly, for many users coming to bzr, CVS, or SVN, or other centralised only tools are the prior experience, and checkout being the same gives them a solid onramp. | 17:21 |
| lifeless | sladen: its a real shame that git is so fundamentally different here, because that adds a tension between help one set, or help another. | 17:22 |
| lifeless | sladen: but like I say, there's a more general 'help folk through things' effort as part of a ui overhaul. | 17:22 |
| sladen | lifeless: nod. converting/helping SVN users is a use-case here | 17:22 |
| jam | lifeless: what TZ are you in now? (real-world, and effective, I guess) | 18:02 |
| jam | I keep seeing you online with *far* too much overlap with my TZ :) | 18:02 |
| lifeless | jam: GMT+15 or so | 18:03 |
| lifeless | I should be in +13 | 18:03 |
| zyga | lifeless, are you working on rebase/rewrite plugin for bzr? | 18:11 |
| lifeless | zyga: me? no, I'm not doing anything on bzr these days. | 18:12 |
| zyga | lifeless, buggers, I wish you did | 18:12 |
| lifeless | zyga: jelmer might in the new year | 18:13 |
| lifeless | who knows | 18:13 |
| zyga | lifeless, I noticed you assigned yourself to one of the bzr bugs about this | 18:13 |
| lifeless | its probably stale | 18:13 |
| lifeless | one of the problems with the 'assigned' state in volunteer structures. | 18:13 |
| === deryck[lunch] is now known as deryck | ||
| axle3d | hay, i want to download a specific branch, LATEST revision with bzr. I already know how to download the branch, but how can i only get the latest revision? | 18:42 |
| jelmer | axle3d: you would just like to check out the latest revision, not any of the history? | 18:43 |
| jelmer | axle3d: "bzr export" should do that for you. | 18:44 |
| === Meths_ is now known as Meths | ||
| spiv | Good morning | 21:04 |
| spiv | jam: and especially good morning to you! | 21:05 |
| jam | morning spiv, good to see you around | 21:05 |
| poolie | hi jam, spiv | 21:19 |
| spiv | jam: I'm really looking forward to commit-on-stacked and shallow branches happening | 21:19 |
| mwhudson | is there an easy way to find all revids that touched a file? | 22:21 |
| mwhudson | tiny repo, ~100 revs, so don't care about performance | 22:21 |
| Peng | bzr log --show-ids some_file | grep ...um...I forget the string... | 22:22 |
| mwhudson | from the api :) | 22:22 |
| mwhudson | i guess i'll read the log source | 22:22 |
| spiv | mwhudson: 'bzr touching-revisions'? | 22:22 |
| Peng | Aww, no fun. | 22:23 |
| Peng | mwhudson: subprocess.call()! :D | 22:23 |
| mwhudson | spiv: hm, thanks | 22:23 |
| mwhudson | only mainline? | 22:23 |
| mwhudson | don't actually care in this case i guess | 22:23 |
| jam | mwhudson: depends whether you consider "I merged your changes, but otherwise didn't touch the content" to be a change | 22:27 |
| jam | 'bzr log' does | 22:27 |
| jam | otherwise | 22:27 |
| jam | revs = repo.all_revision_ids() | 22:27 |
| jam | file_id = ?? | 22:27 |
| jam | possible_keys = [(file_id, r) for r in revs] | 22:27 |
| jam | real_keys = repo.texts.get_parent_map(possible_keys) | 22:27 |
| jam | there are other possibilities | 22:28 |
| jam | if you want just the changes in the ancestry of the given tip, etc | 22:28 |
| spiv | jam: that's not strictly right | 22:28 |
| spiv | jam: a (file_id, rev_id) text may be associated with a revision other than rev_id | 22:29 |
| spiv | I think... | 22:29 |
| jam | spiv: only in the presence of ghosts | 22:29 |
| jam | otherwise a revision must introduce a text with its revid | 22:29 |
| jam | spiv: and IIRC, only bzr-svn cheats this way | 22:30 |
| jam | and jelmer has been trying to figure out if it should | 22:30 |
| jam | the latest version doesn't, but suffers from the mismatched inventories, etc. | 22:30 |
| spiv | Yes, certainly ghosts. I think perhaps there's also some data from relatively old bzr versions that don't adhere to that strict policy, but that we still consider valid. I have vague memories of all this from my past adventures with reconcile. | 22:32 |
| jam | spiv: right, reconcile was meant to fix those. Also, there is the bug that it doesn't track deletions. | 22:34 |
| jam | so the other way to do it is to iter the changes to inventories | 22:35 |
| mwhudson | how do i get bzr builddeb to use the pristine tar info to recreate the orig.tar.gz? | 23:24 |
| mwhudson | ah: make sure the upstream tag is in the branches ancestry | 23:29 |
| mwhudson | (which i thought i'd done, but goofed) | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!