tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VOTE] Release build 6.0.28
Date Thu, 08 Jul 2010 20:44:28 GMT
On 8 July 2010 17:57, Henri Yandell <> wrote:
> On Thu, Jul 8, 2010 at 9:36 AM, sebb <> wrote:
>> On 8 July 2010 16:22, Henri Yandell <> 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
>> 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.


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message