Branch and sub-branch relationship

Hi all,

I have a general question about the inherent relationship between parent and sub-branches. I am relatively new to using TeamSite so I apologize in advance for what may seem like an obvious question. Some background before I ask: We are struggling to decide between a nested branching approach versus a very "stovepipe" linear branching approach.

Is there any inherent functional benefit to using nested branches to structure content? I know it facilitates the sharing of content through an organized structure. Ultimately, doesn't workflow move shared assets between parent and child branches? If so, why wouldn't they just as easily be able to move content assets between "stovepipe" branches? Is it a matter of ease of coding the workflow? Is there any other built-in benefit to using nested branches? Thanks in advance to a very general question.

Find more posts tagged with

Comments

JonathonG

The only functional difference between a nested branch and what you're calling a "stovepipe" branch, is that a nested branch is based off an edition of its parent branch. 98% of the time, this edition is the INITIAL, empty edition, so that there is no functional difference. This idea of basing a branch off a parent's edition comes in handy when you're doing fancy things like splitting off a line of parallel development for later merging. All of the files in the sub-branch would start from the version they were on at branch creation time, making the merge a bit easier.

Jonathon
Independent Interwoven Contractor

mogoo

So, Johnathon, what happens when it comes time for "later merging" of your parallel development - what are the next steps? Do you submit all the new stuff into staging of the sub-branch, then deploy the sub-branch edition to a workarea of the parent branch, replacing only diff files? What happens to any files that had different changes in both the parent and sub-branch during the "parallel development" time?

maureen

Adam Stoller

what are the next steps? Do you submit all the new stuff into staging of the sub-branch, then deploy the sub-branch edition to a workarea of the parent branch, replacing only diff files?

Using OD to do this might be a good way of handling it - especially with OD6 since it will transfer EAs as well as content.

The alternative is to use iwupdate - which I believe may be the better way to go - but you'll want to test things out in small test cases first regardless of which approach you take.

What happens to any files that had different changes in both the parent and sub-branch during the "parallel development" time?

This becomes a case for the Merge utility - but in order to do this correctly you have to make sure the workarea your uploading into is based on a previous edition that was uploaded. That way the files that get changed within that workarea will be based on the previous edition's versions. Then when you go to submit it, Submit will determine if there are files in conflict with the latest version in staging and require you to go through the merge process.

Note: there have been issues with the conflict resolution step when the what changed was metadata (EAs) - in those cases you may have to manually merge the changes yourself and then do an overwrite submit. Hopefully this will rarely (or even never) happen to you.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

I think (as usual) ghoti got most of the answers here. The key to the parallel development is to realize that all of the files in both branches have a common ancestor. So, once you're parallel development is done, you do something like the following:

1) Submit all the files to STAGING on the sub-branch
2) Create an EDITION on the sub-branch (just so you've got a consistent point to work from).
3) Create a new workarea on the parent branch, based on the EDITION you based the sub-branch on.
4) Use iwupdate to move all the files from the sub-branch EDITION to the new workarea.
5) [Ideally] Stop any new development on the parent branch.
5) Use the "Compare" feature to determine conflicts and resolve them (typically using the merge tool).
6) Once all conflicts are resolved, submit changes to STAGING, cut a new EDITION and "Get Latest" to all workareas on the parent branch.
7) Delete the sub-branch, or, at a minimum, remove all workareas so that no more work is done on that branch.

DISCLAIMER: I have talked this process through with a customer or two, but I have never actually been involved in building it. So, I believe the approach is architecturally sound, but I am unaware of any technical implementation potholes in going this route (see ghoti's post for one example).

Jonathon
Independent Interwoven Contractor

Johnny

We currently use sub branching for parallel development streams quite extensively.
Branch versioning works quite well, though we did build a few screens to tie a few functions together to make the merging process straight forward.

basically we follow this method.

piece of work comes along that is of considerable duration or size.

1. edition is cut on the parent branch marking the fork in development. edition names follow a set standard to clearly mark what is what.
2. project (sub) branch is created based off edition created in point 1.
3. development in project branch runs in parallel to any other pieces of work, including business as usual type work in parent branch.
4. all users have ability to submit directly to project branch so they can version their work (like check in)
5. editions are cut at certain milestones (eg first release to UAT etc) and daily snapshots.
6. development complete. edition is cut in project branch marking this milestone.
7. merge to parent (main line) branch
8. edition is cut on parent branch marking pre merge
9. workarea is created in parent branch for merge only. naming convention follows project branch_merge
10. workarea is updated against staging holding most up to date assets and no modified files
11. project branch INITIAL edition is compared against latest edition indicating all assets changed in project.
12. project files are merged into parent branch via temporary merge workarea. only conflict that can arise are locks or branch versioning
IE if file A was version 4 in parent branch when project branch was created and merging back to parent branch file A is now version 6, project file A is in conflict as it was based on a older version.
13. all modified files in merge workarea are related to project only and are submited to a job
14. edition cut in parent branch when all is completed.
15. merge workarea removed.
16. project branch is removed after x weeks of inactivity.

some steps are tied together with custom screens such as the comparing/merge project branch to make it a little more straight forward,
but overall it has proven to be a very robust process.

John Cuiuli

Johnny

Like Jonathon mentioned, the merge workarea could be based off the edition that the project branch was created.

versioning conflicts would be then dealt with during the submit process in the parent branch rather than the update from project branch.

One thing is that the conflict screens dont readily identify versioning conflicts.
It justs says its in conflict.

This is on 6.1

John Cuiuli

mogoo

THANKS so much, guys, this is very helpful information! I really appreciate the insights and details, great info! This stuff should be submitted as an article.
maureen