2008/10/27 Gustavo Machado Campagnani Gama <[EMAIL PROTECTED]>: > Hi, > > On Mon, 2008-10-27 at 14:21 -0500, Linas Vepstas wrote: > >> Over-write? I've been doing 100% of my development in main, >> based on the assumption that was the easiest, most sensible >> thing to do. I certainly would not want to see my (several months) >> worth of work over-written! >> >> Surely the words "merge" and "over-write" have very different >> meanings, I dislike the way they just got used as if they're interchangable. > > I'm not that stupid, Linas. Of course I'd push the 'main' branch with > another name before overwriting anything that you've committed. But yes, > you should rebase your latest changes from 'main' into 'staging', as > I'll have to do a "push --overwrite" when Dave wants me to push > 'staging' as 'main'.
OK, so maybe I am being stupid. What does the "bzr push --overwrite" flag actually do? It sounds to me like it *will* overwrite something. If the code can be merged cleanly, why is the --overwrite flag needed? I've not heard of this flag before, I am googling it now. Actually, google is not finding anything -- I don't see this documented anywhere. Do you have a URL that describes this? >> > Right. That's why Joel's changes, mine and hopefully your's too will >> > land in 'staging' first. >> >> 100% of my changes go into the "main branch", since >> that is the "main" branch. Right? Given what I am working >> on, it doesn't make sense for me to use any other branch >> than main. > > Well, I'm sorry if you don't like the names -- I don't either -- but > it's been stated over and over that people should be branching their > work off of 'staging'. I don't know what has been said "over and over", and I don't know what it means to say "should be branching off of staging". What should be branching what off of which staging, where? I work with *two* bzr repositories: the "main branch", which is hosted at launchpad, and my personal staging branch, which is located on my personal machine. I rebase my personal branch from main every day, and I push to main every day. I do not push to main *until* my staging branch has been tested, and works well. Last time we had this conversation, it was noted that there were 20-25 different staging branches registered on opencog. Many of these proved to be stale. It was recommended that the stale branches should be deleted. It looks like they were, and that now we are down to four branches, called "trunk", "framework", "freecore" and "opencogprime" This is what I currently see listed at https://launchpad.net/opencog I do not see any other registered branches. I commit to trunk. I assume that you and Joel are committing to one of these other branches. The problem that Joel was having is that trunk (which is where I commit) has gotten out of sync with one or more of these other branches. The goal of this email thread is to ... resolve this? >> Yes, but the work on PLN doesn't/shouldn't require any >> changes to other, existing, code in main and so, therefore, >> I see no reason why PLN could not have been done in >> the main branch. > > Sigh. Because everyone should be working from 'staging'. Joel has just > followed the policy. So have I. Maybe the problem is with the word "staging". I have a staging branch on my machine. You have a staging branch on your machine. We are all staging. However, there are only four branches that are registered on launchpad. These are "trunk", "framework" "freecore" and "opencogprime". I am commiting to my own personal staging branch, and then pushing to "trunk". You and Joel are committing to your own personal staging branches, and are pushing to ... one of these other three!? >> But you imply that its bad to merge into the main branch? >> You're comments, above and below, imply that "main" is not >> "main" any more, and that there is a new "main", which >> is called "staging". > > Yay. You seem to have understood it now. :-) Heh. I still misundertand. Are you being sarcastic? >> Yes, exactly! And that is *exactly* why the staging branch >> should be rebased on main *daily*! > > Yes, sure. I'll spend 90% of my time resolving conflicts of code I don't > fully understand. That should be very productive. I assume you are being sarcastic, right? Sooner or later, everybody who is writing code for opencog needs to resolve thier changes against the main branch. When they are done resolving thier changes, they push to main. If you are using bzr correctly, for example, using "bzr rebase" instead of "bzr merge", this should take just about one minute a day, and you should be having exactly *zero* conflicts. The only way that conflicts can occur is if two people edit the same file at the same time, and fail to rebase often enough. Conflicts can be resolved by exchanging email, for example, you asked me not to commit any changes to the directory "atomspace" any more, and so I have not. I'd like to point out that I have been waiting for many months for you to merge your code back in, and you still haven't. It is unfair of you to make such a request, and then make me wait for months. I, too, wish to change code in that directory. I do not want to have to wait months to do so. I believe that rebasing daily or weekly would help resolve this kind of conflict! At any rate, it should not take "90% of your time", it should take about a minute or two a day. This is hardly an unreasonable demand. > 'staging'. Once again: I don't like the names either, but I don't find > it so hard to understand the current policies just because of this. OK, we need different names From now on, we should talk about the four branches that have been published on launchpad: "trunk", "framework", "freecore" and "opencogprime". You and Cassio keep talking about a policy, as if some policy actually existed. But no one has ever written down a policy, and the last time we discussed it, the conversation just sort of died out, where everybody just sort of agreeded that everything would merge in some big and happy way. > Others seem to be on the same boat. Heh. --linas _______________________________________________ Mailing list: https://launchpad.net/~opencog-dev Post to : opencog-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~opencog-dev More help : https://help.launchpad.net/ListHelp
