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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
