=== Logan__ is now known as Logan_ === SamB_ is now known as SamB === Peng__ is now known as Peng === gthorslund_ is now known as gthorslund [06:38] hey guys [06:45] is anyone online? [06:45] many [06:47] bob2, If I develop on my local enviroment and ocasionally want to push my modifications to the production server when i see fit.What is the best setup with bzr to do so? [06:47] And have a proper backup in case one of them goes down [06:48] are you sure you want to pick bzr? [06:49] and something like http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html [06:49] I was reffering to shared repository, where to place it how to work with it [06:50] no need to do that [06:50] how come? [06:50] because there's no need to do that [06:51] the thing you are after is the above link [06:51] but, well, be sure to think about whether bzr is what you want to use for this [06:51] i pretty much have to, all the addons are on launchpad and bzr is used to retreive them [06:52] i might as well use the same thing [06:52] what is? [06:52] is this all about drupal [06:53] openerp of the openobject framework [06:54] you'll probably want to talk to them directly [06:55] this is for a personal project [06:56] I had a module that was versioned with bzr, then i split the module into multiple ones and tried to move the bzr tree to include the rest of the modules [06:56] i ended up losing most of my work [06:56] I'd carefully consider 'able to get support' when picking a dvcs [06:56] well, obviously back thigns up before doing anything dangerous [06:56] regardless of what you're doing [06:56] should of thought of that sooner, i have some previous version but not the latest [06:56] and that sucks [06:57] but really really do consider "how easily can I get help" when picking a tool like a dvcs, especially if you don't have any experience with any of them [06:59] how complicated can it be for basic tasks i need? it's not like i'm merging branches or working with a big team [06:59] just need to backup and push my modifications that's pretty much it [07:00] yes [07:00] but tbh I'd suggest really thinking about it and picking something else [07:00] if you can't figure it out from the above docs [07:01] i don't imagine git being much easier [07:01] either way it's the terms that are really bugging me branch,repository,tree, working tree [07:01] but i'll figure it out sooner or late [07:01] r [07:03] it's not [07:04] but the problem isn't difficulty, it's supportability [07:05] what do you mean by that? [07:05] that you're going to continue to struggle [07:07] if it's not difficulty then why would i struggle? [07:09] ok then, best of luck [07:10] I'm asking because i don't know what you're refering to [07:31] :) [07:35] bob2, when moving files around in a versioned directory, are you supposed to add them with bzr add or can it figure out for himself that they have been moved? [07:36] Wiz_KeeD: if you're moving versioned files, better mention it to bzr with 'bzr mv old_path new_path' [07:36] but now that i did not to that, removing/adding them shouldn't be much of an issue should it? [07:36] Wiz_KeeD: if you forget to do that, you can still catch up before commit with 'bzr mv --after old_path new_path' [07:37] Wiz_KeeD: remove/add and mv are different [07:37] of course [07:37] remove/add is saying bzr: I don't care about the old one. I care about the new one. They are different files. [07:38] yes you are right [07:38] mv is saying: old and new are the same file, I'm changing its name [07:38] so bzr mv --after file.xml new_dir/file.xml [07:38] ? [07:38] please keep track of that so that if I do modifications to old in a different branch and merge it here, I want these changes to be carried over [07:38] Wiz_KeeD: yes [07:39] ok let me do that, thanks for the tip man [07:39] Wiz_KeeD: explicit is better than implicit [07:40] what do you mean? [07:40] can bzr move take multiple arguments? [07:40] Wiz_KeeD: 'bzr mv --auto' will try to guess what you did and should be reasonably accurate but you know better and you will always be right when saying which file/dir has been renamed [07:40] Wiz_KeeD: bzr mv --help [07:40] ahhh that what you were reffering to, i was looking at the manual for that [07:41] what if it's wrong, there must be a way to step back and do the explicit move yourself [07:41] yeah, 'bzr mv wrong good' [07:42] Wiz_KeeD: as long as you don't commit, you're free to change your mind [07:42] aluart/purchase_view.xml => aluart/view/purchase_view.xml (assuming this would have been an auto move and wrong, which is not_ [07:42] Wiz_KeeD: well, even after committing you can still change your mind... [07:43] vila i have a question...i have a production server where i upload my modules and they go into production.on my local machine i develop...what is the best possible setup to have for this environment to have proper backup on both machines and be able to push my modifications [07:43] ? [07:44] Wiz_KeeD: generally it boils down to: can you put the branch on the production server without fear of people accessing your source to read them or write them [07:44] yeah there's no problem for that [07:44] Wiz_KeeD: if you can, as bob2 mentioned, push_and_update is the most transparent way [07:44] bzr+ssh, it's secure and the server is not widely available [07:44] so i have to install a bzr plugin for that [07:44] a repository is not needed for this job? [07:45] Wiz_KeeD: if you can't, the bzr-upload plugin will upload the modified files without requiring a remote branch [07:45] is there any downside to the remote branch? [07:45] i did this setup before and just did bzr push :parent [07:45] Wiz_KeeD: repository and branch have different meanings in bzr, you generally should use and think about branches [07:46] Wiz_KeeD: (hold on, I'm trying to answer your questions in order ;) [07:46] Wiz_KeeD: a repository is where a branch will store the revisions that defines the branch history [07:47] Wiz_KeeD: a repository can be used by a single branch or by several branches [07:48] isn't the branch history stored in the branch itself? [07:48] Wiz_KeeD: when you use multiple branches that shares a lot of history, using a shared repository makes sense but is a conscious and explicit decision. If you don't do it, things will still work but each branch will consume a bit more disk space [07:48] Wiz_KeeD: no, the branch only stores a pointer to the most recent revision, the revisions themselves are in the repository [07:48] Wiz_KeeD: so, when dealing with branches, you rarely have to think about the repository which is an implementation detail [07:49] Wiz_KeeD: if you want to think about it, well, you think about it when creating it, knowing that creating branches in directorieS below the shared repo will use that [07:50] Wiz_KeeD: are things clearer about branches and repository ? [07:50] to get things straight...a BRANCH is basically a mirror-copy version of the original content [07:50] which is what defines the distributed version control system [07:51] a repository is a central location where information about versions and changes reside as you said [07:52] Wiz_KeeD: you can think of it this way, under the hood, there is no difference between a mirror-copy and the original content since they are both defined by a revision identifier [07:52] so when i'm able to see all the changes that have been done on my localhost, that means i copied the repository as well? [07:52] Wiz_KeeD: yes [07:52] ahh, starting to make sense [07:52] so there is no "master repository" [07:52] Wiz_KeeD: but again, things are clearer if you think about branches [07:53] Wiz_KeeD: there are branches, master or trunk or HEAD generally have a special social meaning: that's where people share a common definition of some code [07:53] Wiz_KeeD: people can be reduced to yourself ;) [07:53] what do you mean? [07:53] ahh [07:54] Wiz_KeeD: that you can put the same branch in different places, what you do with them is up to you and people using them [07:54] Is a branch a state of the code at any given moment? [07:54] Without the revision history [07:55] it is a state of the code at a given moment as well as the history [07:55] but you said branches don't hold revisions [07:55] maybe they hold some sort of identifier or tag or revision number [07:55] but no more? [07:55] Wiz_KeeD: exactly [07:56] starting to make sense here, thank God for your patience vila :)) [07:56] so by using that identifier, you're referring to the revision definition which also includes its parent revisions [07:56] when you do a commit, there is a single parent [07:56] when you do a merge, there are two parents [07:57] So the reason you guys suggested i use push and update is not to have two separate repositories just one on my localhost and one in the production environment? [07:57] and not one* [07:57] you can merge several parents at once and commit that, the resulting revisions will have even more parents but it's... rarely used [07:58] The thing is...if i have a repository only on localhost, and just push changes to a branch on the server [07:58] Wiz_KeeD: indeed, I asked you if you wanted a remote branch or not (the repositories will be handled for you so we can stop talking about them now) [07:58] What if something happened to my computer, how can i do reverts and see changes on the server? [07:59] Wiz_KeeD: suppose you lose your computer or needs to start on a different computer, [08:00] Wiz_KeeD: on the new computer you do 'bzr branch ' [08:00] and i'll have the full log of changes? [08:00] yes [08:00] i like using qlog for example [08:00] that's what dvcs is about [08:00] you have the whole branch history and you can work offline [08:01] you don't need access to the server anymore, hence distributed [08:01] whereas in a centralized vcs, you need access to the server to get access to the history [08:01] yeah i read about that [08:01] but that means the repository is copied as well if you can see all the changes [08:01] Wiz_KeeD: now, let's stop talking about repositories, that's not what we care about, we care only about branches [08:02] It's still a concept problem in my head that's why i keep bugging them [08:02] Wiz_KeeD: what we care about too is working trees [08:02] if branches are only a version of data at a given moment with a identifier [08:02] then it means that without a repository you cannot revert or see a full log [08:03] Wiz_KeeD: right, one repository will always be there [08:03] that's why i'm curious about the repositories and how they are created [08:03] ha ok [08:03] where? on the server? or with the branch? [08:03] Wiz_KeeD: both are possible [08:03] Wiz_KeeD: in the simplest scenarios, each branch has its own repository [08:04] "when you use multiple branches that shares a lot of history, using a shared repository makes sense but is a conscious and explicit decision. If you don't do it, things will still work but each branch will consume a bit more disk space" [08:04] yes [08:04] but if your history is small you probably don't care [08:04] let me look up the definition for a shared repository [08:06] ah this is it [08:06] Because all branches store all revisions and each branch is related to another branch at some version, you have a lot of duplicate revisions stored on your computer. [08:07] * vila nods [08:08] what were you trying to say about working-trees? [08:09] Wiz_KeeD: pedantically: branches don't store revisions, repositories do. But a branch is always associated with a repository. So you can safely forget the repository and think of a branch as revision pointer and a repository where this revision and its ancestry is stored [08:09] ahhh that makes much more sense [08:09] Wiz_KeeD: the working tree is where you work (doh ;), a working tree is associated to a branch [08:09] even with a shared repository, the actual repo is copied as well [08:09] Wiz_KeeD: yup [08:10] because if it waren't it wouldn't be a dvcs [08:10] If you had to use the repository from the server it would be a centralized version control system? [08:10] always needing the server to see changes, commit, revert [08:10] Wiz_KeeD: that is, when you pull a branch (or merge or whatever), the revisions involved are copied from the remote branch's repository to the local one [08:10] Wiz_KeeD: yup [08:11] slowly comming together [08:12] so the working tree (WT) also keeps track of the changes versus the branch it is associated with [08:12] confusing [08:12] bzr diff and bzr status will tell you what are these changes [08:12] another question about shared repositories, when there is a simple repository on the server, 3 people do a pull (branch initially) all make modifications [08:12] bzr commit will record these changes in a revision and makes the wt in sync with its branch [08:12] and then push to the server [08:13] Wiz_KeeD: the first to push succeeds [08:13] okay [08:13] then [08:13] Wiz_KeeD: the others are told that their branch has diverged [08:13] Wiz_KeeD: they cannot push [08:13] and they need to merge? [08:13] Wiz_KeeD: they have two choices [08:14] yes... [08:14] Wiz_KeeD: 1) they merge, commit and then they can push [08:14] Wiz_KeeD: 2) they 'bzr push --overwrite' [08:14] and kill the poor guy's work :)) [08:14] bastards [08:14] not kill [08:14] move it aside [08:14] overwrite it [08:14] yeah [08:15] but the pushed revision is still in the remote repo [08:15] ahhhhhhhhhhh [08:15] but the remote branch does not refer to it anymore [08:15] sweet sweeeet [08:15] now, the difference of this case if it's a regular repository or a shared repository [08:15] so push --overwrite is disruptive as far as the sharing is concerned [08:15] no [08:16] the branches matters here, the repo is still just a place to put revisions [08:16] *matter [08:16] http://wiki.bazaar.canonical.com/SharedRepositoryTutorial [08:16] Wouldn't it be great if they could all share the revisions they have in common? This is where shared repositories come into play. [08:17] yes, that's what shared repos are about [08:17] share in what way? [08:17] ha, good point [08:17] they are shared because all branches will add the revisions they need into it [08:18] and will also find the revisions they need into it [08:19] hmm [08:19] so if you have several local branches that at one point were the same remote branch, when creating or updating one of these local branches, you will download only the missing revisions from the remote branch (and its associated repo) [08:19] so it's not a separate entity [08:20] that makes sense [08:20] instead of downloading all the revisions that are part of the whole branch history [08:20] if you create a branch from scratch it will download all the revision anyway [08:20] now returning to my setup [08:22] there is no reason to make a shared repository you said [08:26] vila? [08:26] Wiz_KeeD: it's up to you, if you understand how it works and what are the fallouts, create one. If you doubts, use standalone branches and revisit that decision later. [08:26] *if you *have* doubts [08:27] Wiz_KeeD: if your history is small enough it won't really change your life [08:27] it's just me working on it, not 800 people around the world [08:27] I do tend to commit more frequently in order to prevent loss of data [08:27] Wiz_KeeD: good practice ! [08:28] Wiz_KeeD: especially if you also push often [08:28] Wiz_KeeD: because then you get a remote backup for free [08:28] Wiz_KeeD: and at the same time, a local backup of your remote [08:29] Wiz_KeeD: and if you want yet another backup, well, push your branch on yet another server ;) [08:30] I think i would do that vila [08:30] and it's nice that you do a backup of every revision until then, not just the lame backup of the last version [08:30] So i create a branch on localhost, push it to the server and maybe a 3rd one [08:30] over bzr+ssh [08:30] hello, I got the error can't delete ... because it is not empty in bzr... the documentation says that bzr can't resolve it and depends on the case etc ... anyone who could help me to fix it please? :) [08:31] what does push AND update do? [08:31] Wiz_KeeD: ha, back to wts [08:31] sure [08:31] hikiko: hi, can you wait a bit while I reply to Wiz_KeeD ? [08:32] hikiko's sounds more urgent, i can wait [08:32] i'm getting a free lecture anyway :))) [08:32] sure vila [08:32] Wiz_KeeD: so, if you have a remote branch, you don't always need the associated wt to be in sync [08:33] okay... [08:33] Wiz_KeeD: for example, if you push to that 3rd place, what you care about there is to be able to create a branch and a wt locally, you don't care about having a wt in that 3rd place [08:33] that is correct yes [08:33] Wiz_KeeD: but on your production server you *need* a wt [08:34] Wiz_KeeD: now, push will only update your remote branch but *not* the remote wt [08:34] this is just for pure backup locations, the non-working tree [08:34] Wiz_KeeD: to update the remote wt you can: [08:35] 1) connect to the server, do 'bzr update' after you've pushed. By pushing new revisions, you've changed the remote branch, now you want the wt to be in sync again with that branch [08:35] 2) use push_and_update that will do the above for you ;) [08:36] hikiko: have you read 'bzr help conflict-types' ? [08:38] So basically vila, when you push to a branch, it updates the branch information but the working tree (the actual state of the code in regards to the information stored in the branch) [08:38] is not updated [08:38] hence you must do update in order to bring the files to the state of the latest changes [08:38] Wiz_KeeD: exactly [08:38] what if you do, pull...modify something and then update [08:38] you lose your modifications? [08:39] Wiz_KeeD: hard question [08:39] Wiz_KeeD: you should never lose your modifications [08:39] and what does the checkout command do [08:40] wait [08:40] just read it now [08:40] Wiz_KeeD: but you may end up in situations when you don't know anymore what your modifications are because they are mixed with other modifications you asked for [08:40] Wiz_KeeD: bzr tries to protect you from that but obey your orders in the ned [08:40] end [08:41] haha indeed [08:41] Finally it's starting to make some sense [08:41] Wiz_KeeD: if you want to be on the safe side, bzr diff and bzr status will tell you about your pending changes [08:41] So having a branch with no working tree is useful only for pushing and pulling without doing actual development there [08:41] Wiz_KeeD: if you check those changes before issuing a bzr command that may change them, you should be sage [08:42] No working tree, no actual files are generated, just the bzr data [08:42] Wiz_KeeD: exactly [08:42] Why the hell don't they make a legend of some sort? [08:42] legend ? [08:43] A repository is the place where all changes are tracked in regards to branches, branches are a copy of the code as a set of instructions and revisions and a working tree is a physical representation of the branch information that generates the actual content from the branch [08:43] or something like that [08:43] So you know what is what... [08:44] So i could make a branch on a 3rd server without a working tree pull from it on my localhost and production server with working tree [08:44] and in order to do that i pull and checkout [08:44] if you do a pull it does update the working tree no? [08:46] Wiz_KeeD: yeah, if there is a wt... can be confusing but is generally what you expect [08:48] hmm [08:48] Wiz_KeeD: I think you're on the right track, if you understand what are a repo, a branch and a wt, you should better understand which command affect each part in which way. From there, using the right commands to match your workflow and the layout of your branches across your various PCs should become clearer [08:48] slowly but surely [08:50] i have a repository initiated on the production server [08:50] how can i remove that [08:50] just the repository, keep the files [08:51] Wiz_KeeD: now to understand what you mean here, I need you to properly use repo and branches when they are involved ;) [08:52] Wiz_KeeD: more to the point: [08:52] i have created a shared repository sorry [08:52] i did bzr init-repo dir [08:52] then bzr init dir [08:52] Wiz_KeeD: if you have a shared repo setup on the remote server and have created branches that use that shared repo you should NOT remove the repo or your branches will be broken [08:53] Wiz_KeeD: then you're good, keep going [08:53] well isn't creating a shared repository something we agreed was not neccesairy? [08:53] I did it because it says so here http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ [08:53] Wiz_KeeD: if you want your mind, use 'bzr info' on branches and repository to see how they are configured (you can also use 'bzr config' for that as long as you issue the command in the related directry) [08:54] Wiz_KeeD: it is not necessary but once you do it, references are kept in the branches [08:54] Wiz_KeeD: see 'bzr reconfigure --help' if you want to tell bzr what you want to change [08:56] Wiz_KeeD: in other words: 'bzr init-repo project ; cd project ; bzr init trunk' will create 'trunk' as a branch using 'project' as its repository [08:57] Wiz_KeeD: whereas 'bzr inti-repo dir; bzr init dir' will create a shared repo BUT the 'dir' branch will use that repo as ? [08:57] Wiz_KeeD: a shared repo or as branch's private repo ? [08:58] Wiz_KeeD: note that the tutorial says: 'bzr init-repo sample' and 'bzr init sample/trunk' [08:59] Wiz_KeeD: I don't remember precisely when they were fixed but at some point there were bugs in bzr if you used a shared repo as a branch's private repo, so double-check with 'bzr info' [09:00] Wiz_KeeD: and re-read 'bzr init-repo --help' to make sure you understand the different layouts [09:00] Wiz_KeeD: (I'm not saying you don't, just that I don't know if you do ;) [09:01] Wiz_KeeD: and many people (including me ;) had to learn it the hard way ;) [09:02] Wiz_KeeD: oh, and because it also helps me countless times, when in doubt, also use 'bzr missing' to understand how branches differ [09:03] Wiz_KeeD: and use 'bzr qlog' to understand what your branch's history is (qlog is provided by the qbzr plugin) [09:04] hikiko: 'bzr qlog' can also helps you understand why you end up with conflicts which is generally a good way to understand how to solve them [09:06] vila, sorry I was on a meeting, yes I just found a way to do it, not the best one it was just a hack [09:06] but seems to worj [09:06] hikiko: careful with hacks while resolving conflicts, they sometimes come back to hunt you :) But if you're out of trouble, good ! [09:07] i merged with a previous version, deleted using rm the directory that was causing the conflict then diff and patch and commit [09:07] and it seemed to work [09:07] hikiko: you didn't issue any 'bzr resolve' command ? [09:11] hikiko: anyway, if 'bzr commit' was happy and you didn't commit any file ending with '.THIS' or '.OTHER' or '.BASE' or '.moved' (you get the idea ;), you should be safe [09:11] hikiko: 'bzr st -c-1' should tell you [09:13] :D [09:13] yes everything is fine vila [09:13] thank you!! [09:13] hikiko: great, have a nice day ;) [09:13] you too [09:31] sorry i was away a second [09:33] hmm [09:33] i should remove the repository all together [09:34] vila, in case there is a branch on the server, i pull it, the server dies somehow and then i recreate it on the server [09:34] the initial branch from where it was pulled will be missing right? [09:37] still there vila? === ubot5` is now known as ubot5 [09:39] Wiz_KeeD: yes, it will be missing, your local branch will still refer to it in its branch.conf file (in the .bzr/branch directory) [09:39] dunno how good that is [09:39] in another tutorial it says if you do bzr branch branch then it makes a independent copy if you do bzr checkout it gets the actual branch that you will merge later on [09:39] Wiz_KeeD: 'bzr info' and 'bzr config' will tell you that, that's the parent_location config option [09:39] idk for my development case how it would be better [09:40] i guess a separate branch would be better, don't ask me why :) [09:40] Wiz_KeeD: that's true, at the time you did bzr branch and later bzr pull, your remote and local branches were in sync [09:40] Wiz_KeeD: if you want your local branch to refer to a different parent you should do: 'bzr config parent_location=` [09:41] Wiz_KeeD: or 'bzr pull --remember ' [09:41] hmm interesting [09:42] What would you do in this scenario vila? You have the modules that run into the framework on the production server, and you develop on your local server [09:42] You can test on local and push just when you want and you are sure it's okay [09:42] Create a branch on server, bzr branch on local then push and update? [09:42] yup [09:43] creating and keeping in sync as many branches you need to hold the framework and the modules [09:49] well 2 in this case i guess [09:50] Wiz_KeeD: you know better than me ;) If all modules are in the same branch and the framework in another, then yes, 2 should do [09:55] let me try that setup [09:55] does it make a difference where the "parent" branch is, so to speak? [09:56] now i have the shared repository and the branch in the same place [09:57] the best way to have just the branch and remove the shared repository out of the equation? [09:58] vila? [09:59] Wiz_KeeD: bzr reconfigure [09:59] --standalone [10:00] yup [10:00] bzr: ERROR: '/opt/openerp/extra/' is already standalone. [10:00] yet bzr info says repository branch: . [10:00] good then [10:01] how is it good, it says it's a shared repository still, no? [10:01] or not [10:01] ? [10:01] does it says 'shared repository: some_path' ? [10:03] *say [10:05] hmm [10:05] i guess not [10:05] though i did init-repo on it [10:05] should be ok then and i can push modifications [10:05] but you say it will not be updated unless i do update as well [10:05] or push-update [10:06] yes, try it, start with an up-to-date remote tree (bzr diff and bzr status outputs should be empty) [10:06] push from local [10:06] check bzr diff and bzr status again [10:06] do bzr update [10:06] i have to install the plugin? [10:06] check bzr diff and bzr status again [10:06] Wiz_KeeD: not yet [10:07] well i did bzr branch over bzr+ssh [10:07] made some changes, commited (or i should now) [10:07] Wiz_KeeD: now, install the plugin, push from local, check bzr diff and bzr status once more [10:07] i have to check a tutorial on how to install it [10:08] bzr branch lp:bzr- ~/.bazaar/plugins/ if you want to install from source [10:09] Wiz_KeeD: don't forget to remove the leading 'bzr-' which is illegal as a python module name [10:10] Wiz_KeeD: use 'bzr plugins -v' before and after the install to check [10:30] ah the plugin is on bazaar? [10:30] on launchpad sorr [10:30] what other options are there? [10:34] ugh bzr: ERROR: Parent of "/home/wiz/.bazaar/plugins/push_and_update" does not exist. [10:35] bzr branch lp:bzr-push-and-update ~/.bazaar/plugins/push_and_update does not work [10:36] hm, i had to create the directory myself [10:36] strange [10:39] vila, now i have to do bzr push-and-update :parent [10:39] right? [10:40] also setup a ssh key so i don't enter the password 20 times [10:43] Wiz_KeeD: yup, yeah, the .bazaar/plugins should be created manually. I think there is a bug about creating automatically but I don't remember the details [10:43] Wiz_KeeD: yup, setting an ssh key is the way to go [10:43] i created the plugins dir myself [10:44] * vila nods [10:44] YAY it worked so quick [10:44] ssh-copy-id user@example.com [10:44] :o [10:44] and that's it! [10:44] i use the same one for launchpad, should be good [10:45] i see it makes 3 ssh connections when i do bzr push-and-update [10:45] Wiz_KeeD: $HOME/.bzr.log may contain more details [10:45] Wiz_KeeD: lunch time here, bbl [10:45]