10

We've got a sizable chunk of auto-generated code that we keep around in subversion. Sometimes I'm working on a piece of the generator while another coworker is working on a different piece of the generator. One of us checks in, and the other gets the latest. Now our generated code is in conflict. Because it's generated it'll be correct after the next time the generator is run, but subversion has flagged it as conflicted. It's a bit of a pain to go around, find these conflicts, verify that they are indeed due to generated code, and then manually "accept mine" to clear the conflicts.

Is there a way to have subversion recognize that for all the files in a given folder I just want to automatically accept mine? I'd like to stay away from dedicated batch files, as most of the office uses Tortoise SVN and I'm looking for a solution that everyone can use.

Hounshell
  • 5,321
  • 4
  • 34
  • 51
  • 3
    Either you care about the conflicts, so you should fix them, or you don't, in which case the auto-generated code should not be in SVN in the first place. SVN != Workflow automation. –  Jan 04 '10 at 20:53

3 Answers3

16

You should probably avoid having generated files in SVN in the first place - as you can tell, this is a source of conflicts. Better to have them be ignored, and build them as part of the build.

But as to your question, you should be able to use the --accept mine-full option to svn update, which makes conflicts automatically resolve to mine. See the Subversion manual and man pages for more details.

bahrep
  • 29,961
  • 12
  • 103
  • 150
Avi
  • 19,934
  • 4
  • 57
  • 70
14

svn update --accept [postpone|base|mine-full|theirs-full|edit|launch]

Jason
  • 2,341
  • 17
  • 14
4

That should be

svn resolve --accept [postpone|base|mine-full|theirs-full|edit|launch]

No?

euroblaze
  • 306
  • 3
  • 6
  • 1
    `svn resolve -R --accept mine-full *` without the asterisk mark I got "Not enough arguments provided" and note the -R for recursion. – Ivan Marinov Sep 25 '12 at 18:05