| === fawek_ is now known as fawek | ||
| eferraiuolo | I have a question about using the contrib/bzr_access script | 00:51 |
|---|---|---|
| eferraiuolo | Invocation: bzr_access <bzr_executable> <repo_collection> <user> | 00:51 |
| eferraiuolo | do you have to call this with every user? | 00:51 |
| eferraiuolo | I'm confused about the "user" param; I though the config file would handle the user stuff | 00:52 |
| eferraiuolo | I guess it get it now, when a user logs-in the bzr_access command is ran | 00:59 |
| === dereine is now known as dereine[OFF] | ||
| === Spaz is now known as IRS | ||
| === IRS is now known as Spaz | ||
| beekor | Hi ya'll. I'm new at VCS type stuff, and am a bit lost. I'm aiming for the Centralized Development model in the userguide. I got my directory all init'd on the server part, and did a Checkout to make the directories on my user machine. I committed a change on my machine, now I'm trying to figure out how to get it back to the server. | 07:07 |
| beekor | I did a Merge, but it says Nothing to do. so that makes me thing that's not correct. | 07:07 |
| AfC | $ bzr push | 07:12 |
| AfC | {shrug} We don't really do centralized development, so I don't know what the User Guide is recommending about that these days. | 07:12 |
| beekor | yeah I tried a push, but that gave me conflicts. | 07:13 |
| beekor | What format do you all use then ? | 07:13 |
| beekor | I'm just one guy trying to work at 2 computors. | 07:13 |
| beekor | so i commit then i push. okay. hmmm | 07:14 |
| AfC | beekor: we have a number of contributors all of whom have branches; I also act as a gatekeeper as I'm the only one who can publish to the project's public 'mainline' branch, so people send me bundles if they want their work considered for merging and publication (as part of the project). | 07:15 |
| beekor | gotcha. I'm still working through the terminology a bit here. | 07:16 |
| AfC | Straight forward DVCS, except that people have been living with the crippled centralized modality of CVS & Subversion heritage that the decentralized world all seems a bit horrible and scary. | 07:16 |
| beekor | this is my first foray into any of the VCS programs at all. | 07:17 |
| AfC | It's not, really, but it takes a bit of getting used to. In my experience, decentralized has entirely been worth getting people up to speed with, but for very small changes it can be a bit fiddly. | 07:17 |
| AfC | (and given that most people's first interactions are for small deltas, all the fiddling about seems excessive. This is not an unreasonable first impression) | 07:18 |
| beekor | so basically, i Merge to update my branch(?) from the server, and then Push to update the server of my changes that I've Commit-ed ? | 07:18 |
| AfC | um | 07:18 |
| beekor | haa | 07:18 |
| AfC | you get a branch from the server | 07:18 |
| beekor | i don't liek that um. | 07:18 |
| beekor | okay. | 07:18 |
| AfC | you then make changes | 07:18 |
| AfC | you commit | 07:18 |
| beekor | im with ya so far. | 07:19 |
| AfC | you can then push to the server. | 07:19 |
| AfC | HOWEVER | 07:19 |
| AfC | if the server has since diverged from when you branched, | 07:19 |
| AfC | then you cannot push | 07:19 |
| AfC | (or, if you were sitting on the server, you could not pull) | 07:19 |
| beekor | was that my conflicts that I got? | 07:19 |
| AfC | and (again, from the server side) you would have to do a merge instead of a pull | 07:19 |
| AfC | beekor: probably | 07:19 |
| beekor | k | 07:19 |
| beekor | hmm. | 07:19 |
| AfC | Now. Bazaar has a notion called "bound branch" which you can (perhaps deliberately, perhaps inadvertently) create with | 07:20 |
| AfC | $ bzr checkout | 07:21 |
| AfC | instead of | 07:21 |
| AfC | $ bzr branch | 07:21 |
| AfC | the *only* difference | 07:21 |
| AfC | between the two (bound in the first case, unbound in the second) | 07:21 |
| AfC | is that with a checkout (bound branch) you cannot commit to the local branch unless the commit first succeeds on the other [typically remote] branch. | 07:21 |
| AfC | which turns out to be the "centralized" model we're used to from CVS. | 07:22 |
| AfC | for people who are accessing our public 'mainline' for which not a one of them have write access to, | 07:22 |
| AfC | this means that they in effect get a read-only local copy [mirror, even] of the upstream project. | 07:23 |
| AfC | they can then branch that locally to have a copy they can work in. | 07:23 |
| AfC | This tends to be a useful approach | 07:23 |
| beekor | okay. so to work on my user machine, i originally did a Checkout. maybe that is a source of my issues. I will try with a Branch | 07:23 |
| AfC | beekor: http://java-gnome.sourceforge.net/4.0/get/#source describes this, although it may not be interesting to you | 07:24 |
| AfC | beekor: other than this bound bit | 07:24 |
| AfC | (and it literally is a boolean, there's nothing else on disk that differentiates them) | 07:24 |
| AfC | there is no difference between a checkout and branch. A "checkout" in Bazaar *is* a branch | 07:24 |
| AfC | with some extra constraints thrown in | 07:24 |
| beekor | okay. | 07:24 |
| AfC | (and you can always unhook that constraint with | 07:25 |
| AfC | $ bzr unbind | 07:25 |
| AfC | ) | 07:25 |
| AfC | so the real issue | 07:25 |
| AfC | is deciding how you want changes to flow. | 07:25 |
| AfC | this has little to do with Bazaar, actually | 07:25 |
| AfC | if you are only moving changes (ok, revisions, actually) | 07:25 |
| beekor | now, i should only have to checkout/branch initially. after that, i stay updated with Merge. is that correct ? | 07:25 |
| AfC | in one direction | 07:25 |
| AfC | and assuming you have constant always on write access to the other side, and just want the other side to always be what's local | 07:26 |
| AfC | then a local branch bound to the remove one will do you fine. | 07:26 |
| AfC | there were a lot of "always" in that last sentance. | 07:26 |
| beekor | ha. | 07:26 |
| AfC | If you're working independently on both sides then you'll have to be more careful | 07:27 |
| AfC | s/careful/deliberate/ | 07:27 |
| AfC | but if you only ever work locally and are just pushing deltas up to a server | 07:27 |
| AfC | then a) no need for it to be a checkout and b) push will always work | 07:27 |
| beekor | okay. | 07:27 |
| AfC | [or, ssh server && bzr pull] | 07:27 |
| AfC | [assuming access works in the other direction, which it usually doesn't] | 07:28 |
| AfC | So that's about all you're getting out of me pro bono. | 07:28 |
| AfC | If you think about all that you'll probably find your way. | 07:28 |
| AfC | The fact that you created divergence on the server side indicates lots of things, but I imagine you'll be able to play with it from here. | 07:28 |
| beekor | well that's a lot of free info, i'd say. | 07:29 |
| beekor | not a lot that I understand at this point, but that's my issue. | 07:29 |
| beekor | i will save this conversation and refer to it laterwise. | 07:30 |
| beekor | thanks for the help. i do appreciate it. | 07:30 |
| AfC | beekor: one last thought: people tend to overcomplicate things. | 07:30 |
| beekor | hahaha. | 07:30 |
| === dereine[OFF] is now known as dereine | ||
| === AfC1 is now known as AfC | ||
| === dereine is now known as dereine[OFF] | ||
| === jamesh__ is now known as jamesh | ||
| === _Nicke_ is now known as Nicke | ||
| === dereine[OFF] is now known as dereine | ||
| === dereine is now known as dereine[OFF] | ||
| nielsbom | Anyone know a good introductory screencast for bzr? (and yes I googled) | 15:11 |
| LarstiQ | nielsbom: emmajane might have done one | 15:14 |
| nielsbom | LarstiQ: I saw those two :) | 15:14 |
| nielsbom | They were good, but I would like some more. | 15:15 |
| LarstiQ | nielsbom: what would you like to see? | 15:16 |
| * LarstiQ attempts flashing his bios | 15:16 | |
| nielsbom | LarstiQ: well I have trouble visualizing/envisioning how bzr merges files | 15:16 |
| nielsbom | LarstiQ: and I'd like to know how it works before I start using it :) | 15:17 |
| LarstiQ | nielsbom: perfectly? ;) | 15:20 |
| nielsbom | LarstiQ: well somewhat :) | 15:21 |
| nielsbom | LarstiQ: I can stand a bit of black-boxxines | 15:21 |
| garyvdm | nielsbom: do you understand how 3 way file merges work? | 15:21 |
| nielsbom | garyvdm: nope | 15:22 |
| jelmer | LarstiQ, ping | 15:22 |
| nielsbom | Ow btw a more concrete question (and a noob one) how can I set up my hosted server so that I can push a revision to it? | 15:22 |
| garyvdm | nielsbom: This explains it nicely in the context of vcs | 15:22 |
| garyvdm | http://www.ericsink.com/scm/scm_file_merge.html | 15:22 |
| nielsbom | (just ftp?) | 15:22 |
| jelmer | LarstiQ, can you check whether bug 320113 is fixed? | 15:23 |
| ubottu | Launchpad bug 320113 in bzr-svn "svn-upgrade fails with a KeyError (in rebase generate_transpose_plan)" [Undecided,Incomplete] https://launchpad.net/bugs/320113 | 15:23 |
| LarstiQ | jelmer: I can. | 15:23 |
| LarstiQ | jelmer: do you want me to do that now? | 15:23 |
| jelmer | LarstiQ, yeah, if possible | 15:23 |
| jelmer | LarstiQ, I'm pondering about releasing 0.5.0 today | 15:23 |
| garyvdm | nielsbom: You can push your revisions to ftp, but it won't update the working tree in the ftp dir | 15:24 |
| LarstiQ | nielsbom: just ftp works, although it is ahorrible protocol, use sftp if you can | 15:24 |
| LarstiQ | jelmer: ok, let me see | 15:24 |
| LarstiQ | jelmer: I don't suppose you can help me flashing my bios? ;) | 15:25 |
| nielsbom | garyvdm: "won't update the working tree in the ftp dir", but what good does it do then? (in the case that I want to push code to my server?) | 15:25 |
| jelmer | LarstiQ, you're still trying to do that ? :-) | 15:25 |
| garyvdm | nielsbom: you can use the upload plugin to upload a tree. | 15:25 |
| garyvdm | nielsbom: Note that this is not a working tree - so you shouldn't edit the tree, and you can commit it. | 15:26 |
| nielsbom | garyvdm: can or can't? | 15:27 |
| garyvdm | Sorry - can't | 15:27 |
| nielsbom | right | 15:27 |
| garyvdm | nielsbom: It works well if you are using bzr to vc a website. | 15:28 |
| nielsbom | garyvdm: but what is the best practice if I want to push local code to my server using FTP? (or is there another step after using the upload plugin?) | 15:28 |
| Peng_ | No SFTP or SSH access? :X | 15:28 |
| garyvdm | nielsbom: Just use upload. | 15:28 |
| nielsbom | garyvdm: yes I want to VC a website | 15:28 |
| LarstiQ | jelmer: different laptop | 15:29 |
| nielsbom | garyvdm: sorry that I don't seem to understand but if I use the upload, it does not update the working tree right? How can I make that happen? | 15:29 |
| LarstiQ | nielsbom: bzr-upload | 15:29 |
| nielsbom | Ow and I might have SSH to my server, that would simplify matters, right? | 15:30 |
| LarstiQ | jelmer: do I need a new version of rebase too? | 15:30 |
| LarstiQ | nielsbom: yes | 15:30 |
| jelmer | LarstiQ, yes | 15:30 |
| LarstiQ | jelmer: this is on my Acer Aspire One, where I'd like to use an SD card, but for some reason the bootable images hang before I get to the flashing part | 15:31 |
| garyvdm | nielsbom: Yes - if you have ssh access - then use https://launchpad.net/bzr-push-and-update | 15:31 |
| LarstiQ | jelmer: the last commit of rebase is funny: 'Fix bug #.' | 15:32 |
| Peng_ | nielsbom: If you have SSH access and bzr is installed (or you can install it, which should be easy enough). | 15:32 |
| Peng_ | nielsbom: At the very least, SFTP > FTP, even if (with bzr) there isn't any difference. | 15:32 |
| nielsbom | garyvdm: just checked: no SSH or SFTP | 15:33 |
| nielsbom | garyvdm: my host is pretty cheap, so no wonder | 15:34 |
| Peng_ | Cheap isn't an excuse for that. | 15:34 |
| LarstiQ | jelmer: could you not raise a bare ImportError in check_subversion_version()? | 15:34 |
| nielsbom | Peng_: true... | 15:34 |
| Peng_ | Wait, I'm still paying like $7 a month for some SSHless web hosting account I haven't touched since 2006... | 15:35 |
| nielsbom | garyvdm: but after I upload a tree to my server using FTP, how can I change that to be the working tree? | 15:35 |
| nielsbom | Peng: $7 is quite a lot | 15:35 |
| nielsbom | Peng_: I pay EUR 25 a year and I get quite a lot (but no SSH) | 15:36 |
| LarstiQ | jelmer: KeyError: 'svn-v4:cd2972fe-eb09-0410-94ea-d8feb256cc61:trunk/kmx:8048' | 15:36 |
| Peng_ | nielsbom: That's on top of the $30 for non-sucky hosts I do use (mostly). :P | 15:36 |
| garyvdm | nielsbom: You don't need to make it a working tree. | 15:36 |
| nielsbom | Peng_: ouch, but then again, you probably make some nice $$$ or :) :) :) of off it too, right? | 15:37 |
| Peng_ | nielsbom: Certainly not. But it's fun! | 15:37 |
| nielsbom | garyvdm: is that because the upload plugin just uploads it without the need for there being bzr on the server? | 15:38 |
| garyvdm | nielsbom: bzr-upload will uploads the dirs/files that are the latest version in bzr to your ftp dri | 15:38 |
| nielsbom | Peng_: if it's worth it, it's worth it | 15:38 |
| garyvdm | nielsbom:yes | 15:38 |
| nielsbom | garyvdm: ok now I understand, thanks | 15:38 |
| garyvdm | https://launchpad.net/bzr-upload | 15:39 |
| nielsbom | garyvdm: but this _can_ get problematic with multiple people committing right? Then I'd have to use classic VC right? (Check out first...) | 15:39 |
| garyvdm | nielsbom: | 15:39 |
| LarstiQ | nielsbom: I'd recommend seperating versioning from deployment. | 15:40 |
| garyvdm | nielsbom: No - there is a solution for that. | 15:40 |
| jelmer | LarstiQ, what should I do instead of raising an importerror? | 15:40 |
| LarstiQ | jelmer: fold the warning into the importerror? | 15:40 |
| LarstiQ | jelmer: ie, raise ImportError("Need at least subvertpy 0.6.1, got 0.6") instead of raise ImportError | 15:41 |
| LarstiQ | jelmer: that way I can see what is wrong just by looking at the stacktrace. | 15:41 |
| nielsbom | LarstiQ: garyvdm: So I use one testing server (with VC) and one live server to which I deploy (from test to live). Me and other developers then use the testing server to commit our changes. Is that a correct way? | 15:42 |
| LarstiQ | nielsbom: having live and testing servers is good practice. | 15:42 |
| LarstiQ | nielsbom: but I'd personally commit locally and deploy to testing from there, as well as deploying to live from there. | 15:43 |
| nielsbom | LarstiQ: So code and commit locally. Deploying to test: local --> test. Deploying to live: local --> live. | 15:44 |
| LarstiQ | nielsbom: that is what I would do, yes. | 15:44 |
| nielsbom | LarstiQ: ok understood, thanks for your help, and garyvdm: too! | 15:45 |
| jelmer | LarstiQ, fixed | 15:45 |
| LarstiQ | *glomp* | 15:45 |
| garyvdm | LarstiQ: that implies nielsbom would become a gatekeper? | 15:45 |
| LarstiQ | garyvdm: I'd keep that workflow for everyone involved. But maybe it can be done better? | 15:46 |
| nielsbom | garyvdm: well unless other people also have the right to upload to live right? | 15:46 |
| garyvdm | LarstiQ: or should he have a rule that uploads must be from the central repo? | 15:46 |
| LarstiQ | garyvdm: I'll try top rephrase | 15:48 |
| LarstiQ | the point I find icky is versioning a 'live' (test in this case) site directly, instead of using a deployment mechanism | 15:48 |
| nielsbom | LarstiQ: do I understand correctly that you advise against using bzr as a deployment tool (my sites aren't that critical btw) | 15:50 |
| nielsbom | LarstiQ: (question mark) | 15:51 |
| LarstiQ | nielsbom: not exactly. The bzr-upload plugin I find is a good deployment tool. | 15:54 |
| LarstiQ | nielsbom: you are correct that I wouldn't have any bzr branches there. | 15:54 |
| garyvdm | nielsbom: This is my suggestion: lets say you have a group of devs - create 2 branches that are shared, one for you testing server, one for you live server. | 15:55 |
| LarstiQ | nielsbom: but there are multipel ways to do things, I believe garyvdm is going to tell you about a workflow I wouldn't feel comfortable using :) | 15:56 |
| garyvdm | Then use the bzr-upload --auto option on each of those branches. | 15:56 |
| garyvdm | So when a dev pushes to say your test branch, bzr-upload will upload the latest version of that branch to your test server. | 15:57 |
| === fawek_ is now known as fawek | ||
| garyvdm | LarstiQ: why? | 15:59 |
| LarstiQ | garyvdm: I'm in fullermd's camp. Our minds seem to require a more formal division between versioning and deployment. | 16:02 |
| nielsbom | garyvdm: I think I understand :) | 16:02 |
| * garyvdm thinks deployment control requires versions control - thats why old version control systems were called "software configuration management" | 16:05 | |
| luks | requires != is :) | 16:09 |
| Ycros | deployment branches ftw | 16:11 |
| jelmer | LarstiQ, still there? | 16:32 |
| jelmer | hi abentley | 16:32 |
| LarstiQ | jelmer: yes | 16:33 |
| jelmer | LarstiQ, what happens if you try with the patch in http://samba.org/~jelmer/tmp/assert.diff applied? | 16:38 |
| LarstiQ | jelmer: the assert is triggered | 16:41 |
| jelmer | LarstiQ, can you change it to return None if has_revision() returns False ? | 16:42 |
| LarstiQ | and then run it I assume :) | 16:43 |
| jelmer | yup, that's the idea | 16:44 |
| LarstiQ | jelmer: it completed | 16:44 |
| * LarstiQ runs missing against his fresh 0.5 branched copy | 16:44 | |
| nielsbom | <3 meta VC on a VC project :-) | 16:45 |
| LarstiQ | jelmer: hmm, now missing blows up | 16:46 |
| jelmer | LarstiQ, how? | 16:46 |
| LarstiQ | File "/home/wouter/.bazaar/plugins/dev/svn/mapping3/__init__.py", line 293, in _parse_revision_id | 16:46 |
| LarstiQ | return (uuid, branch_path, int(srevnum), scheme) | 16:46 |
| LarstiQ | ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade' | 16:46 |
| LarstiQ | jelmer: which is the revision we were having trouble with | 16:46 |
| jelmer | LarstiQ, What argument are you specifying to svn-upgrade? | 16:48 |
| LarstiQ | jelmer: right, other operations blow up as well | 16:48 |
| LarstiQ | jelmer: nothing | 16:48 |
| LarstiQ | just `bzr-experiment svn-upgrade` | 16:48 |
| jelmer | LarstiQ, what is the pull location of that branch? | 16:49 |
| LarstiQ | jelmer: svn+ssh://source/home/wouter/tmp/kmx_svn/trunk/kmx | 16:49 |
| jelmer | LarstiQ, so the strange thing seems to be that that revision should exist in the svn repository but it doesn't | 16:52 |
| abentley | jelmer: Hi. | 16:55 |
| LarstiQ | jelmer: I'm not entirely sure what you mean with that. | 16:55 |
| LarstiQ | jelmer: obviously svn rev 8048 exists. | 16:56 |
| jelmer | LarstiQ, and that was a round-tripped revision? | 16:56 |
| LarstiQ | jelmer: the bzr-svn metadata, I don't know how that meshes. | 16:56 |
| LarstiQ | jelmer: yes | 16:56 |
| LarstiQ | jelmer: from 0.5 | 16:56 |
| jelmer | LarstiQ, ah, I think I understand what the problem is here | 16:56 |
| LarstiQ | jelmer: and I can make fresh branches with 0.4 and 0.5 both, that is not an issue. | 16:56 |
| LarstiQ | jelmer: ok :) | 16:56 |
| LarstiQ | hey jdub! | 16:56 |
| jelmer | Hi Jeff | 16:57 |
| jdub | morning | 16:57 |
| jdub | hey jelmer | 16:57 |
| LarstiQ | jdub: that's a long time ago. | 16:57 |
| LarstiQ | abentley: heya | 16:57 |
| jdub | thanks heaps for fixaging that bug :-) | 16:57 |
| abentley | LarstiQ: Hey. | 16:57 |
| LarstiQ | abentley: you mentioned we should talk? | 16:57 |
| abentley | LarstiQ: Yeah. | 16:57 |
| jdub | jelmer: the fix has prompted me to ask for a tip though ;-) | 16:57 |
| jelmer | jdub: Np, thanks for bringing it to my attention before I released 0.5.0 | 16:57 |
| jelmer | jdub, uhoh | 16:57 |
| abentley | I'll be working on Nested Trees once I finish what I'm currently working on. Maybe this week or next. | 16:58 |
| LarstiQ | abentley: ok | 16:58 |
| abentley | LarstiQ: I didn't realize you were working on them too. | 16:58 |
| jdub | jelmer: i have a repo with a couple of svn bits in it (trunk, branch) and a bzr branch... now i've upgraded the svn bits, the bzr branch needs rebasing. | 16:58 |
| jdub | jelmer: how do i do that sanely? :-) | 16:58 |
| abentley | LarstiQ: Where are they at? | 16:58 |
| LarstiQ | abentley: I hadn't been, but recent requests prompted me to start looking again. | 16:58 |
| abentley | LarstiQ: Ah, okay. | 16:59 |
| abentley | LarstiQ: There does seem to be a lot of interest. | 16:59 |
| LarstiQ | abentley: haven't actually done much since yet, other than paging code into my head and fixing some conflicts. | 16:59 |
| LarstiQ | abentley: well, and looking at scmproj | 16:59 |
| jelmer | jdub: the bzr branch basically contains the svn branch with some extra bzr revisions on top? | 17:00 |
| jdub | jelmer: yeah | 17:00 |
| abentley | LarstiQ: Yeah, I'm going to be looking at svn externals to try and see what they did right and wrong. | 17:00 |
| LarstiQ | abentley: cool | 17:00 |
| jelmer | jdub, backing up that bzr directory and then running "bzr svn-upgrade <svn-repository-url>" should fix that | 17:00 |
| jdub | ahar | 17:00 |
| jdub | ok, will try | 17:00 |
| jdub | ta :-) | 17:00 |
| abentley | LarstiQ: Should we try to work together on this? | 17:00 |
| LarstiQ | abentley: I'd like that. Whatever the case, I defer to your lead. | 17:01 |
| * LarstiQ doesn't want to get in abentley's way | 17:01 | |
| abentley | Thanks. It will certainly be a great help to start from your fixed-up version. | 17:02 |
| jdub | jelmer: hrm, what should that url be? | 17:02 |
| LarstiQ | abentley: I'll try to get a recent bzr.dev merge done this week | 17:02 |
| jelmer | jdub, the URL of root of the subversion repository | 17:02 |
| abentley | LarstiQ: Cool. | 17:02 |
| jdub | jelmer: so one level above trunk? | 17:03 |
| LarstiQ | jelmer: the repo root, or the branch root? | 17:03 |
| jelmer | repository root | 17:03 |
| jelmer | yeah, generally that would be one level above trunk | 17:03 |
| jdub | eg. bzr svn-upgrade http://svn.automattic.com/wordpress/ ? | 17:03 |
| jelmer | "svn info <some-svn-url>" will tell you the repository root | 17:03 |
| jelmer | jdub, yep | 17:04 |
| abentley | LarstiQ: IIRC, there are a bunch of commands that need updating to work with nested trees, and merge probably needs to be re-done. | 17:04 |
| jdub | ok, i get sweet traceback action :-) | 17:04 |
| LarstiQ | abentley: move is still having problems atm | 17:04 |
| abentley | LarstiQ: Also, a new branch format with a better mechanism for specifying the locations of nested trees. | 17:04 |
| * LarstiQ nods at abentley | 17:04 | |
| abentley | LarstiQ: Ah, okay. | 17:05 |
| jelmer | jdub, whoa, can you please pastebin the traceback? | 17:05 |
| abentley | LarstiQ: I think the first priority, once we get a clean merge, is to get as much merged back into trunk as we can. | 17:05 |
| jdub | jelmer: ah, ok | 17:05 |
| jdub | http://pastebin.ubuntu.com/112494/ | 17:05 |
| abentley | We'll probably want to split it up into a loom, so that the patches aren't crazy-long. | 17:06 |
| LarstiQ | abentley: that sounds good, I'll need to lookup how to work with looms. | 17:06 |
| jdub | jelmer: oh, my rebase is up to date with trunk | 17:07 |
| jdub | as of just before this discussion ;-) | 17:07 |
| jelmer | jdub, Do you have the latest bzr-svn? | 17:07 |
| abentley | LarstiQ: Looms aren't very good for collaboration at this point, so that's probably a task for one person. | 17:07 |
| jdub | 0.5.0~rc2-1~bazaar1~intrepid | 17:07 |
| abentley | We should quickly get back to having a branch with unmergeable changes, and then we can work on that. | 17:08 |
| jdub | (using bzr and friends from the beta ppa) | 17:08 |
| jelmer | jdub, you'll need the tip of http://people.samba.org/bzr/jelmer/bzr-svn/0.5, which matches the updates I made to rebase | 17:08 |
| jdub | jelmer: can i just check that out into .bazaar/plugins as with rebase? | 17:08 |
| jelmer | jdub, yep | 17:08 |
| jelmer | hmm, deja vu - didn't you also run into svn-upgrade bugs at the last major release of bzr-svn? | 17:09 |
| LarstiQ | abentley: ok | 17:09 |
| jdub | yeah, but they were beyond fixage due to local braindamage | 17:10 |
| jdub | so i dumped those | 17:10 |
| jdub | oh, and this is actually a different repo (wp.org rather than wpmu) | 17:10 |
| LarstiQ | jelmer: make a not in the bzr-svn release docs, 'ask jdub to give it a testrun'? | 17:10 |
| LarstiQ | note, bweh | 17:11 |
| jdub | edge case is my middle name(s)! | 17:11 |
| abentley | LarstiQ: The next things I'll be working on are to make it possible for the nested-tree format to be our default. | 17:12 |
| abentley | LarstiQ: So, making working trees not automatically detect nested trees, and fixing the sha1-rewriting issue. | 17:12 |
| jdub | jelmer: oh rock! that was fixed and fast :-) | 17:13 |
| jdub | jelmer: thanks heaps | 17:13 |
| jelmer | jdub: np | 17:13 |
| jelmer | LarstiQ, I also found the real issue behind your bug | 17:13 |
| LarstiQ | abentley: this eek you mean, or after we're at a state of unmergeable changes? | 17:13 |
| LarstiQ | jelmer: is it fixed yet? :) | 17:13 |
| abentley | LarstiQ: I think after the unmergeable changes, but it's fluid at this point. | 17:14 |
| LarstiQ | k | 17:14 |
| jdub | ooh, this is interesting: | 17:14 |
| jdub | jdub@sliver:~/src/wordpress/wpsu/masspress$ bzr unshelve 1 | 17:14 |
| jdub | M wp-content/plugins/vipers-video-quicktags/vipers-video-quicktags.php | 17:14 |
| jdub | bzr: ERROR: A nested progress bar was not 'finished' correctly. | 17:14 |
| abentley | LarstiQ: Is http://bazaar-vcs.org/NestedTreeProgress accurate? I think we should have a wiki page listing outstanding tasks, so that we can claim them. | 17:15 |
| LarstiQ | abentley: no, it's not accurate. | 17:16 |
| LarstiQ | abentley: agreed on the breaking up work, claiming, and public progress report. | 17:16 |
| LarstiQ | abentley: I don't think the page has drifted too much | 17:17 |
| abentley | LarstiQ: Okay. If you could polish it, that would be helpful, since you know the current status better than me. | 17:17 |
| LarstiQ | abentley: I will need to keep paging things into my head. I'll start with updating the current devel branch location. | 17:19 |
| jdub | jelmer: thanks again... night all! | 17:20 |
| abentley | LarstiQ: Thanks. | 17:20 |
| CaMason | hi guys. I'm getting "bzr_log.TAqjxu~" style files in my working copy every time I commit | 17:23 |
| jelmer | LarstiQ, please try again with current bzr-svn | 17:28 |
| LarstiQ | CaMason: any other warning/error? Hints in ~/.bzr.log? | 17:29 |
| jelmer | LarstiQ, (throwing away the previous branch created with svn-upgrade) | 17:36 |
| LarstiQ | jelmer: yeah | 17:37 |
| LarstiQ | jelmer: still get ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade' | 17:37 |
| jelmer | LarstiQ: Is this in a completely new repository, etc? | 17:38 |
| LarstiQ | jelmer: good catch | 17:38 |
| LarstiQ | branching outside of that repository now | 17:39 |
| ronny | how can i undo the last commit? | 17:42 |
| jelmer | ronny, bzr uncommit | 17:42 |
| ronny | thx | 17:44 |
| LarstiQ | jelmer: svn-upgrade, completes, log doesn't give any errors, but missing blows | 17:47 |
| Goundy | hi | 17:51 |
| Goundy | quick & noob question (again) :P : well I've two branches @local: mainline and working | 17:51 |
| Goundy | I work on working and then merge into mainline and then do push on mainline | 17:51 |
| Goundy | now I want my working branch to become the main branch | 17:51 |
| Goundy | to avoid commiting with same messages twice | 17:51 |
| Goundy | How can I do that ? and thanks | 17:51 |
| garyvdm | cd mainline | 17:52 |
| garyvdm | bzr pull ../working | 17:52 |
| garyvdm | If I understand you correctly | 17:53 |
| Goundy | garyvdm and then I can delete mainline by rm -rf mainline right ? | 17:53 |
| LarstiQ | ehm | 17:53 |
| garyvdm | No - Ok - I thought you wanted to do this once off | 17:53 |
| Goundy | garyvdm well please let me explain again (sorry I've a small experience with DVCS) | 17:54 |
| LarstiQ | Goundy: are these two the only branches in play, or are there more? | 17:54 |
| Goundy | that's why I'm getting hard to explain what am doing. Well I'll reexplain :P | 17:54 |
| Goundy | LarstiQ am going to reexmplain :P | 17:54 |
| Goundy | I've a branch on launchpad it's called: aures | 17:54 |
| Goundy | and it's a development branch. | 17:54 |
| Goundy | at first I did checkout on this branch to get a local copy | 17:55 |
| Goundy | and then I did: bzr branch aures working | 17:55 |
| Goundy | So I always work on "working" (useless yea :/) | 17:55 |
| Goundy | and then I do: cd aures && bzr merge && bzr push | 17:55 |
| Goundy | So I use working when coding and I use aures to push up | 17:55 |
| Goundy | So now I want to be able to do PUSH through "working" | 17:56 |
| Goundy | and I want to kick out aures | 17:56 |
| garyvdm | cd working | 17:56 |
| Goundy | (kicking local aures and not these on launchpad) | 17:56 |
| garyvdm | bzr pull ../aures (to make sure that you have the latest in working) | 17:57 |
| garyvdm | cd .. | 17:57 |
| garyvdm | rm aures | 17:57 |
| garyvdm | errr rm aures -r | 17:57 |
| Goundy | yea | 17:57 |
| Goundy | that's all ? | 17:57 |
| garyvdm | cd working | 17:57 |
| garyvdm | bzr push lp:aures | 17:58 |
| garyvdm | deleting aures on you hdd won't touch whats on lp | 17:58 |
| garyvdm | that's all | 17:58 |
| Goundy | garyvdm doesn't work man :/ | 17:58 |
| Goundy | it recreated the branch aures when I did push >_< | 17:59 |
| garyvdm | ok - you will need to do this the first time: | 17:59 |
| garyvdm | bzr push lp:aures --remember | 17:59 |
| Goundy | garyvdm rox ! thank you very much | 18:01 |
| === fta_ is now known as fta | ||
| garyvdm | Pleasure Goundy. | 18:02 |
| Goundy | :) | 18:02 |
| Goundy | bazaar is really > svn | 18:02 |
| Goundy | damn, what a powerful release >_> | 18:03 |
| === lamont` is now known as lamont | ||
| kfogel | whoa. bzr selftest has the tests specified just by prefix, e.g.: | 19:51 |
| kfogel | LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v test_status 2>&1 | sed -e 's/^/[ascii] /' | 19:51 |
| kfogel | runs all the tests whose names begin with "test_status", such as test_status_nonexistent_file() | 19:51 |
| jelmer | kfogel, I think the argument is a regex | 19:52 |
| kfogel | jelmer: ah, that's possible too, let's see | 19:53 |
| kfogel | LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v 'status_.*existent' 2>&1 | sed -e 's/^/[ascii] /' | 19:53 |
| kfogel | yup | 19:53 |
| kfogel | that runs the same test | 19:53 |
| kfogel | jelmer: oddly, though, it seems to run the same test twice. | 19:53 |
| kfogel | e.g.: | 19:53 |
| jelmer | kfogel: Is the name exactly the same ? | 19:53 |
| * kfogel waits for test output to appear | 19:54 | |
| kfogel | jelmer: oh | 19:54 |
| jelmer | it can be running the test against two different bzr formats | 19:54 |
| kfogel | never mind | 19:54 |
| jelmer | or something like that | 19:54 |
| kfogel | two different tests | 19:54 |
| lifeless | moin | 19:54 |
| kfogel | [ascii] running 2 tests... | 19:54 |
| kfogel | [ascii] ...tatus.BranchStatus.test_status_nonexistent_file OK 174ms | 19:54 |
| kfogel | [ascii] ...tus.CheckoutStatus.test_status_nonexistent_file OK 51ms | 19:54 |
| kfogel | [ascii] tests passed | 19:54 |
| jelmer | hey lifeless | 19:54 |
| kfogel | jelmer: actually, that test is only defined once, in bzrlib/tests/blackbox/test_status.py (class BranchStatus). But that file *also* defines class CheckoutStatus(BranchStatus), and therefore the test gets run twice when requested once. I have no idea if this is a desired result or not :-). | 19:55 |
| jelmer | kfogel, Yeah, that would be desired | 19:59 |
| jelmer | kfogel, you should be able to specify the full test name | 19:59 |
| jelmer | bzrlib.tests.blackbox.test_status.BranchStatus.test_status_nonexistent_file | 19:59 |
| jelmer | to run just that test | 19:59 |
| kfogel | jelmer: thanks | 19:59 |
| lifeless | kfogel: its two tests :P | 20:03 |
| lifeless | kfogel: tests are namespaced | 20:03 |
| lifeless | kfogel: you could do Branch.*status_none as a pattern also | 20:03 |
| kfogel | lifeless: the idea is that bzr might behave differently in a branch vs in a checkout? | 20:04 |
| kfogel | lifeless: IOW, write all the tests once, but run them in two different scenarios | 20:04 |
| kfogel | (I may be using wrong terminology: I mean "bzr might behave differently in the presence/absence of a working tree" I guess) | 20:05 |
| lifeless | kfogel: the status command looks at both the tree and the branch | 20:11 |
| thumper | morning peoples | 20:11 |
| lifeless | though looking at CheckoutStatus its a little superficial, some specific tests for out of date detection would not go astray | 20:11 |
| kfogel | thumper: morning | 20:12 |
| kfogel | lifeless: hmm, okay. It's not blocking me or anything, I'm just trying to understand the test suite better. I get the feeling it sort of grew by accretion. | 20:12 |
| lifeless | :p yes we wrote tests roughly at the same time as the code | 20:14 |
| lifeless | we've also increased support capability slightly behind when it was needed | 20:14 |
| kfogel | Hey, anyone remember what's preferred in python these days, 'file()' or 'open()'? http://docs.python.org/library/stdtypes.html#file-objects seems to imply that 'open()' is what the cool kids do nowadays. | 20:19 |
| lifeless | open() | 20:20 |
| kfogel | lifeless: thanks | 20:20 |
| lifeless | its clearer | 20:20 |
| paroneayea | I'm not sure I get branches in bazaar. Are they supposed to be subdirectories, or am I doing something wrong? Also, how do you list all branches in bazaar? | 20:21 |
| kfogel | paroneayea: I'm not a bzr expert, but I think 'bzr branches' will show you all the branches ('bzr help commands' is what told me that). In my way of working so far, it's common to put branches in subdirectories -- that is, one subdir for each branch -- but I'm not sure you have to do it that way. Have you read the Users Guide? | 20:24 |
| kfogel | Also, comparing http://bazaar-vcs.org/Scenarios/OneOffContribution with http://bazaar-vcs.org/Scenarios/RepeatedContributions might give you some idea of the relationship between branches and repositories. | 20:24 |
| paroneayea | kfogel: yeah, I'm trying to look at the user's guide but I didn't see it describing the way subdirectories work and stuff | 20:26 |
| paroneayea | I'm used to the git idea | 20:26 |
| paroneayea | where you have all these branches but you only see one at a time | 20:27 |
| lifeless | paroneayea: we are looking at changing this; the git layout seems pretty popular | 20:27 |
| lifeless | it clicks better for enough folk | 20:27 |
| lifeless | anyhow | 20:27 |
| kfogel | paroneayea: you can do that in bzr too, it's not actually so different (that is, have a bunch of branches present in your repository locally, and only be viewing one at a time in the actual checked out tree, using the 'bzr switch' command). | 20:28 |
| lifeless | yes, one directory per branch at the moment [unless you use a plugin that changes that] | 20:28 |
| kfogel | I hope someone else here will correct me if I make any wrong assertions. | 20:28 |
| kfogel | paroneayea: it's more a matter of bzr having a different default right now, that's all | 20:28 |
| paroneayea | ah. Okay, this conversation helps | 20:29 |
| lifeless | kfogel: you do know about the brisbane-core project yes? | 20:30 |
| paroneayea | lifeless: do you know of such a plugin? | 20:30 |
| kfogel | lifeless: I know about it, but I think I might only know about some of the performances speedup stuff going on there. Is it about more than that? | 20:30 |
| lifeless | paroneayea: yes, the colocated-branch plugin jelmer put together | 20:30 |
| lifeless | paroneayea: its not really polished, but its a usable proof of concept | 20:30 |
| lifeless | also 'bzr-loom' does something similar (its similar to topgit) | 20:31 |
| lifeless | [or rather topgit is similar to it :P] | 20:31 |
| lifeless | kfogel: re bug 246891 | 20:31 |
| LarstiQ | paroneayea: a similar workflow can be achieved with `bzr cbranch` and friends from bzrtools, but some people dislike having branches be actual filesystem objects | 20:31 |
| ubottu | Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] https://launchpad.net/bugs/246891 | 20:31 |
| kfogel | lifeless: yes, thanks -- I'd heard people mention brisbane-core. But is it scheduled to land at a particular time? | 20:32 |
| lifeless | kfogel: as soon as we can :P | 20:33 |
| lifeless | kfogel: its more that there is very little we have identified as 'doable' to improve performance on tree delta operations (both -v and subdir-contents in log require that) without it landing | 20:34 |
| kfogel | lifeless: can't come soon enough for me (and GNU Emacs :-) ) | 20:34 |
| paroneayea | well anyway, I will keep following bazaar... it has a much cleaner command set than git. But for now it's too much of a disruption for me to have the multiple subdirectory branches in my workflow, so I think I'm sticking to git for now | 20:43 |
| paroneayea | thanks for the help :) | 20:43 |
| LarstiQ | paroneayea: even with switch? | 20:43 |
| paroneayea | LarstiQ: well, maybe I should look at it some more. But it's confusing, there's not much documentation on this workflow in bazaar. I can't tell if it's safe to remove subdirectories and whatever | 20:44 |
| lifeless | paroneayea: to remove a branch, rm -rf it | 20:45 |
| paroneayea | lifeless: but that won't remove it from the database? | 20:46 |
| LarstiQ | paroneayea: your pointer in the revision DAG is gone, but if you know the revision (tagged it, it's a head, or written it down) you can resurrect the branch | 20:47 |
| LarstiQ | paroneayea: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout 5.5.3, but I see that should be updated | 20:48 |
| LarstiQ | paroneayea: afaik it is possible to just use `bzr switch sibling` if the branch currently checked out is a sibling of where you want to switch to | 20:49 |
| LarstiQ | paroneayea: (if it was a standalone branch, it would be entirely gone) | 20:49 |
| lifeless | paroneayea: in git terms, the ref is contained in the .bzr/branch/ of each branch | 20:49 |
| lifeless | paroneayea: so rm -rf removes the ref; the revision won't propogate anywhere | 20:50 |
| lifeless | there is a gc plugin I think | 20:50 |
| lifeless | paroneayea: are you concerned that old branches will take up space? or get lost? or .. | 20:55 |
| Lo-lan-do | lifeless: Assuming I'm concerned about the space, is there already an answer? | 21:14 |
| LarstiQ | Lo-lan-do: it depends on the situation. Standalone branches? rm -rf the branch and the space is reclaimed. | 21:15 |
| Lo-lan-do | Nah, shared repository :-) | 21:15 |
| LarstiQ | Lo-lan-do: shared repo? Are there other branches using the same revisions? Then there is no space lost. | 21:15 |
| LarstiQ | Lo-lan-do: Shared repo and no branches use the revisions anymore? | 21:15 |
| LarstiQ | ah. | 21:15 |
| LarstiQ | Lo-lan-do: that would be the case where a `bzr gc` would make life easier. | 21:16 |
| Lo-lan-do | My potential use case is that I pushed a branch to the wrong repo. | 21:16 |
| * LarstiQ nods | 21:16 | |
| LarstiQ | Lo-lan-do: I'm not aware of anything that automates that much. | 21:17 |
| LarstiQ | Lo-lan-do: making a new repo and branching over what you want to keep is a bit of a hassle. | 21:17 |
| LarstiQ | Lo-lan-do: you're at fosdem, right? | 21:17 |
| Lo-lan-do | It can be scripted, probably, but I see. | 21:17 |
| Lo-lan-do | Not yet, but I intend to go, yes :-) | 21:18 |
| LarstiQ | Lo-lan-do: it shouldn't be hard to write up an initial version of that command. | 21:18 |
| LarstiQ | Lo-lan-do: right :p | 21:18 |
| LarstiQ | Lo-lan-do: so if you're interested in doing that, I suggest we work on that? | 21:18 |
| LarstiQ | Lo-lan-do: the remove-revisions plugin already does removal | 21:19 |
| Lo-lan-do | I never hacked bzr itself; if you think that might provide a gentle first step, then I'm all in favour. | 21:19 |
| Lo-lan-do | Then I may be able to help bzr-git :-) | 21:19 |
| LarstiQ | Lo-lan-do: I think it should be fine. | 21:20 |
| Lo-lan-do | Great :-) | 21:22 |
| lifeless | so the challenge in writing 'gc' correctly is prevent concurrent insertions into the db | 21:25 |
| lifeless | like git, bzr is multi-writer | 21:25 |
| lifeless | git uses the refs as a way to handle gc AFAICT | 21:26 |
| Lo-lan-do | Isn't there a repository-wide lock? | 21:26 |
| lifeless | Lo-lan-do: insertions are done in a 2-phase operation; phase 1 prepares the insertion, phase-2 commits it | 21:26 |
| lifeless | there is a lock for phase-2, but its short-lived, and doesn't prevent phase-1 | 21:26 |
| lifeless | so to do a gc, you need to: prepare a phase-1 operation that will insert a new pack containing the non-gc'd elements of all the packs that have things to be gc'd. | 21:27 |
| lifeless | other writers doing a phase-2 insertion before you will succed, so in your phase 2 you need to check you are not dropping anything referred to by packs added during the gc. | 21:28 |
| lifeless | its not terribly hard, but its plumbing not porcelain | 21:28 |
| lifeless | (if someone has added a ref, abort the gc) | 21:29 |
| * LarstiQ intended to be far less subtle in the first go | 21:29 | |
| lifeless | in fact, as a cheap start, you could simply abort the gc if the packs list has changed; that would be safe and correct-enough | 21:29 |
| LarstiQ | Lo-lan-do, lifeless: I sent a mail to the list stating our intention. | 21:30 |
| luke-jr | how do I get 'bzr merge' to do a real merge when cherrypicking? | 21:38 |
| luke-jr | it only wants to do a diff+patch for me ☹ | 21:38 |
| Lo-lan-do | luke-jr: I don't think it's doable right now. | 21:38 |
| luke-jr | -.- | 21:39 |
| lifeless | luke-jr: what do you mean 'real merge' | 21:39 |
| luke-jr | lifeless: one that 'bzr status' shows | 21:39 |
| lifeless | cherry picks don't join the graph | 21:39 |
| lifeless | by definition | 21:39 |
| luke-jr | "pending merges:" | 21:39 |
| lifeless | if you cherry pick adjacent to a merged revision, it will be treated as a normal merge | 21:40 |
| luke-jr | what does that mean? | 21:40 |
| luke-jr | I want to merge a bugfix from trunk.. | 21:40 |
| luke-jr | but I don't want to merge trunk's enhancements | 21:40 |
| luke-jr | seems like a pretty common use case | 21:40 |
| lifeless | and it should work fine | 21:40 |
| luke-jr | no, it just modifies the working copy and doesn't note it as a merge at all | 21:41 |
| lifeless | I think what you are missing is that 'log' doesn't show the merge revision, right? | 21:41 |
| luke-jr | I would hope merges are more than mere log changes | 21:41 |
| lifeless | merges do one thing with a few implications. They set the 'parent' pointer in the revision graph | 21:42 |
| lifeless | that pointer, as it is in git and hg and pretty much everything, is a transitive pointer in a DAG | 21:42 |
| luke-jr | … | 21:42 |
| luke-jr | whatever that means | 21:42 |
| garyvdm | lifeless: What will happen if you cherrypick a revision, and later try to merge it. Will you have a conflict, or does bzr know that it has allready been merged? | 21:42 |
| lifeless | garyvdm: our merge code tries quite hard to make that not conflict unless you further changed it | 21:43 |
| luke-jr | I just want it to show up as it would if I committed to the oldest valid branch and merged those upward | 21:43 |
| lifeless | luke-jr: ok, right now you can't | 21:43 |
| luke-jr | sigh | 21:44 |
| luke-jr | can I get the log to look as if I did? | 21:44 |
| lifeless | I was trying to explain, but you seem uninterested | 21:44 |
| lifeless | I'll be back in a bit | 21:45 |
| luke-jr | I just want it to work, I don't really care about the details as to how or why | 21:46 |
| LarstiQ | luke-jr: you could include the log messages of the cherry picked revisions in your commit, does that help? | 21:47 |
| luke-jr | LarstiQ: you mean manually? | 21:48 |
| LarstiQ | something like bzr ci -m "Merge bugfix foo.\n `bzr log -r x..y`" | 21:48 |
| luke-jr | sigh | 21:48 |
| luke-jr | guess that works | 21:48 |
| LarstiQ | luke-jr: what about that isn't good enough? Would you be satisfied if the commit included those log messages automatically? | 21:50 |
| LarstiQ | luke-jr: or, and this is why I'm asking and where lifeless was going afaics, do you actually require the revision graph to be altered there? | 21:50 |
| luke-jr | I have no clue wtf the reivison graph is | 21:51 |
| LarstiQ | luke-jr: ok. Could you then either explain what it is you want, or listen to an explanation of how things work? | 21:51 |
| garyvdm | Pending merges indicated that the revisions graph is going to have extra stuff.... | 21:52 |
| luke-jr | LarstiQ: I just want it to work as if I had made my changes in 0.1 and merged that into 0.2 and trunk | 21:53 |
| LarstiQ | luke-jr: the problem is, "as if I had made my changes" has lot of implications, most of them probably not relevant to you | 21:55 |
| LarstiQ | luke-jr: making it work that way requires a lot more effort, and hence will be finished on a larger timeframe | 21:55 |
| LarstiQ | luke-jr: knowing which parts you care about make it easier to do something about it. | 21:58 |
| davidstrauss | luke-jr: This is a highly dangerous approach to version control systems: "I just want it to work, I don't really care about the details as to how or why" | 22:00 |
| davidstrauss | luke-jr: It's like getting on the road without knowing traffic rules and only caring about "getting there." | 22:01 |
| garyvdm | "An SCM tool is not like a clock. Clock users have no need to know how a clock works inside. We just want to know what time it is. Those who understand the inner workings of a clock cannot tell time any more skillfully than the rest of us. | 22:01 |
| garyvdm | An SCM tool is more like a car. Lots of people do use cars without knowing how they work. However, people who really understand cars tend to get better performance out of them." - Eric Sink | 22:01 |
| LarstiQ | both not actually the thing at hand imo. | 22:01 |
| davidstrauss | LarstiQ: My point is that the question he's asking may not serve his long-term interests. | 22:02 |
| LarstiQ | without eloborating it is impossible for me to tell what luke-jr wants, not knowing requirements makes writing software hard. | 22:02 |
| LarstiQ | davidstrauss: good point | 22:03 |
| * LarstiQ needs to go to sleep | 22:03 | |
| LarstiQ | night | 22:03 |
| davidstrauss | LarstiQ: night | 22:03 |
| garyvdm | night LarstiQ | 22:03 |
| davidstrauss | lifeless: ping | 22:08 |
| lifeless | davidstrauss: hi | 22:09 |
| davidstrauss | lifeless: would you like the bzr.log from our beloved windows committed? | 22:09 |
| davidstrauss | committer* | 22:09 |
| lifeless | davidstrauss: uhm, remind me of the situation, I'm embarrased but its paged out | 22:09 |
| davidstrauss | lifeless: This is the smart server repo corruption we discussed last week | 22:10 |
| lifeless | oh yes | 22:10 |
| lifeless | the content-from-unmerged-rev one | 22:10 |
| lifeless | yes that log is a good starting point | 22:10 |
| lifeless | did we open a bug ? | 22:10 |
| davidstrauss | lifeless: how should i get it to you? | 22:10 |
| davidstrauss | lifeless: i don't think so | 22:11 |
| lifeless | either email me, robert@canonical.com | 22:11 |
| davidstrauss | lifeless: i think it would be wise to open a formal bug report | 22:11 |
| lifeless | or if we can open a bug, even a private one if there is other stuff in the log, and attach it there | 22:11 |
| davidstrauss | lifeless: nothing to hide here | 22:11 |
| davidstrauss | lifeless: this is all Drupal GPL development | 22:11 |
| lifeless | then a bug would be best | 22:12 |
| lifeless | as it lets other devs chime in | 22:12 |
| davidstrauss | lifeless: posting it now | 22:16 |
| lifeless | thanks | 22:19 |
| davidstrauss | lifeless: https://bugs.launchpad.net/bzr/+bug/324100 | 22:19 |
| ubottu | Launchpad bug 324100 in bzr "Content from unmerged revision breaks branch" [Undecided,New] | 22:19 |
| davidstrauss | I wish launchpad would assume the bugs I post "affect me too" | 22:20 |
| mwhudson | you could make the bug about that as affecting you i guess :) | 22:20 |
| mwhudson | s/make/mark/, sigh | 22:20 |
| davidstrauss | It would be awesome to have a Firefox plugin to browse bzr repositories when I click a bzr:// link. | 22:22 |
| lifeless | doesn't bzr-gtk install a bzr:// handler? | 22:23 |
| davidstrauss | It might, but I'm on OS X. | 22:23 |
| * garyvdm adds that to qbzr todo | 22:24 | |
| lifeless | ah | 22:24 |
| davidstrauss | I have an Ubuntu VM open, so I can certainly try it. | 22:24 |
| davidstrauss | How can I get a Bazaar sticker for my laptop? | 22:24 |
| lifeless | thats a good idea | 22:25 |
| lifeless | I don't htink we have them at the moment | 22:25 |
| davidstrauss | Or maybe a very covertly technical bumper sticker? | 22:25 |
| bob2 | "my other car's a version control system" | 22:25 |
| davidstrauss | bob2: Insurance would be cheaper if accidents had "uncommit" | 22:26 |
| lifeless | oh nice | 22:26 |
| bob2 | hah, that's close to NRMA's current campaign | 22:27 |
| === kiko-afk is now known as kiko | ||
| lifeless | spiv: http://launchpadlibrarian.net/21885424/bzr.log if you're interested | 22:40 |
| * spiv looks | 22:40 | |
| lifeless | 3.7MB | 22:40 |
| lifeless | davidstrauss: do you remember, I think it was rev 521 broke it ? | 22:42 |
| davidstrauss | lifeless: yes | 22:42 |
| davidstrauss | lifeless: that ought to go into the but | 22:42 |
| davidstrauss | bug* | 22:42 |
| lifeless | done | 22:42 |
| davidstrauss | lifeless: thanks | 22:43 |
| === spm_ is now known as spm | ||
| lifeless | beuno: is verterok around? | 22:44 |
| lifeless | spiv: I see update, status, info, commit-on-bound-branch | 22:46 |
| lifeless | but the update appears to be a no-op, checking further | 22:47 |
| lifeless | jelmer: would you consider making 4587.877 Unable to open <bzrlib.transport.local.LocalTransport url=file:///C:/Program%20Files/xampp/htdocs/drupal_test_7_fic/modules/field/field.form.inc/> with Subversion: Unable to open an ra_local session to URL | 22:47 |
| lifeless | jelmer: be only shown with -Dtransport? | 22:48 |
| === fta_ is now known as fta | ||
| lifeless | davidstrauss: can you get the user, to cd to C:/Program%20Files/xampp/htdocs/drupal_test_7_fic/ | 22:49 |
| lifeless | davidstrauss: and run | 22:49 |
| davidstrauss | lifeless: his repo has been overwritten with the fixed upstream one | 22:49 |
| lifeless | davidstrauss: damn, did he keep a backup? | 22:50 |
| lifeless | or did he overwrite using 'pull' ? | 22:50 |
| davidstrauss | lifeless: i'm guessing he ran "update" from my fixed repository | 22:51 |
| davidstrauss | lifeless: and that probably wiped out the troublesome revisions | 22:51 |
| lifeless | no they will be there | 22:52 |
| lifeless | so, 'bzr cat-revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py' | 22:52 |
| lifeless | this is assuming he did update/pull | 22:52 |
| lifeless | as long as he didn't rm the thing, they will be candidates for gc, but not actually removed | 22:52 |
| lifeless | davidstrauss: AFAICT there is no reason for his tree to have magically grown references to that revid | 22:54 |
| lifeless | davidstrauss: he hasn't run merge, in the timespan of the log | 22:55 |
| davidstrauss | lifeless: I'll ask him to run it. | 22:55 |
| lifeless | he has run update, but that will be grabbing from the master branch - he has a checkout, rather than a seperate branch | 22:55 |
| davidstrauss | lifeless: Actually, I'll ask him for a zip file of his working copy, including .bzr stuff. | 22:55 |
| lifeless | davidstrauss: good idea | 22:55 |
| davidstrauss | lifeless: Email is perhaps the highest latency remote shell in the world. | 22:56 |
| beuno | lifeless, hi! I don't see him on any of the normal channels of communication (plus, I'm in Brazil) | 23:00 |
| lifeless | beuno: trying to track down a nasty commit bug; I want to ryle out the xmlcommit etc commands | 23:00 |
| lifeless | davidstrauss: except on windows, where you can send them a script to run, and it will just run it :) | 23:01 |
| davidstrauss | lifeless: yes, but i can just copy his checkout to a windows VM I have | 23:01 |
| davidstrauss | lifeless: oh, just got the joke | 23:02 |
| beuno | lifeless, I haven't looked at the code since he did the rpc thingie. I'll poke him if I see him around. Is there a bug #? | 23:02 |
| lifeless | davidstrauss: :P | 23:02 |
| lifeless | 324100 | 23:02 |
| lifeless | beuno: ^ | 23:02 |
| * beuno looks | 23:02 | |
| spiv | lifeless: I don't see any obvious red flags in that log file. | 23:04 |
| lifeless | spiv: indeed | 23:04 |
| sproaty | whenever I use push and it asks for my password, I have to press "deny" first before it'll accept it | 23:04 |
| sproaty | I'm typing the same password 4 times, nothing - press deny then it'll work :/ | 23:04 |
| lifeless | sproaty: what url do you push to ? | 23:04 |
| sproaty | sftp://sproaty@bazaar.launchpad.net/~sproaty/whyteboard/development/ | 23:04 |
| lifeless | e.g. sftp/ftp/bzr+ssh/lp/ ? | 23:04 |
| spiv | sproaty: do you use some sort of SSH key agent? | 23:05 |
| lifeless | sproaty: ok, bzr itself doesn't manage passwords for tht | 23:05 |
| lifeless | sproaty: so its your OS/ssh client | 23:05 |
| sproaty | ah | 23:05 |
| spiv | Also, bazaar.launchpad.net's SSH/SFTP server doesn't ever accept passwords. | 23:05 |
| sproaty | well I used ssh to get some key to upload to launchpad | 23:05 |
| sproaty | so it's probably asking for key verification? | 23:05 |
| spiv | (And says so at the SSH protocol level) | 23:05 |
| davidstrauss | sproaty: It's probably your SSH key agent implementation. | 23:06 |
| davidstrauss | sproaty: actually | 23:06 |
| spiv | So if it's asking for your LP password, then your SSH client is buggy. Or maybe it's asking for a passphrase to unlock your private key, but it doesn't sound like it. | 23:06 |
| davidstrauss | sproaty: It's probably your SSH client making a crappy attempt to get a password instead of trying your key first. | 23:06 |
| davidstrauss | sproaty: Some broken SSH clients assume you'll always need to submit a password. | 23:07 |
| sproaty | OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 | 23:07 |
| lifeless | sproaty: what is the exact question it asks you | 23:08 |
| lifeless | sproaty: the title of the window, everything | 23:08 |
| sproaty | erm I dunno, I closed them...should I push again to see? | 23:08 |
| sproaty | well actually, don't want to commit a change with no changes | 23:08 |
| fullermd | Just trying to push (even when there's nothing to push) will make it try to connect. | 23:09 |
| davidstrauss | sproaty: your only other option is to leave us guessing | 23:09 |
| fullermd | Or pull, or missing. Doesn't much matter; it just needs to get as far as doing the SSH connection. | 23:09 |
| davidstrauss | sproaty: And I doubt this is a problem with your core OpenSSH implementation. It's likely a problem with some GUI wrapper. | 23:10 |
| sproaty | it seems to have saved the password for a while. | 23:10 |
| lifeless | sproaty: next time it comes up, grab a screen shot | 23:11 |
| sproaty | gotcha | 23:11 |
| lifeless | sproaty: then cut the dialog out of it and you can show it to us :) | 23:11 |
| sproaty | It did seem different to ubuntu's root password prompt thingy | 23:11 |
| davidstrauss | sproaty: as it should be | 23:12 |
| sproaty | :) | 23:13 |
| sproaty | I'm not sure what SSH client I have. | 23:13 |
| lifeless | theres a keychain thing in gnome these days | 23:14 |
| lifeless | I don't like it :P | 23:14 |
| sproaty | I may have installed one the other day | 23:17 |
| kfogel | I'm writing blackbox tests for some new status output, and noticed that assertStatus() and assertEqual() helpers (used in bzrlib/tests/blackbox/test_status.py) assume that status lines will be printed in a certain order. That is, even though bzr could often choose any order for path statuses to be printed, it seems as though the tests assume the order will always be the same. Anyone know if that's on purpose, or just an accident of how bzr i | 23:21 |
| kfogel | s written? | 23:21 |
| lifeless | sproaty: its there by default | 23:21 |
| lifeless | kfogel: assertEqual is deliberate | 23:22 |
| lifeless | I don't recall about assertStatus | 23:22 |
| lifeless | status doesn't do most things in arbitrary order though | 23:22 |
| kfogel | lifeless: assertStatus() is just a wrapper around assertEqual | 23:22 |
| lifeless | kfogel: could you expand on what you are doin | 23:27 |
| kfogel | lifeless: finishing issue #306394 | 23:27 |
| * kfogel waits for the bot | 23:27 | |
| kfogel | okay | 23:28 |
| kfogel | bug #306394 | 23:28 |
| ubottu | Launchpad bug 306394 in bzr "bzr status should not ignore all other command line arguments when passed a non-existent file" [Undecided,Confirmed] https://launchpad.net/bugs/306394 | 23:28 |
| kfogel | lifeless: see Ian's mail, referred to from a comment at the end of that bug | 23:28 |
| kfogel | lifeless: larger context: this is one of the bugs that was an annoyance for GNU Emacs; it's the least important of the bugs tagged with "emacs-adoption", but it's the one I can fix... and I hate to start something and not finish it :-). | 23:29 |
| lifeless | fair enough | 23:29 |
| lifeless | so why does emacs ask about unversioned files | 23:30 |
| mlh_ | a bit OT but do any DVCs support having the repo on one disk and the checkout/tree on another? | 23:30 |
| spiv | Oh man. This is like the mailing list thread all over again ;) | 23:30 |
| lifeless | mlh_: bzr does | 23:30 |
| mlh_ | oh nice | 23:30 |
| lifeless | spiv: the risk of going on leave is that you miss things | 23:31 |
| mlh_ | I thought'd have to hack it with ln -s /some/mirrored/disk/.bzr /some/fast/disk/.bzr | 23:31 |
| spiv | lifeless: :) | 23:31 |
| lifeless | spiv: right now there is at least one patch I'm really unhappy with in bzr; I'm feeling motivated to prevent more | 23:31 |
| kfogel | lifeless: I'm not sure. I prefer the new, non-aborting behavior anyway, so if it makes some Emacs VC maintainers happy too, then great. | 23:32 |
| spiv | lifeless: FWIW the thread started on Dec 23, and has "306394" in the subject, and was ~35 messages. | 23:33 |
| lifeless | spiv: so the import thing | 23:33 |
| kfogel | lifeless: oh, were you referring to this patch above ("...motivated to prevent more") | 23:33 |
| lifeless | kfogel: indeed | 23:34 |
| lifeless | kfogel: not saying its wrong, saying I have motivation to examine | 23:34 |
| lifeless | this is probably unhealthy | 23:34 |
| kfogel | lifeless: sure, understood | 23:34 |
| lifeless | cause mesh gatekeeping doesn't scale | 23:34 |
| spiv | lifeless: IIRC, Aaron was pretty skeptical about accomodating this behaviour (on the basis that emacs should just "bzr st" the whole tree?), but Martin thought it was reasonable. Hopefully I'm not misrepresenting the thread too badly... | 23:35 |
| lifeless | I'm with Aaron | 23:35 |
| kfogel | however, it might be better (for the future) if re-exams would happen before the implementor does the work... :-) (I.e., we had a discussion about it, rough consensus seemed to be that more of us want it than don't want it) | 23:35 |
| lifeless | whole tree status is much faster that status-per-file or status-per-dir | 23:35 |
| kfogel | spiv: I think Aaron's reasons had nothing to do with Emacs (as they shouldn't). | 23:35 |
| kfogel | I was arguing for the new behavior on the basis that it's better anyway, and I think those who agreed agreed on that basis. | 23:36 |
| lifeless | and in fact, status-per-dir is much faster than 'status-of-these-files-that-happen-to-be-all-in-the-same-dir' | 23:36 |
| spiv | kfogel: s/emacs/programs invoking bzr/ :) | 23:36 |
| kfogel | Aaron was arguing that it's worse, also independently of programs invoking bzr. | 23:36 |
| lifeless | kfogel: yes, and provisionally, I agree. | 23:36 |
| kfogel | lifeless: can you expand? | 23:37 |
| kfogel | (you mean you agree with Aaron, right?) | 23:37 |
| lifeless | kfogel: yes. | 23:37 |
| lifeless | kfogel: listing a path is an explicit request from the user that it's status be obtained | 23:37 |
| kfogel | lifeless: sure, we all agree on that | 23:38 |
| lifeless | you can argue then, that 'absent and never versioned' is simply the status of a named-missing-and-never-versioned-path | 23:38 |
| kfogel | lifeless: some people just think that "nonexistent" is a legit status, right | 23:38 |
| lifeless | but you can also argue that its likely a typo | 23:38 |
| kfogel | lifeless: in which case, instead of aborting the whole rest of their status, we can just print out the paths at the end with "nonexistent:" or "X" | 23:39 |
| lifeless | kfogel: we should still exit with error though | 23:39 |
| lifeless | kfogel: because status != 2 implies commit-is-safe | 23:39 |
| lifeless | kfogel: unpacking a little, 'status X not erroring implies commit X will not error either' | 23:40 |
| kfogel | lifeless: hmmm. Is that true/important? Do people or programs really behave that way? | 23:40 |
| lifeless | with the caveat on partial-commits-of-merges being a technical limitation we want to get rid of, not a ui goal | 23:40 |
| kfogel | lifeless: *nod* | 23:41 |
| lifeless | well, the more special cases, the harder the system is to learn, it becomes more modal and less inferrable | 23:41 |
| lifeless | currently there is a very strong mapping between what makes status error and what makes commit error | 23:41 |
| spiv | lifeless: https://lists.ubuntu.com/archives/bazaar/2008q4/051045.html is Martin's thoughts in that thread on exit status, btw | 23:42 |
| lifeless | spiv: yes, precisely | 23:43 |
| kfogel | lifeless, spiv: so you think error code 2 or 3? | 23:44 |
| lifeless | kfogel: 3 probably | 23:44 |
| kfogel | lifeless: (when you said "status != 2" earlier, I assumed you meant "status != 0"...) | 23:44 |
| kfogel | oh | 23:44 |
| kfogel | lifeless: nm | 23:44 |
| lifeless | 0 is no-change, 1 is changes, 2 is unrepresentable changes, 3 is error | 23:44 |
| kfogel | 0 is nothing changed, 1 is something changed, 2 warnings, 3 err | 23:44 |
| kfogel | right | 23:44 |
| lifeless | I'm fine with status doing additional work, but I do believe that status absent-unversioned file should be an error | 23:45 |
| lifeless | you can render that however you like | 23:45 |
| kfogel | lifeless: ret code 3 sounds reasonable to me | 23:45 |
| lifeless | but, and I suspect that this is in the thread somewhere, it should still look like an error to the user | 23:46 |
| lifeless | kfogel: why do you say status outputs in arbitrary order/ | 23:46 |
| kfogel | lifeless: if we use the current (in my branch) output, plus ret code 3, then we have: "non-existent is represented as just another status, but still returns error to retain the mapping with 'bzr commit' " | 23:47 |
| kfogel | lifeless: not arbitrary, just the same every time | 23:47 |
| lifeless | kfogel: you were expressing surprise or something | 23:47 |
| kfogel | lifeless: sort of. I was expressing surprise more that the test suite actually tests this behavior (for example, it could expect certain status lines in the output, but expect them in any old order... instead, it expects them in exactly a certain order). | 23:49 |
| kfogel | lifeless: well, also surprise at the actual order | 23:50 |
| kfogel | lifeless: for example: | 23:50 |
| kfogel | If I do 'bzr status --short FILE_B FILE_C' and they're both modified, they'll get printed in that order. But take off the --short, and they show up in the reverse order. | 23:51 |
| lifeless | kfogel: are those the exact file names? | 23:51 |
| kfogel | lifeless: well, the answer to that is complicated. | 23:52 |
| kfogel | Yes, in my tests (but my test has more changed than that). | 23:52 |
| kfogel | No, in the manual test I ran just now using README and INSTALL in the bzr top level. | 23:52 |
| kfogel | so try this: make trivial changes to README and INSTALL. Then do 'bzr status README INSTALL', then do 'bzr status --short README INSTALL'. | 23:52 |
| lifeless | kfogel: --short is a little odd there IMO | 23:54 |
| lifeless | but I never use it so shrug :P | 23:54 |
| lifeless | normal status is alpha output per dir | 23:55 |
| kfogel | lifeless: I've run into a bunch of idiosyncracies like that. I'm not sure the effort of detailing them all is important, but they surprised me. | 23:55 |
| lifeless | kfogel: well, you could alter --short to be alpha sorted rather than iterating the list it was given | 23:55 |
| kfogel | lifeless: I could, but ... opportunity cost. There are bigger fish to fry; even #306394 is a bit questionable in that regard, although it's so close that might as well just finish it. | 23:56 |
| lifeless | sure | 23:56 |
| kfogel | no one *really* cares about status output order, in real life :-) | 23:56 |
| mlh_ | lifeless: what's that feature called - standalone trees? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!