You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Giulio Troccoli <Gi...@uk.linedata.com> on 2008/05/28 09:01:02 UTC
Linux working copy through SAMBA
Sorry for the cross-posting but I'm really not sure whether this is a
question more suitable for the TortoiseSVN mailing list or for the SVN
mailing list.
Our Subversion server is a Linux box with SVN 1.4.4 and Apache 2.0.
The Web Team uses another Linux box as their development server and each
developer has a working copy. This box has SVN 1.4.4.
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.
Re: Linux working copy through SAMBA
Posted by Toby Thain <to...@telegraphics.com.au>.
On 28-May-08, at 5:36 PM, Ryan Schmidt wrote:
>
> 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;...
>
> Be that as it may, this configuration can work. It worked for us. ...
>
>> 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. ...
One better way is simply to run an instance of the site locally...
--Toby
>
>> 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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Linux working copy through SAMBA
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 29, 2008, at 05:43, John Peacock wrote:
> Ryan Schmidt wrote:
>
>> 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.
>
> Your mode of operation requires each developer machine to be
> configured with exactly the same server software as the main
> servers, which can be an extreme hardship (and sometimes impossible
> due to license requirements) depending on the software involved.
But that's exactly what our mode of operation didn't require, because
all working copies were stored in the developers' home directories on
the central Linux development server and accessed via Samba on the
developers' Windows machines. The server software (apache, php,
mysql, imagemagick, etc.) needed only to be configured on the central
Linux development server.
> It also speaks to a certain level of programming immaturity that a
> developer would have to repeatedly make small changes to get
> something working.
Did I mention I quit that job? :-) But I think we all have days when
it takes several tries to do something. Nobody's perfect. And I would
prefer that there be one commit to implement a feature or fix
entirely, not a bunch of half- (or even non-) solution commits.
> As a counter example, with your methodology if a developer gets
> something working, but then tries one or two more things and breaks
> it again, they have to remember what they subsequently changed to
> correct it back to working order. With my methodology, they just
> reverse out the last few changes and they are back with a working
> page. It is all too easy to say "I'll commit this in a second
> after I try /one/ more thing" and then not commit at all (remember,
> all programmers are lazy). ;-)
>
> Both methodologies have strengths and weaknesses; I prefer mine,
> even if it means that sometimes the log messages are "Dammnit does
> this work?" because it means that all changes are versioned (even
> the stupid ones).
I think you may be thinking of bigger changes than I am. I'm talking
about making several rapid changes to, say, the horizontal position
of an element of text until it looks right. Or tweaking a color until
it looks right. Or trying out various email encoding strategies until
it produces an email that looks right in the email client.
For a different scenario, take what I was doing before I read your
email. I'm trying to fix a problem building a universal binary of
some software on Mac OS X. I'm trying various things to make the
universal binary build properly. I don't want to commit every time I
make a change, because I don't yet know that my change fixes the
problem, nor even that it doesn't make the situation worse. To
determine this, I need to run the build. I only want to commit once
the build succeeds and the resulting binary works to my satisfaction.
In the same way, a web developer should not be forced to commit every
time they save their text document. They should only commit once
they've tested their changes and are happy that they solve the
problem they were setting out to solve.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Linux working copy through SAMBA
Posted by John Peacock <jo...@havurah-software.org>.
Ryan Schmidt wrote:
> 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.
Your mode of operation requires each developer machine to be configured with
exactly the same server software as the main servers, which can be an extreme
hardship (and sometimes impossible due to license requirements) depending on the
software involved. It also speaks to a certain level of programming immaturity
that a developer would have to repeatedly make small changes to get something
working.
As a counter example, with your methodology if a developer gets something
working, but then tries one or two more things and breaks it again, they have to
remember what they subsequently changed to correct it back to working order.
With my methodology, they just reverse out the last few changes and they are
back with a working page. It is all too easy to say "I'll commit this in a
second after I try /one/ more thing" and then not commit at all (remember, all
programmers are lazy). ;-)
Both methodologies have strengths and weaknesses; I prefer mine, even if it
means that sometimes the log messages are "Dammnit does this work?" because it
means that all changes are versioned (even the stupid ones).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Linux working copy through SAMBA
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Ryan" == Ryan Schmidt <su...@ryandesign.com> writes:
Ryan> If the working copy gets hosed, check out a new one. If it
Ryan> happens too often, try a different version of Samba, or try NFS
Ryan> maybe? Not sure.
That doesn't sound like the sort of advice I would want to give my
colleagues. And it sounds to me like the sort of situation that
justifies the "this isn't supported, don't do it" rule.
If I run Subversion in a supported configuration, I do NOT want to see
"hosed" working copies. If I do see one it will be classified as a
Subversion bug, of course. I should be able to use a source control
system, including its working directories, without having to worry
that my work may evaporate suddenly due to some glitch that is
perceived as "normal risk".
If you feel that this level of risk is acceptable to your environment,
that's your privilege, but it doesn't seem like good advice to give to
the list.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Linux working copy through SAMBA
Posted by Ryan Schmidt <su...@ryandesign.com>.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Linux working copy through SAMBA
Posted by John Peacock <jo...@havurah-software.org>.
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 -
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.
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org