We operate a similar system here.
All code in the trunk is based from the last system
test, which has tested feature/bug fixes merged into
it.
Every single change unless VERY minor is carried out
in a branch. When development is finished on the
bug/feature all new changes to the trunk since branch
are brought into the branch. Conflicts resolved. It is
then tested (probably just unit/link rather that full
system). Once it has passed and is properly signed off
then the feature/bug is merged back into the trunk.
and then onto any other parallel branches - like
maintained old versions if it is a bug fix.
The benefit with this approach is the developers can
commit nightly protecting them against machine
failure. These commits needn't be compiling as they
aren't committing to trunk. It also enables us to see
all the changes for a particular bug/feature as they
were merged into the trunk in 1 operation. this (in
theory) makes porting easier.
Find attached some 'dia' generated diagrams. I also
have a document that describes quite verbosely our
release process if you are interested.
--- Alan Saunders <ADS_at_Tigersolv.com> wrote:
> Hi,
> The development environment here is extremely fluid,
> with several developers working on different
> (sometimes exclusive, sometimes overlapping) and
> independent developments within the larger project,
> or simply debugging or bug fixing prior to release
> or on a customer bug report.
> I envisage all bug-fixing operations to be carried
> out in the Current (trunk) area, whilst new
> features/functionality are carried out in the
> developer areas. As the application is very
> extensive, and makes great use of both common code,
> and common feature setting areas any of which could
> be changed in a feature development, it is essential
> that these changes don't break either the current
> branch, or any other developers code. In this
> scenario, each developer would complete his/her
> work, compilation testing etc., make it available
> for peer review and testing, and when complete merge
> back to the current when it is solid and stable.
>
> Regards .. Alan
> -----Original Message-----
> From: lassevk_at_gmail.com
> [mailto:lassevk_at_gmail.com]On Behalf Of Lasse
> Vågsæther Karlsen
> Sent: 05 February 2008 11:47
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: New User - Importing a project with
> active changes
>
>
> What specifically will you gain by each developer
> having his own repository folder and not working
> against the same one?
>
>
> On Feb 5, 2008 12:38 PM, Alan Saunders
> <ADS_at_tigersolv.com> wrote:
>
> Hi All
>
> I have been doing some development on a (VB.NET
> 2005/8) project started by a
> programmer who is no lnger employed by this
> company.
> His storage and control of program versions was
> non-existent. After I had
> made extensive changes, I had reason to retrieve
> the original version issued
> to a client, which required that I examine his
> computer drive and check file
> version numbers and dates bbefore (eventually
> obtaining a version of the
> system that matched the client's, and that
> actually compiled, and worked as
> the installed version before I could start to
> clear up the operational
> problems on the customer site.
> As a result, I determined that an SCC was
> essential, and persuaded the Boss
> to let me implement Subversion and TortoiseSVN.
>
> As a Windows site, mainly using VB in all it's
> dialects (along with ASP,
> ASP.NET etc, etc) the old 'nix idea of
> Trunk/Branches/Tags is not
> appropriate, nor undestandable to most of our
> developers. More
> understandable to them, whilst retaining the
> same functionality, I have
> decided to use Current/Changes/Releases.
>
> My startup problem is that, starting with an
> empty repository, I need to
> import the existing working version of the code
> (as released to the client)
> into the Current and Releases. (this bit's easy,
> import into the Current
> (Trunk), then create a Release (Tag) from the
> same working copy.) Now the
> problem. How to 'import' my extensive changes
> into a new
> Changes(Branches)/Alan folder. (The Changes
> repository will contain a folder
> for each developer.)
>
> I have read the Subversion book, and the
> TortoiseSVN help from cover to
> cover, and all examples in both seem to follow
> the Initial
> import/checkout/change commit scenario, nothing
> seems to describe what I
> want to do!
>
> Regards .. Alan
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_tortoisesvn.tigris.org
> For additional commands, e-mail:
> users-help_at_tortoisesvn.tigris.org
>
>
>
>
>
> --
> Lasse Vågsæther Karlsen
> mailto:lasse_at_vkarlsen.no
> http://presentationmode.blogspot.com/
> PGP KeyID: 0xBCDEA2E3
-----------------------
N: Jon Hardcastle
E: Jon_at_eHardcastle.com
'The writing is on the wall...'
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-02-05 13:41:04 CET