top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

preferred way of code merging in informatica

+2 votes
1,266 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..
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 ?
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?

Similar Questions
+2 votes

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

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

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

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

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?

...