opencog-dev team mailing list archive

["Linas Vepstas" <linasvepstas@xxxxxxxxx>]

2008/10/27 Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>:
> 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