Quoting Ryan Schmidt <subversion-2008b_at_ryandesign.com>:
>
> On May 30, 2008, at 08:33, Mark Cimini wrote:
>
>> I was wondering if Subversion has been used to source code
>> control of a shared subdirectory among users? Basically a disk is
>> NFS'ed and a small team shares the development subdirectory. I'd
>> like subversion to occasionally go in an capture the state of the
>> tree.
> Do not do this when using Subversion. Doing so is prone to problems and
> negates many of the advantages of using Subversion (or any version
> control system). Read the book for how to use Subversion properly. The
> first point will be that each developer has a working copy unique to
> them, not shared with anyone else.
>
> http://svnbook.org
For material examples,
1) When separate working copies are used, concurrent editing is
managed by SVN. i.e. if person A changes function func_a in file
source.c and person B changes function func_b in file source.c,
subversion will make sure both changes appear in the file when
everybody has committed and updated. If you use shared filestore then
the last person to save is the winner, and the loser loses his or her
changes. (read-modify-write concurrency problem)
2) If user A upgrades their installation of SVN and user B does not,
then the working copy may become corrupt as changes to the SVN client
are made on the assumption that it is one client host per working copy.
If you still go ahead I would like to hear of any problems you
encounter, as we are using a shared working copy for binary files.
Because we use MS Office, (1) doesn't apply to us, but (2) has already
affected us.
> Mark Cimini also wrote:
> Reasons include that some COTS tools do not lend themselves to the
> standard SCC model. These tools usually think of the development
> space as there own.
On our development side we use Visual Studio as well as emacs, vi, gcc
and python. We have no problem just "svn add"ing a Visual Studio
solution. The only integration SVN needs with your COTS tools is that
the COTS stuff shouldn't remove the .svn directories. SVN doesn't
then care what happens to the working copy files, it just diffs them
with its own records.
> Also some development is R&D where there is "architecture on the fly."
I have a "general" project for this kind of work, and when I hack a
prototype together I just put it in its own directory and "svn add"
it. It's a small change to your developers' habits but the benefits
of doing it SVN's way are very great.
So I reiterate for development work, it really is best to use separate
working copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-02 11:22:43 CEST