We created a branch out of trunk (using TortoiseSVN) and now we need to merge it back. The problem is that the files are data models' xmi files which is not allowing us to resolve conflicts to merge it back. The editor just shows loads of weird characters or interrogation marks.
I couldn't find much on the net about solutions for it. Any ideas please?
Thanks
Check if EMF Compare could help
Probably your files contains binary data but they are being considered as text by TortoiseSVN, confusing the TortoiseMerge process.
By the way, if the branch files are the most recent, consider resolve the conflict using the branch version of the files.
Additionally, think about mark your XMI files with property svn:mime-type application/octet-stream. This will avoid TortoiseMerge to misbehaviours.
Related
We recently implemented mandatory reviews (Helix Swarm) for the files that are checked into our source control (Helix Perforce). For now this also applies to files that are tool generated, InstallShield .ism files in particular. Since they are text files, a classic diff can be reviewed. The quality of such a review of course is poor, because the files are not intended to be human-readable. An alternative is to open the files in the InstallShield editor, but only few people in my team have the needed license which prooves to be a significant bottleneck in review speed.
Because of the aforementioned problems we are discussing to abolish reviews for InstallShield alltogether. I'd like to know if there is a feasable way to review InstallShield files, so that two people can have a look at changes in the installation routine.
For now we have decided to just do simple plausibility checks. Compare what is described in the pull request with what information that can be easily grasped from the presented diff of the XML file.
Example:
Descripion: Add/Update Library xy
Check if added/changed/deleted lines are containing the library name and possibly version.
If lines of seemingly irrelevant files changed, it's a reason to report a possible defect.
This may not be a perfect quality control of what the setup will finally do, but at least we can catch obvious mistakes early on, without the need for further tooling.
You can add 'MsiDiff.exe' as diff application by extension in Perforce to review InstallShield ism files.
MsiDiff.exe can be found in [IS-INSTALLDIR]\System.
Here is how you can add it in Perforce:
Perforce diff application by extension
I am new to Tortoise SVN.
I have done changes on local files and meanwhile somebody updated the sources on the server.
So my projects .cpp files are full of
<<<<<<< .mine
and
>>>>>>> .r46
kinds of labels.
Reading documentation I understand it is the way SVN keeps traces on the mismatched sources between server and local.
I would have expected the diff tool in the Tortoise contextual menu to take into account these labels to display the diffs and help the manual merge. But instead I have a 'brutal' diff between the valid sources and dirty local file.
Is there a way to have the diffs displayed more nicely in the tool (auto hide the labels, and suggest modifications) ?
Also my code does not compile no more because of these labels :(
Right click on the file with conflicts, then TortoiseSVN -> Edit Conflicts. It will show you text editor with yours and theirs version. Use it to resolve conflicts and save it as your local copy. More about this tool in here: Resolving Conflicts.
I have a two systems to develop the vc++ mfc project. We working in single project. How do we merge the two different header files,cpp files,dialog developed in different systems. But the project(Projectname.dsw) is same. Instead of redesigning and rework. Can any one advise.
Thanks in advance.....
If the files have the same names you can use another application like Git to do this merge. You commit the first project and after commit the another one and do the merges using the Git interface. I never did this but I think this gonna work. Winmerge can help to do this manually too, file by file.
I did a merge of bunch of files in perforce from one project into another. Turns out one of the file (VC++ .rc) file didn't merge properly and can't even open this in IDE as a result. I just want to remerge this single file again and leave the rest as is. Is this possible?
I did try 'rollback' on the file in target project but haven't checked in yet. Than I tried to re-merge/integrate just this file but it doesn't really work.
Perforce has a couple of suggestions in their knowledgebase: http://kb.perforce.com/article/517
Essentially what you probably have to do is to "update" the .rc file to the revision prior to the failed merge (probably using rollback) and then re-integrate that file. If it mumbles something about already having been integrated you should be able to use the "force" flag (-f) for p4 integrate.
Two questions:
How to make the TortoiseSvn diff tool ignore the EOL style?
How to fix mixed EOL style files during the conversion from PVCS to SVN?
I've just imported a PVCS archive to Subversion using the excellent free Polarion conversion tool. Everything looks fine, there is just one annoying thing that I'd like to fix.
Some of the cpp files in the original PVCS archive have mixed EOL styles (due to the PVCS merge tool). These files (and all their revisions) are now copied into the Subversion archive using the autoprops setting "svn:eol-style=native".
When I use the TortoiseSvn diff to see a difference between two versions I get the error message "Inconsistent line ending style".
The whole idea of converting 10 years of revision history from PVCS to Subversion is to make it easy for the programmers to see what changes were made in the past - and if you need to clean-up an old file manually before a diff is possible, it's not going to work.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed.
Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.
I use WinMerge as Tortoise’s diff tool and it has an option to treat all EOL styles as equivalent.
WARNING: The REAL problem with the EOL styles is in the java converter that reads the PVCS repository and generates the Subversion dump files. It takes the autoprops settings and applies them to the file types you specified - in my case the eol-native property - EVEN if the files have mixed EOL. Normally svn checks for this on commit and makes sure that files are cleaned-up before they are committed. Lesson learned: Do NOT use the eol-stype autoprops when converting from PVCS to subversion. If you need it then add it after the conversion is completed and get the files cleaned in the process.