Sure, there's certainly an element of subjectivity here. Sometimes it doesn't even make sense to merge at all, for instance in the case where you add a workaround to alpha and then do a more elegant redesign in the main line. I just think we should merge in changes as soon as possible, and avoid doing a massive rollup at the end.
Rich


Michael Merz wrote:

Well, I was wondering where the changes would go initially -- alpha or
trunk.

I personally like checking in things in small chunks. So if a change
involves several areas, I'd rather wait until all the work involved has
been completed and then do a single merge for that particular change.

Merging right after each check-in sounds like quite some overhead;
merging on a regular basis to keep alpha and trunk from drifting too
far, however, is definitely fine by me; makes sense, too :)

In the end, when we do the release, we'll need to make sure that all
changes that are meant for both alpha and trunk are actually in both
branches.

Cheers,

-michael

PS: In our (WSM) case, practically all changes would go into both trunk
and alpha. Thus, for WSM the merge shouldn't be all that tough anyway...
shouldn't... :)

-----Original Message-----
From: Carlin Rogers Sent: Friday, October 29, 2004 11:21 AM
To: Beehive Developers
Subject: Re: V1 Alpha Branch created


-1, sorry ;-)

Just wondering why we wouldn't have developers go ahead and
merge their alpha changes in to the main line trunk when
they commit?

Waiting until the end might be create a difficult merge where
conflicts in code occur. Also the one person performing the
merge would need to be very familiar with the code base and
all the other developer changes to resolve conflicts... or
would need to coordinate the merge with multiple people.

Just a thought.
Carlin


Heather Stephens wrote:



+1   Sounds like the best approach.

-----Original Message-----
From: Michael Merz Sent: Thursday, October 28, 2004 9:07 AM
To: Beehive Developers
Cc: Heather Stephens
Subject: RE: V1 Alpha Branch created


Just for clarification: we'll merge the branch back into trunk once
V1Alpha has been released, right? In other words, all ApacheCon work
should go into the branch, not into the trunk.

-michael

-----Original Message-----
From: Heather Stephens Sent: Wednesday, October 27, 2004 10:36 PM
To: Beehive Developers
Subject: RE: V1 Alpha Branch created


As a reminder, for rampdown all checkins should have an associated bug
in jira. ( http://wiki.apache.org/beehive/Release_20Process Sec 2.3,
last bullet)

And as Ken said earlier, let's begin to drive that count in the


V1Alpha


milestone to zero and ship this puppy!!

"ApacheCon, ApacheCon, ApacheCon -- Rah, Rah, Sis-Boom-Bah"



-----Original Message-----
From: Heather Stephens Sent: Wednesday, October 27, 2004 10:22 PM
To: 'Beehive Developers'
Subject: V1 Alpha Branch created


I created the V1 Alpha branch.  It is located here -->
https://svn.apache.org/repos/asf/incubator/beehive/branches/v1/alpha/

Revision 55770 was the last modification to the trunk before this
branch.
Branch is complete with revision 55785.

Depending on how you did your original svn co, you have a few options


of


how to begin working on this copy.

*If you only checked out the trunk when you began working on beehive
   **Obviously you can checkout a copy from the new location (svn co)
or
   **You can do an svn sw (switch your working copy to the new
location).

*If you checked out the entire beehive tree when you begain, you


should


just do an svn up at the appropriate location.

Cheers.
H.










Reply via email to