forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: svn commit: r367799 - /forrest/branches/dispatcher/
Date Fri, 13 Jan 2006 05:27:24 GMT
David Crossley wrote:
> Thorsten Scherler wrote:
> > Ross Gardler escribi??:
> > > Thorsten Scherler wrote:
> > > > Ross Gardler escribi??:
> > > > Thorsten Scherler wrote:
> > > > ...
> > > > 
> > > >>>yeah agree, so what do you suggest? Like said I do not see the
point in
> > > >>>a 100% copy if I change <5%.
> > > >>
> > > >>That is not how branching works. When you create a branch it only 
> > > >>creates copies of the parts that are changed. Therefore, doing an "svn

> > > >>switch" is really quick and easy.
> > > >>
> > > >>Since you have found your requred changes will affect trunk, I'd suggest

> > > >>using a proper branch.
> > > > 
> > > > What speaks against "just create the final dispatcher
> > > > plugins (like I did in the branch) in the trunk and leave v1 and v2 in
> > > > our trunk till we have pelt contracts working with the dispatcher"?
> > > 
> > > I may have misunderstood, but I thought you said that your changes would 
> > > couse problems in trunk and that is why you finally decided to use a 
> > > "branch".
> > 
> > Yes and no. Yes if I use the v2 plugins directly, no if I start new
> > plugins.
> 
> I too was confused about the previous statement that
> the next phase of Dispatcher work would break trunk.
> I presumed that that meant the current skins, hence
> the need to branch. I also wondered if it meant that
> the work was happening in the existing structurer and
> themer plugins, hence the need to branch.
> 
> > > The only other thing that worries me is that there are already two 
> > > different versions of views in whiteboard, you are now working on a 
> > > thir. It is getting very confusing (your title is well deserved ;-).
> >
> > jeje ;-)
> 
> :-)
> 
> I too find the technique of copies of plugins confusing
> and hard to manage and hard to keep documentation
> up-to-date.
> 
> > I totally understand you and we need to clear out the confusion. Still I
> > think creating 2 new plugins would be quickest and easiest way. I will
> > start clearing the v1 plugins then we have the same number of
> > plugins ;-)
> > 
> > wdyt?
> 
> That is still too many.
> 
> We should bear in mind that we have emphasised that
> the Dispatcher work should not be relied upon. So we
> are safe to make radical changes. We can assume that
> whoever is using it, is also reading the dev list
> with glee. They probably have a copy of a working svn
> to manage their current website and local development,
> and they have a local version of the matching docs.
> Other brave souls are at the head of trunk, so no need
> to worry about them.
> 
> So i reckon that we do not need to support versions
> of rapid development work.
> 
> When the next minor hurdle of Dispatcher development
> is ready in a branch, then we announce it on the
> dev list and then just do it. Everyone then can decide
> for themself whether to 'svn up' or not.
> 
> Our main Changes for 0.8-dev should state the major
> changes (and perhaps the svn revision number) and
> then the rest of the detailed changes are in the
> plugin's status.xml file.

What do people think? Is that the way that we should
handle situations like this?

-David

Mime
View raw message