Oops: sorry to post re KAZ in the mailing list (musta done a reply to
all???)

How embarrassing...

Michael.

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brogan, Daniel
Sent: Monday, 25 June 2007 3:38 PM
To: [email protected]
Subject: RE: [OzTFS] TFS branching strategy to support releases
[SEC=UNCLASSIFIED]

 

Classification : SEC=UNCLASSIFIED 

OK - so let me see if I have this right.

 

as an example, PSP 1 modifies apple.txt. It is merged into the
integration line. Then other PSPs are also merged into the integration
line.

 

So to pull out PSP 1 I need to rollback the modifications to apple.txt
and then merge back into the integration line (and check-in). Then in
the PSP codeline rollback the rollback to return the modifications made
to apple.txt so that the PSP1 team can continue developing. Is that
right?

 

Also how do you rollback to a specific label? I've googled for this
before but the task seemed non-trvial.

 

 

________________________________

From: Michael Daniel [mailto:[EMAIL PROTECTED] 
Sent: Monday, 25 June 2007 1:25 PM
To: Brogan, Daniel
Subject: RE: [OzTFS] TFS branching strategy to support releases
[SEC=UNCLASSIFIED]

Hi Dan,

How goes the AFP? Glad to be out of KAZ still? J

As you can see I'm with Avanade now (left KAZ just after you did)

I'll be presenting on TFS at Tech Ed this year if you are going.

 

Let me see if I get this right: they do multiple merges into the
Integration branch and then (for whatever reason) decide they want to
pull one of the earlier merges out?

Very quickly:

In the PSP you want to roll back out of integration, roll back to the
version before they merged and merge that version back into Integration.

To identify the pre-merge version have them label the entire PSP branch
whenever they merge.

 

Does that make sense? (So much harder to describe without pictures...)

 

Michael.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Give me a call if

Cheers,

 

Michael Daniel | Applications & Integration Group 

Avanade Inc. | W: +61 (2) 6217 3004 | F: +61 (2) 6217 3003

Mobile: +61 (0) 408 900 111
E-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 

  <http://www.avanade.com/about/avanade/index.aspx> 

 

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brogan, Daniel
Sent: Monday, 25 June 2007 12:51 PM
To: [email protected]
Subject: [OzTFS] TFS branching strategy to support releases
[SEC=UNCLASSIFIED]

 

Classification : SEC=UNCLASSIFIED

Hi All,

 

A client of mine is currently trying to find a branching structure that
is supported by TFS and facilitates their release process. They have
some basic requirements that their structure needs to support.

 

The Requirements:

*       Fixed date, monthly releases of a single large product into an
environment that they control. 
*       If a sub project (feature/bug fix) does not make it make by the
release date it is pulled rather than extending the release date. 
*       Only one version of the software is supported at a time. That is
each month, each environment is updated with the latest monthly release.

*       Some sub projects are completed within a development month while
others are longer running (i.e. they forward integrate changes each
month into their project). 
*       They work in an agile environment and wish to avoid code
freezes. They currently achieve this by branching early. 

The Background:

 

Currently they have the following structure:

 

Below PSP stands for Product Sub Project e.g. product feature or major
bug

 

Main Line --> Integration Line --> PSP 1

                               --> PSP 2

                               --> PSP 3

                               --> PSP 4

 

So as an example, in preparation for a release PSP 1 and PSP 2 are
reviewed, tested and then reverse integrated (RI) (merge up) into the
integration line. Integrations testing goes well, sponsors sign off and
the product is moved into prod. Somewhere during this process a PSP that
is releasing would usually request a new branch to start working on next
months work or even two branches to support multiple months of work.

 

Main Line --> Integration Line --> PSP 1  (last month) 

                               --> PSP 1b (current work) 

                               --> PSP 2  (last month) 

                               --> PSP 2b (current)

                               --> PSP 2c (future work) 

                               --> PSP 3  (ongoing) 

                               --> PSP 4  (ongoing) 

 

Everyone forward integrates (merge down) from the integration line on
stable labels (usually a release label). No one works on the integration
line directly.

 

The Problem:

 

The issue they have is what to do if a project gets pulled out of the
release at the last minute (after being merged and checked-in to the
integration line). This is usually due to problems beyond their control
(e.g. no sponsor sign off or major bug found late in testing).

 

How do they reliably rollback multiple merges for a single PSP out of
the integration line? Also bear in mind that there are usually multiple
RI merges per PSP for each monthly release. Rolling back large
un-sequential merge changesets seems unpredictable. Also most other
branching patterns I have seen either have too many baseless merges
(only a problem in TFS) or assume non fixed release dates that are
further apart.

 

So I am turning it over to you. Any ideas?

 

Regards,

Daniel

 


**********************************************************************
                                WARNING

This email message and any attached files may contain information
that is confidential and subject of legal privilege intended only for
use by the individual or entity to whom they are addressed.   If you
are not the intended recipient or the person responsible for
delivering the message to the intended recipient be advised that you
have received this message in error and that any use, copying,
circulation, forwarding, printing or publication of this message or
attached files is strictly forbidden, as is the disclosure of the
information contained therein. If you have received this message in
error, please notify the sender immediately and delete it from your
InBox.

AFP Web site: http://www.afp.gov.au
**********************************************************************

OzTFS.com - to unsubscribe from this list, send a message back to the
list with 'unsubscribe' as the subject. View the web archives at
http://www.mail-archive.com/[email protected]/
Powered by mailenable.com - List managed by www.readify.net 

 


**********************************************************************
                                WARNING

This email message and any attached files may contain information
that is confidential and subject of legal privilege intended only for
use by the individual or entity to whom they are addressed.   If you
are not the intended recipient or the person responsible for
delivering the message to the intended recipient be advised that you
have received this message in error and that any use, copying,
circulation, forwarding, printing or publication of this message or
attached files is strictly forbidden, as is the disclosure of the
information contained therein. If you have received this message in
error, please notify the sender immediately and delete it from your
InBox.

AFP Web site: http://www.afp.gov.au
**********************************************************************

OzTFS.com - to unsubscribe from this list, send a message back to the
list with 'unsubscribe' as the subject. View the web archives at
http://www.mail-archive.com/[email protected]/
Powered by mailenable.com - List managed by www.readify.net 




OzTFS.com - to unsubscribe from this list, send a message back to the list with 
'unsubscribe' as the subject. View the web archives at 
http://www.mail-archive.com/[email protected]/

Powered by mailenable.com - List managed by www.readify.net

<<image001.png>>

Reply via email to