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. It gets around having a commit to a tag by hiding the change in the copy. I'd rather get over the notion that tags can't be modified than be tagging uncommitted code. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
