On Tue, Feb 26, 2013 at 8:48 AM, BRM <bm_witness_at_yahoo.com> wrote:
>>>
>> 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.
We do development on trunk. It just seems like the logical place...
> 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).
On the other hand, it would be helpful if there were a "best
practices" document on how best deal with the inherent conflict
between the concepts of concurrent development on trunk, and the
conventions of (a) externals always being pegged in tags and (b) no
changes _after_ tagging. The only clean approach looks to me like
making a branch whose only purpose is to be a place to make the change
to the external references - but that also seem like a lot of extra
effort and clutter in the repository for that operation. But, if
that is what it takes, it would be easier to convince developers to do
it that way if there were some official document describing it.
>> 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.
I'm just saying it would be nicer if every user didn't have to make up
a different workflow process to accomplish the same thing...
>>> 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.
How can a script possibly know the correct tag for an external target
which is currently pointing at the trunk in a repository that permits
concurrent operations?
> 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.
That is a lot easier if you can make that solution avoid extra work
that doesn't have any obvious benefit. The intermediate branch seems
to have little benefit other than following some abstract conventions
unless there will be later support work on it - and you can always
create the branch later from the tag if that turns out to be
necessary.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-02-26 17:57:01 CET