On May 28, 2008, at 06:35, John Peacock wrote:
> 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).
Be that as it may, this configuration can work. It worked for us.
There may have been working copy problems once in awhile, I'm not
sure, as I wasn't one of the developers using this configuration. But
I was one of the admins in charge of the Subversion server, and I
don't recall hearing complaints about this from the developers who
were using it.
If the working copy gets hosed, check out a new one. If it happens
too often, try a different version of Samba, or try NFS maybe? Not sure.
> 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.
It's contrary to the notion of committing things once they've been
tested, which I subscribe to. Whether this matters for the OP is of
course for him to decide. But in the web site development shop where
I worked, it's common for a programmer to make a small change in the
text file, save, press reload in the browser, go back to the text
editor, make another small change, save, reload in the browser, back
and forth very very quickly until they get whatever it is they're
working on right. To force them to commit after every little save
(and invent a commit description for every new attempt) would slow
them down immensely. Maybe this applies in the OP's case too.
> I actually wrote SVN::Notify::Mirror and SVN::Notify::Config -
>
> http://search.cpan.org/search?query=SVN::Notify::Mirror
> http://search.cpan.org/search?query=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 23:36:43 CEST