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

[<scott@xxxxxxxxxxxxxxxx>]

Here's another idea, maybe this will be useful for you:
SVN supports a property called svn:externals.  It's a way to 'link' other
parts of a repository or other repositories to your current repo.  It would
be possible to have MyDialogType be a repository by itself.

Within the vtp project, the property would look like:

MyDialogType       http://vtp.domain.com/repos/MyDialogType

You can even specify a certain revision number:
MyDialogType -r21  http://vtp.domain.com/repos/MyDialogType

The online subversion book has info about externals
http://svnbook.red-bean.com/en/1.0/ch07s03.html

For additional tracking of things, you can look into commit hooks if you
haven't already.  There's some pretty nice tools such as svn mailers that
maintain watcher lists and email everyone upon commit.

Scott


On Wed, 09 Jan 2008 11:06:30 -0600, Trip Gilman <trip@xxxxxxxxxxxxxxx>
wrote:
> 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
> 
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev