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
<<image001.png>>
