On Thu, Jul 8, 2010 at 9:36 AM, sebb <seb...@gmail.com> wrote: > On 8 July 2010 16:22, Henri Yandell <flame...@gmail.com> wrote: >> >> IIUC, it means the tag would not refer to any trunk revision. > > Strictly speaking, yes, there is no exact match in trunk, because the > version fixes are deliberately not applied to trunk. > >> It gets around having a commit to a tag by hiding the change in the copy. > > Sort of. The changes are not hidden, they are shown in the commit e-mail.
e-mails are fairly worthless though. The issue for me is that while it is in the svn log history, it's in a trunk->tag copy that many will assume is an atomic step. Immutability of tags vs atomic commits. >> I'd rather get over the notion that tags can't be modified than be tagging >> uncommitted code. > > All the code is committed; it's just not all in trunk. > > However, if you modify the tag after creation as you suggest, again > the revisions to the tag won't appear in trunk. > > AFAICT, the only way to ensure that a tag corresponds to a trunk > revision is to tag from trunk and then never change the tag => > immutable tag. Agreed; but not agreed on it being important. The need for a tag to point to a trunk revision is an arbitrary invention of our development process; instead: * Create release branch. * Develop on release branch. * Declare release branch releaseable [vote]. * 'Tag' by making release branch read-only. In SVN terms, mv the release branch from 7.0.0-release to 7.0.0. Not saying that's great, just that issue may be in how we're defining the problem. > The end result of the method I propose is similar to creating the tag > and then updating it, but it's easier to spot violations, because a > tag should only appear the once, and never in an update commit. But obscures history. I may be weird - I seem to spend a lot of my time in source control history so care a lot about keeping it simple. Also I'm bikeshedding - I've not been a Tomcat release manager, so there may be details that differ from my experience elsewhere. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
