On 8 July 2010 16:22, Henri Yandell <flame...@gmail.com> wrote: > On Thu, Jul 8, 2010 at 3:59 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: >> On 08.07.2010 01:14, sebb wrote: >>> >>> On 7 July 2010 21:19, Rainer Jung<rainer.j...@kippdata.de> wrote: >>>> >>>> On 07.07.2010 21:00, sebb wrote: >>>>> >>>>> On 7 July 2010 10:47, Rainer Jung<rainer.j...@kippdata.de> wrote: >>>>>> >>>>>> On 29.06.2010 17:17, jean-frederic clere wrote: >>>> >>>>>> - build.properties: it would be nice, if you did the release changes >>>>>> to >>>>>> the >>>>>> file before tagging (and undo after) like Mark does for TC 7 >>>>>> (properties >>>>>> version and version.build). That way checking the identity between the >>>>>> tag >>>>>> and the release source would be easier (less deltas to ignore). >>>>> >>>>> Or: >>>>> >>>>> Create clean workspace from SVN. >>>>> >>>>> Make any necessary updates that apply to the tag only. >>>>> >>>>> Create the tag from the workspace using svn copy dir https://.../ >>>>> >>>>> Trunk is then untainted by unnecessary changes, and the tag commit >>>>> e-mail shows the changes made. >>>>> History is also preseved. >>>> >>>> I personally do not like edits of tags. I think tags should be used as a >>>> single cross cut through the code (like in CVS) and uniquely identify one >>>> revision, so not be edited. Personal preference though. >>> >>> My preference too. Tags should be immutable. >>> >>> I see now that my phrase "the tag commit e-mail shows the changes >>> made." could be taken to mean that the tag is editted. >>> >>> However that is not the case. >>> >>> The tag is created from the workspace + changes; the e-mail shows the >>> changes from the initial workspace checkout. >>> >>> So instead of seeing the changes as commits to trunk, followed by a >>> simple SVN copy which creates the tag, the copy and changes appear in >>> the tag creation e-mail itself. >>> >>> OK? >> >> Interesting, never tried that, sounds good, especially since the email you >> describe would contain the info you'd like to see (the changes relative to >> trunk). Good idea. > > 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. > 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. 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. > 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
