On 2012-12-27 16:03, Karl Heinz Marbaise wrote:
> Hi,
>
> i just want to check my assumption by the user/dev community.
>
> I have the following scenario.
>
> From a central SVN server there should be done checkouts (different working copies) on a network drive.
> The working copies will be accessed from different users which means a thing like this:
>
> Network: working-copy-1
> User 1 accesses working-copy-1 and changes some files and will checkin those changes.
>
> User 2 accesses working-copy-1 and changes some files and will checkin those changes.
> etc.
>
> My knowledge is that if those accesses to the above working copy can be handled strictly sequential it might work but i'm not 100% sure..(may be someone can give more detailed informations)..
>
> Apart from that I expect failures if a working copy will be accessed in parallel from different users at the same time on the network based on the pristine-copy information and other meta-data which is stored in the .svn folder (SQLite database etc.).
>
> Can someone give more detailed information if the above assumption is right or wrong ? I assume it's right...
>
> Many thanks in advance.
> Kind regards
> Karl-Heinz Marbaise
I'm not sure if I got your scenarios right ...
- the working-copy-1 is located on a network share which is mounted by other users in read/write mode
- user 1 - user N has mounted the working copy and modifies files there, so this changes are direct transparent to all others without "svn update"
- user 2 --" same as user 1 "--
My question for this scenario is then more in the direction from which location in the working copy will user1/2 commit/update?
Or is someone the svn master who updates/commits the changes?
About the wc.db, even on a network share the database should be locked exclusive for write, so no other can do update/commits at the same time.
I expect for this scenario more failures in the way how a single file will be locked during the work (two users are working on the same file, in worst case with notepad that does not lock the file and does not recognize changes)
--
Regards,
olli
Received on 2012-12-27 18:05:22 CET