forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyriaque Dupoirieux <>
Subject Re: svn commit: r367799 - /forrest/branches/dispatcher/
Date Wed, 11 Jan 2006 09:12:28 GMT

I wander why we need a branch whereas there is not yet a delivery ?
Since the 0.8-dev is not yet released, I think we can continue in the same branch (HEAD) as
we already did with the dispatcher v2.
If some - like me - wants to help with the v3 of the dispatcher, we don't have to change of
If some wants to continue with the stable version, they keep on with the current org.apache.forrest.plugin.internal.view.

I don't think we are much to work with the two following plugins :

so Thorsten may update these with his latest devs.



Thorsten Scherler wrote:

El mar, 10-01-2006 a las 22:18 +0000, Ross Gardler escribió:




Author: thorsten
Date: Tue Jan 10 13:36:57 2006
New Revision: 367799

URL: <>
Creation of the dispatcher refactoring branch


        I'm a little confused here. This is not a branch, it is a new
        directory within the branches repository.

What are you intending on doing in here and why is it not a true branch?



    It is not a true branch because I will change 5% of the trunk.

I have copied the related resources into the branch and renamed them.

Now I can

    ln -s them with the trunk again. It is like I am working with the
    trunk but

doing the editing in the dispatcher branch. This way we do not have to
merge the branch, because the resulting work will replace all
view/dispatcher related work of the trunk.

I thought I should use a branch for it. That is what you suggested the

    other time (or better said I understood).

Is there a problem with the chosen method?

I did suggest a *branch*, but this is not a branch.

I foresee a few problems:

1) Non standard use of SVN therefore difficult to trace what is actually 
done (especially historically) 2) "ln -s" does not work on windows 
platforms, therefore a number of devs are prevented from participating 
(even as testers) 3) The "branch" already has a directory structure that 
is different from trunk (samples) How much of a problem these will 
become I am not sure, but at the very least (2) is working against the 




*Cyri@que Dupoirieux* <>
( 	Tél : - Fax :
Mobile :
+ 	PCO Technologies <>
Burolines - 2 ter rue Marcel Doret
31700 Blagnac

View raw message