> 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: Tuesday, February 26, 2013 11:56 AM
> Subject: Re: Tagging svn:externals
>
> 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...
That's one of two recognized methods - trunk is prestine or trunk is "dirty".
For "trunk is dirty" there is no guarantee that any given revision is useable.
For "trunk is prestine" development methodology says any given revision
must be useable. Both are enforced by project preferences and policy.
>> 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.
From what I can tell - and others can verify this - Subversion tries to allow the
developers to choose the development model that best fits their needs. As
such, such a document would have to be generated for numerous development
models.
That said, I think what you're looking to do makes more sense in a "trunk is prestine"
model than a "trunk is dirty" model. My own repositories use the "trunk is prestine"
model.
>>> 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...
I think it's a matter of finding what works best for your team. Good tools, like Subversion,
make it easy to customize your workflow for what you need to do. Some functions fit
certain workflows better than others; but they are available.
>>>> 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?
In my example, it would simply update, then pull the revision number to generate the peg
revision information in the svn:externals data, essentially:
^/somePath_at_r1829 -r 1829
The "1829" portion is easily scriptable to find.
>> 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.
I would suggest using branches for the features, bug fixes, etc. The normal process
then involves branching for the work, changing the external and updating the main
project accordingly, and reintegrating the branch to trunk when you're done. Everyone
would get the same workflow. Now, that's basically the "trunk is prestine" model.
As you can probably guess, I'm a big fan of "trunk is prestine"; mostly because I'm a
big fan of doing things in a very structured, deterministic way. You seem to be wanting
that determinism. It'd be interesting to see what a big fan of "trunk is dirty" would say
for how to do the same thing; but somehow I suspect you can't do it while maintaining
the determinism.
As always,
$0.02
Ben
Received on 2013-02-26 23:30:21 CET