Is there anyway to get TortoiseSVN to act more like TortoiseCVS?

Question

I work in a mixed source control environment. We are still mostly on CVS, but newer projects are in SVN. However, I am finding it hard to get buy-in for SVN because TortoiseSVN doesn't work like TortoiseCVS.

The 3 way merge has a lot of cognitive dissonance and while TortoiseCVS seems to always get the merges right, TortoiseSVN almost always requires manual help. Also after fixing any conflicts, you have to manually mark the file as ok.

Does anyone have any tips on how to get TortoiseSVN working more like TortoiseCVS?

EDIT

To be more clear, I don't want to do a three way merge, if possible, I would like to do a two way merge like TortoiseCVS does. I know that the resulting file is the same in CVS and SVN, for example a Visual Studio project file has two different Versions. This will always end in a conflict in TortoiseSVN and never in a conflict in TortoiseCVS.

SVN looks like:

<<<<<<< .mine
     <ApplicationRevision>22</ApplicationRevision>
=======
     <ApplicationRevision>28</ApplicationRevision>
>>>>>>> .r195290

CVS loks like

<<<<<<< SomeFile.cproj
     <ApplicationRevision>22</ApplicationRevision>
=======
     <ApplicationRevision>28</ApplicationRevision>
>>>>>>> 1.121

so I should be able to get the same kind of merge. Also, TortoiseSVN almost always has conflicts when updating if two people work on the same file, even though they are working in different locations, TortoiseCVS doesn't have this problem. I assume TortoiseSVN is being more conservative and forcing you to check the merge TortoiseCVS is assuming CVS got it right. I was wondering if there where some options hidden somewhere in TortoiseSVN for it to be more liberal, and also to do a two way merge instead of a three way.

Oh, and yes we are using Subversion 1.5 which has merge points (branches were basically useless without this).

Answer 1

Take a look at BeyondCompare and Araxis Merge. They offer instructions on integrating them into TortoiseSVN as custom merge/diff tools.

Answer 2

Just a wild guess here but if you're using CVSNT on the server this observation might be based on the fact that CVSNT simply is much better at merging than SVN because it has the notion of "mergepoints". This typically leads to far fewer conflicts when merging from/to the same branch multiple times.
I don't think there's much that can be done about this, at least not in an unobtrusive way.

EDIT: I stand corrected. As of v1.5 SVN also has mergepoints. I'd delete this answer but I guess it might still be of some use to someone using an older version of SVN.

If that's not what you're talking about maybe you should clarify your question a little bit more. Are you sure this is about differences between TortoiseSVN and TortoiseCVS and not rather between CVS(NT?) and SVN?

Answer 3

Uh, maybe I'm missing the problem. If TortoiseCVS does it "right" (as your team needs it done - or expects it to be done) ... then why would you want to choose TortoiseSVN?

Don't confuse the "purpose" of this technology ... to "serve" the development team in the development process.

(I am using both at the moment to try out TortoiseSVN .. but I don't like the tag/branching methodology in SVN as much so far)

Ron

Answer 4

I think your question is focused on how to better support merging with Subversion on Windows.

It may not be specifically what you were hunting for, but I regularly use Emacs under windows to facilitate merging under Subversion.

Emacs + SVN under Windows

A combination of EmacsW32 + cygwin (with svn) + psvn emacs package + "built-in" emacs merge tooling works well under windows. you'll find psvn comes standard in Emacs nowadays, and if it is not in yours, you can download and install easiliy and quickly.

Because of the integrated support in the Emacs-based toolset, I am about 5x to 10x faster at resolving merges than a typical co-worker. They seem content using TortoiseSVN + their other favorite editor and mete out it that way... I have offered multiple times to instruct them on the usage and power of the Emacs capabilities (once it is setup up, it takes care of itself), but it seems they'd rather stick to their rudimentary tools and not invest in increasing their productivity.

SVN is a powerful tool, and if you are required to use it, you might as well consider spending some time investing in making it work for you.

David

Answer 5

Conflict marking shouldn't have anything to do with Tortoise itself, but rather SVN vs. CVS. It is SVN that determines whether a file is conflicted, not Tortoise. I can't say why that's the case or what you can do about it. Probably very little. SVN is probably just more conservative when it comes to accepting merges. Again, not positive about the algorithm that's used, but it seems to flag a file as conflicted when changed lines are near enough to each other (and the changes are different).

I think the TortoiseMerge is fairly nice actually, so hopefully I can explain it as best I can and you might see something that you didn't know before. You normally have 2 panes side-by-side, and then a lower pane. The lower pane is the result of the merge, with conflicts marked in red, along with other pieces that were already merged successfully. On the conflict lines, you can right-click, and choose whether to keep your changes (as seen in the "Mine" pane), other changes (as seen in the "Theirs" pane), or you can accept a combination of those.

Lastly, I can explain why saving a merge and marking it as resolved are two separate steps. In SVN, marking something as resolved allows it to be committed again. It's basically a fail-safe that helps to keep you from committing a file that you've merged in the tool and saved, but still haven't finished editing/testing it. Basically SVN is distinguishing between saving something in a merge tool and actually resolving.

Hope that helped.