Re: [vtp-dev] Project meta data is out of date fortechnology.voicetools

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Thanks Scott.  That approach sounds very similar to what we're doing now.
It works fairly well to get things moving.  However, I'd like to incorporate
something into the process that will help us track the current efforts under
way other than relying on the commit comments.  I was thinking having the
branch be the integration build location and doing any modifications in
branches.

For example, if I wanted to add support for a new type of dialog to the
runtime, I'd create a branch called MyDialogType and work in there.  When
that effort reaches a stable state, it would be merged into the integration
build.  We're working on implementing a continuous build system for the vtp.
I'd like to have a fairly stable location for this.  Really, I'd just like
to add a little more traceability but limit its impact on development speed.

Trip Gilman


On 1/9/08 8:41 AM, "scott@xxxxxxxxxxxxxxxx" <scott@xxxxxxxxxxxxxxxx> wrote:

> Out of the various SVN usage methods, at bluestone we use an 'unstable'
> trunk and 'stable' branches.  This method is great for very fast
> development speeds as well as a great product release cycle.  Everyone just
> commits early and often to trunk, it almost doesn't matter if it's broken.
> Then as it gets towards release time, the trunk is fixed up as much as
> possible for the release and then branched.  That new release branch is
> only for the release, so therefore only bug fixes go in.  After the branch
> is made, development on the trunk continues as well as bug fixes from the
> branch are merged into the trunk.  The advantage of this method is that
> each branch is a basically a throw away.  For example a quick fix can be
> put into the branch but the better fix can be put into the trunk.  Once the
> next release is done, that old quick fix is never seen again.
> 
> Each SVN method stems from what your goals are.  If your goals aren't the
> same, then this method may not be the best.
> 
> Scott
> 
> On Tue, 08 Jan 2008 16:54:15 -0600, Trip Gilman <trip@xxxxxxxxxxxxxxx>
> wrote:
>> We've got our new SVN repository.  I'll be transferring the code base
> over
>> this week.  My initial idea is to have the plugins divided up into groups
>> based on usage, such as one group being devoted to the runtime and
> another
>> to the GUI designer functionality.
>> 
>> Also, branches will be created at the project root instead of under
>> individual plugins.  In SVN, branches are cheap copies and the merging
>> capabilities are improved over CVS, so this approach won't add much
>> overhead
>> to the development process.
>> 
>> I'll update the 1.0 release information in the portal and schedule a
>> tentative release for Q2 this year for the integrated 3.0 release.  The
>> 2.0
>> release was pretty much indefinitely postponed due to delay in the IP
>> process, but will be available within the repository for those interested
>> in
>> it.
>> 
>> If anyone has any thoughts on branching schemes or development
>> organization
>> I'm all ears.  I'd like to find a process that will work for all of us.
>> 
>> Trip Gilman
>> 
>> 
>> On 1/8/08 3:47 PM, "portal on behalf of emo" <emo@xxxxxxxxxxx> wrote:
>> 
>>> Projects are required to keep meta data up to date using the
>> MyFoundation
>>> Portal (http://portal.eclipse.org/).  The following problems were found
>>> with this project's meta-data:
>>> 
>>> * The date for release 1.0 is in the past, but the release is not
>>> completed. If it is completed, it should be marked as completed; if it
>> has
>>> been postponed, it should be given a new target date.
>>> * There is no next/future release of this project. All Eclipse projects
>>> must have a "next release" planned and scheduled.
>>> _______________________________________________
>>> vtp-dev mailing list
>>> vtp-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/vtp-dev
>> 
>> _______________________________________________
>> vtp-dev mailing list
>> vtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/vtp-dev
> 
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev