[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] directory names

From: Peter McNab <mcnab_p_at_melbpc.org.au>
Date: 2005-08-30 12:41:57 CEST

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
> trunk.

> 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
missing something?

> 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
> '/release/'.
>
> It would be nice if you could specify multiple paths in the property,
> newline separated, as for the ignore property.
> tsvn:commitwarning = /tags/
> /release/
> /vendorbranch/
>
Agreed.

> 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
Trunk
Branches
Tags
Releases
VendorDrops
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.
>
> Simon
>
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.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 30 12:42:25 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.