| jelmer | anthony__: #ubuntu is probably more appropriate for ubuntu problems | 00:03 |
|---|---|---|
| spiv | Good morning. | 01:06 |
| mwhudson | spiv: good morning | 01:08 |
| mwhudson | spiv: enjoy your weekend? :) | 01:08 |
| mwhudson | i hear something happened in australia | 01:08 |
| spiv | mwhudson: turns out we get to join the UK in making 'hung' parliament jokes! | 01:09 |
| mwhudson | spiv: congrats | 01:13 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| poolie | hi spiv, lifeless | 02:54 |
| lifeless | hi poolie | 02:54 |
| spiv | Hi poolie | 02:56 |
| poolie | spiv, apparently you are pp this week | 02:57 |
| spiv | Oh, right. Thanks for reminding me :) | 02:57 |
| === poolie 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 | bzr 2.2-final has gone gold, build those installers | ||
| poolie | np | 02:58 |
| poolie | rms complained on behalf of emacs devs about the "locks aren't released on interrupts" bug | 03:01 |
| poolie | https://bugs.edge.launchpad.net/bzr/+bug/257217 | 03:01 |
| ubot5 | Launchpad bug 257217 in Bazaar "closing terminal causes stale lock (affected: 0, heat: 2)" [High,Confirmed] | 03:01 |
| poolie | iwbn to either check it's unwound, or perhaps auto-delete locks from the same machine where the process is obviously gone | 03:01 |
| spiv | Treating SIGHUP as KeyboardInterrupt sounds ok to me. | 03:05 |
| poolie | there was a bug about insisting on a username being set | 03:05 |
| poolie | that'd be a good start | 03:06 |
| poolie | i was thinking of doing that this afternoon since elmo etc seem to find it painful | 03:06 |
| spiv | (And quick experiments suggest that SIGHUP is probably what is happening.) | 03:06 |
| poolie | istm that using $user@$mailname should be safe, and should probably work without manual configuration on our machine | 03:06 |
| poolie | machines | 03:06 |
| poolie | arguably we should unwind on sigterm too | 03:07 |
| poolie | i think the other problem we're likely to hit here is that the transport may be busy | 03:07 |
| poolie | or may not like being interrupted | 03:07 |
| spiv | True, although what's the worst that'll happen? Most likely the worst is that the unwind will run afoul of EINTR issues and fail to unlock, so no worse than the status quo :) | 03:08 |
| spiv | And hopefully better for at least some transports. | 03:09 |
| poolie | oh, i'm not saying this is a reason not to unwind on those signals | 03:16 |
| poolie | rather that people may just find that they get TooManyConcurrent things | 03:17 |
| poolie | instead of it actually unlocking | 03:17 |
| poolie | however we can fix that one step at a time | 03:17 |
| spiv | Right. | 03:22 |
| poolie | spiv, i'm away after today, is there anything you want me to do, or to give my attention to? | 03:31 |
| spiv | Not off the top of my head. If I think of something I'll let you know ASAP. | 03:32 |
| === mlh_ is now known as mlh | ||
| thumper | http://www.ibm.com/developerworks/aix/library/au-spunix_bazaar/index.html | 05:59 |
| thumper | in case people missed it | 05:59 |
| thumper | interesting that the author is a ruby on rails guy | 05:59 |
| thumper | (interesting in that most of ruby people use git) | 05:59 |
| === zooko` is now known as zooko | ||
| glyph | Hey guys. Any workaround for this? <https://bugs.launchpad.net/bzr/+bug/622549> | 06:55 |
| ubot5 | Launchpad bug 622549 in Bazaar "bzr 2.2 as bundled for MacOS can't make a branch of CalendarServer (affected: 1, heat: 6)" [Undecided,New] | 06:55 |
| spiv | jelmer: got a workaround for glyph? | 07:01 |
| spiv | glyph: I suppose you could try get Launchpad to import it... | 07:02 |
| spiv | glyph: I wouldn't expect it to do much better, but at least it'll cause the LP devs to care about the bug too ;) | 07:03 |
| glyph | spiv: Well, you've got the URL :). Unfortunately my next step is to go back to SVN, unless I can find an immediate workaround. | 07:03 |
| glyph | spiv: is there already a launchpad project for C&CS? | 07:09 |
| poolie | glyph: i would try installing bzr-svn into ~/.bazaar/plugins | 07:09 |
| poolie | from its trunk | 07:09 |
| spiv | glyph: not that I know of. If a quick search doesn't find one I'd just register one. It's not too hard to shift the branches across later if it turns out there is a project for it already. | 07:09 |
| poolie | glyph: to judge from the bug it seems to be a dupe of, it is a bug in the mac packaging not in the code it-self | 07:11 |
| glyph | poolie: huh. from trunk? how about a release version? :) | 07:19 |
| poolie | or the latest release | 07:19 |
| glyph | OK, I'll give that a shot tomorrow, catch you later :) | 07:21 |
| vila | hi all! | 08:00 |
| glyph | poolie: After sticking the last bzr-svn release into my ~/.bazaar/plugins, it is looking good-ish | 08:12 |
| poolie | glyph: that's great | 08:12 |
| glyph | poolie: thanks for the help :) | 08:34 |
| poolie | np, sorry for the snag | 08:37 |
| poolie | and thanks for the feedback | 08:37 |
| GaryvdM | Hi poolie. | 09:00 |
| GaryvdM | I'm looking at Bug #621161 | 09:01 |
| ubot5 | Launchpad bug 621161 in Bazaar "failed to load compiled extension: cannot import name _bytes_to_text_key (affected: 1, heat: 8)" [High,In progress] https://launchpad.net/bugs/621161 | 09:01 |
| === lindbohm.freenode.net changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.2-final has gone gold, build those installers | ||
| poolie | thanks gary | 09:02 |
| GaryvdM | poolie: I see you added the *_pyx.c files to the packaging branches, but they are not in the debian unstable branch. Any objection to me removing them? | 09:03 |
| poolie | no | 09:03 |
| GaryvdM | Ok | 09:03 |
| poolie | i didn't intentionally specifically add them | 09:04 |
| spiv | cody-somerville: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/528041 has SRU approval now | 09:07 |
| ubot5 | Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 145)" [Undecided,Confirmed] | 09:07 |
| spiv | Heh. | 09:09 |
| GaryvdM | jelmer: It seems like you have renamed .bzrignore to .bzrignore.THIS in http://bzr.debian.org/pkg-bazaar/bzr/unstable/ | 09:17 |
| === Guest73756 is now known as jelmer | ||
| jelmer | GaryvdM: ah, thanks | 09:18 |
| === jelmer is now known as Guest76162 | ||
| Guest76162 | I suspect that may be related to bzr merge-upstream removing .bzrignore | 09:18 |
| poolie | vila, spiv was going to see about getting the sru policy to state that we're allowed to put in point releases | 09:37 |
| poolie | i don't know if we should still push on this | 09:38 |
| poolie | spiv it might be worth still just talking the issues over with one of the sru managers | 09:38 |
| === Guest76162 is now known as jelmer | ||
| vila | poolie, spiv: great to hear, I'm pretty our point release policy is in line with the SRU one but we may need a few iterations to convince people | 09:40 |
| vila | s/convince/demonstrate or something/ | 09:40 |
| poolie | mm, i think it is | 09:40 |
| poolie | vila, you could talk to them instead/as well if you want | 09:40 |
| poolie | i think colin watson is one | 09:40 |
| poolie | night spiv, GaryvdM | 10:27 |
| GaryvdM | night poolie | 10:28 |
| spiv | poolie, vila: I was talking with pitti about this earlier today | 10:39 |
| vila | spiv: cool, and the summary is ? | 10:39 |
| spiv | vila: the key bit I guess is <pitti> if all the changes in the new version are just safe and tested bug fixes, it's generally accepted | 10:40 |
| spiv | vila: plus the regression risk for our changes are quite low (especially as bzr isn't going to make your system unbootable) | 10:40 |
| spiv | And concretely he approved the diff for the 2.1.2 update quite quickly: our test suite gives a lot of confidence I think. | 10:42 |
| vila | spiv: great, so our efforts will pay off. If we can get newer bzr versions into older ubuntu releases that will make less maintenance for us :) | 10:42 |
| poolie | i wonder why the _pyx.c files are showing up in the diff? | 10:49 |
| GaryvdM | poolie: In some versions of the packaging branch, .bzrignore is removed / renamed. | 10:54 |
| GaryvdM | I'm not sure what creates the diff though, so that may be a miss diagnosis. | 10:55 |
| spiv | poolie: My guess is the .deb packages are based on our release tarballs, which include *_pyx.c files IIRC | 11:06 |
| spiv | Certainly the packaging branch has no common history with lp:bzr :/ | 11:07 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| === jkakar_ is now known as jkakar | ||
| thrope | hi - is there any way to copy a file from one branch to another unrelated branch while preserving history for that file? | 13:23 |
| Noldorin | i'm trying to manually remove a plugin from bzr, but when i delete it from the plugins folder, bzr still recognises it (listed under 'bzr plugins' | 13:30 |
| Noldorin | what's the problem here? | 13:30 |
| maxb | There must be another copy installed somewhere else | 13:31 |
| thrope | Noldorin: maybe you have an egg ... check for anything in site-packages | 13:31 |
| Noldorin | thrope, right... | 13:31 |
| fullermd | thrope: No, you can't really do that sort of copy. Files don't have history, history has files. | 13:32 |
| thrope | no plugin or tool to just play the commits affecting that file (and only the bits affecting that file) in a new repo? | 13:33 |
| fullermd | Not that I know of. Unless there's something in rewrite. | 13:34 |
| thrope | ok thanks | 13:34 |
| Noldorin | thrope, maxb: nothing in site-packages now, but it's still listing | 13:35 |
| thrope | do you have a .local or anytihng in your home directory? | 13:35 |
| maxb | Noldorin: start a python interpreter, do "import bzrlib.plugins.whatever" then "bzrlib.plugins.whatever" | 13:35 |
| Noldorin | ok | 13:35 |
| Noldorin | thrope, where would that be (on windows)? | 13:37 |
| Noldorin | maxb, yeah, so that pointed to a 'tfs' dir in site-packages, which i then removed. same problem though | 13:37 |
| thrope | oh I'm not sure - youre user home directory but I think thats much less likely on windows | 13:37 |
| thrope | how are you running bzr? if it is through tortoise have you restarted? | 13:38 |
| maxb | Noldorin: do it again after removing whatever you removed, then | 13:38 |
| Noldorin | maxb, maybe this sheds some light on the problem? http://pastebin.com/D0h8u1xK | 13:39 |
| Noldorin | thrope, via the command line. | 13:39 |
| Noldorin | it's installed as an EXE until c:\program files\bazaar | 13:39 |
| GaryvdM | Noldorin: If you run bzr plugins -v, it shows you the file location that it got the plugin from. | 13:42 |
| Noldorin | GaryvdM, unfortunately it doesn't list the directory of the plugins that couldn't load | 13:43 |
| Noldorin | just they they couldn't be loaded from 'C:/Program Files/Bazaar/plugins' | 13:43 |
| Noldorin | hrmm | 13:44 |
| GaryvdM | Noldorin: From the pastebin, it seems you have 3 copies of tfs: 'C:/Program Files/Bazaar/plugins/tfs', 'C:/Program Files/Bazaar/plugins/tfsd' and another that should show in plugins -v | 13:44 |
| Odd_Bloke | Hello all. Is it possible to fast-export a particular subdirectory of my bzr branch (i.e. /addons/accounts/) and get rid of a prefix of the paths? So all the commits related to /addons/accounts/ would be output as relating to /accounts/. | 13:52 |
| jelmer | Odd_Bloke: any reason for not just using "bzr split" ? | 13:56 |
| Odd_Bloke | jelmer: Ignorance. :) | 13:57 |
| Odd_Bloke | jelmer: I still need to be able to fast-export, to import into a git repo. bzr split doesn't seem to do this? | 14:03 |
| maxb | GaryvdM: new bzr-pipeline packages uploaded to bzr/proposed. | 14:07 |
| GaryvdM | maxb: Great~ | 14:08 |
| GaryvdM | 11 hour build queue though :-( | 14:08 |
| maxb | I cheated slightly, and uploaded them as urgency=medium :-) | 14:09 |
| maxb | lucid build just finished :-) | 14:09 |
| GaryvdM | Oh - I did not know that made a difference :-O | 14:09 |
| jam | hey vila, good to have you back | 14:32 |
| GaryvdM | Hi jam. | 14:34 |
| vila | hey jam ! Good to be around and welcome back too :) | 14:35 |
| Noldorin | GaryvdM, http://pastebin.com/KqNnVWc2 - not quite i'm afraid | 14:46 |
| Noldorin | GaryvdM, any thoughtS? | 14:55 |
| GaryvdM | Noldorin: Well - I would start by removing the tfsd copy. | 15:01 |
| Noldorin | GaryvdM, it's not there :S | 15:02 |
| jam | vila: ping about https://code.launchpad.net/~jameinel/bzr/2.3-btree-chk-leaf/+merge/31904 | 15:05 |
| vila | jam: /me scratching head | 15:07 |
| vila | jam: they are test fixtures, I can't think of a previous case where we needed test fixtures in production code | 15:08 |
| vila | jam: are they static functions or can you call them from a different C module ? | 15:10 |
| jam | vila: they are thunks over to the actual C code | 15:11 |
| jam | I can call them whatever you want | 15:11 |
| jam | I can't really put all of them in another module, since some of them are on the class | 15:11 |
| jam | I can call them "_foo" instead of "foo" or py_foo or whatever | 15:11 |
| jam | and we have those in other code | 15:11 |
| jam | though I probably called them py_foo | 15:12 |
| GaryvdM | Noldorin: I'm sorry, I'm not sure then. | 15:12 |
| Noldorin | GaryvdM, no worries. but yeah, it's odd. no tfs/tfsd folder anywhere | 15:12 |
| vila | jam: I won't block on that but having test fixtures in production code tells me something is wrong either the API doesn't expose the right bits to be testable or we don't test the right things or... dunno, bad feeling | 15:16 |
| vila | may be just make them private or something if they are just accessors... | 15:18 |
| GaryvdM | Noldorin: Have you looked at .bzr.log? | 15:18 |
| vila | it may also be because they should be tested from a C framework... | 15:18 |
| vila | jam: may be the 'test_' prefix triggered a knee-jerk | 15:19 |
| jam | vila: if I was writing Cython code, I would have used "cpdef foo" | 15:19 |
| jam | which defines both a pure-python 'foo' and a C 'foo' and selects the right one at compile time | 15:20 |
| vila | they don't test anything really | 15:20 |
| vila | hmm, interesting, when do we switch ? :D | 15:20 |
| jam | vila: they don't test anything, they expose a function to pure python that I only want the code to be calling from within C | 15:21 |
| vila | jam: right, so they are accessors targeted at tests, may be a simple s/test_/get_/ will be enough | 15:21 |
| jam | would you be happier with py_ or _py_ prefix? | 15:21 |
| vila | jam: yup, I think so | 15:22 |
| Noldorin | GaryvdM, http://pastebin.com/hkfm92kc | 15:22 |
| Noldorin | interesting | 15:22 |
| jam | they are a little bit test related, since the return types, etc are tuned for ease of testing, versus ease of use as an api | 15:22 |
| vila | jam: no problem with that, if more uses are discovered, since they are private, they could be tuned again :) | 15:22 |
| jam | they aren't exactly accessors, since some of them actually call another function | 15:23 |
| jam | but some, yes, since they wrap the internal object back into python objects | 15:23 |
| vila | jam: on the other hand, IME tests help a lot to find the right APIs... so I'm not that concerned about them not addressing needs you didn't... need :) | 15:24 |
| GaryvdM | Noldorin: Line 13 does seem to suggest that there is a C:/Program Files/Bazaar/plugins\tfsd | 15:25 |
| Noldorin | GaryvdM, yeah, it's really strange. it definitely doesn't exit. | 15:25 |
| jam | *sigh* I just upgraded to Thunderbird 3, and it turns out to be a bigger memory hog that *Firefox* | 15:33 |
| jam | I had to prune a lot of old stuff because otherwise the indexing would hit 1GB+ | 15:33 |
| jam | (I had ~300k spam messages, that I didn't really want indexed, and was just keeping in case I wanted to train a future spamassassin, sort of thing) | 15:34 |
| GaryvdM | jam: Yhea - I ended up disabling the indexing. | 15:34 |
| jam | the global search seems interesting, but the bloat, dear god the *bloat* :) | 15:35 |
| fullermd | 300k spams?! | 15:35 |
| fullermd | Why would you keep a whole week around? | 15:35 |
| jam | I should not be getting lag *while typing* | 15:35 |
| GaryvdM | I give the indexing a go again when 3.1 is available in ubuntu | 15:36 |
| jam | GaryvdM: I also find it very surprising that on Windows, they put the global sqlite file in Roaming. Which means 400-1GB of data gets put in what would be your 'synchronized between machines' location. | 15:38 |
| jam | GaryvdM: you *can* select a folder to not be indexed, but you have to do it manually for each folder you want that way, I couldn't find a way to batch select | 15:40 |
| jam | which was also pretty annoying, since I was sorting old content | 15:40 |
| Noldorin | GaryvdM, as stumped as me, eh? | 15:42 |
| GaryvdM | Noldorin: Yhea. I would maybe resort to using pdb, but maybe someone else may be able to help. | 15:43 |
| Noldorin | GaryvdM, ok, no worries. thanks anyway | 15:44 |
| Noldorin | pdb i might try, yeha | 15:44 |
| dahoste | hey #bzr gurus. | 15:50 |
| dahoste | I'm a recent convert from svn. Loving bzr so far. Lightweight checkouts were the seal-the-deal feature for me (over hg). | 15:51 |
| dahoste | I have a new project about to get started, though, and there's a very strong case for needing 'sparse' (sometimes called 'partial') checkouts, which are common in svn-land. | 15:52 |
| dahoste | What are the odds of ever seeing good native bzr support for such a feature? | 15:52 |
| fullermd | Well, I'd like to see it, but I don't think it's in screaming distance of the top of anybody's todo list... | 15:57 |
| dahoste | I.e. is it architecturally feasible, and just hasn't been done yet, or does the notion itself go too severely against the grain of bzr's concept of repo? | 15:57 |
| jam | dahoste: the recommendation is to split up the project into multiple smaller projects | 15:57 |
| jam | it is against the concept of 'atomic tree' | 15:58 |
| jam | possible, we've discussed it periodically | 15:58 |
| fullermd | Well, distinguish partial _checkouts_ from partial _branches_. There's no sensible way to _branch_ just a subpart of a branch, but there's no reason at all that you can't conceptually have a _working tree_ that only has some of the files. | 15:58 |
| fullermd | Bah. So does being able to specify files to 'commit'. In fact, it's exactly the same againstness. | 15:58 |
| jam | but it raises some issues with 'commit' when files aren't present, and what to do if 'merge' would touch files you don't have, etc | 15:58 |
| dahoste | yeah, in my case I figured the 'need' for partial checkouts should probably be converted into an argument for re-organizing the project into multiple pieces. That's sensible to some degree, but still runs aground in some places. The _ideal_ scenario would indeed allow for partial branches, but partial checkouts would be a huge win. | 16:05 |
| dahoste | jam, as for commit issues... it probably makes a huge difference whether a hypothetical 'partial' working tree is partial in a fine-grain sense (i.e. scattershot, file by file, dir by dir) vs. partial in a course-grain sense (the checkout designated a node in the tree as a root point and implicitly included everything from there down, as an 'atomic subtree'). If that makes any sense.... | 16:09 |
| fullermd | Well, I don't worry about partial branches. That's a major break, and besides, as long as you're in a repository, the marginal cost of a branch is near zero. | 16:11 |
| dahoste | But I'm talking just from an outside perspective. I don't have any insight into the guts, of either svn or bzr. For instance, I know svn poops in every dir of the working tree ('.svn') but don't know if that's the lynchpin in its ability to do partials, or is just incidental implementation detail. And note that I love the fact that bzr doesn't poop all over the working tree. | 16:12 |
| rubbs | I'm not familiar with partial checkouts/branch workflows, but would views help? | 16:15 |
| fullermd | Well, since svn doesn't have any "base" granularity, it sorta has to have arbitrary support to work at all. | 16:15 |
| fullermd | Since each dir only knows about itself and its subdirs in a .svn/ sense, partials Just Work(tm). Doing it all from a central location requires explicitly adding support. | 16:16 |
| jam | dahoste: one of the primary problems with the svn model is that while commit either succeeds or fails, it doesn't track whether the files are in a consistent state across the tree | 16:17 |
| jam | meaning. if you commit to 'foo' I can commit to 'bar' without updating foo | 16:17 |
| jam | even though they may be logically linked | 16:17 |
| jam | pretty much all DVCS take that to the next step, and say that everything in the tree must be up to date for the commit | 16:17 |
| jam | (each commit is a tree-wide state) | 16:18 |
| jam | being able to branch 'part' of that doesn't make a lot of sense | 16:18 |
| dahoste | rubbs, I did initially hope that views combined with a lightweight checkout might scratch the itch well enough. But my understanding of views is that they're really just local 'convenience' filters, and don't affect what comes/goes over the wire, or what actually resides in the working tree. | 16:18 |
| rubbs | dahoste: correct, but I'm not sure why that's such a big problem. Again, I'm naive about partial branch workflows, but why would you not want a consistant branch altogether? Partials to me seem to give a disjointed feel. | 16:20 |
| === zyga is now known as zyga-afk | ||
| jam | rubbs: my guess is for someone coming from svn, where everything is one-big-tree | 16:21 |
| fullermd | Again, distinguish partial branches from partial checkouts. Since revisions are whole-tree, partial branching is a serious model break. | 16:21 |
| fullermd | Partial checkouts aren't. Certainly you can think of a handful of different levels of support, of increasing demands on the tool, but... | 16:22 |
| dahoste | jam, yeah, I guess that's just the inherent trade-off of the design. And don't get me wrong - I'm not faulting bzr for not being able to do partials. But it came up as a potential show-stopper for using bzr in a new project, and I just wondered what the likelihood was of bzr ever fielding such a feature. hg has some half-baked notions about it, but I'm not holding my breath about it either -- I'm sure it faces similar architectural obstacles t | 16:22 |
| dahoste | o doing it as bzr. | 16:22 |
| jam | dahoste: the most likely solution bzr will implement is similar to git's submodules, and IIRC hg's forest extension. Where you can define that *this* tree depends on 'those' trees. So when you do a checkout of the top level, you get everything, but you can also just request for a single subtree | 16:23 |
| fullermd | I don't believe there's a single architectural obstacle. It's just a moderate hunk of implementation. | 16:23 |
| jam | Right now we have scmproj and bzr-externals, to do something like this | 16:23 |
| jam | poolie has mentioned that it is likely to be a priority feature in the next 6-month cycle | 16:24 |
| fullermd | That's just not the same at all.. | 16:24 |
| dahoste | rubbs, partials are disjointed. And even in svn, where it's par for the course, there's an understood responsibility on the part of the person using a partial to keep in mind that they're (purposefully) working with just part of a larger dependent tree. There's nothing stopping them from doing something stupid and breaking something 'uptree'. | 16:25 |
| jam | fullermd: it isn't the same functionality (a priori versus ad hoc subtrees), however it solves the basic use cases that we've determined from people wanting the feature | 16:25 |
| jam | "I just want docs" (make it a subtree), etc | 16:25 |
| * fullermd points at the ports tree. | 16:25 | |
| dahoste | yes, hg's forest seems like it might be enough. And (for me anyway), a priori subtrees would be just fine... I don't need svn's ad hoc support. Yeah: it's the classic case of: subdir so-and-so of a big src tree functions independently _enough_ that someone can contribute to it meaningfully without being burdened with the entire tree. Particularly if, say, the subtree can be had for a few MBs or less, and the rest of the tree takes a few G | 16:34 |
| dahoste | Bs. | 16:34 |
| dahoste | And while that's also the case that argues most strongly for just constituting the project as multiple sub-projects, it's nice to be able to still be capable of managing the project from one mega root node (for those that need to). Having cake and wanting to eat it too. :) | 16:37 |
| dahoste | Thanks all for your thoughts and time. I'll keep my eye out for progress on nested-trees, or any other similar approach. Cheers! | 16:52 |
| === Ursinha is now known as Ursinha-lunch | ||
| === zyga-afk is now known as zyga | ||
| === beuno is now known as beuno-lunch | ||
| mneptok | http://www.ibm.com/developerworks/aix/library/au-spunix_bazaar/index.html | 17:48 |
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno-lunch is now known as beuno | ||
| maxb | GaryvdM: You said you did an installability test on hardy...... including loggerhead? | 18:57 |
| pygi | heya | 19:04 |
| pygi | :) | 19:04 |
| maxb | Why do we ship testtools and subunit in the bzr PPAs? | 19:11 |
| === deryck is now known as deryck[lunch] | ||
| james_w | maxb: they are needed for the testsuite, so either Build-Depends, or for the benefit of developers? | 19:43 |
| === deryck[lunch] is now known as deryck | ||
| maxb | lifeless: hi. do we just publish testtools and subunit in the bzr ppas for developer convenience, or is there a greater reason? | 20:34 |
| maxb | (I've noticed that Launchpad has somehow managed to silently fail to publish testtools in ~bzr/proposed jaunty+karmic, though the web ui says it has) | 20:35 |
| lifeless | I don't remember :(. We do occasionally ask a user to run the test suite to check platform idionsyncracies | 20:38 |
| maxb | I am tempted to rebuild both subunit and testtools to get rid of the version numbers which pretend to be main-archive uploads but aren't :-/ | 20:42 |
| === Mario_ is now known as pygi | ||
| jam | GaryvdM: are you using the win32 ec2 host? | 21:14 |
| jam | vila: are you around? | 21:18 |
| jam | jml: you don't have any tags for testtools releases aside from 0.9.2 | 21:37 |
| jam | in lp:testtools | 21:37 |
| rubbs | Ok, quick question, it's been quite some time since I've been in the bzr world. In terms of checkouts, a Heavyweight checkout is the default, and really it's just a local branch that sends it's commits to it's master before it commits locally. And a Lightweight checkout is more like SVN checkouts. Is this correct? | 21:38 |
| dash | rubbs: correct. | 21:38 |
| rubbs | dash: thanks. | 21:38 |
| fullermd | Except thinking about heavy checkouts like that is IMAO likely to confuse more than help... | 21:40 |
| rubbs | Ok, now I think I'm getting it. Then binding a branch "A" to branch "B" makes A a 'heavy checkout' with B as it's master. Unbinding A from B would change it back to a normal standalone branch (assuming it's not in a repo) correct? | 21:41 |
| dash | fullermd: why so? | 21:41 |
| rubbs | fullermd: how so? how would you suggest thinking about them? | 21:41 |
| fullermd | Cue iteration 11,471 of "bound branches vs heavy checkouts"... | 21:41 |
| fullermd | Better to think of no heavy or light, just checkouts with or without a local cache. | 21:41 |
| dash | rubbs: some folks have made a distinction between checkouts and bound branches but i never figured it out. | 21:41 |
| rubbs | is there something I can read on this. I don't mean to beat an already dead horse | 21:42 |
| dash | i do, i do ;D | 21:42 |
| rubbs | haha | 21:42 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches | 21:42 |
| rubbs | thank you. | 21:42 |
| dash | yeah but that's not documentation about how bzr works =/ | 21:43 |
| fullermd | No, how bzr works is that it has neither bound branches nor heavy checkouts. It has something that's part one, part the other, and used for botrh. | 21:43 |
| dash | it sounds like you are using those terms differently from everyone else then :) | 21:44 |
| fullermd | Leaving aside "how it should be", I still believe that THINKING of the two as separate things and bearing in mind which mechanism you want in any given case, will make things work smoother in the long run, even though to bzr the two are the same. | 21:45 |
| fullermd | I don't think so. I think I'm just using them more clearly. | 21:45 |
| dash | so... to bzr, they're the same. | 21:45 |
| dash | okay then :) | 21:45 |
| fullermd | (I also think bound branches tend to be more confusing than checkouts, and that a lot of people aren't clear as to which role they're trying to use, which is the primary source of corner-painting) | 21:46 |
| rubbs | Ok, maybe this would be better to ask the best way to implement the following workflow: I'm looking for a way for developers to have their own branches, but have those branches mirrored on a central location so that it makes it easier for backups (for me). Here's the kicker though, most devs are on the LAN so network traffic wouldn't be bad, but we have two devs who work from home. I'd like a way for them to be able to lots of stuff locally ... | 21:47 |
| rubbs | ... and sync up when needed. | 21:47 |
| rubbs | to do lots * | 21:47 |
| fullermd | IMO, as soon as there's a network involved (even a LAN), light checkouts can be fairly well ignored (perhaps not conceptually, but certainly implementionally) | 21:48 |
| fullermd | Bound branches sound like what you want there. | 21:48 |
| rubbs | well right, hence the heavy vs bound branch I was goint to ask ;) | 21:48 |
| rubbs | sounds like heavy checkouts are more svn-esk and bounc branches are just mirrored branches. (conceptually at least) | 21:49 |
| fullermd | The distinction as to which way you'd think about it there, I think, would hinge on the question of how you think about where the branches are. | 21:50 |
| fullermd | If you're thinking of devs having their own branches on there machines, that are automagically mirrored to the server when they do stuff, that's a bound branch. | 21:50 |
| fullermd | If the dev's branches are on the server, and they just happen to have a full cache of it in their local WT, that's a heavy checkout. | 21:50 |
| dash | in other words... a distinction without a difference. | 21:50 |
| rubbs | ok, but are they implemented the same way? | 21:50 |
| rubbs | I understand what you are saying | 21:51 |
| fullermd | Well, history in bzr vs. history in git is a distinction without a difference too. | 21:51 |
| fullermd | Well, they're implemented the same way because bzr doesn't acknowledge any distinction. | 21:52 |
| rubbs | I will likely teach them the heavy way as I think I'd like them to stick with "server" centric ideology, but I'm hoping that this doesnt' limit me on a technical side. If I do heavies and not bound branches, am I going to cause problems if I need to convert those heavy co's to standalones on their machines? | 21:52 |
| rubbs | ah | 21:52 |
| rubbs | you just answered my question then. thank you | 21:53 |
| rubbs | but I think I understand your distinction there and I think it's going to be easier to teach them that. | 21:53 |
| rubbs | thanks | 21:53 |
| rubbs | My questinos were more of a clarification of what I was pretty sure I knew, just didn't know how to say it, so you guys helped me figure that out | 21:54 |
| dash | rubbs: to convert to a standalone branch you do 'bzr unbind' | 21:56 |
| dash | rubbs: and also you can do 'bzr ci --local' to commit without sending it upstream | 21:56 |
| dash | (without unbinding) | 21:57 |
| rubbs | dash: ah that last one is perfect, I should have remembered that. | 21:57 |
| rubbs | thanks | 21:57 |
| rubbs | also is there any difference between checkin and commit? should be the same correct? | 21:57 |
| fullermd | They're the same command. | 21:57 |
| fullermd | The difference is about the same as the difference between [ and test ;) | 21:58 |
| rubbs | haha, great thanks | 21:58 |
| === Guest39999 is now known as jelmer | ||
| ddaa | except less evil... [ is one evil bit of shell hacker | 22:30 |
| ddaa | it looks like a grouping syntax, but it's just a command name | 22:30 |
| fullermd | I prefer to think of that more as a symtom of the infirmery of sh as a language than a failing of test ;p | 22:32 |
| jelmer | it's evil disguised as cleverness | 22:32 |
| dash | everybody's got a shell with [[ now though | 22:32 |
| fullermd | $ which [ | 22:32 |
| fullermd | /bin/[ | 22:32 |
| ddaa | sh makes sense as far as it goes, but [ is like a alligator in the hide of a kitten. | 22:33 |
| ddaa | dash: that's funny you should say that, considering your nickname :-) | 22:33 |
| ddaa | maybe it's even bash.org worthy :-) | 22:34 |
| fullermd | Oh, the doubly irony :p | 22:34 |
| fullermd | Extra funny how I just spend the last week watching another round of "we need a better scripting language than sh" run around a mailing list :p | 22:36 |
| ddaa | submitted to bash.org as 928499 | 22:37 |
| ddaa | fullermd: just saw that on pypi: http://pypi.python.org/pypi/pc/0.0.1 | 22:38 |
| fullermd | Ick, but you'd have to have python for that ;] | 22:39 |
| fullermd | I like how version 0.0.1 was uploaded today, and 0.0.3 was uploaded... today. | 22:39 |
| fullermd | Now that's fast development. | 22:40 |
| ddaa | or banana software | 22:40 |
| fullermd | Oh, I was hoping they had a more creative syntax I could steal... shucks. | 22:45 |
| ddaa | like using __repr__ for command substitution? :-) | 22:45 |
| fullermd | Over my head :p | 22:46 |
| ddaa | in python<3, `foo` is an alias for repr(foo), it little known though | 22:46 |
| fullermd | But I have a vague desire for some sneaky-simple syntax for calling out commands for my creeping-along make(1) replacement. | 22:46 |
| fullermd | Haven't yet looked at it in-depth, since it's way down the todo list. | 22:47 |
| ddaa | maybe check logix: http://logix-language.sourceforge.net/ | 23:01 |
| dash | that's pretty dead unfortunately :( | 23:01 |
| ddaa | it's still kind of neat | 23:01 |
| ddaa | python lacks a good DSL framework | 23:02 |
| fullermd | Well, that's why I figure if I work slowly enough at it, I can just convert it to perl 6 before it's ready for release ;p | 23:04 |
| jam | losa ping | 23:08 |
| mbarnett | heya jam | 23:11 |
| jam | hi mbarnett, I'm trying to figure out if pqm is hung or not, can you check it out? I sent it something that ended up having a lot of failures for python2.4, and I haven't gotten any response yet. | 23:11 |
| jam | I fixed it up, and resubmitted, but I don't see the new request either | 23:11 |
| jam | I was worried the response email might be too big, and gumming things up | 23:12 |
| jam | mbarnett: anyway, its end-of-day for me now, and I think it just showed up, so if you're busy, it can wait until tomorrow | 23:12 |
| mbarnett | jam: heh, i'll certainly poke at pqm and look for any obvious errors | 23:15 |
| jam | mbarnett: thanks | 23:16 |
| mbarnett | welcome | 23:16 |
| jelmer | hmm | 23:26 |
| sttng359 | hello | 23:37 |
| sttng359 | I'm having trouble with bzr-svn and symlinks not being created correctly | 23:37 |
| sttng359 | sometimes I get zero-length files where there should be symlinks | 23:38 |
| sttng359 | svn check out without issue. | 23:38 |
| sttng359 | When I checkout the images folder directly with bzr, I get symlinks, but when I checkout the top-level trunk folder, it creates zero-length files for symlinks in the images folder | 23:40 |
| sttng359 | oh, it appears I have bad information in the shared repository I'm using | 23:55 |
| sttng359 | A fresh checkout of trust without shared repo does create proper symlinks. | 23:56 |
| sttng359 | trust should be trunk. | 23:56 |
| sttng359 | is there any way I can try and resync my existing repo with svn? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!