> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: BRM <bm_witness_at_yahoo.com>
> Cc: "users_at_subversion.apache.org" <users_at_subversion.apache.org>
> Sent: Thursday, February 21, 2013 11:09 AM
> Subject: Re: Tagging svn:externals
>
> 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....
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.
And if I don't need to modify an external during development, then it never moves from the release the project used.
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.
$0.02
Ben
Received on 2013-02-22 16:03:24 CET