preferred way of code merging in informatica

1,587 views

I would like to understand different way of doing code merging in informatica i.e. what is a preferred approach for code merging?

posted Aug 23, 2013 by Deepak Dasgupta

Looking for an answer? Promote on:

Facebook Share Button

Twitter Share Button

LinkedIn Share Button

Deepak, can you please be more specific. not able to understand your problem..

commented Aug 24, 2013 by Nandan Kumar

we are using informatica extensively but one of the biggest challenges that we are facing is merging the informatica codes.

Currently, we are merging the codes by comparing same mapping having different mapping logic from different folders and after finding out the differences we are making changes to one of the mappings.

Recently, we are trying to merge the codes by exporting the mapping from different folder and doing the code merging using file merging tools. so literally, we are merging both the version of XML files to come out with new XML and we are planning to import the new XML file to the Informatica repository.

Is this a prerfered approach for code merging ?

commented Aug 30, 2013 by anonymous

No This is not the right approach. Let us assume that there are two folders A and B.
There is a mapping say x in both the folders. Now people started working on these mappings in both folder and have done many changes. so , now the mapping available in A is having different changes and B is having different changes. in the Mapping , lets say a field called M is having different logic in folder A and B. Now when merging , which logic will you consider. This is just for one field. If you have 20 fields, how will ensure the consistency?

commented Nov 2, 2016 by anonymous

Similar Questions

+2 votes

Merging SVN repositories

I need to do copy the content from one SVN repository to the other SVN repositories. Also, I need to make sure that Bidirectional merges are working after I copy content from one SVN to other.

Does anybody know how to do that. I think we have a svnsync command to copy the contents from one svn to other. But I am not sure if this allows bidirectional merging or not or bidirectional merging is even possible or not.

+1 vote

Correct way to undo commit of a tag in SVN?

My most recent commit was the creation of a tag. I want to delete that tag. Should I reverse merge the commit or simply delete the tag?

If I do a reverse merge I see a tree conflict:

C:>svn merge -c -69  

--- Reverse-merging r69 into '.': 

 C tagsTAG_ 

--- Recording mergeinfo for reverse merge of r69 into '.': 

U . 

Tree conflict on 'tagsTAG_ 

 > local dir edit, incoming dir delete upon merge 

Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:

What is the best thing to do here?

0 votes

Consequence of not using --reintegrate option in SVN merge

We have a situation where a few folks don't use --reintegrate option when performing SVN merge, while others do.
Whats
1- the consequence of not using --reintegrate option; can the feature branch continue to svn merge to trunk the 2nd time and thereafter ?
2- the impact on those feature branches that do use --reintegrate option; from what we read in the manual, that one cannot use this feature branches anymore.

+2 votes

merge issue - files not updated because of svn commits fail

We are using svn 1.6 - we tried merging from Trunk to a feature branch using svn merge (automatically). We just found out that some files are not updated with the merges but mergeinfo has already indicated and ci with the messages that those files are merged. We like to perform svn merge again using the same revision number from the trunk to the feature branch would svn refuse simply because it was merged "successfully" before ?

Are there side effects in applying svn merge again on the same revision numbers from the mergeinfo property ?

+1 vote

SVN merge for large number of files

I have 30 files that I want to merge, but I do not know which would be the easiest and much efficient and save way to do so.
I have the main production line Z and two other branches X and Y. All of the branches are still in production since X and Y are minor releases. Therefor on a time frame they are look this:
Z - trunk, next major releaseY - next minor release (Z - Y = small changes)X - used to make patches for an old release
The idea is that between Z and Y arent so many differences, but between X and Y(or Z) are plenty. There was a fix in the X branch that needs to be back ported into Z and Y. I am using svn merge to merge changes from X to Y, but because of the big differences I think it adds even code that could not be useful in Y, showing as conflicts just a few code blocks/file. which would be the best approach for such a merge?

...