Versioning "in place" and sharing a working copy

Our database [1] can treat a unix directory as a "file" (which means
that text files in the directory are considered records in the
database.) This is how we store programs and subroutines (loosely,
stored procedures.)

The programs only work in that environment, there's no way to 'check
it out locally, compile, test, and check in changes.' We've been
sharing the directory for years, it's not a problem because there are
only a few people, and it's rare for any two of us to want to work on
the same program at once.

I now have those directories full of programs under version control with
  svn co svn://example.com/repos/path/CUSTOM.SOURCE .
so that we can 'svn add' individual programs as we start working on
them. There are hundreds of programs that will never be touched
again, so I didn't import the whole directory.

What happens if two people, using the same working copy, try to check
in two different programs 'at once' ? (Unlikely, but do we need to
coordinate checkins to be safe?)

Is there anything else I need to be careful about in this situation?
It *seems* to be working fine, the checkout was done as the user who
owns the database files, and I was able to svn add and commit, as
myself.

How do file permissions play into this? When I look at the file
permissions in .svn, the files are not group writeable, and are owned
by the user who did the 'svn co' or 'svn add'.

I found one thread [2] suggesting to chmod -R ug+rw the .svn
directory. This is probably a simple unix question, but is there
something I can set on the .svn directory itself so that this
automatically happens when a new file is added?

[1] IBM UniData, a multi-valued DBMS
[2] http://svn.haxx.se/users/archive-2004-09/0545.shtml

Thanks,

-- 
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org