On 8 July 2010 17:57, Henri Yandell <flame...@gmail.com> wrote: > 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.
AFAIK, it is. > 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. Which I think complicates the history even more. > 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. Huh? I don't see how updating a tag (potentially multiple times) is more clear than creating the tag once. Also, creating a branch for the tagging adds even more places to search for history. > Also I'm bikeshedding - I've not been a Tomcat release manager, so > there may be details that differ from my experience elsewhere. One important item I forgot to mention: if you update trunk, and then create the tag from that, there is a window when trunk will contain incorrect information about versions. I'm not sure how you can prevent accidental use of trunk when in that state - e.g. it might be used in CI systems. The method I describe completely avoids that. But if you have a better method, or want to use something else - that's fine by me. I just wanted to point out what I think is a simple and effective method for creating immutable tags. > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
