[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Linux working copy through SAMBA

From: John Peacock <john.peacock_at_havurah-software.org>
Date: Wed, 28 May 2008 07:35:09 -0400

Giulio Troccoli wrote:
> However all their work is done on their PCs, accessing their WC using
> TortoiseSVN (1.4.5) and a SAMBA mounted drive. Once a changed is
> committed they can tested straight away on their PC. Basically they
> never work on the test linux box.

This isn't really a supported configuration. Trying to keep your WC's on a
remote mounted filesystem is never a good idea; it only really works
consistently when using a really good NFS implementation (with locking), like
most SAN's. The Windows filesystem in particular has some issues with locking
and timing with regards to temporary files (which is why even local access has
conflicts with AV programs). And Samba is one step removed from native NTFS
access, so you are even more prone to have issues (as you've discovered).

You are much better off having the developers keep their WC's locally and commit
to the repo for testing. Then the devel server keeps it's own WC up to date
with a post-commit hook. It means you "waste" revision numbers on code that is
potentially broken, but so what; revision numbers are cheap.

I actually wrote SVN::Notify::Mirror and SVN::Notify::Config -


for this exact situation. All development happens on trunk and the dev box gets
updated automatically as commits are made. To move something into production,
the developer only needs to make a tag that matches a pre-defined (by you)
regular expression (say RELEASE_.+) and the production server gets switched to
the new tag.



To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-28 13:34:29 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.