=== fawek_ is now known as fawek [00:51] I have a question about using the contrib/bzr_access script [00:51] Invocation: bzr_access [00:51] do you have to call this with every user? [00:52] I'm confused about the "user" param; I though the config file would handle the user stuff [00:59] I guess it get it now, when a user logs-in the bzr_access command is ran === dereine is now known as dereine[OFF] === Spaz is now known as IRS === IRS is now known as Spaz [07:07] 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] I did a Merge, but it says Nothing to do. so that makes me thing that's not correct. [07:12] $ bzr push [07:12] {shrug} We don't really do centralized development, so I don't know what the User Guide is recommending about that these days. [07:13] yeah I tried a push, but that gave me conflicts. [07:13] What format do you all use then ? [07:13] I'm just one guy trying to work at 2 computors. [07:14] so i commit then i push. okay. hmmm [07:15] 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:16] gotcha. I'm still working through the terminology a bit here. [07:16] 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:17] this is my first foray into any of the VCS programs at all. [07:17] 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:18] (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] 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] um [07:18] haa [07:18] you get a branch from the server [07:18] i don't liek that um. [07:18] okay. [07:18] you then make changes [07:18] you commit [07:19] im with ya so far. [07:19] you can then push to the server. [07:19] HOWEVER [07:19] if the server has since diverged from when you branched, [07:19] then you cannot push [07:19] (or, if you were sitting on the server, you could not pull) [07:19] was that my conflicts that I got? [07:19] and (again, from the server side) you would have to do a merge instead of a pull [07:19] beekor: probably [07:19] k [07:19] hmm. [07:20] Now. Bazaar has a notion called "bound branch" which you can (perhaps deliberately, perhaps inadvertently) create with [07:21] $ bzr checkout [07:21] instead of [07:21] $ bzr branch [07:21] the *only* difference [07:21] between the two (bound in the first case, unbound in the second) [07:21] 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:22] which turns out to be the "centralized" model we're used to from CVS. [07:22] for people who are accessing our public 'mainline' for which not a one of them have write access to, [07:23] this means that they in effect get a read-only local copy [mirror, even] of the upstream project. [07:23] they can then branch that locally to have a copy they can work in. [07:23] This tends to be a useful approach [07:23] 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:24] beekor: http://java-gnome.sourceforge.net/4.0/get/#source describes this, although it may not be interesting to you [07:24] beekor: other than this bound bit [07:24] (and it literally is a boolean, there's nothing else on disk that differentiates them) [07:24] there is no difference between a checkout and branch. A "checkout" in Bazaar *is* a branch [07:24] with some extra constraints thrown in [07:24] okay. [07:25] (and you can always unhook that constraint with [07:25] $ bzr unbind [07:25] ) [07:25] so the real issue [07:25] is deciding how you want changes to flow. [07:25] this has little to do with Bazaar, actually [07:25] if you are only moving changes (ok, revisions, actually) [07:25] now, i should only have to checkout/branch initially. after that, i stay updated with Merge. is that correct ? [07:25] in one direction [07:26] 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] then a local branch bound to the remove one will do you fine. [07:26] there were a lot of "always" in that last sentance. [07:26] ha. [07:27] If you're working independently on both sides then you'll have to be more careful [07:27] s/careful/deliberate/ [07:27] but if you only ever work locally and are just pushing deltas up to a server [07:27] then a) no need for it to be a checkout and b) push will always work [07:27] okay. [07:27] [or, ssh server && bzr pull] [07:28] [assuming access works in the other direction, which it usually doesn't] [07:28] So that's about all you're getting out of me pro bono. [07:28] If you think about all that you'll probably find your way. [07:28] 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:29] well that's a lot of free info, i'd say. [07:29] not a lot that I understand at this point, but that's my issue. [07:30] i will save this conversation and refer to it laterwise. [07:30] thanks for the help. i do appreciate it. [07:30] beekor: one last thought: people tend to overcomplicate things. [07:30] hahaha. === 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] [15:11] Anyone know a good introductory screencast for bzr? (and yes I googled) [15:14] nielsbom: emmajane might have done one [15:14] LarstiQ: I saw those two :) [15:15] They were good, but I would like some more. [15:16] nielsbom: what would you like to see? [15:16] * LarstiQ attempts flashing his bios [15:16] LarstiQ: well I have trouble visualizing/envisioning how bzr merges files [15:17] LarstiQ: and I'd like to know how it works before I start using it :) [15:20] nielsbom: perfectly? ;) [15:21] LarstiQ: well somewhat :) [15:21] LarstiQ: I can stand a bit of black-boxxines [15:21] nielsbom: do you understand how 3 way file merges work? [15:22] garyvdm: nope [15:22] LarstiQ, ping [15:22] 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] nielsbom: This explains it nicely in the context of vcs [15:22] http://www.ericsink.com/scm/scm_file_merge.html [15:22] (just ftp?) [15:23] LarstiQ, can you check whether bug 320113 is fixed? [15:23] 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] jelmer: I can. [15:23] jelmer: do you want me to do that now? [15:23] LarstiQ, yeah, if possible [15:23] LarstiQ, I'm pondering about releasing 0.5.0 today [15:24] nielsbom: You can push your revisions to ftp, but it won't update the working tree in the ftp dir [15:24] nielsbom: just ftp works, although it is ahorrible protocol, use sftp if you can [15:24] jelmer: ok, let me see [15:25] jelmer: I don't suppose you can help me flashing my bios? ;) [15:25] 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] LarstiQ, you're still trying to do that ? :-) [15:25] nielsbom: you can use the upload plugin to upload a tree. [15:26] nielsbom: Note that this is not a working tree - so you shouldn't edit the tree, and you can commit it. [15:27] garyvdm: can or can't? [15:27] Sorry - can't [15:27] right [15:28] nielsbom: It works well if you are using bzr to vc a website. [15:28] 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] No SFTP or SSH access? :X [15:28] nielsbom: Just use upload. [15:28] garyvdm: yes I want to VC a website [15:29] jelmer: different laptop [15:29] 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] nielsbom: bzr-upload [15:30] Ow and I might have SSH to my server, that would simplify matters, right? [15:30] jelmer: do I need a new version of rebase too? [15:30] nielsbom: yes [15:30] LarstiQ, yes [15:31] 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] nielsbom: Yes - if you have ssh access - then use https://launchpad.net/bzr-push-and-update [15:32] jelmer: the last commit of rebase is funny: 'Fix bug #.' [15:32] nielsbom: If you have SSH access and bzr is installed (or you can install it, which should be easy enough). [15:32] nielsbom: At the very least, SFTP > FTP, even if (with bzr) there isn't any difference. [15:33] garyvdm: just checked: no SSH or SFTP [15:34] garyvdm: my host is pretty cheap, so no wonder [15:34] Cheap isn't an excuse for that. [15:34] jelmer: could you not raise a bare ImportError in check_subversion_version()? [15:34] Peng_: true... [15:35] Wait, I'm still paying like $7 a month for some SSHless web hosting account I haven't touched since 2006... [15:35] garyvdm: but after I upload a tree to my server using FTP, how can I change that to be the working tree? [15:35] Peng: $7 is quite a lot [15:36] Peng_: I pay EUR 25 a year and I get quite a lot (but no SSH) [15:36] jelmer: KeyError: 'svn-v4:cd2972fe-eb09-0410-94ea-d8feb256cc61:trunk/kmx:8048' [15:36] nielsbom: That's on top of the $30 for non-sucky hosts I do use (mostly). :P [15:36] nielsbom: You don't need to make it a working tree. [15:37] Peng_: ouch, but then again, you probably make some nice $$$ or :) :) :) of off it too, right? [15:37] nielsbom: Certainly not. But it's fun! [15:38] garyvdm: is that because the upload plugin just uploads it without the need for there being bzr on the server? [15:38] nielsbom: bzr-upload will uploads the dirs/files that are the latest version in bzr to your ftp dri [15:38] Peng_: if it's worth it, it's worth it [15:38] nielsbom:yes [15:38] garyvdm: ok now I understand, thanks [15:39] https://launchpad.net/bzr-upload [15:39] 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] nielsbom: [15:40] nielsbom: I'd recommend seperating versioning from deployment. [15:40] nielsbom: No - there is a solution for that. [15:40] LarstiQ, what should I do instead of raising an importerror? [15:40] jelmer: fold the warning into the importerror? [15:41] jelmer: ie, raise ImportError("Need at least subvertpy 0.6.1, got 0.6") instead of raise ImportError [15:41] jelmer: that way I can see what is wrong just by looking at the stacktrace. [15:42] 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] nielsbom: having live and testing servers is good practice. [15:43] nielsbom: but I'd personally commit locally and deploy to testing from there, as well as deploying to live from there. [15:44] LarstiQ: So code and commit locally. Deploying to test: local --> test. Deploying to live: local --> live. [15:44] nielsbom: that is what I would do, yes. [15:45] LarstiQ: ok understood, thanks for your help, and garyvdm: too! [15:45] LarstiQ, fixed [15:45] *glomp* [15:45] LarstiQ: that implies nielsbom would become a gatekeper? [15:46] garyvdm: I'd keep that workflow for everyone involved. But maybe it can be done better? [15:46] garyvdm: well unless other people also have the right to upload to live right? [15:46] LarstiQ: or should he have a rule that uploads must be from the central repo? [15:48] garyvdm: I'll try top rephrase [15:48] the point I find icky is versioning a 'live' (test in this case) site directly, instead of using a deployment mechanism [15:50] LarstiQ: do I understand correctly that you advise against using bzr as a deployment tool (my sites aren't that critical btw) [15:51] LarstiQ: (question mark) [15:54] nielsbom: not exactly. The bzr-upload plugin I find is a good deployment tool. [15:54] nielsbom: you are correct that I wouldn't have any bzr branches there. [15:55] 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:56] 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] Then use the bzr-upload --auto option on each of those branches. [15:57] So when a dev pushes to say your test branch, bzr-upload will upload the latest version of that branch to your test server. === fawek_ is now known as fawek [15:59] LarstiQ: why? [16:02] garyvdm: I'm in fullermd's camp. Our minds seem to require a more formal division between versioning and deployment. [16:02] garyvdm: I think I understand :) [16:05] * garyvdm thinks deployment control requires versions control - thats why old version control systems were called "software configuration management" [16:09] requires != is :) [16:11] deployment branches ftw [16:32] LarstiQ, still there? [16:32] hi abentley [16:33] jelmer: yes [16:38] LarstiQ, what happens if you try with the patch in http://samba.org/~jelmer/tmp/assert.diff applied? [16:41] jelmer: the assert is triggered [16:42] LarstiQ, can you change it to return None if has_revision() returns False ? [16:43] and then run it I assume :) [16:44] yup, that's the idea [16:44] jelmer: it completed [16:44] * LarstiQ runs missing against his fresh 0.5 branched copy [16:45] <3 meta VC on a VC project :-) [16:46] jelmer: hmm, now missing blows up [16:46] LarstiQ, how? [16:46] File "/home/wouter/.bazaar/plugins/dev/svn/mapping3/__init__.py", line 293, in _parse_revision_id [16:46] return (uuid, branch_path, int(srevnum), scheme) [16:46] ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade' [16:46] jelmer: which is the revision we were having trouble with [16:48] LarstiQ, What argument are you specifying to svn-upgrade? [16:48] jelmer: right, other operations blow up as well [16:48] jelmer: nothing [16:48] just `bzr-experiment svn-upgrade` [16:49] LarstiQ, what is the pull location of that branch? [16:49] jelmer: svn+ssh://source/home/wouter/tmp/kmx_svn/trunk/kmx [16:52] LarstiQ, so the strange thing seems to be that that revision should exist in the svn repository but it doesn't [16:55] jelmer: Hi. [16:55] jelmer: I'm not entirely sure what you mean with that. [16:56] jelmer: obviously svn rev 8048 exists. [16:56] LarstiQ, and that was a round-tripped revision? [16:56] jelmer: the bzr-svn metadata, I don't know how that meshes. [16:56] jelmer: yes [16:56] jelmer: from 0.5 [16:56] LarstiQ, ah, I think I understand what the problem is here [16:56] jelmer: and I can make fresh branches with 0.4 and 0.5 both, that is not an issue. [16:56] jelmer: ok :) [16:56] hey jdub! [16:57] Hi Jeff [16:57] morning [16:57] hey jelmer [16:57] jdub: that's a long time ago. [16:57] abentley: heya [16:57] thanks heaps for fixaging that bug :-) [16:57] LarstiQ: Hey. [16:57] abentley: you mentioned we should talk? [16:57] LarstiQ: Yeah. [16:57] jelmer: the fix has prompted me to ask for a tip though ;-) [16:57] jdub: Np, thanks for bringing it to my attention before I released 0.5.0 [16:57] jdub, uhoh [16:58] I'll be working on Nested Trees once I finish what I'm currently working on. Maybe this week or next. [16:58] abentley: ok [16:58] LarstiQ: I didn't realize you were working on them too. [16:58] 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] jelmer: how do i do that sanely? :-) [16:58] LarstiQ: Where are they at? [16:58] abentley: I hadn't been, but recent requests prompted me to start looking again. [16:59] LarstiQ: Ah, okay. [16:59] LarstiQ: There does seem to be a lot of interest. [16:59] abentley: haven't actually done much since yet, other than paging code into my head and fixing some conflicts. [16:59] abentley: well, and looking at scmproj [17:00] jdub: the bzr branch basically contains the svn branch with some extra bzr revisions on top? [17:00] jelmer: yeah [17:00] LarstiQ: Yeah, I'm going to be looking at svn externals to try and see what they did right and wrong. [17:00] abentley: cool [17:00] jdub, backing up that bzr directory and then running "bzr svn-upgrade " should fix that [17:00] ahar [17:00] ok, will try [17:00] ta :-) [17:00] LarstiQ: Should we try to work together on this? [17:01] 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:02] Thanks. It will certainly be a great help to start from your fixed-up version. [17:02] jelmer: hrm, what should that url be? [17:02] abentley: I'll try to get a recent bzr.dev merge done this week [17:02] jdub, the URL of root of the subversion repository [17:02] LarstiQ: Cool. [17:03] jelmer: so one level above trunk? [17:03] jelmer: the repo root, or the branch root? [17:03] repository root [17:03] yeah, generally that would be one level above trunk [17:03] eg. bzr svn-upgrade http://svn.automattic.com/wordpress/ ? [17:03] "svn info " will tell you the repository root [17:04] jdub, yep [17:04] 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] ok, i get sweet traceback action :-) [17:04] abentley: move is still having problems atm [17:04] LarstiQ: Also, a new branch format with a better mechanism for specifying the locations of nested trees. [17:04] * LarstiQ nods at abentley [17:05] LarstiQ: Ah, okay. [17:05] jdub, whoa, can you please pastebin the traceback? [17:05] 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] jelmer: ah, ok [17:05] http://pastebin.ubuntu.com/112494/ [17:06] We'll probably want to split it up into a loom, so that the patches aren't crazy-long. [17:06] abentley: that sounds good, I'll need to lookup how to work with looms. [17:07] jelmer: oh, my rebase is up to date with trunk [17:07] as of just before this discussion ;-) [17:07] jdub, Do you have the latest bzr-svn? [17:07] LarstiQ: Looms aren't very good for collaboration at this point, so that's probably a task for one person. [17:07] 0.5.0~rc2-1~bazaar1~intrepid [17:08] We should quickly get back to having a branch with unmergeable changes, and then we can work on that. [17:08] (using bzr and friends from the beta ppa) [17:08] 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] jelmer: can i just check that out into .bazaar/plugins as with rebase? [17:08] jdub, yep [17:09] hmm, deja vu - didn't you also run into svn-upgrade bugs at the last major release of bzr-svn? [17:09] abentley: ok [17:10] yeah, but they were beyond fixage due to local braindamage [17:10] so i dumped those [17:10] oh, and this is actually a different repo (wp.org rather than wpmu) [17:10] jelmer: make a not in the bzr-svn release docs, 'ask jdub to give it a testrun'? [17:11] note, bweh [17:11] edge case is my middle name(s)! [17:12] 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] LarstiQ: So, making working trees not automatically detect nested trees, and fixing the sha1-rewriting issue. [17:13] jelmer: oh rock! that was fixed and fast :-) [17:13] jelmer: thanks heaps [17:13] jdub: np [17:13] LarstiQ, I also found the real issue behind your bug [17:13] abentley: this eek you mean, or after we're at a state of unmergeable changes? [17:13] jelmer: is it fixed yet? :) [17:14] LarstiQ: I think after the unmergeable changes, but it's fluid at this point. [17:14] k [17:14] ooh, this is interesting: [17:14] jdub@sliver:~/src/wordpress/wpsu/masspress$ bzr unshelve 1 [17:14] M wp-content/plugins/vipers-video-quicktags/vipers-video-quicktags.php [17:14] bzr: ERROR: A nested progress bar was not 'finished' correctly. [17:15] 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:16] abentley: no, it's not accurate. [17:16] abentley: agreed on the breaking up work, claiming, and public progress report. [17:17] abentley: I don't think the page has drifted too much [17:17] LarstiQ: Okay. If you could polish it, that would be helpful, since you know the current status better than me. [17:19] abentley: I will need to keep paging things into my head. I'll start with updating the current devel branch location. [17:20] jelmer: thanks again... night all! [17:20] LarstiQ: Thanks. [17:23] hi guys. I'm getting "bzr_log.TAqjxu~" style files in my working copy every time I commit [17:28] LarstiQ, please try again with current bzr-svn [17:29] CaMason: any other warning/error? Hints in ~/.bzr.log? [17:36] LarstiQ, (throwing away the previous branch created with svn-upgrade) [17:37] jelmer: yeah [17:37] jelmer: still get ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade' [17:38] LarstiQ: Is this in a completely new repository, etc? [17:38] jelmer: good catch [17:39] branching outside of that repository now [17:42] how can i undo the last commit? [17:42] ronny, bzr uncommit [17:44] thx [17:47] jelmer: svn-upgrade, completes, log doesn't give any errors, but missing blows [17:51] hi [17:51] quick & noob question (again) :P : well I've two branches @local: mainline and working [17:51] I work on working and then merge into mainline and then do push on mainline [17:51] now I want my working branch to become the main branch [17:51] to avoid commiting with same messages twice [17:51] How can I do that ? and thanks [17:52] cd mainline [17:52] bzr pull ../working [17:53] If I understand you correctly [17:53] garyvdm and then I can delete mainline by rm -rf mainline right ? [17:53] ehm [17:53] No - Ok - I thought you wanted to do this once off [17:54] garyvdm well please let me explain again (sorry I've a small experience with DVCS) [17:54] Goundy: are these two the only branches in play, or are there more? [17:54] that's why I'm getting hard to explain what am doing. Well I'll reexplain :P [17:54] LarstiQ am going to reexmplain :P [17:54] I've a branch on launchpad it's called: aures [17:54] and it's a development branch. [17:55] at first I did checkout on this branch to get a local copy [17:55] and then I did: bzr branch aures working [17:55] So I always work on "working" (useless yea :/) [17:55] and then I do: cd aures && bzr merge && bzr push [17:55] So I use working when coding and I use aures to push up [17:56] So now I want to be able to do PUSH through "working" [17:56] and I want to kick out aures [17:56] cd working [17:56] (kicking local aures and not these on launchpad) [17:57] bzr pull ../aures (to make sure that you have the latest in working) [17:57] cd .. [17:57] rm aures [17:57] errr rm aures -r [17:57] yea [17:57] that's all ? [17:57] cd working [17:58] bzr push lp:aures [17:58] deleting aures on you hdd won't touch whats on lp [17:58] that's all [17:58] garyvdm doesn't work man :/ [17:59] it recreated the branch aures when I did push >_< [17:59] ok - you will need to do this the first time: [17:59] bzr push lp:aures --remember [18:01] garyvdm rox ! thank you very much === fta_ is now known as fta [18:02] Pleasure Goundy. [18:02] :) [18:02] bazaar is really > svn [18:03] damn, what a powerful release >_> === lamont` is now known as lamont [19:51] whoa. bzr selftest has the tests specified just by prefix, e.g.: [19:51] LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v test_status 2>&1 | sed -e 's/^/[ascii] /' [19:51] runs all the tests whose names begin with "test_status", such as test_status_nonexistent_file() [19:52] kfogel, I think the argument is a regex [19:53] jelmer: ah, that's possible too, let's see [19:53] LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v 'status_.*existent' 2>&1 | sed -e 's/^/[ascii] /' [19:53] yup [19:53] that runs the same test [19:53] jelmer: oddly, though, it seems to run the same test twice. [19:53] e.g.: [19:53] kfogel: Is the name exactly the same ? [19:54] * kfogel waits for test output to appear [19:54] jelmer: oh [19:54] it can be running the test against two different bzr formats [19:54] never mind [19:54]