On Thu, Feb 21, 2013 at 9:42 AM, BRM <bm_witness_at_yahoo.com> wrote:
>
>> On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>>> Some clients like TortoiseSVN have a feature that will pin the external to
>>> the revision you are copping when doing the tag. Otherwise, you have to do
>>> it manually before or after you create your tag.
>>
>> Neither choice 'feels' quite right to me unless you have an
>> intermediate branch to make the change. That is, if you make it on
>> the trunk before you copy to the tag you break the likely continuing
>> work on the trunk that expects the externals to also follow trunk
>> components. And if you change it in the tag you are breaking the
>> convention that you don't change tags. And if you copy the working
>> copy to a tag you might get other changes in the tag that weren't
>> committed anywhere else. Is there a 'best practice' consensus for
>> this step?
>>
>
> While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project.
That makes sense when you aren't concurrently working on a component
and the project using it. But that is the problem case - and common.
> 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....
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-02-21 17:09:58 CET