> 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: Friday, February 22, 2013 10:57 AM
> Subject: Re: Tagging svn:externals
> On Fri, Feb 22, 2013 at 9:02 AM, BRM <bm_witness_at_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.
It's fully a matter of how you structure release process for anyone.
If you keep trunk prestine, then I don't think that would be an issue - your process just has to say that trunk
can only have released svn:externals and always be ready for QA.
And QA would have to have a similar process specified for any updates they do.
Ultimately nothing I/we say can do anything but help you define the process
and how it needs to work for you and your team(s).
>> 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.
I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers.
>> 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?
By automation I mean having scripts setup that can update the pegs revisions or tags automatically.
It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use.
The script would just need to be able to parse "svn pget svn:externals" and "svn info" on the various externals.
I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go.
Personally I think the right solution is defining your processes for everyone.
Keep it easy to do, but make sure everyone understands what they are suppose to do.
Ben
Received on 2013-02-26 15:49:20 CET