tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [VOTE] Release build 6.0.28
Date Thu, 08 Jul 2010 15:22:33 GMT
On Thu, Jul 8, 2010 at 3:59 AM, Rainer Jung <rainer.jung@kippdata.de> wrote:
> On 08.07.2010 01:14, sebb wrote:
>>
>> On 7 July 2010 21:19, Rainer Jung<rainer.jung@kippdata.de>  wrote:
>>>
>>> On 07.07.2010 21:00, sebb wrote:
>>>>
>>>> On 7 July 2010 10:47, Rainer Jung<rainer.jung@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message