Simon Large wrote:
> What are we trying to provide protection against? I think it is mainly
> against someone switching their WC to a tag, then forgetting they have
> done that and making changes which they commit to the tag instead of
> So this is really only important if you _do_ have a WC.
Yes. If it can happen it will and it does but since providing a release
branch it's happening much less often, just because there is no need to
check out an actual tag to compile from..
A part aim of having releases, which do get checked out is to compile
from and publish/export from etc.
> Also, if you apply the property to trunk, when you create the tag the
> property will be copied there as well.
Not sure why one would apply the property to the trunk though. Am I
> The trick is in deciding how to use the tag. Maybe the simplest way is
> just to mimic what we already have, so:
> tsvn:commitwarning = /release/
> will generate a warning if you try to commit to a path which contains
> It would be nice if you could specify multiple paths in the property,
> newline separated, as for the ignore property.
> tsvn:commitwarning = /tags/
> To make this work in practice, the end user has to make sure the
> property is set on the lowest level that tags will be created from,
> but that is true of all TSVN properties.
This bit I'm not quite sure that I follow. My mental model of a project
repository has (where applicable) paths for
as root paths/folders all at the same level.
So applying the property <tsvn:commitwarning =...> to appropriate
folders at that root level seems clear enough for my simple brain. (If
there is a better strategy go with it, don't be coerced by the lowest
common denominator brain.)
> Should this mechanism be in addition to existing hard coded protection
> of /tags/, or should it replace that? If we replace, then existing
> working copies will lose that protection until they add the new property.
Somehow I think the default /tags/ mechanism should remain for continued
compatibility and the ability to protect additional or alternate named
"tags" be added as user electable properties.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Aug 30 12:42:25 2005