Content Merge & Conflict Resolution - Urgent

I am looking for an effective Content Merge & Conflict Resolution solution to support multiple development streams. Our development and content management team would like to have a solution similar to the CVS approach.

1. All documents in a branch should tagged.
2. All documents in a branch should inherit the tag from the base edition at its creation time.
3. The tag should be modified to track changes to a file.
4. Comparing two branches ( based on the same edition ) should list the files that have been changed based on the tag information. That means, it should only list the files that have been changed in the branches.

We feel with consistent tagging, we could compare and list the changes from two branches effectively as all the branches will be created from an edition that inherits its tag from a root tag (ROOT). As it often happens, there is tremendous effort being spent to indentify changes between branches to perform merges and conflict resultion when there is a huge gap between releases due to business priorities.

Any comments or ideas please?

Regards

Find more posts tagged with

Comments

Adam Stoller

I am looking for an effective Content Merge & Conflict Resolution solution to support multiple development streams. Our development and content management team would like to have a solution similar to the CVS approach.

1. All documents in a branch should tagged.
2. All documents in a branch should inherit the tag from the base edition at its creation time.
3. The tag should be modified to track changes to a file.
4. Comparing two branches ( based on the same edition ) should list the files that have been changed based on the tag information. That means, it should only list the files that have been changed in the branches.

We feel with consistent tagging, we could compare and list the changes from two branches effectively as all the branches will be created from an edition that inherits its tag from a root tag (ROOT). As it often happens, there is tremendous effort being spent to indentify changes between branches to perform merges and conflict resultion when there is a huge gap between releases due to business priorities.

Any comments or ideas please?

Regards

1. All documents in a branch should tagged.

requirements are first - and then determine whether the system being used supports those requirements - and if so, how. If you don't think of it in terms of CVS vs. TeamSite, but more in terms of what you are really trying to accomplish - you may be able to find a completely different solution than what you were originally thinking of.

Srinivas

Many thanks for the quick replay.

Following the earlier suggestion, I think I have managed to pin down the requirements after some useful discussions over the last week.

I would like to give some details about our current setup which, I hope, will help the forum to help us with some brilliant ideas to improve our process of managing the application assets and content assets.

Background:

Our content repository consists of application assets (dynamic pages - JSPs, Fragments), content assets (Meta DCRS, Static Pages and Images) and templated assets.

The application assets are managed by an application development team (DEV Team)
The content assets are managed by a content management team (CM Team)

Both application assets and content assets are stored in same branch with individual workareas for team members of DEV Team and CM Team.

Our branching structure is as follows:
WEBSITE1 (PRODUCTION)
|_______CM Team Member 1
|_______CM Team Member 2

|______STAGING
|_______CM Team Member 1
|_______CM Team Member 2

|______MAINTENANCE
|______ DEV Team Member 1
|______ DEV Team Member 2
|______ DEV Team Member 3
|_______CM Team Member 1
|_______CM Team Member 2

|_______PROJECT1
|______ DEV Team Member 1
|______ DEV Team Member 2
|______ DEV Team Member 3
|_______CM Team Member 1
|_______CM Team Member 2

|_______PROJECT2
|______ DEV Team Member 1
|______ DEV Team Member 2
|______ DEV Team Member 3
|_______CM Team Member 1
|_______CM Team Member 2

WEBSITE2
WEBSITE3

• The top level branch is for the repository for content distribution services and hence the editions from the branch are deployed to target deployment environments.
• MAINTENANCE branch is for continuous enhancements and break fix releases
• PROJECT1…..2 are the branches for major release initiatives
• CM Team is part of a unit business(owner of the website) and hence they have workareas in the staging and production branches where they make content changes and deployment to staging and production environments

The problem

A huge effort is being spent in merging the changes into PRODUCTION branch from a PROJECT branch and sometimes leading to chaotic situations.
SCENARIO I
• CM Team creates and deployments content editions on regular basis. Therefore content editions gets incremented on regular basis
SCENARIO II

• CM and DEV Teams work together to create MAINTENANCE release on monthly basis and put it through a release cycle. Once it passes TESTING, the release will be deployed to STAGING for USER testing. On passing USER testing the monthly MAINTENACE release will be merged into PRODUCTION branch and final maintenance edition is created and deployed to STAGING environment for regression testing. If everything is ok, then the same edition is deployed to the PRODUCTION environment. Once the monthly maintenance released has been deployed to PRODUCTION, the MAINTENANCE branch will get refreshed with latest content edition at that point in time.
SCENARIO III

• For any major release initiative, a new branch with project name is created with base edition as the latest content edition from PRODUCTION branch. CM Team and DEV Teams work together through the complete project life cycle. On successful USER testing, the project will be marked as ready for release. The time lag between the inception of the branch and final release ready could be anything between 2months – 12 months. Once the project is approved for release, a huge effort will be spent to merge the project branch and current production branch. AS it stands, it is a manual process and error prone.

Conclusion

Current our DEV Team is doing the merge process and found that SCENARIO III
is the worst of all. However, code ( JAVA libraries ) managed by CVS seems to relatively simple to merge and resolve any conflicts due to inherent support for tags and its integration with ECLIPSE IDE.

Therefore, the one main driver for the earlier post was that our application development team found CVS merge and conflict resolution process very efficient with strong support from Eclipse (Java IDE). Hence, a suggestion came forward to emulate the similar mechanism in TeamSite.

Given the requirements, I think there is a strong case to build a utility that would help the process of merging and conflict resolution of application assets that are stored along with content assets in a multi-stream development environment efficiently.

Well, I believe ECM is not just a repository but the entire suite of content management tools. Hence, by building utilities to support custom process wouldn't go against the basic principal of ECM platform.

Request

Any suggestion to improve our process of managing the content is appreciated.

Regards