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

Re: SVN Usage - working on both tag and trunk

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Thu, 11 Nov 2010 06:20:15 +1000

On Thu, Nov 11, 2010 at 4:26 AM, Jonathan dos Santos <
jonathan_at_prioriti.com.br> wrote:

> Hello, first of all if Iím infringing any rule on the mailing list Iím
> really sorry. Iíve tryied searching but couldnít find a good phrase to
> describe my problem.
> Iím pretty new to svn and version control so this question may be very
> elementary:
> In our company we use SVN to manage the source code of our Delphi
> applications, generally we use trunks tomake changes to the source code and
> we only generate tags when we need to deploy the implemented features, still
> bugs happen and since the software is used in critical processes (at least
> for our clients they are criticalÖ) , we need to fix bugs and deploy the
> corrections quickly sometimes,
> generally we need to develop both in the trunk and the tag and sometimes
> thatís really frustrating Ė mainly because some processes are huge and after
> each minimal change we need to test it over and over in a dozen ways, I try
> my best to use patches or to convince the deployer to make a new tag. Still
> It happens more often the I wish it too, is there a way to prevent this
> through SVN or its more of a company problem unrelated to svn usage? Or
> maybe its just me ?
> Thanks for your help in advance

It sounds like a little of both.

1) Tags are usually read-only, so you could prevent modification via
pre-commit hooks or path-based authorization of some sort.

2) The 'standard' process for using trunk/branches/tags structure is:
develop on trunk, merge to a release branch, and system-test there. Once
ready, tag the branch. If a change needs to be made (ie urgent fix), then
make it on trunk, merge to the release branch, and re-tag.

Daniel B.
Received on 2010-11-10 21:21:25 CET

This is an archived mail posted to the Subversion Users mailing list.

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