You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steven Lavallee <st...@yahoo.com> on 2006/06/05 20:27:32 UTC
SVN: Branches Questions
I am a new user to Subversion.
1. Can we migrate code to our QA and Production
environments but tagging the specific code changes?
2. Would we use branches to migrate the code after it
has been approved?
We have DEV, UAT, QA and Production environments and
we want the ability to migrate just the specific code
changes not the entire source code.
Thank you,
Steve
__________________________________________________
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
Re: SVN: Branches Questions
Posted by "brinkleybw@bigfoot.com" <br...@gmail.com>.
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.
Re: SVN: Branches Questions
Posted by Eric Lemes <er...@gmail.com>.
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 <st...@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 <an...@gmail.com> wrote:
>
> > On 6/5/06, Steven Lavallee <st...@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
>
>
Re: SVN: Branches Questions
Posted by Miha Vitorovic <mv...@nil.si>.
Steven Lavallee <st...@yahoo.com> wrote on 06.06.2006 04:54:54:
> 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
Steve,
In addition to what everyone else said, remember that Subversion supports
file and folder properties. They fit your need to mark certain files just
perfectly.
Best regards,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN: Branches Questions
Posted by Steven Lavallee <st...@yahoo.com>.
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 <an...@gmail.com> wrote:
> On 6/5/06, Steven Lavallee <st...@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
Re: SVN: Branches Questions
Posted by Andy Levy <an...@gmail.com>.
On 6/5/06, Steven Lavallee <st...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN: Branches Questions
Posted by Steven Lavallee <st...@yahoo.com>.
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?
Thank you,
Steve
--- Andy Levy <an...@gmail.com> wrote:
> On 6/5/06, Steven Lavallee <st...@yahoo.com>
> wrote:
> >
> > I am a new user to Subversion.
> >
> > 1. Can we migrate code to our QA and Production
> > environments but tagging the specific code
> changes?
> >
> > 2. Would we use branches to migrate the code
> after it
> > has been approved?
> >
> > We have DEV, UAT, QA and Production environments
> and
> > we want the ability to migrate just the specific
> code
> > changes not the entire source code.
>
> Before going too far, understand that unlike with
> CVS and other SCM
> systems, branches (and tags) carry no special
> significance in SVN -
> they are just copies. SVN can't tell the difference
> between a tag,
> branch, or copy (they're all just cheap copies)
>
> Answering your questions:
>
> 1) Most users will tag a full release, not specific
> files/changes.
> Basically taking a snapshot of the whole source tree
> at a moment in
> time. The idea being the ability to point at a URL
> and say "if you
> look here, you will always find release 1.4.62."
>
> 2) A common use case is to create a branch from
> trunk to use as the
> basis for QA and testing. Create a branch called
> "version_1.0.0" and
> then any changes required as a result of QA are made
> here and ported
> to trunk later. Once QA has signed off, you'll
> probably create a tag
> from here indicating the final 1.0.0 release.
>
> If you haven't yet, The Book (http://svnbook.org/)
> is a very
> worthwhile read and can help answer a lot of
> questions. There are a
> few others that have been very helpful to me as
> well; /Subversion
> Version Control/ by William Nagel (he participates
> on this list as
> well), and /Pragmatic Version Control Using
> Subversion/ by Mike Mason.
>
__________________________________________________
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
Re: SVN: Branches Questions
Posted by Andy Levy <an...@gmail.com>.
On 6/5/06, Steven Lavallee <st...@yahoo.com> wrote:
>
> I am a new user to Subversion.
>
> 1. Can we migrate code to our QA and Production
> environments but tagging the specific code changes?
>
> 2. Would we use branches to migrate the code after it
> has been approved?
>
> We have DEV, UAT, QA and Production environments and
> we want the ability to migrate just the specific code
> changes not the entire source code.
Before going too far, understand that unlike with CVS and other SCM
systems, branches (and tags) carry no special significance in SVN -
they are just copies. SVN can't tell the difference between a tag,
branch, or copy (they're all just cheap copies)
Answering your questions:
1) Most users will tag a full release, not specific files/changes.
Basically taking a snapshot of the whole source tree at a moment in
time. The idea being the ability to point at a URL and say "if you
look here, you will always find release 1.4.62."
2) A common use case is to create a branch from trunk to use as the
basis for QA and testing. Create a branch called "version_1.0.0" and
then any changes required as a result of QA are made here and ported
to trunk later. Once QA has signed off, you'll probably create a tag
from here indicating the final 1.0.0 release.
If you haven't yet, The Book (http://svnbook.org/) is a very
worthwhile read and can help answer a lot of questions. There are a
few others that have been very helpful to me as well; /Subversion
Version Control/ by William Nagel (he participates on this list as
well), and /Pragmatic Version Control Using Subversion/ by Mike Mason.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org