If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

I think the best is to explain it with an example.
In the attached file the Version 1.55.1.5 is merged with 1.56.
The line between this Versions occurs if I use the MKS internal merge tool.
If I use BC it is not created.
Maybe that MKS needs somehow a feedback. Maybe that it is not possible.

My current workaround is to start the Internal tool, and merge just one simple difference and save the target file. Then the line is created. After that I use BC and compare/ merge the rest of the file.

Comment

Hmmm... It's still not clear to me what a "merge line" is. The attached picture doesn't look like a merged file...nor does it look like output from a merge tool. It looks like a high-level version control representation of the version history of a branched file that was later merged back into the main file. Version control software should represent the file versioning control in the same way regardless of what merge tool is actually used for the text merge itself. If it doesn't then perhaps it hasn't been configured properly???

During a manual text merge/compare other tools often show offset blocks of code with lines between the corresponding sections on each side of the compare. If that is what is meant by a merge line, one of the reasons I prefer Beyond Compare is their clean, always-aligned view that doesn't require reference lines between the two sides. If, one day, Beyond Compare starts to support multi-line match recognition (same text on both sides but broken up differently into separate lines) and/or line wrapping, then I would expect to see some type of indicator to tie matched text together. Until then, I prefer the clean look that Beyond Compare has today.

If, by merge line, you mean something entirely different, then please explain it further...and how you would envision Beyond Compare using it...because your mention of it has raised my interest as well.

BC v4.0.7 build 19761
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Comment

[QUOTE=Michael Bulgrien;19940]Hmmm... It's still not clear to me what a "merge line" is. The attached picture doesn't look like a merged file...nor does it look like output from a merge tool. It looks like a high-level version control representation of the version history of a branched file that was later merged back into the main file. Version control software should represent the file versioning control in the same way regardless of what merge tool is actually used for the text merge itself. If it doesn't then perhaps it hasn't been configured properly???
QUOTE]

Hello Michael,
you are right. The merge line is shown in a graphical overview of the file history. I also expected that it should be shown by the version control software ( in this case MKS) independen from the used tool, but unfortunately it does not.

I thing that the reason for this behavior is located in MKS. I also started a support request at MKS. But until now there is no reply.

Comment

I Have the dropdown Boxes, but there only BC2 not BC 3 is offered.
Therefore I Can not use it. ( I have MKS 2006 , may be this will change with MKS 2009)
Therefore I am using the command line as mentioned above.

P.S.:
(1) Besides the correct version of MKS-Client, MKS-Client only creates a merge line when the external merge tool has changed the working file. So I always change something in the merge-result window (e.g. add and remove a white space) and hit the save-button in the right bottom area of BC3-Pro. This works.

Comment

Your command line in the settings is correct (you're using 2-way merge, don't you?).

So the MKS version you're using is most likely the reason.

Best regards,
Alex.

P.S. I've just heard we get a next update of MKS in this autumn. So I recommend to wait for the coming update.
I hope they'll have fixed another of my suggestions: Right now MKS changes the original file name extensions of the temporarily checked-out files [when diffing files] to *.tmp. So this is pretty annoying because then BC3 doesn't have a chance to automatically recognize the file format. (Workaround: Assigning *.tmp to the file format most often diffed (c/cpp at my site).

These can be used similarly as the /lefttitle command, except these will also affect which file format is picked. So if you have *.tmp, but know at the time of the command call what filetype it should be, you can pass that in with the /vcsleft arguement and the fileformat will be correctly selected.

More detailed reference can be found in the Help file under Command Line Reference. Let us know if you have any questions.

Aaron P Scooter Software

Comment

Unfortunately it doesn't help with MKS. When diffing two file revisions selected in its history, MKS does not provide any information about the working file name [,extension]. It only provides the revision numbers and the paths to the checked-out temp files (with the *.tmp extension). So I don't have any information I could pass to BC via /vcs*-arguments.