Resolve conflict using 'theirs' means that when you try to check in two files that have conflicting edits, SVN will discard your changes and use the other persons change instead.
Resolve conflict using 'mine' means that you will discard their changes, and use your version of the file instead.
I wanted to add the whole list for further reference:
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
BuzzAnn is correct. mine vs theirs is ambiguous, since what's in the repository might also be mine. The unambiguous distinction is repository vs local copy.
The SVN command line merge is confusing especially when merging a branch back into the trunk. "My changes" are the ones I made in the branch, but that would be wrong according to SVN. To really complicate things, SVN refers to the paths as SOURCE, TARGET, and HEAD in the command line help.
Here is the simple answer, if you run this merge statement from the directory C:\Project1\Trunk
If you accept that what is in the repository is no longer (solely) yours, it is shared with all that have access, then it might be clearer.
In this context:
"theirs" means "the team's shared code in the repository"
"mine" means (my)"working copy" (probably on local machine)
"using theirs" replaces your working copy with the shared copy, discards your changes that exist on your local machine.
"using mine" deciding that the code in your working copy is what should be kept in repository, discarding what is currently in the repo.