On Wed, Feb 27, 2013 at 4:14 PM, BRM <bm_witn...@yahoo.com> wrote: >> >> 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. > > From that description, it'll have to be a manual process that you run from > within your working copy. > Just update the svn:externals appropriately and then do an "svn update". > You can test whatever you like without committing.
Everything is built by jenkins and has to come from the repository. Things in uncommitted workspaces aren't necessarily repeatable. >> 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. > > So if you don't need a branch, delete it. > Personally I do an "svn del" on any branch that I no longer need - whether > abandoned or reintegrated. > This keeps the branch list short, and (more importantly) relevant. > The nice thing with Subversion is that you can still get to all those old > branches. That's a not-so-nice thing too. The repo is growing at about 10 gigs/year. While I realize that extra tags/branches are a very small part of the problem I don't want to encourage unnecessary clutter until there is some reasonable way to reorganize and actually remove things. >> 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. > > Let me propose this: > > For QA, let them do a simple modified working copy to get the svn:externals > where you want them; but then they are not allowed to commit or make other > changes. Won't work - it has to be committed somewhere or it won't be built. -- Les Mikesell lesmikes...@gmail.com