On Fri, Feb 22, 2013 at 9:02 AM, BRM <bm_witn...@yahoo.com> wrote:
>
>>> Not only does it solve the above, but it also enforces a discipline in how
>> projects are updated to use newer versions of the tags; it also requires
>> developers to be aware of which externals affect which projects - which,
>> IMHO,
>> is a good thing.
>>
>> Sure, it would be great if every component had well-tested, frozen
>> APIs at release quality before any upper level project touched them.
>> But on the other hand, APIs tend to miss the mark if they aren't
>> adjusted for the needs of real-world use. So there's a problem either
>> way....
>
> All true. But that's what your release process is for. Part of my release
> process for the projects that use svn:externals is to first tag and release
> any externals that are not released already.
Agreed, but the scenario is making a QA tag from trunk work. Most of
these are dead ends if QA rejects them - that is, with rare exceptions
anything that needs to be fixed would be fixed on the trunk and a new
QA tag made. My thinking is that there really should be an
intermediate QA branch where the externals are pinned but it seems
like a big waste when there will never be any other change on that
branch. Plus, we are increasingly automating this with a jenkins
plugin that allows tagging after a build.
> And if I don't need to modify an external during development, then it never
> moves from the release the project used.
Sure, many/most stay tied to tagged component releases even during
trunk work on the upper level projects, but it is still a common
scenario to need to make changes in both simultaneously.
> Now, in a sense you're looking to do that automatically as you make a release
> of the project you're working on.
> But it really all comes down to the release process, the tools you use for
> release, and their capabilities.
I don't think you can do it automatically unless you pin to peg
revisions in the same repository. How would anything automatic find
the right component tag or deal with concurrent changes in a separate
repo?
--
Les Mikesell
lesmikes...@gmail.com
