| ovnicraft | hi folks, i branch a project from lp i made my changes, commited now i try to pull from lp and tell: | 00:12 |
|---|---|---|
| ovnicraft | bzr: ERROR: These branches have diverged. Use the missing command to see how. | 00:12 |
| ovnicraft | Use the merge command to reconcile them. | 00:12 |
| maxb | Indeed. You don't want to pull, in this case | 00:17 |
| ovnicraft | so pull is not the way to update from lp | 00:20 |
| ovnicraft | maxb, that is what i want, what i need to do? | 00:20 |
| maxb | "Use the merge command to reconcile them." | 00:21 |
| maxb | bzr merge | 00:21 |
| ovnicraft | maxb, i dont have write permissions in lp that is not a problem? | 00:25 |
| maxb | no | 00:26 |
| wallyworld___ | bzr 101? - if i have a branch and merge from trunk, can i commit just those changes and not my own as yet uncommitted ones so that bzr status shows just my in progress changes and not everything? | 00:27 |
| maxb | No. bzr merge will remind you that your working tree has changes when you try to merge | 00:28 |
| maxb | Either commit or shelve your local changes first | 00:29 |
| maxb | Or branch your branch, merge in that, and pull the result back into your first branch | 00:29 |
| wallyworld___ | shelving may be the go. i want to keep current with trunk but am not ready to commit my in progress work | 00:30 |
| wallyworld___ | thanks | 00:30 |
| wallyworld___ | seems like a bit of a pain though. is the workflow i am wanting considered "unusual"? | 00:31 |
| wallyworld___ | coming from a svn world, it seems normal to do that sort of thing :-) | 00:32 |
| LeoNerd | I use shelve a -lot- | 00:34 |
| LeoNerd | To the point that when I was still being required to use CVS at one workplace, I wrote myself a cvs-shelve command :) | 00:34 |
| maxb | There's no real workflow difference from svn here | 00:37 |
| wallyworld___ | yes, it's a useful feature, especially with good merge support in the VCS. not sure how well it would work with CVS :-) | 00:37 |
| maxb | or, had you not ever committed since branching? In which case, pull, don't merge | 00:37 |
| wallyworld___ | no, i had committed. | 00:38 |
| wallyworld___ | with svn, you don't have to first shelve before updating from the central server | 00:38 |
| maxb | In svn if you wanted to merge from trunk whilst having uncommitted changes, you'd need to "shelve" the changes off as a patch file first | 00:38 |
| wallyworld___ | so to me there is an extra step with bzr | 00:38 |
| wallyworld___ | i've never had to do that with svn - i just update and all the changes from trunk come down and a "status" just shows my uncommitted changes as expected | 00:40 |
| dash | wallyworld___: sure, but this is about merging not updating | 00:40 |
| dash | wallyworld___: merges change your working copy | 00:40 |
| dash | (in both bzr and svn) | 00:40 |
| maxb | wallyworld___: If you were in the same situation in bzr, you would pull, not merge, and you'd get the same result | 00:41 |
| wallyworld___ | would you still pull even if you had uncommitted changes? doesn't it complain? | 00:41 |
| dash | it doesn't | 00:42 |
| dash | for the same reason svn doesn't | 00:42 |
| wallyworld___ | ah ok. i thought that it did. sorry. | 00:42 |
| wallyworld___ | thanks for the input, much appreciated | 00:43 |
| spiv | Good morning. | 01:02 |
| poolie | hi spivvo | 02:12 |
| spiv | Hi poolie, I just had a bit of a tour of the wonderful world of generating sphinx docs from optparse. https://code.edge.launchpad.net/~spiv/bzr/html-cmd-help/+merge/36244 | 02:34 |
| mkanat | poolie: I didn't get to loggerhead today, just FYI. Perhaps tomorrow or Thursday. I did start to do some research yesterday, though. | 03:00 |
| mkanat | poolie: Just wanted to let you know so that I wasn't going dark on anything. :-) | 03:01 |
| mkanat | Anyhow, I'm out for the evening! :-) | 03:05 |
| mkanat | Night. :-) | 03:05 |
| ovnicraft | hi folk i have a question i can versioning my documents with bzr? | 03:07 |
| spiv | ovnicraft: yep! | 03:11 |
| ovnicraft | spiv, so bzr can show in 'rich text' the diff ? | 03:12 |
| spiv | No, if it's not plain text bzr will just say "binary file changed" for that file in the diff. | 03:12 |
| ovnicraft | spiv, assuming an Ooo doc from writer is a zip bzr knows how works with work? | 03:12 |
| spiv | And similarly it can't automate merging. | 03:12 |
| ovnicraft | i need something like that | 03:13 |
| spiv | So bzr can happily store the different versions of binary files, but it can't help you compare them. | 03:13 |
| spiv | (Unless someone writes a bzr plugin for that kind of file) | 03:14 |
| poolie | spiv, wow, that specific check for '1.9' is gross | 03:23 |
| jbowtie | Hmmm, a bzr plugin for diffing archives would be interesting; especially if you could treat archives as folders. | 03:32 |
| poolie | meaning ppa archives? | 03:40 |
| poolie | or zips? | 03:40 |
| jbowtie | poolie: Meaning zips | 03:49 |
| jbowtie | There are plenty of file formats (including ODF) that are just zips of some files; being able to diff them would be handy. | 03:51 |
| jbowtie | Actually, being able to merge them would be even better. | 03:52 |
| spiv | The hook point for merging them already exists. | 03:52 |
| spiv | So it's just a simple matter of writing the plugin then ;) | 03:53 |
| jbowtie | Actually I thought it might be more fun to write a plugin to allow merging of GIMP/Photoshop formats. | 03:53 |
| jbowtie | As long as the changes are on different layers you can actually do a conflict-free merge. | 03:54 |
| spiv | Heh, that would be cute. | 03:55 |
| poolie | heh | 03:55 |
| poolie | i don't know how often that happens but it would be cute | 03:55 |
| jbowtie | But that's just a blue-sky project until I knock the documentation bug count down to zero. | 03:55 |
| poolie | you know showing conflicts as layers might even kind of work too | 03:55 |
| poolie | jbowtie: thanks so much for all your patches | 03:55 |
| poolie | you're getting through them at a great rate | 03:55 |
| spiv | poolie: Ooh, layers called THIS, BASE, and OTHER? :) | 03:55 |
| jbowtie | Well, artists are always complaining about not being able to version using a DCVS. But the collaboration workflow actually usually has them touching different subfiles within some massive binary zip. | 03:57 |
| spiv | *nod* | 03:57 |
| jbowtie | poolie: It's for my own sanity as well; hate looking something up and having it be wrong. | 03:57 |
| jbowtie | So being able to support layers or (in the case of Blender, animations versus meshes versus textures) would address some of those artist issues. | 03:58 |
| jbowtie | But that involves working with the various free software art tools to come up with useful diff/merge/conflict resolution. | 03:59 |
| spiv | Right. | 03:59 |
| spiv | It would be a neat project. | 03:59 |
| spiv | It would possibly also encourage us to keep improving our performance when dealing with large files... | 04:00 |
| poolie | spiv did my 'scripts' branch fail? | 04:01 |
| spiv | poolie: text conflict in NEWS... | 04:02 |
| poolie | huh | 04:04 |
| spiv | poolie: but not when I try locally with news_merge enabled | 04:04 |
| spiv | So I guess PQM still doesn't have news_merge working :/ | 04:04 |
| lifeless | spiv: probably need to upgrade bzr | 04:05 |
| spiv | poolie: https://pastebin.canonical.com/37408/ is how news_merge was configured on PQM | 04:05 |
| lifeless | spiv: it runs from a source tree | 04:05 |
| lifeless | hysterical raisins | 04:05 |
| spiv | lifeless: the RT had step 0 as checking that bzr was already upgraded | 04:05 |
| lifeless | spiv: the one in the source tree? | 04:05 |
| spiv | But yes, there's enough confusing wrinkles in the PQM deployment that this sort of thing never goes smoothly :( | 04:06 |
| spiv | lifeless: I don't know, I don't have access to see | 04:06 |
| spiv | lifeless: it was RT #41382, if that helps you | 04:07 |
| poolie | spiv, i'll update and repush it | 04:22 |
| spiv | poolie: Hmm | 04:23 |
| spiv | poolie: it's kinda nice to have the test for whether news_merge is working ;) | 04:23 |
| spiv | But not worth holding up your branch unless that's likely to be fixed soon. | 04:23 |
| spiv | I'm not sure what to do about it... I don't feel I have enough information to construct an RT to correct whatever is wrong. | 04:24 |
| spiv | And I assume LOSAs would rather not receive "it doesn't work, please fix" RTs any more than we like them as bug reports :) | 04:25 |
| spiv | Making any changes to the PQM deployment always feels about 10x more frustrating than seems reasonable :/ | 04:26 |
| poolie | iirc it's a useful but not critical patch | 04:26 |
| poolie | so, there's no rush | 04:26 |
| spiv | Right. | 04:26 |
| poolie | hm | 04:27 |
| poolie | i'm suspecting we might be better off prototyping tarmic | 04:27 |
| thumper | hi | 04:27 |
| poolie | *tarmac | 04:27 |
| thumper | does the BZR_EMAIL for committer id need to be "email shaped"? | 04:27 |
| thumper | or can it be any string | 04:27 |
| spiv | thumper: andrew@Aihal:/tmp/a-branch$ BZR_EMAIL="any string" bzr ci -m "Foo." --unchanged | 04:28 |
| spiv | Committing to: /tmp/a-branch/ | 04:28 |
| spiv | Committed revision 1. | 04:28 |
| thumper | spiv: is there an expectation that it is email shaped? | 04:28 |
| thumper | will there be a future tightening of the constraint? | 04:28 |
| thumper | could there be a future tightening/ | 04:28 |
| thumper | ? | 04:28 |
| spiv | I don't think so. | 04:29 |
| thumper | thanks | 04:29 |
| spiv | I'm pretty sure there'd already be not-email-shaped commits in the wild | 04:29 |
| spiv | e.g. imports from CVS | 04:29 |
| jbowtie | Just found out Rob Collins is also from NZ. I wonder how many mutual acquaintances we have? | 04:54 |
| jbowtie | Sorry, guys, that was meant for Twitter. | 04:59 |
| spiv | jbowtie: that's ok | 04:59 |
| jbowtie | You say that now, but next time it'll be something far more embarrassing. :) | 05:01 |
| jtv | jbowtie: at least IRC doesn't spread XSS attacks quite so well | 05:01 |
| jbowtie | jtv: I'm safe until they target Gwibber. Then all my networks are toast. | 05:02 |
| * jtv gets the butter and prepares to wait | 05:03 | |
| poolie | it's funny how much twitter reinvents irc | 05:07 |
| jbowtie | If I push a fix to a branch that has been proposed for merge, do I need to do anything else for reviewers to take note of the fact? | 05:08 |
| poolie | uh kinda | 05:09 |
| poolie | it shows up on the web page | 05:09 |
| poolie | normally that's enough | 05:09 |
| spiv | jbowtie: the diff on the web page will be automatically updated, but the reviewers won't get notified | 05:09 |
| poolie | if you want to specifically ask, you have to mail the mp | 05:09 |
| spiv | So add a comment if you want to to draw attention to the update. | 05:09 |
| jbowtie | spiv: You answered the question before I finished typing it. | 05:10 |
| spiv | You can also resubmit, which starts a fresh review. | 05:10 |
| spiv | For small changes in response to a review so far I'd usually just add a comment. | 05:11 |
| spowers | i'm transitioning my brain from svn to bzr right now.. what's the bzr equivalent of svn postcommit hooks? i push from my laptop to a server, want the server to execute something when i push to it | 05:14 |
| spiv | Ugh, my html-cmd-help fix broke test_help | 05:14 |
| spiv | spowers: there's a post_change_branch_tip hook in the API | 05:15 |
| spiv | Unfortunately you can't just put a command in a configuration file, but you can use it by writing a simple plugin. | 05:16 |
| spiv | (Hmm, ISTR to recall I had an prototype of a plugin that could run a command from a config file when that hook fires, I should dig that up) | 05:18 |
| spowers | it sounds like people have found other ways to solve the same problem? | 05:18 |
| spowers | after i push to the server, i need to have it kick apache | 05:20 |
| spiv | Well, many people just want email notifications, and there's already a plugin for that. | 05:20 |
| spiv | For everyone else... well, as I say, it's not difficult to write a simple plugin. | 05:21 |
| spowers | ok, i'll look into that | 05:21 |
| spowers | there are client side hooks too, right? | 05:21 |
| spiv | Yes, the exact same ones. | 05:22 |
| spowers | that's probably all i need.. i have ssh keys set up, so i could just flip a switch via ssh | 05:23 |
| poolie | good morning vila | 07:27 |
| vila | poolie: morning poolie ! | 07:27 |
| vila | hi all ! | 07:27 |
| vila | poolie: quick chat ? | 07:31 |
| poolie | sure | 07:32 |
| poolie | vila, i wonder if a registry is a good fit for this because to me they seem very oriented to looking up a single thing by name | 09:11 |
| poolie | whereas this is more of a multiple dispatch deal | 09:11 |
| poolie | however i agree, we probably want to somehow combine various relevant sources | 09:11 |
| vila | right, so the idea is that the registry will change the way we get our config objects from calling BranchConfig or GlobalConfig explicitly to calling get_config('branch') | 09:12 |
| vila | from there it becomes possible to define what a branch config is or what a tree config is without being forced to create a new class | 09:12 |
| vila | the idea of multi-level configs is that if one config doesn't define a variable, we fall back to another config | 09:13 |
| vila | this should scale pretty well for the user once we provide a 'bzr config' command that will tell *where* a variable is currently defined | 09:14 |
| === spike_ is now known as spikeWRK | ||
| vila | and also *which* config files are involved for a given variable | 09:14 |
| vila | this file <-> variable relationship may need to better specified too, as currently *some* variables should not be overridden | 09:15 |
| lifeless | I thought we already had multi level configs | 09:16 |
| lifeless | via a composite pattern | 09:16 |
| vila | lifeless: we have | 09:16 |
| lifeless | good good | 09:16 |
| spiv | There's also some code in bzr-pqm along those lines, IIRC | 09:17 |
| vila | I'd like to replace the composite approach by a more generic list based approach where you just say branch.conf > locations.conf > bazaar.conf | 09:17 |
| spiv | --ignore-local needed it for some reason | 09:18 |
| spiv | vila: it's been a while, but that sounds rather like the code in bzr-pqm | 09:18 |
| vila | to allow tree.conf > branch.conf > repo.conf > locations.conf > bazaar.conf and allow plugins to put whatever they see fit wherever they see fit | 09:18 |
| vila | but we need some way to also define that a variable *cannot* be redefined in some cases | 09:19 |
| spiv | vila: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel/annotate/head%3A/pqm_submit.py#L198 | 09:19 |
| vila | spiv: exactly, thanks for finding the relevant url so fast ! | 09:20 |
| spiv | vila: see #L226 for where it is used | 09:20 |
| vila | so, one example of a variable that we don't want to redefine may be the stacked_on url which is defined server-side (may be not the best example but you get the idea) | 09:21 |
| spiv | vila: I'd wanted to get that put into core bzrlib, but lacked a motivation other than "it'd be nice" | 09:21 |
| spiv | There's also some security concerns, in that using an untrusted branch shouldn't be able to e.g. configure bzr, or a bzr plugin, to rm -rf /. | 09:23 |
| vila | spiv: yeah, exactly, you needed a new class *and* various calls to achieve: get_config('branch') | 09:23 |
| vila | spiv: right, that should be defined at the *variable* level | 09:24 |
| spiv | Yes, probably. | 09:24 |
| vila | spiv: may be not specified for evey variable but what I have in mind is the ability to *declare* a variable in config and use various decorators | 09:24 |
| spiv | Sounds like a good approach to me. | 09:25 |
| vila | in config or elsewhere, in fact, the discussion with poolie was to make it trivial to turn any constant in the code base into a config variable | 09:26 |
| spiv | vila: actually the motivation I did have for maybe putting StackedConfig in core is it possibly would simplify bzrlib/config.py a bit, because the general facility it provides might simplify some hard-coded "this config asks this other config" logic. | 09:26 |
| vila | add the '-O' option from the command line and we get the ability to try various tricks | 09:26 |
| vila | spiv: yup | 09:27 |
| vila | ok, so I'll see what first step I could propose, any thoughts ? A first 'bzr config' showing the variables values and where they are coming from, plus a way to set a new value or delete a variable may be ? | 09:32 |
| vila | argh reboots needed everywhere, bbiab | 09:34 |
| spiv | The first half of that sounds like a fairly small and worthwhile step, the second half ("plus a way to set...") sounds a bit large, perhaps. | 09:34 |
| vila | well, no, not yet, but soon | 09:35 |
| vila | spiv: ok | 09:35 |
| spiv | But try it and find out :) | 09:35 |
| spiv | (That's just a quick reaction, not a deeply considered opinion) | 09:35 |
| spiv | Hmm, it's getting late. | 09:35 |
| * spiv -> dinner | 09:36 | |
| vila | spiv: enjoy ! Thanks for feedback | 09:36 |
| jbowtie | Bug #636712 says we shouldn't be recommending sftp | 10:17 |
| ubot5` | Launchpad bug 636712 in Bazaar "docs shouldn't recommend sftp (affected: 1, heat: 41)" [Medium,Confirmed] https://launchpad.net/bugs/636712 | 10:17 |
| Glenjamin | isn't sftp recommended because its the most secure way to use a server without setting anything up on the server? | 10:19 |
| jbowtie | That implies that in the mini-tutorial, we should be telling people to set up a bzr+ssh server. | 10:19 |
| ddaa | sftp is not recommended because it is inefficient | 10:19 |
| Glenjamin | compared to what? | 10:19 |
| ddaa | bzr+ssh, for example | 10:19 |
| Glenjamin | only a smart server, which isn't introduction stuff | 10:19 |
| Glenjamin | bzr+ssh needs bazaar on the server, sftp doesnt | 10:20 |
| ddaa | Glenjamin: that's a different issue | 10:20 |
| ddaa | Which transport is recommended for general use | 10:20 |
| ddaa | and which transport is easiest to setup and secure | 10:20 |
| Glenjamin | i quite like bzr+https personally, as the web server has plenty of ways to layer auth | 10:21 |
| jbowtie | Well, we want to make sure people understand that sftp is not the best option. | 10:21 |
| Glenjamin | a general transport comparison page would be cool | 10:21 |
| Glenjamin | and then mention the comparison page in the tutorial | 10:21 |
| ddaa | Glenjamin: IMO, that's still significantly harder to set up than bzr+ssh | 10:21 |
| ddaa | also, I heard it's less efficient | 10:21 |
| Glenjamin | yes it is, but its more flexible imo | 10:21 |
| ddaa | but I don't know why | 10:21 |
| jbowtie | Which could be reduced to just a note anywhere we mention sftp. | 10:22 |
| Glenjamin | i dont trust file ownership with multi-user bzr+ssh, but maybe thats just me | 10:22 |
| ddaa | that's just you | 10:22 |
| lifeless | bzr+ssh will be better than sftp | 10:22 |
| ddaa | if you don't trust operating systems permissions, you have a big problem | 10:22 |
| jbowtie | Probably bad memories of early svn servers. ;) | 10:22 |
| lifeless | sftp masks out bits needed for multi user managed directories. | 10:22 |
| lifeless | (on the server) | 10:23 |
| Glenjamin | i understand them, they just tend to break | 10:23 |
| Glenjamin | such as when other people poke around on my servers | 10:24 |
| jbowtie | The mini-tutorial doesn't explain how to set up a SFTP server, just says "if you have access to one". With bzr+ssh we could look at linking through to the setup instructions. | 10:25 |
| jbowtie | Really, what's the best experience for the complete newbie who wants her own server? | 10:26 |
| Glenjamin | launchpad! | 10:26 |
| jbowtie | Launchpad is the best option, unless you're setting up a corporate server. | 10:26 |
| jbowtie | We already have launchpad covered in the mini-tutorial. | 10:27 |
| Glenjamin | and if you're setting up a corporate server, you don't need the short version, you need to know the details | 10:27 |
| jbowtie | I agree - but setting up ssh is easier than setting up http. And sftp is easier still, which is probably why the docs originally went with that. | 10:28 |
| jbowtie | However sftp is a bad example because performance will kill you when you go to import your svn server. | 10:29 |
| jbowtie | So I'm thinking - give bzr+ssh as the main example; with a note about the alternatives (bzr+http and sftp) | 10:29 |
| jbowtie | Of course in the user guides we have all the details anyway, it's just the tutorial examples I'm thinking about. | 10:30 |
| jbowtie | Setup isn't so bad, it's "apt-get install bzr sshd" (or your distro equivalent) on your server then you can push with bzr+ssh. | 10:31 |
| jbowtie | poolie: You filed the bug, any opinion? | 10:34 |
| maxb | The big sticking points for corporate servers are access control and organization of many branches | 10:45 |
| Glenjamin | i'd say there's plenty of ways to do access control, but i'm not aware of a good entry-point for restricting branch organisation | 10:47 |
| jbowtie | maxb: I know, I handle Subversion, TFS, and Bazaar servers at my current employer. | 10:48 |
| Glenjamin | what method do you use for the bazaar repo / branch permissions? | 10:48 |
| jbowtie | We use ssh. If branches need different permissions we put them in different locations on disk. | 10:49 |
| Glenjamin | everyone uses their own ssh login, and shared branches are done via groups? | 10:50 |
| jbowtie | We could also split branches across different servers if needed. | 10:50 |
| jbowtie | Correct. And I handle merges to trunk. | 10:50 |
| jbowtie | Normally we do feature and bug branches, so there's not too many shared branches, I create those manually. | 10:51 |
| Glenjamin | ah, so you set the permissions for the shared branch explicitly | 10:52 |
| jbowtie | Sort of, I have directories corresponding to our usual groups and branch into those locations so they inherit permissions. | 10:53 |
| jbowtie | bzr+ssh://my.server/editorial/feature-X | 10:53 |
| Glenjamin | i've got two different repo setups here - both use a wrapper to manage access/permissions and have all branches owned by the same unix user | 10:54 |
| maxb | This is the major sticking point to corporate bazaar, I think - everyone has to reinvent a variant of this | 10:54 |
| maxb | it's almost as if we need a mini-launchpad :-) | 10:54 |
| jbowtie | In theory you can set up your own launchpad. | 10:55 |
| jbowtie | I haven't had a machine to play with though. | 10:55 |
| Glenjamin | i'm pretty happy with the latest approach i've done: loggerhead proxied through apache and bzr+https via mod_wsgi+apache at the same location | 10:55 |
| Glenjamin | and then I use apache's access controls to limit access (using ldap) | 10:56 |
| jbowtie | That's pretty much what we do with the Subversion servers, probably would consider it for bzr if admin load increased too much. | 10:56 |
| maxb | jbowtie: Yes, but first you need to invest an awful lot of time in it replacing all the images | 10:57 |
| millun | http://dpaste.com/247244/ | 10:58 |
| millun | hi | 10:59 |
| jbowtie | maxb: True, but with open source only one person really needs to do that work once. | 10:59 |
| maxb | ish, subject to merging ongoing development | 11:00 |
| Glenjamin | well you could abstract out the branding | 11:00 |
| Glenjamin | and get it back upstream | 11:00 |
| millun | bzr fails to install on debian lenny (from backporst) | 11:00 |
| millun | backports | 11:00 |
| millun | http://dpaste.com/247244/ | 11:02 |
| millun | pycentral: pycentral pkginstall: error byte-compiling files (735) | 11:02 |
| millun | maybe it needs python 2.6? | 11:03 |
| jbowtie | millun: I'm having a quick look now to see if there's anything obvious | 11:03 |
| millun | cheers | 11:03 |
| millun | python on lenny is 2.5. my localhost py is 2.6 | 11:04 |
| jbowtie | millun: Do you have multiple versions of Python installed on that machine? | 11:08 |
| millun | no | 11:08 |
| millun | maybe not | 11:08 |
| millun | i'll check | 11:08 |
| Glenjamin | is there a way to get a more verbose error? that one's a bit vague (i'm not too familiar with dpkg) | 11:09 |
| vila | millun: <shudder> we are currently releasing 2.0.*6* would you mind trying to push the upgrade on the debian side ? I don't know whether this will address your immediate problem but at least you'll get the fixes done since 2.0.3 | 11:09 |
| millun | oh ok. i'll ask the guy who decides | 11:10 |
| vila | millun: and I should have said: we are leasing 2.0.6, 2.1.3, 2.2.1 and 2.3b1 the first three being stable releases | 11:10 |
| vila | millun: I don't want to make your life harder (quite the contrary) but it's a bit deceiving to use a packaged distro if you can't get the last available stable updates :-/ | 11:11 |
| vila | fullermd: Quick FreeBSD question, I do regular 'updports.sh ; portupgrade -a' (as in once every full moon) and there is a number of patches mentioned there. ~2400 seems.. hard to relate to the number of packages updated, is "patch" here referring to a CVS commit ? What's the level of detail ? | 11:14 |
| jbowtie | vila: packages.debian.org shows 2.0.3 in lenny-backports; maybe we should bounce a reminder to their maintainer team? | 11:14 |
| vila | jbowtie: yeah, I did that, but no response so far | 11:14 |
| vila | jbowtie: but may be I didn't ping the right ones ? What will *you* do ? | 11:15 |
| vila | jbowtie: or rather, if you know what to do, please do :-) And put me in the CC :-) | 11:16 |
| jbowtie | vila: I'm looking at their mail archive right now to see what's been going on. | 11:16 |
| vila | I'm not familiar enough with debian to know whether they are still interested with our 2.0 updates or not... | 11:16 |
| vila | jbowtie: great | 11:17 |
| jbowtie | vila: Sure, consider it an audition for my BSE application. :P | 11:17 |
| vila | jbowtie: err, which one ? url ? | 11:17 |
| vila | jbowtie: hehe, couln't hurt, but I'm not the one taking the decision here ;-) | 11:17 |
| jbowtie | http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/ | 11:17 |
| vila | right, so my mail should be there | 11:17 |
| jbowtie | I see it, they apparently have no spam filter on that list though, judging from the state of the archive. | 11:19 |
| maxb | backports.org is not technically an official Debian service yet. | 11:21 |
| maxb | Also, it's a backports service, so if anything, they might as well update it to 2.2.1 | 11:21 |
| vila | maxb: who should decide, or better, act here ? | 11:22 |
| jbowtie | vila: Looks like jelmer is probably the best person to talk to, he's listed as a maintainer and is active on their list. | 11:23 |
| vila | jbowtie: hehe, yeah, jelmer is great, but looks a bit overbooked, so who is the backup there ? ;-D | 11:23 |
| maxb | vila: Anyone who wants to volunteer their time. Non DD/DMs need to act through the Debian mentors. Reminding the person who last uploaded the package to lenny-backports is a good idea | 11:25 |
| maxb | <maxb> backports.org is not technically an official Debian service yet. | 11:25 |
| maxb | Ooops, now it is! | 11:25 |
| vila | maxb: ok, DM == Debian Mentors, are you one ? I really need to start somewhere... | 11:26 |
| maxb | Also, packages are supposed to hit testing before being considered for backports, so at the moment, it's 2.1.2 that's eligible | 11:26 |
| maxb | DM == Debian Maintainers | 11:26 |
| maxb | No, I have no Debian official affiliation at present | 11:27 |
| vila | gah, so who are the mentors ? Any DD or DM ? | 11:27 |
| maxb | Though one of these days I ought to re-investigate my potential for DM and/or MOTU | 11:27 |
| vila | maxb: so, re-reading http://packages.debian.org/search?keywords=bzr , you mean 2.1.2 can go from testing to backports ? | 11:28 |
| vila | maxb: can 2.2.0 go from unstable to testing ? | 11:28 |
| maxb | No, the freeze is on | 11:29 |
| maxb | 2.1.2 can go to backports if someone does stuff according to http://backports.debian.org/Contribute/ | 11:29 |
| vila | freeze for (sorry for the idiotic questions but as I said I ahve to start somewhere :-}) | 11:29 |
| maxb | pre-release freeze for squeeze | 11:29 |
| vila | maxb: which means it will become stable ? | 11:30 |
| maxb | eventually | 11:30 |
| jbowtie | vila: I'll fire off some emails to the lists in about 10 hours to see if there are any DD's hanging around, maybe we can get jelmer to give us some names. | 11:30 |
| vila | jbowtie: ok | 11:30 |
| vila | jbowtie: thanks | 11:30 |
| vila | maxb: let see, where can 2.0.6 go (in debian context) ? Nowhere ? | 11:31 |
| maxb | correct | 11:32 |
| vila | 2.1.2 goes to backports | 11:32 |
| vila | 2.2.1 to unstable ? | 11:33 |
| vila | or should we just target 2.2.1 to backports ? | 11:33 |
| vila | maxb: quite different than Ubuntu where we want 2.0.6, 2.1.3 and 2.2.1 deployed and 2.2.1 and 2.3b1 in the ppas right ? | 11:34 |
| vila | or may be not that much, debian being closer to what we do for ppas ? | 11:35 |
| maxb | The key difference is that Ubuntu has an -updates pocket | 11:35 |
| jbowtie | vila: I'll also email the debian-backports list to see if anyone wants to help sort this specific issue. | 11:36 |
| mgz | hi all. | 11:36 |
| maxb | vila: Debian has its own concept of updates, but they're limited to security and dire emergencies | 11:37 |
| vila | mgz: _o/ | 11:37 |
| vila | jbowtie: good idea | 11:37 |
| vila | maxb: how do we apply that to our releases then ? | 11:40 |
| maxb | We put the latest stable into Debian unstable, except when there's a freeze on. We consider helping update stable-backports from testing. | 11:42 |
| vila | wow http://backports.debian.org/Contribute/ seems a bit intimidating at first... I may to filter a bit about what we already do in bzr | 11:42 |
| vila | maxb: ok, so 2.2.1 -> unstable except not, 2.1.2 to backports then right ? | 11:43 |
| maxb | yes | 11:43 |
| vila | and then... 2.2.x to unstable after the freeze or 2.3.x depending on when it occurs | 11:45 |
| vila | in summary we push only two of our series and help our older stable releases to progress in backports unless some serious bug is considered for... testing ? | 11:47 |
| millun | thanks guys, upgrade resolved the issue | 12:04 |
| millun | i forgot if i should do checkout or branch | 12:08 |
| Glenjamin | depends what you're getting | 12:09 |
| jbowtie | millun: Checkout creates a bound branch (commit has to succeed at server before it is applied locally) | 12:09 |
| Glenjamin | if you want a copy of a remote branch that's easy to update, i'd use checkout | 12:10 |
| Glenjamin | if you're going to make local changes, then branch | 12:10 |
| jbowtie | millun: Branch creates an unbound branch (commits are local, use push and pull to interact with server) | 12:10 |
| millun | i have a php project, i want to run it on a dev server | 12:11 |
| millun | some minor changes in config files will occur | 12:12 |
| Glenjamin | config files which change should be outside of version control, if generally use checkout for a deployment | 12:12 |
| Glenjamin | s/if/i/ | 12:12 |
| millun | i know i was using bzr pull command | 12:13 |
| jbowtie | millun: If you were using pull, then you would have used branch instead of checkout. | 12:13 |
| millun | did checkout now | 12:13 |
| millun | should be goo | 12:13 |
| millun | d | 12:13 |
| millun | so now i will be using bzr update or like? | 12:14 |
| jbowtie | Correct, or you can use bzr unbind and then use bzr pull. | 12:14 |
| millun | ok | 12:15 |
| millun | thankls | 12:15 |
| jbowtie | Right, I'm off, time for bed in my time zone. | 12:15 |
| cbz | when using bzr-svn with an existing maven'ised svn project is there something i can use in the scm section of the pom.xml file so that bzr tools will be launched locally instead of svn tools? | 13:23 |
| maxb | I don't think so | 13:29 |
| vila | millun: when you say " upgrade resolved the issue" which version do you use now ? | 13:33 |
| ploum | Hello | 13:49 |
| ploum | I'm looking for a way to store the current revision number in a file | 13:49 |
| ploum | The file itself has to be commited with that revision | 13:50 |
| ploum | How can I achieve that ? | 13:50 |
| maxb | That feels wrong | 13:50 |
| ploum | I want the revision number to be available in any export of the branch, why does it feel wrong ? | 13:51 |
| spiv | To be pedantic, that's a different requirement to wanting the committed text to have the revision number :) | 13:52 |
| * spiv -> bed | 13:52 | |
| vila | ploum: because a revision content should be fully known before giving it a revision-id | 13:52 |
| vila | ploum: may be you're searching for 'bzr version-info' instead | 13:52 |
| maxb | vila: Well, actually, you can know the revno that a revision you're about to commit will get, so it's doable :-) | 13:53 |
| ploum | vila: I'm already using version-info | 13:53 |
| vila | maxb: I went for the simplest explanation, there is still a chiken and egg problem there | 13:53 |
| maxb | I think a better solution would be a trivial script that wraps bzr export and bzr revno | 13:53 |
| maxb | vila: I agree it's not a very nice option, but I don't see any chicken/egg problem involved. | 13:54 |
| ploum | maxb: how can I achieve that other than a "current+1" ? (that I don't want to avoid doing +1 when the commit fail (because it is empty) | 13:54 |
| vila | ploum: then what are you trying to achieve exactly ? | 13:54 |
| ploum | sorry, this is not related to export, (I'm confused by another problem) | 13:55 |
| maxb | current+1 is the only way you can predict the revno of a future revision | 13:55 |
| maxb | But, I second vila, what are you trying to achieve exactly ? | 13:55 |
| ploum | vila: I'm working in a very large SVN tree including multiple module. As I work only on a small part (one module), I use bzr-svn to work on that very small part. People working with the whole tree want to know exactly what is the "internal revision" of my module. | 13:56 |
| ploum | Bzr keep its own revno so it's fine | 13:57 |
| ploum | for example, my revno 5 is the rev 134 of the SVN | 13:57 |
| ploum | and I want to have a file, in that tree, that contains that internal revno | 13:57 |
| maxb | hrm | 13:57 |
| ploum | I currently write bzr revno | 13:58 |
| ploum | maybe simply revno+1 could be enough ? | 13:58 |
| vila | ha, so you'd like people pulling from your branch (even indirectly) to get what your consider to be the revno, but it doesn't have to be the bzr revno, just an incremented value (for appropriate values of incrmented) right ? | 13:58 |
| vila | the problem with 'bzr revno[+1]' is that it would be wrong if you uncommit for example | 13:59 |
| ploum | vila: more or less. I want it to be the bzr value so when they ask something, I can quickly revert to that number | 13:59 |
| ploum | vila: indeed | 13:59 |
| maxb | Would it actually be wrong if you uncommit? | 14:00 |
| maxb | I don't think it would | 14:00 |
| vila | nothing robust comes to mind :-/ You really want nested tree here (once more) | 14:01 |
| vila | maxb: it won't be "wrong" but you can end up with the same revno and different content, if people have already pulled... you lose | 14:01 |
| maxb | vila: Can you see anything wrong with a pre_commit hook which writes the revno + 1 to a file? | 14:01 |
| vila | except for not being reliable in case of uncommit, no | 14:01 |
| maxb | Oh, yes. But that's true of any pushed uncommit. So don't do that :-) | 14:02 |
| vila | so I think an alternative would be a pre-commit hook which increments the value there while you still retain control over it | 14:02 |
| vila | so it's *always* incremented (and address uncommits) but you can still tweak it when needed | 14:03 |
| vila | of course the drawback is that it can go out-of-sync with bzr revno, but with a bit of care you should be able to resync | 14:03 |
| vila | i.e. start with revno+1 before the next commit and in the worst case... decrement if you're sure you haven't push or something | 14:04 |
| maxb | hmm, pre_commit docs say lots of things about not being allowed to modify the about-to-be-committed tree | 14:05 |
| vila | also, revno can drastically change if you re-pull from trunk instead of merging, using revnos as a communication mean require some enforced workflow of the shared trunk | 14:06 |
| vila | meh, maxb is right, I'm confused, I thought we had one hook for that... | 14:09 |
| maxb | pre_pre_commit? :-) | 14:09 |
| maxb | oh, wait, MutableTreeHooks.start_commit | 14:10 |
| vila | exactly, pre_commit should reference it | 14:11 |
| Glenjamin | does it necessarily have to be stored as a file | 14:12 |
| Glenjamin | bzr revno svn://path would tell you the number, if they dont have svn it might be simpler to give them a way to get that info | 14:13 |
| Glenjamin | *if they dont have bzr | 14:13 |
| vila | Glenjamin: good point, relying on the VCS tool is generally more robust | 14:14 |
| vila | ploum: ^ can this address your problem ? You should be able to match the svn revno to the bzr one no ? | 14:14 |
| Glenjamin | hrm | 14:15 |
| Glenjamin | neither revno nor version-info take the -r option | 14:15 |
| Glenjamin | so probably can't map an arbitrary svn revno to a bzr one in this way | 14:16 |
| vila | no, but I think bzr-svn manage to display the svn revno somewhere (no direct experience sry) | 14:16 |
| Glenjamin | it displays it in the bzr log | 14:17 |
| Glenjamin | and provides a revision specifier prefix svn: | 14:17 |
| vila | so if someone mentions an svn revno, ploum can find the bzr correspoding one, ha, svn: even better :) | 14:17 |
| Glenjamin | yes, but bzr revno -rsvn:149 won't work | 14:17 |
| Glenjamin | log might | 14:18 |
| vila | it sure must :) | 14:18 |
| Glenjamin | it does in fact | 14:18 |
| Glenjamin | as i've just tried it | 14:18 |
| vila | ploum: does the above address your "People working with the whole tree want to know exactly what is the "internal revision" of my module" ? | 14:21 |
| vila | or not at all ? | 14:21 |
| maxb | http://paste.ubuntu.com/498470/ works. Until you try to run "bzr commit <some pathnames>", at which point it of course does not commit your flag file | 14:25 |
| ploum | vila: not really | 14:43 |
| ploum | I think that I will go with the revno+1 approach | 14:43 |
| ploum | as we will probably not uncommit | 14:44 |
| ploum | thanks a lot for the brainstorm :-) | 14:45 |
| millun | vila: 2.0.3 i believe | 14:48 |
| vila | millun: 'bzr version' could turn your beliefs into facts :-D | 14:49 |
| fullermd | vila: I believe 'patch' in that sense is one change to one port. So it's sorta a proxy for CVS commits, though a commit could touch multiple ports. (or I could be wrong; I never delved into portsnap internals) | 15:00 |
| fullermd | I'd expect a pretty vague relation to the number of things you update. For one, multiple changes to a port since your last update would be multiple packages. But more importantly, you don't have most ports installed :p | 15:02 |
| vila | fullermd: what I was after was some rough estimate of the a threshold above which I should start to worrying | 15:02 |
| vila | but yeah, since it's a reduced setup it could be hard for you :-/ | 15:03 |
| vila | what is your update frequency and how many patches do you see then ? (On average) | 15:03 |
| fullermd | According to INDEX, there are 22,138 in the tree as of my last update. I have 841 installed on my workstation; you surely have less. | 15:03 |
| vila | INDEX is a file ? path ? | 15:04 |
| vila | INDEX-8 in /usr/ports/ ? | 15:04 |
| fullermd | Oh, I dunno. Depending on the system, somewhere between a couple times a week and a couple times a month maybe. | 15:04 |
| fullermd | Number of patches varies a lot. There was an autoconf update recently; sweeping stuff like that, or gettext updates, tend to touch a huge number of files all at once. | 15:05 |
| vila | hmm, I'm climbing the wrong tree it seems :) | 15:05 |
| fullermd | Yah. | 15:05 |
| vila | bah, nvm | 15:07 |
| fullermd | I've seen updates like 10k patches, on stuff I let get real outdated ;) | 15:07 |
| vila | oh, so I'm not so bad with 2400 then | 15:08 |
| vila | It's a bit hard to remember when everything went well ;) | 15:08 |
| fullermd | Yeah, it's not surprising at all if there were one or two sizable things in it. | 15:09 |
| vila | I just had a doubt this morning when I saw 2400 and went... is this really expected... | 15:09 |
| fullermd | autoconf update was in the last week. There was a KDE update a couple weeks ago. Both of those touched a big ol' pile of stuff. | 15:09 |
| fullermd | Either of those could easily be a couple hundred each, I'd WAG. | 15:10 |
| vila | right, so autoconf should be in but not kde, as long as I can run emacs with a remote X, I'm happy. So I never tried to setup a desktop manager there :-P | 15:11 |
| fullermd | Well, you'd still have all the patches to update the ports. | 15:11 |
| vila | ooh, I see | 15:12 |
| vila | ok, even less representative for my case then | 15:12 |
| fullermd | You'd just save the 6 weeks of build time to recompile it all ;) | 15:12 |
| fullermd | Yeah, the 'patches' count is a proxy for "number of changes to any ports since your last update"; that's probably only vaguely proportional to "number of things I've installed that now need updating" | 15:13 |
| vila | yeah, but those packaging stuff is eating my disk space ! I knew it, I knew it | 15:13 |
| fullermd | Nom nom nom! | 15:13 |
| mgz | vila, what rev did you branch 2.3b1 off? | 15:18 |
| vila | mgz: I've mentioned it in some mail I think, let me check | 15:18 |
| vila | 5432 revid:pqm@pqm.ubuntu.com-20100917142727-49blehg006i4nc9n | 15:19 |
| mgz | thanks, so that's just got this fix. | 15:21 |
| mgz | urk, but I now can't set the milestone correctly... | 15:22 |
| vila | bug # ? | 15:22 |
| mgz | vila, is there any way of marking bug 576269 as fixed in 2.3b1 now? | 15:23 |
| ubot5` | Launchpad bug 576269 in Bazaar "verbose mode in selftest show "running 0 tests" (affected: 2, heat: 12)" [Low,In progress] https://launchpad.net/bugs/576269 | 15:23 |
| mgz | (it's not really that important, but I'm curious) | 15:23 |
| vila | mgz: yes, making the 2.3b1 milestone active, marking the bug, making the milestone inactive again | 15:23 |
| vila | mgz: https://edge.launchpad.net/bzr/2.3/2.3b1 do you see pen icon near change details there ? | 15:23 |
| vila | no NEWS entry for it right ? | 15:25 |
| mgz | nope. | 15:25 |
| vila | mgz: ok, that's why I missed it | 15:25 |
| mgz | on the pen, that is. | 15:25 |
| vila | done | 15:25 |
| mgz | and probably no on the news as well, I was changing a bunch of testing things and getting news conflicts on pqm for every merge | 15:25 |
| vila | then you don't have enough rights to activate a milestone | 15:25 |
| vila | I can leave the milestone active if you think there are other bugs like this one | 15:26 |
| vila | but we try to keep the list of active milestones minimal to make it easier to use | 15:26 |
| mgz | no, I just pushed that literally as I was leaving the house on Friday and am only now getting back to updating the bug tracker | 15:27 |
| vila | though, until the release is officially announced, I may as well leave it active | 15:27 |
| mgz | so mark it inactive again. | 15:27 |
| vila | no other bugs ? | 15:27 |
| mgz | nothing else landed in that window, no. | 15:27 |
| vila | anyway, if you need it again, you know where to ask :) | 15:27 |
| Glenjamin | guys, is the general idea to move towards pycurl or away from it (in bzr)? | 15:28 |
| mgz | yeah, thanks for the walkthrough vila. | 15:28 |
| vila | Glenjamin: away | 15:28 |
| Glenjamin | is there a list of bugs blocking this somewhere? | 15:28 |
| Glenjamin | i keep hitting issues due to bzr on ubuntu using pycurl =/ | 15:28 |
| vila | roughly we need to implement ssl cert verification into our urllib-based implementation | 15:28 |
| vila | what kind of issues ? | 15:29 |
| Glenjamin | bzr: ERROR: Generic bzr smart protocol error: Invalid http response for https://<host>/servers/auth/.bzr/smart: Unknown response code 401 | 15:29 |
| vila | wut ? | 15:29 |
| vila | 401 is an authentication error... I thought the invalid cert was different... .bzr.log says more ? | 15:30 |
| Glenjamin | https with http auth using pycurl doesn't prompt for credentials | 15:30 |
| vila | ha ! right, yeah | 15:31 |
| vila | Glenjamin: do you care about the certs being verified ? | 15:31 |
| Glenjamin | nope, i've just installed that default urllib plugin you did | 15:31 |
| vila | Glenjamin: and is it a problem just for you or do you need to address it for a wide range of people ? | 15:32 |
| vila | Glenjamin: ha, right, sorry, didn't connect the dots :D | 15:32 |
| Glenjamin | its a problem i need to address globally, but i'm ghosting the machines | 15:32 |
| vila | so, yes, we want to go away and only retain pycurl so far for 1) people that needs cert verification 2) some support for auth protocols that may not be supported in our urllib implementation | 15:33 |
| vila | my vagueness on the later indicates that it's less important than the former | 15:33 |
| fullermd | Well, either that of you're just vague ;) | 15:37 |
| jszakmeister | As I'm writing up some notes, I actually sat down to look at the difference between "bzr checkout" and "bzr branch --bind". | 15:49 |
| jszakmeister | The only difference I found that was branch sets the parent location, while checkout does not. | 15:50 |
| jam | mgz: if you could forward my message back to the tracker. I responded before I remember LP will reject any emails I send it, and I don't really feel like rewriting it. | 15:50 |
| jszakmeister | Any reason why checkout doesn't set the parent location? | 15:50 |
| Glenjamin | bzr branch --bind == bzr branch && bzr bind :parent | 15:50 |
| mgz | I shall jam. | 15:50 |
| Glenjamin | would be my assumption. | 15:50 |
| mgz | is there any progress on the bug that's eating your email? | 15:50 |
| ddaa | jszakmeister: because the branch parent is a useful default for "merge" and "pull" | 15:51 |
| * fullermd rallys himself for another checkout discussion.. | 15:51 | |
| ddaa | typically, you'd make a checkout of a feature branch in centralized development process | 15:51 |
| ddaa | and you'd want "bzr merge" to merge from "trunk" | 15:51 |
| Glenjamin | then what's bzr branch --bind for? | 15:52 |
| ddaa | whereas, by using "bzr branch --bind", you indicate that you are working in a decentralized workflow, and you want to start with your branch bound. | 15:52 |
| jszakmeister | ddaa: I'm not sure I understand what you're saying there. If the parent location isn't set, the you have to specify what you're merging from, right? | 15:53 |
| fullermd | A checkout has a parent location. It's on the branch. | 15:53 |
| ddaa | Glenjamin: it's a shortcut for branch + bind. | 15:53 |
| Glenjamin | yes, i get that - but why? | 15:54 |
| jszakmeister | fullermd: but not locally. Note: I'm not talking about lightweight checkouts... which is another topic all together. | 15:54 |
| fullermd | It shouldn't be. | 15:54 |
| ddaa | Glenjamin: because bound branches are branches that do "push" automatically for you. | 15:54 |
| Glenjamin | so you're saying that conceptually a bound branch is in some way different from a checkout? | 15:54 |
| ddaa | There are really two ways to look at bound branches. | 15:55 |
| jszakmeister | ...man, I didn't mean to start any fires. :-) | 15:55 |
| ddaa | One way is to think of them as "lightweight checkout with a local cache, and the ability to do the occasional local commit when working offline" | 15:55 |
| ddaa | The other way is to think of them as "branch that pushes automatically whenever you commit" | 15:56 |
| ddaa | (or pull) | 15:56 |
| jszakmeister | ddaa: doesn't it work the same under the hood? Certainly, from a branch perspective, the contents of .bzr/branch are the same... | 15:56 |
| ddaa | jszakmeister: yes, it does work the same. | 15:56 |
| jszakmeister | with the exception that branch sets the parent and checkout doesn't. | 15:56 |
| ddaa | it's only a matter of how you want to think about your branch. | 15:57 |
| Glenjamin | basically, i don't get why you'd ever do branch --bind | 15:57 |
| Glenjamin | it sets parent, which is used for pull and merge - but in this case update will do the same | 15:57 |
| ddaa | Glenjamin: because you're too lazy to remember to "bzr push" | 15:57 |
| Glenjamin | but why use branch --bind instead of checkout | 15:58 |
| fullermd | Because hopefully some day, that giant pile of bugs will be fixed... | 15:58 |
| ddaa | fullermd: you say they should behave the same? | 15:58 |
| ddaa | I see a useful semantic distinction. | 15:59 |
| fullermd | Quite the contrary. | 15:59 |
| ddaa | fullermd: then you say there should be additional differences between checkouts and bound branches? | 15:59 |
| fullermd | I say we should _have_ heavy checkouts, and bound branches, rather than neither masquerading as both. | 15:59 |
| jam | mgz: no progress yet. Martin mentioned that they recently started checking timestamps to help avoid replay attacks. | 15:59 |
| ddaa | and how would they further differ? | 15:59 |
| Glenjamin | what would be the difference? ^^ | 16:00 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches | 16:00 |
| jam | however, the timestamps look good to me... | 16:00 |
| dash | i still find that page incoherent | 16:00 |
| jszakmeister | fullermd: is the distinction that a checkout modifies the remote branch, rather than committing locally and pushing? | 16:01 |
| ddaa | dash: I think the "Consequences and Changes to Current UI" section makes sense | 16:01 |
| fullermd | No, the fundamental distinction is that for a checkout there IS only one branch. You can't modify a local branch, because there conceptually isn't one. | 16:02 |
| ddaa | I WAS burnt in the past by doing "update" in a bound branch, wanting to update the tree to the branch, not pull the master. | 16:02 |
| Glenjamin | what benefits would that bring? | 16:02 |
| jszakmeister | fullermd: I think that's what I was trying to say... you modify the remote side (the target of the checkout) directly. It's not really a branch locally. | 16:03 |
| fullermd | Yah. It distinguishes the use-cases of "I want to work on that branch" from "I want to automate keeping these branches in sync" | 16:03 |
| ddaa | Glenjamin: it's not really a discussion about "benefits", but about "clear concepts" | 16:03 |
| Glenjamin | my point is, what would be gained by separating the concepts. And I can't think of anything | 16:04 |
| fullermd | The benefits (on the co side; fixing that 'update' bug on the bound branch side would be bigger) are relatively small; a big part of them is just fixing all the misbehaviors of heavy vs. light checkouts that are caused by acting boudnish, like handling of branch config. | 16:05 |
| ddaa | Glenjamin: among other things, a meaningful answer to "what's the different between checkout and branch --bind" | 16:05 |
| ddaa | Glenjamin: also, the ability to update the tree of a bound branch without actually pulling from the master. | 16:06 |
| Glenjamin | My workflow involves heavy checkouts for pretty much everything, so I guess I haven't run into these issues | 16:06 |
| jszakmeister | One thing I found surprising is that in my environment "bzr branch --bind" works fine using http:// against a smart server... | 16:06 |
| jszakmeister | checkout fails. | 16:06 |
| jszakmeister | I always have to use "bzr+http://" to make checkout work. | 16:06 |
| Glenjamin | you mean http dumb server? | 16:06 |
| Glenjamin | oh right, autodetect | 16:06 |
| fullermd | As does mine. I've never had any use for bound branches, but I'm all about checkouts. But certainly some people are just the opposite way aroudn. | 16:06 |
| Glenjamin | when I make a new branch, i update local trunk, branch local trunk, push to central, bind to push | 16:07 |
| Glenjamin | presumably if checkouts != bound branches, i'd have to do something differently | 16:07 |
| ddaa | fullermd: actually, the update misbehavior can occur when you have lightweight checkout of a bound branch. | 16:07 |
| Glenjamin | what's this update misbehaviour by the way? | 16:08 |
| mgz | okay jam, I've replied to both the mails I got from you so they'll be in the mp record. | 16:08 |
| ddaa | update on a bound branch is equivalent to update + pull. | 16:08 |
| ddaa | (modulo conflicts) | 16:08 |
| ddaa | let me rephrase that | 16:09 |
| ddaa | update on a lightweight checkout of a bound branch, is equivalent to "pull" in the branch then "update" in the lightweight checkout. | 16:09 |
| ddaa | Which is surprising. | 16:09 |
| jam | mgz: well the second one I went straight to the website. I've also been attempting to set my local time differently, etc. | 16:10 |
| jam | mgz: btw, can you check the gpg --verify output from the original email? | 16:10 |
| ddaa | It should just do "update" in the lightweight checkout. | 16:10 |
| jam | Knowing the timestamp it thinks is present, etc, would be helpful | 16:10 |
| ddaa | And a lightweight checkout of a checkout should not be allowed. | 16:10 |
| jam | I know what is says *here* but I'd like a second opinion | 16:10 |
| Glenjamin | I see | 16:10 |
| ddaa | But this discussion is somewhat of a nitpick. | 16:11 |
| fullermd | More abstractly, "update is a command that writes to the working tree based on reading the branch. Oh, except in this other magic case where it writes the branch based on a different branch" | 16:11 |
| mgz | jam: you'd also sent one about 2.3-filter-tests | 16:11 |
| mgz | I'll check with gpg now. | 16:11 |
| jam | ah rgiht | 16:11 |
| jam | right | 16:11 |
| jam | thanks | 16:11 |
| fullermd | Model-breaking mental page faults FTL :( | 16:12 |
| jszakmeister | Is there any movement on changing things? | 16:14 |
| fullermd | Not AFAIK. It's not entirely uncontroversial. | 16:16 |
| ddaa | well, it does sound like an arbitrary restriction | 16:16 |
| ddaa | and there WILL be a reconfigure option to switch between bound branches and checkouts | 16:17 |
| ddaa | so it will be possible to break the model | 16:17 |
| jszakmeister | Well, I like the idea of checkouts... at least in the sense that they update the remote branch rather than push revision after committing locally. | 16:18 |
| mgz | jam: reckons that's a good sig here | 16:18 |
| ddaa | fullermd: I think that would be a good thing, because it would make for easier documentation. | 16:18 |
| jszakmeister | I'm still not sure what happens when two people try to commit at the same time... | 16:18 |
| jam | mgz: the sig is good, can you give me the time that it thinks it was at? | 16:18 |
| ddaa | on of them will have an error "out of date" | 16:19 |
| fullermd | Well, so do I. That's why I keep griping about it 8-} | 16:19 |
| mgz | gpg: Signature made 09/22/10 15:26:02 using DSA key ID 848D0003 | 16:19 |
| mgz | gpg: Good signature from "John A Meinel <john@arbash-meinel.com>" | 16:19 |
| jszakmeister | I guess it all works out in the end (whoever loses, the commit gets uncommitted) | 16:19 |
| mgz | I'm on BST (+1) | 16:19 |
| Glenjamin | dont bound branches grab a write lock before comitting locally? | 16:19 |
| mgz | this is the 2.3-filter-tests message. which has the header: | 16:20 |
| mgz | Date: Wed, 22 Sep 2010 09:26:02 -0500 | 16:20 |
| Glenjamin | or at least exhibit equivalent behaviour | 16:20 |
| jam | mgz: that certainly sounds like it matches mine, which is 09:26 CDT (-5) | 16:20 |
| ddaa | Glenjamin: "out of date" or "lock taken", anyway. | 16:20 |
| fullermd | Yes, which I think is another bit of conflation fallout (at least, it's made "easier" by the conflation) | 16:20 |
| ddaa | Glenjamin: the contract is that only one commit will succeed. | 16:20 |
| ddaa | The other will fail atomically. | 16:21 |
| ddaa | bzr use a two-step commit in this case, it won't update the local branch until the remote branch was sucessfully committed to. | 16:22 |
| === Ursinha is now known as Ursinha-lunch | ||
| jszakmeister | Is there a plugin that provides the equivalent of graphlog in Mercurial? | 17:43 |
| jszakmeister | Google didn't turn up anything. | 17:43 |
| Glenjamin | got a screenshot? | 17:47 |
| Glenjamin | ah, i see | 17:47 |
| Glenjamin | jszakmeister: qlog does that graphically, not sure about on the command line | 17:47 |
| jszakmeister | Oh, I'm familiar qith QBzr and friends. :-) | 17:48 |
| jszakmeister | I was looking for something textual though. | 17:48 |
| fullermd | You use bzr-hg, push into a mercurial repo, and... | 17:49 |
| jszakmeister | :-) | 17:49 |
| fullermd | Or push into mtn; it draws those things by default. | 17:50 |
| fullermd | Wish it wouldn't, thought; for anything not trivial and tiny, it's just wasted space. | 17:50 |
| jszakmeister | Wow. I haven't played with monotone in a while. | 17:51 |
| jszakmeister | Yeah, that's one of those things that's occasionally useful... I wouldn't want it all the time either. | 17:51 |
| mgz | Gary's done the hard bit for qlog tests anyway, you might be able to persuade him to pull some of that out into a plugin | 17:52 |
| jszakmeister | mgz: that's a good idea | 17:53 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| jasonlife | I created a branch and updated a file, and tried to merge this new branch in trunk, but merge doesn't work.. any way to investigate this problem? | 19:07 |
| dash | what kind of doesn't work? | 19:09 |
| jasonlife | merging don't work.. | 19:09 |
| dash | yes. how doesn't it work? | 19:09 |
| jasonlife | the file I updated in branch doesn't applied to the same file in master.. | 19:10 |
| dash | what does it do instead? | 19:10 |
| jasonlife | I ran "bzr merge ../test-branch" , and got bzr: ERROR: [Errno 5] Input/output error | 19:11 |
| jasonlife | I normally get this error without any problems for other bzr commands though.. | 19:12 |
| dash | jasonlife: yikes! | 19:12 |
| * fullermd is a little creeped out by "normally" and "get this error". | 19:12 | |
| dash | what OS are you using? what filesystem? | 19:12 |
| jasonlife | hang on.. | 19:12 |
| jasonlife | fedora 10 | 19:13 |
| jasonlife | nfs | 19:13 |
| dash | yeah um, sounds like you've got some nfs issues | 19:14 |
| jasonlife | I see.. | 19:14 |
| jasonlife | Is it known issue? | 19:14 |
| jasonlife | any way to fix? or investigate? | 19:15 |
| jasonlife | Are there other ways to merge between branches? | 19:16 |
| dash | what version of bzr are you using? | 19:16 |
| === khmarbaise_ is now known as khmarbaise | ||
| jasonlife | Bazaar (bzr) 2.1.0 | 19:17 |
| dash | jasonlife: this may be relevant: https://bugs.launchpad.net/bzr/+bug/98836 | 19:17 |
| ubot5` | Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed] | 19:17 |
| dash | oh, this is the specific one: https://bugs.launchpad.net/bzr/+bug/137387 | 19:18 |
| ubot5` | Launchpad bug 137387 in Bazaar "close or truncate of os-locked file gives EIO on some NFSv4 servers (dup-of: 98836)" [Low,Incomplete] | 19:18 |
| ubot5` | Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed] | 19:18 |
| jasonlife | it seems the issue with ntfs hasn't been resolved yet.. | 19:42 |
| jasonlife | hmm.. | 19:42 |
| jasonlife | Is there any other way to merge between branches ? | 19:43 |
| jasonlife | sorry,,, ntfs/nfs | 19:45 |
| jasonlife | s/ntfs/nfs | 19:45 |
| jam | jasonlife: use a local checkout anywhere on your filesystem that isn't nfs, the branches can stay where they are | 19:56 |
| jasonlife | i see.. thanks jam | 19:57 |
| === Meths_ is now known as Meths | ||
| jeremyw | Is there an API for telling if a directory is a bzr branch or not? | 21:42 |
| jszakmeister | jeremyw: not as far as I know. I think you just have to try opening the directory and seeing if you get NotBranchError. | 21:46 |
| jszakmeister | via Branch.open(), that is. | 21:47 |
| jeremyw | Okay. | 21:47 |
| === Ursinha is now known as Ursinha-afk | ||
| thumper | jam: around? | 22:58 |
| === Ursinha-afk is now known as Ursinha | ||
| dOxxx | Good evening. | 23:26 |
| dOxxx | Downgrading pyqt is a pain in the ass. Riverbank Computing doesn't keep old versions in their downloads. | 23:55 |
| poolie | hello doxx | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!