Steven, I'd like to provide another alternative. This has worked for me in
several different environments (from waterfall to agile) and is not
SVN-specific. You could code on the trunk and periodically create "build"
branches each time you release a "build" for testing. For example, if you
are working on release "5.0" of your software, the patch-level release is
5.0.1, and this is the first build that has been released for UAT;
therefore, name the branch "5.0.1.001". It is important to note that
the environment to which build has been released (e.g. UAT, QA, etc.) is not
indicated in the branch name, but is tracked using some other mechanism.
From a Configuration Management perspective (if this is of concern in your
workplace), you are releasing the EXACT same code/product base to each
environment, NOT different branches into different environments, which
bolsters the integrity of your Configurations and makes things more simple
to follow.
As for identifying diffs between the prior release and current release (even
releases only for testing), I do not know SVN well enough at this point to
speculate on native functionality to do this. My inclination is to redirect
a directory listing (ls -lar) and/or other script output (e.g. per-file
md5sum) to a file for each branch and use a good visual diff tool to compare
the two files for differences.
Hope this helps!
-B
On 6/5/06, Eric Lemes <ericlemes@gmail.com> wrote:
>
> Hello Steven,
>
> I'll try to give some contribution to your questions. I have the same.
>
> SVN will not solve your problem alone. I think you will need some other
> tools + process to put this working.
>
> I'm setting up a process for my current project. This is an aproach. If
> someone has any other ideas, feel free to contribute. The idea is (based on
> the subversion book):
>
> 1) Trunk is the has most features and less stability. It's unstable by
> default.
> 2) In a moment, you will do your first QA release. Then you make a branch
> of whole repository and call it 1.0.
> 3) While QA does every tests, your development team will work on new
> features. This features will be commited at trunk.
> 4) When QA finished a test cycle, your corrections will be commited in the
> 1.0 branch. Then you have two options. Tell your developers to do every
> correction commit at 1.0 and trunk or tell your developers to do every
> correction only in 1.0 then do a big patch at the end (I never tried this
> before). Tools like commit notifiers helps to keep this process really
> working. If someone commit a at branch without a corresponding commit to
> trunk, then you cut his hands off.
> 5) Once the corrections is finished, you can tag the 1.0 branch as 1.0.1.
> 6) New test cycles generates tags 1.0.2, 1.0.3, until someone consider
> this stable. Then you compile everything and put in production.
> 7) You'll make another branch for QA. You can call it 1.1. Now you have
> trunk for development (unstable), 1.0.x for production (most stable) and
> 1.1.x (under QA).
> 8) If a new bug is found, the correction must be made in 1.0, 1.1 and
> trunk.
> 9) Every new QA fix goes in 1.1 and trunk.
> 10) Every new feature goes on trunk.
> 11) The cycle continue for every new release.
>
> The question is. How can I send only the differences to production, QA, or
> wherever I need?
>
> SVN provides a very, very beautiful tool for source control. This is not
> the only problem. There's a lot of other ones.
> - Continuos Integration: To assure all your "live" branches to be
> compilable. There's a lot of tools for a lot platforms (Java, .Net, Delphi,
> and many other stuff). Most of them with integration with subversion.
> - Building tools, like ant, nant and other stuff, to make these build
> scripts easier.
> - Tools to build documentations
> - Tools to build installer (most of the build tools do that).
>
> In my company, I'm currently working on a differential build machine.
> Something like that:
> 1) Get sources from 1.0.1
> 2) Get sources from 1.1.0
> 3) Look for differences, file to file. For every source file modified,
> identify the affected binary. Mark the binary as "needed in differential
> build".
> 4) Compare SQL scripts between the releases. Compile the differences to a
> new one.
> 5) Pack it all, in the structure needed for publishing.
>
> I think this kind of tool must be built especially for your needs. Some
> applications has heterogeneous technologies, dependencies and make it more
> difficult.
>
> I don't know if this kind of discussion is completely off-topic. If it is,
> feel free to mail me in private.
>
>
> []'s
>
>
> Eric Lemes
>
>
>
>
>
> On 6/5/06, Steven Lavallee <stvcinlav@yahoo.com> wrote:
> >
> > Yes, sorry I will describe the process.
> >
> > We are setup with one trunk that the developers use to
> > check in (unit tested) their changed code. A UAT TAG
> > is created each day to migrate the changes to UAT.
> > The issue is I do not know how we are going to get the
> > code that has been approved in UAT to QA because the
> > TAG that was created for QA contains approved and
> > unapproved code. I thought that a QA branch could be
> > used to handle the changes moving forward. Is there a
> > way to mark the approved code so that it can be
> > checked out for migration to QA and PROD?
> >
> > Thank you,
> > Steve
> >
> >
> > --- Andy Levy <andy.levy@gmail.com> wrote:
> >
> > > On 6/5/06, Steven Lavallee <stvcinlav@yahoo.com>
> > > wrote:
> > > > Thank you for the information.
> > > >
> > > > I do not understand how the code migrates to
> > > > Production after it has been approved in QA. Not
> > > all
> > > > of the code in a TAG for QA is approved. We have
> > > > weekly migrations to Production how do pieces of
> > > the
> > > > TAG get moved to Production?
> > >
> > > How things migrate really is dictated by your team &
> > > process. SVN is
> > > just a tool that holds your project artifacts. It
> > > doesn't enforce
> > > anything that you don't set it up to (via hook
> > > scripts and/or process
> > > management).
> > >
> > > Only tag what's supposed to move to production. If
> > > you can't isolate
> > > those elements, then you need to re-evaluate your
> > > strategy, your
> > > source layout, or your choice of SCM tools. Or,
> > > create branches from
> > > 100% approved versions and ONLY change items that
> > > can be approved
> > > (then tagged & released) within a week. But that
> > > will quickly become
> > > a branch-management nightmare.
> > >
> > > Perhaps if you could describe for us your full
> > > process, someone could
> > > propose a more workable solution. Giving details in
> > > drips and drabs
> > > will just prolong the confusion, and may send you
> > > down the wrong path.
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
Received on Tue Jun 6 16:27:42 2006