I meant that each project will copy the complete tree into its own subdir.
>From there, dependencies can be replaced by externals to the required
versions.

Example:
Assume I have AR trunk which is a copy of the current trunk. To shield
against changes in DP trunk, which I depend upon, I replace the tools/DP2
folder with a link to branches/DP/2.1/tools/DP2. Then I branch my AR trunk
on release to get an AR2.0 branch for further maintenance.
If I now want to work on AR3, I change the externals on my AR trunk from
branches/DP/2.1/tools/DP2 to branches/DP/trunk/tools/DP2 to get bleeding
edge.

What remains is a problem of integrating all trunks, all stables and so on.
That is what the CI should do, so /stable and /trunk should be a collection
of externals to the respective trunk and release branches.

What will pose a problem, is the usage of external libraries in the
integration branches (/stable, /trunk). Changes must be discussed on the
list to ensure that all depending projects can use the new version.

Example: AR3 needs to use NH3 trunk. I have to check that the NH facility
maintainer is fine with it, or I will either break mine or his project on
/trunk integration build ( I can still use NH3 on my local trunk and build
there, but I will the CI build).
-Markus

2009/5/4 Jonathon Rossi <[email protected]>

> Not quite. I was planning on making /trunk exactly what you just mentioned.
> And creating another called /stable or /released which is pointing to the
> released revisions of all projects.
>
> An example of what I mean. If I branch /trunk/Tools/DP to
> /branches/DP/2.1.x then I won't be able to run a build with NAnt (which may
> not be a big problem), I'd need /trunk instead of /trunk/Tools/DP. I guess
> once we have released projects we can't just go and make changes around
> heaps of projects and then commit it all at once. The changes need to
> support backwards compatibility which then allows the project to be released
> and dependent projects to use those changes.
>
>
> On Tue, May 5, 2009 at 1:11 AM, Markus Zywitza 
> <[email protected]>wrote:
>
>> You mean to work with a all-trunk-version? That's easy - add another
>> branch called BleedingEdge which mirrors the default trunk, but contains
>> svn:externals to the projects trunk versions instead of the released ones.
>>
>> -Markus
>>
>> 2009/5/4 Jonathon Rossi <[email protected]>
>>
>> I branched /trunk to /branches/Core/1.1.x before and was going to do the
>>> same with DP. However, I stopped and haven't changed /trunk to use these as
>>> externals because this will require us to have about 10 full checkouts of
>>> Castle on our machines to be able to work on all projects once all projects
>>> have a release with a current branch.
>>>
>>> This follows on from a discussion we had the end of last year on this
>>> topic:
>>>
>>> http://groups.google.com/group/castle-project-devel/browse_thread/thread/ccaab32a9720dcb5/fe24167df491b8a6
>>>
>>> I will wait until we decide how we are going to proceed before I continue
>>> with branching Core and DynamicProxy.
>>>
>>> --
>>> Jono
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Jono
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to