> From: Les Mikesell <lesmikes...@gmail.com> > To: BRM <bm_witn...@yahoo.com> > Cc: "users@subversion.apache.org" <users@subversion.apache.org> > Sent: Thursday, February 21, 2013 11:09 AM > Subject: Re: Tagging svn:externals > > On Thu, Feb 21, 2013 at 9:42 AM, BRM <bm_witn...@yahoo.com> wrote: >> >>> On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer > <bob.arc...@amsi.com> wrote: >>>> Some clients like TortoiseSVN have a feature that will pin the > external to >>>> the revision you are copping when doing the tag. Otherwise, you > have to do >>>> it manually before or after you create your tag. >>> >>> Neither choice 'feels' quite right to me unless you have an >>> intermediate branch to make the change. That is, if you make it on >>> the trunk before you copy to the tag you break the likely continuing >>> work on the trunk that expects the externals to also follow trunk >>> components. And if you change it in the tag you are breaking the >>> convention that you don't change tags. And if you copy the > working >>> copy to a tag you might get other changes in the tag that weren't >>> committed anywhere else. Is there a 'best practice' > consensus for >>> this step? >>> >> >> While I do agree, I think the simple solution is to generally just use > tagged externals to start with, and then switch them to trunk or a branch > when > you need to work on them from that project. > > That makes sense when you aren't concurrently working on a component > and the project using it. But that is the problem case - and common. >> Not only does it solve the above, but it also enforces a discipline in how > projects are updated to use newer versions of the tags; it also requires > developers to be aware of which externals affect which projects - which, > IMHO, > is a good thing. > > Sure, it would be great if every component had well-tested, frozen > APIs at release quality before any upper level project touched them. > But on the other hand, APIs tend to miss the mark if they aren't > adjusted for the needs of real-world use. So there's a problem either > way....
All true. But that's what your release process is for. Part of my release process for the projects that use svn:externals is to first tag and release any externals that are not released already. And if I don't need to modify an external during development, then it never moves from the release the project used. 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. $0.02 Ben
