On Tue, Feb 26, 2013 at 4:29 PM, BRM <bm_witness_at_yahoo.com> wrote:
>
>> 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.
But that's not what I want. I want the externals in tags to point to
previously tagged component versions. Without forcing that to be
committed to the trunk or encouraging copying to tags from a workspace
that doesn't match any trunk commit.
>
> 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.
I'm a fan of not cluttering the repository with unnecessary branches,
and in making it simple for everyone involved to pick up each others'
changes sooner rather than later. And in getting determinism through
consistent tagging, and only using release tags where determinism
matters.
> 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.
The question is just about what would be considered "best practice" in
where/how that change between an unpinned external and one pointing to
a separately released tagged version should happen. I don't think
whether the ongoing work is a branch or trunk matters. As long there
is continuing (possibly concurrent) development in the location before
you make the tag, you have to decide whether to (a) make another
branch just to hold this change, (b) commit the change back to the
development location, then undo it after the tag copy, (c) copy to the
tag from a modified working copy, or (d) change it in the tag,
violating the 'tags never change' convention? I personally don't
like the idea of tagging from a modified working copy because of the
possibility that other changes with no history can accidentally be
brought along.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-02-27 00:13:30 CET