On Tue, Feb 26, 2013 at 4:29 PM, BRM <bm_witn...@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@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 lesmikes...@gmail.com