19

We're looking at moving from a check-out/edit/check-in style of version control system to Subversion, and during the evaluation we discovered that when you perform an Update action in TortoiseSVN (and presumably in any Subversion client?), if changes in the repository that need to be applied to files that you've been editing don't cause any conflicts then they'll be automatically/silently merged.

This scares us a little, as it's possible that this merge, while not producing any compile errors, could at least introduce some logic errors that may not be easily detected.

Very simple example: I'm working within a C# method changing some logic in the latter-part of the method, and somebody else changes the value that a variable gets initialised to at the start of the method. The other person's change isn't in the lines of code that I'm working on so there won't be a conflict; but it's possible to dramatically change the output of the method.

What we were hoping the situation would be is that if a merge needs to occur, then the two files would be shown and at least a simple accept/reject change option be presented, so that at least we're aware that something has changed and are given the option to see if it impacts our code.

Is there a way to do this with Subversion/TortoiseSVN? Or are we stuck in our present working ways too much and should just let it do it's thing...

Bjorn Reppen
  • 22,007
  • 9
  • 64
  • 88
saw-lau
  • 405
  • 1
  • 5
  • 10

5 Answers5

14

It's in the FAQ: How can I prevent Subversion from doing automatic merges?

  1. In TortoiseSVN->Settings->General->Subversion configuration file, click on the edit button.

  2. Change the [helpers] section by adding

      diff-cmd = "C:\\false.bat"

    (note the double backslash)

  3. Create the file C:\false.bat which contains two lines

      @type %9
  @exit 1
Sam
  • 40,644
  • 36
  • 176
  • 219
Nordic Mainframe
  • 28,058
  • 10
  • 66
  • 83
10

Here is a trick for TortoiseSVN:

How to turn off “auto-merge” in Subversion

Trick for svn.exe is to set svn external diff tool to a program that will constantly fail.

svn --diff-cmd=/bin/false

If external diff program fails, svn concludes that conflict is unresolvable and wouldn't merge it.

bahrep
  • 29,961
  • 12
  • 103
  • 150
aku
  • 122,288
  • 32
  • 173
  • 203
6

The best way around this is to educate the developers. After you do an update in TortoiseSVN it shows you a list of affected files. Simply double clicking each file will give you the diff between them. Then you'll be able to see what changed between your version and the latest repository version.

Mark Ingram
  • 71,849
  • 51
  • 176
  • 230
  • 4
    Before you notice any changes svn will gladly merge your files. Anyway it's a good idea to check what changed :-) – aku Sep 10 '08 at 12:12
  • 19
    Why is every answer to an SVN issue education? Doesn't this indicate the tool requires a large amount of tribal knowledge in order to operate and should be fixed? – whitey04 Jul 08 '12 at 21:38
  • 3
    "_Then you'll be able to see what changed between your version and the latest repository version_", which may not be trivial to reinstate, especially in the case where the file in question is eg designer-generated XML for something like a graphical EAI tool. Points for guessing who just got burned while updating some files generated by a graphical EAI tool :-). – Sepster Feb 06 '14 at 06:36
  • 1
    He asking for a way to change the behaviour of the program, not the behaviour of humans. – Rho Phi Mar 16 '16 at 15:27
1

I would suggest you should learn to work with the natural Subversion model if at all possible. In practice we find conflicts are rare, and the type of logic conflict you talk about almost non-existent (I can't recall an instance in the last 4 years in our repository).

Team members should check-in changes on as small a scale as possible (whilst maintaining correctness) rather than batching up a whole days work to just check it in once. This will reduce the possibility of stepping on someone else's work.

If you are concerned about about a particular change you are making Subversion does provide a locking mechanism to let you prevent other changes to the file. See the Red Book chapters on locking.

Rob Walker
  • 46,588
  • 15
  • 99
  • 136
  • 7
    This is a major problem with the "subversion model". It assumes that an automated merge is likely successful. I've never found a tool that can reliably do code merges without human intervention at least 50% of the time. – whitey04 Aug 24 '11 at 22:03
  • 2
    I check-in frequently and still find that SVN breaks lots of stuff each time it automatically merges. – Sam Jul 29 '14 at 02:00
0

This is why automated (unit) testing is a fundamental part of distributed software development. In the example you give, at least one unit test should fail on svn update and alert you to the error.

Remember what Subversion is: a version control system, not a perfectly-working-code-merging-tool.

APWorsley
  • 144
  • 1
  • 3
  • 5
    Unit testing is useful and superb unit testing could eliminate these types of problems. I think the point is that yes, it isn't a perfectly-working-code-merging-tool (it can't possibly be perfect without AI), so we want to be able to disable the purely automatic merging part of it, at least have some user interaction with it. – Mafu Josh Jun 18 '13 at 14:52
  • 1
    Unit testing will never be able to catch everything potentially caused by this. It's just poor behavior. – User Feb 28 '17 at 18:17