Simon Large wrote:
> On 12/04/2008, Jaco Vosloo <jvosloo_at_wesbank.co.za> wrote:
>> Simon Large wrote:
>>> On 11/04/2008, Vosloo, Jaco <JVosloo_at_wesbank.co.za> wrote:
>>>> Create your project structure as follows:
>>>> ++ projectname
>>>> +++ trunk
>>>> +++ branches
>>>> +++ tags
>>>> ++++ testing
>>>> ++++ production
>>> If you need a stable branch for testing, by convention you would put
>>> that on a branch, and rather than delete and create a new branch every
>>> time trunk changes you merge changes from trunk to branch.
>>> Normally a tag is a snapshot of (say) trunk at some particular point,
>>> usually a release, and it is named according to the release identity.
>>> The tags directory contains multiple snapshots so that you can easily
>>> see which one refers to a particular released version...
>> Thank you for the reply Simon.
>> I have updated my how-to to reflect your recommended structure:
>> ++ projectname
>> +++ trunk
>> +++ branches
>> ++++ testing
>> +++ tags
>> ++++ release-1.00
>> ++++ release-1.01
>> ++++ release-1.10
>> The ideal solution would be that I could set a label on a revision and do
>> an "svn update to specific label" and my working copy would be updated to
>> the revision as pointed to by the label.
> Labels is an often requested feature, but it has to go into Subversion
> before TSVN can use it, so you are petitioning the wrong list.
> As a workaround have you considered using svn:externals? You could
> define a folder called testing which has no content but just has an
> svn:externals property set which calls up a particular revision of
> trunk. Look in the help file for how to use externals.
> When you change the svn:externals property to specify a different
> revision, a user who has checked out the testing folder will then get
> the new content on update.
> As for unversioned files, there is no way to get rid of those through
> any subversion action.
Externals seems to be a good idea, I will try it as an alternative. I
do not believe that subversion really need to implement labels as it is
already powerful enough to handle any scenario. It is just a matter of
deciding on a way to implement it in the frontend using the existing
functionality i.e. branches or externals or hooks.
To read WesBank's Disclaimer for this email click on the following address or copy into your Internet browser:
If you are unable to access the Disclaimer, send a blank e-mail to
emaildisclaimer_at_wesbank.co.za and we will send you a copy of the Disclaimer.
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-04-14 17:06:57 CEST