svn in xcode

6.5: proj.addn/net.stackoverflow.com/questions/511913/svn-and-xcode-woes:
. while doing a search [@] web.addn/dev.mac/subversion with xcode?
I noticed another asking the same question,
[@] http://stackoverflow.com/questions/511913/svn-and-xcode-woes
so, I pointed them to my find:
apple's 2005 advice:
) .
6.18: proj.addn/mac/svn clients:
. where are svn gui app's for mac?
. here is some mac code;
Note carefully the Subversion version included in this installer
(from the installer package name). 0.7.3q - svn.1.6.2
If you have been using an earlier version of Subversion from the command line,
or with some other client,
you should upgrade all other such versions before installing this.
Otherwise, any working copy that has been touched by SCPlugin
will no longer be usable by your other clients.
Conversely, if you have other Subversion clients that use Subversion 1.5.x,
be sure to use a 1.5.x version of SCPlugin.
) .
my mac's svn version is 1.4.4
. I'm betting that I have not used mac's svn for anything
except to bring src down from other's svn's .

booking"svn (svnbook.red-bean)
Subversion, CVS, and many other version control systems
use a copy-modify-merge model as an alternative to locking.
In this model, each user's client contacts the project repository
and creates a personal working copy
-- a local reflection of the repository's files and directories.
Users then work simultaneously and independently,
modifying their private copies.
Finally, the private copies are merged together into a new, final version.
The version control system often assists with the merging,
but ultimately, a human being is responsible for making it happen correctly.
When Harry attempts to save his changes to a file updated by sally,
the repository informs him that his file A is out of date.
So Harry asks his client to merge any new changes from the repository
into his working copy of file A.
Chances are that Sally's changes don't overlap with his own;
once he has both sets of changes integrated,
he saves his working copy back to the repository.
) --
[. from here I'm getting the impression
that the reason svn is sufficient
is that it's meant for collaborations
only by teams that are lead by
mgt, or concensus,
so that concurrent efforts are well orchestrated .
. the only time there would be a need for a merge
is when one person is doing the coding
while the other persons are doing only
review and corrections,
or additions to documentation sections;
ie, being meant as additions,
the merging should be a snap . ]