You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Keirse <ja...@tvh.be> on 2011/10/07 10:08:19 UTC
Betr.: Subversion working copy via Samba
Dalibor Karlović <da...@burza.hr> schreef op 07/10/2011 09:52:01:
> Hello,
>
> I don't know is this a Samba or Subversion (or my faulty config) related
> issue so I'll start here. I'd like to clarify that the need to have just
one
> working copy (and not one per user on his/her local disk) is vital here.
Can we know why?
> Also, I'd like to note that this same mail was sent to Samba's list as I
> can't yet figure out is this a Samba or SVN issue.
It's Subversion.
> Target:
> - check out a working copy to this directory
> - allow only members of @Production to access it
> - allow various Subversion clients to be used via Samba on the working
copy
Then do the checkout from the client.
> - allow for using SVN directly on the server (not via Samba, MUCH faster
for
> large operations like checkout) without the need to fix permissions
> afterward (seamlessly)
No, impossible. Working copies are platform dependant. Either always
access them from windows or always access them from linux.
If it occasionally work it's coincidence, it may fail tomorrow.
> Now, I get most of it done:
> - I login via SSH and do a checkout
> - access the share via Samba (Linux, Fedora 14), it works
> - can commit/update/delete on either side, no issues
That's just coincidence, it may fail with the next version of SVN.
> But, as soon as my co-worker on Win7/TortoiseSVN deleted a file (via
Samba),
> he gets (Q:\ points to this share):
>
> Commit succeeded, but other errors follow:
> Error bumping revisions post-commit (details follow):
> In directory 'Q:\webs\<censored>\trunk\images'
> Error processing command 'committed' in
'Q:\webs\<censored>\trunk\images'
> Can't set file
>
'Q:\webs\<censored>\trunk\images\.svn\prop-base\avatar_small.png.svn-base'
> read-write: Access is denied.
See it can't work ;-)
> and from then on, the working copy is so badly damaged (locked, missing
> files/directories), etc. that I haven't found a way to fix it.
>
> Examining the permissions on the file in question, it seems Subversion
sets
> the access mode to r--r--r-- as to avoid tampering (?) and the Windows
> client isn't able to change it. The other reason might be that one user
is
> changing the file another user owns, but they're in the same group.
>
> So, my question is: is there anybody out there who has a similar setup
which
> in fact runs OK? Also, am I missing something obvious here (except for
the
> weird SVN usage pattern)?
Working copies are platform dependant. You should only ever access them
with one platform. You can use different clients (ie TortoiseSVN and
svn.exe) but they have to be on the same platform.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
Re: Betr.: Re: Betr.: Subversion working copy via Samba
Posted by "Joshua J. Kugler" <jo...@azariah.com>.
On Friday, October 07, 2011, Dalibor Karlović elucidated thus:
> Jan Keirse wrote:
> > Setting all that up shouldn't take very long.
>
> Yeah, for one site, but this would be like num_of_sites *
> num_of_people = ALOT. :)
Not really. We do it where I work. We have a single vhost, and the dev
checks out the web site into:
/home/username/websites/domain.com
The Doc root is 'html' in the above directory (in our case).
Then, they access that test domain via:
username.domain.com.ourtestdomain.com
The correct site gets served up via rewrite rules. Works very well.
j
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
joshua@azariah.com - Jabber: pedahzur@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
Re: Subversion working copy via Samba
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 7, 2011, at 07:42, Jan Keirse wrote:
> For example you should be able to create one apache httpd.conf containing
> num_of_sites of virtual hosts, and an /etc/hosts
> (c:\windows\system32\drivers\etc\hosts on windows) containing 172.0.0.1
> site1.local, 172.0.0.2 site2.local,...
> The /etc/hosts can be the same for all hosts and users, the httpd.conf
> will contain a little variation for each platform you use, but the virtual
> hosts will all be the same.
> These files can then be deployed to all people involved.
You don't need to distribute an /etc/hosts file if you instead run a local DNS server that handles those names.
Betr.: Re: Betr.: Re: Betr.: Subversion working copy via Samba
Posted by Jan Keirse <ja...@tvh.be>.
Dalibor Karlović <da...@burza.hr> schreef op 07/10/2011 14:15:39:
> Jan Keirse wrote:
>
> > Setting all that up shouldn't take very long.
>
> Yeah, for one site, but this would be like num_of_sites * num_of_people
=
> ALOT. :)
Not really. You need only one httpd.conf for all sites and people, with
only very small variations for each platform.
For example you should be able to create one apache httpd.conf containing
num_of_sites of virtual hosts, and an /etc/hosts
(c:\windows\system32\drivers\etc\hosts on windows) containing 172.0.0.1
site1.local, 172.0.0.2 site2.local,...
The /etc/hosts can be the same for all hosts and users, the httpd.conf
will contain a little variation for each platform you use, but the virtual
hosts will all be the same.
These files can then be deployed to all people involved.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
Re: Betr.: Re: Betr.: Subversion working copy via Samba
Posted by Dalibor Karlović <da...@burza.hr>.
Jan Keirse wrote:
> Setting all that up shouldn't take very long.
Yeah, for one site, but this would be like num_of_sites * num_of_people =
ALOT. :)
> If you still don't want to do that I think your best bet would be to do
> everything related to subversion on the server, maintain the working copy
> on the server, do all commits from there. You can still access the working
> copy from Samba to do the actual coding, just don't commit anything from
> windows.
Yeah, this is also a no-op as users (even developers) can't find their way
around the command line SVN client, so I'd be the one doing all the commits,
too much bus factor.
OK, I did some testing and it seems there isn't a good way to get this
working (or am I mistaken)?
This means I should implement the old setup (which I wanted to avoid):
- forcing user and group via Samba
- changing the ownership of the files on the server to that user:group combo
This leaves much to be desired in the flexibility, but as Subversion is
changing the permissions (even through Samba), can't seem to do anything
better.
Thanks,
--
Dado
Re: Subversion working copy via Samba
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 7, 2011, at 04:09, Dalibor Karlović wrote:
>
> Sure, I'll lay it out:
> - we're a small web development studio
> - we have a development server which exposed one share to the team via Samba
> - if we're developing a new site called foo.com, we create a working copy on
> the server and make it available as foo.com.web in our local domain which
> makes it accessible from each workstation right away
> - this gives us a point to which anybody working on the site can hook up to
> and we all can see exactly what's going on at any point in time
> - also, the less tech-savy guys/gals (designers, copywriters, PMs) don't
> need to setup their own entire work environment (server, database, virtual
> hosts, etc), they just open the share and a browser and start working.
> - we cannot automate the procedure because there's alot of different systems
> on staff (WinXP, Win7, MacOSX, Fedora, Ubuntu, etc).
Having developers editing code in a single shared working copy means you lose many of the advantages using Subversion offers.
> The one "working copy per user" has too high of a (time) cost here.
(At least) one working copy per developer per project is what you should be striving to use. That way developers can work independently and don't step on each others' toes.
In the small web development shop where I worked, we also had a central development server which ran the web server, database server and Subversion repository. A central working copy (for each project) was auto-updated via post-commit hook as described here:
http://subversion.apache.org/faq.html#website-auto-update
The web server was configured to allow access to this directory (e.g. http://dev.example.com/project1 or http://project1.dev.example.com). Nobody but the post-commit hook had permission to modify this directory; it was a pristine always-up-to-date copy of the project's trunk from the repository. Management and other non-developers could access this URL to see how things were going.
Each developer got his or her own working copy(ies) on the development server as well. Each developer had a login on the server and could make working copies in their home directory's public_html folder. Our projects were engineered such that it was easy to run them from any URL, so our developers could access their own work areas like http://dev.example.com/~developer1/project1/workingcopy1. Developers could create and delete working copies as needed. If your projects are not engineered to work on any URL, and require that they be at a the root of the URL space, then you could manually set up each developer's working copies as new vhosts, like http://workingcopy1.project1.developer1.dev.example.com
In our setup, we shared a single database instance among all working copies, so obviously developers had to be very careful when making schema changes to the database. The alternative would be to give each developer their own database instance, but that's tough to keep synchronized. We did ok with just a single instance, duplicating the database only as needed when making really involved backward-incompatible changes.
Using a working copy stored on a Samba server is not recommended because you tend to run into permissions errors like you saw. We used Samba in our shop and for whatever reason it worked ok for our Windows users but not for me on Mac OS X so I just ssh'd in, or kept my working copies on my Mac and ran my own web server.
Re: Betr.: Subversion working copy via Samba
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 07.10.2011 11:09, schrieb Dalibor Karlović:
> Actually, we've been working like that for years and it worked great as long
> as the minor version of all the clients accessing it is the same, as soon as
> the WC is upgraded, we all need to upgrade.
>
> How we had it setup was up to now was:
> - set perms for files to one user:group combo (say, developer:production)
> - force user developer, force group production in Samba
>
> and that worked, except you couldn't just go the the WC on the server itself
> and run SVN commands w/o breaking permissions / working copy.
That just means you didn't set it up as you claimed, i.e. that you
forced the user/group to fixed values. I guess the reason for that is
that a local mount circumvents Samba. Just mount the Samba share
locally, too, and use that to access the working copy.
That said, I tend to agree with others that this kind of setup is not
really stable and also, using a single working copy, you waste the
advantage of detached development. Imagine I make one breaking change
and then leave the house for lunch. Everyone else will have to wait for
me to return before they can continue. Alternatively, they revert my
changes, losing hours of my work. Even worse, if I have a file open in
an editor and someone changes it, I might accidentally overwrite the
changes. Or, someone checks in their changes while I save a file, so
their checking includes my half-finished changes.
Good luck anyway!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************
Betr.: Re: Betr.: Subversion working copy via Samba
Posted by Jan Keirse <ja...@tvh.be>.
Dalibor Karlović <da...@burza.hr> schreef op 07/10/2011 11:09:08:
> Jan Keirse wrote:
>
> >> I don't know is this a Samba or Subversion (or my faulty config)
related
> >
> >> issue so I'll start here. I'd like to clarify that the need to have
just
> > one
> >> working copy (and not one per user on his/her local disk) is vital
here.
> >
> > Can we know why?
>
> Sure, I'll lay it out:
> - we're a small web development studio
> - we have a development server which exposed one share to the team via
Samba
> - if we're developing a new site called foo.com, we create a working
copy on
> the server and make it available as foo.com.web in our local domain
which
> makes it accessible from each workstation right away
> - this gives us a point to which anybody working on the site can hook up
to
> and we all can see exactly what's going on at any point in time
> - also, the less tech-savy guys/gals (designers, copywriters, PMs) don't
> need to setup their own entire work environment (server, database,
virtual
> hosts, etc), they just open the share and a browser and start working.
> - we cannot automate the procedure because there's alot of different
systems
> on staff (WinXP, Win7, MacOSX, Fedora, Ubuntu, etc).
>
> The one "working copy per user" has too high of a (time) cost here.
I don't think it should be a lot of work to set it up to work with local
sandboxes:
* make a project containing the apache config files for the various
platforms. That way you only have to create them once for each platform,
and most parts of that will largely be copies.
* standardize paths: ie everything should go under either c:\www or /www,
so that config files don't need to be modified.
Developers just go to foo.localhost instead of foo.com.web. You can do an
automatic checkout of what's committed to foo.com.web to show what's under
development.
Setting all that up shouldn't take very long.
If you still don't want to do that I think your best bet would be to do
everything related to subversion on the server, maintain the working copy
on the server, do all commits from there. You can still access the working
copy from Samba to do the actual coding, just don't commit anything from
windows.
Kind Regards,
JAN KEIRSE
ICT-DEPARTMENT
Software quality & Systems: Software Engineer
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
Re: Betr.: Subversion working copy via Samba
Posted by Dalibor Karlović <da...@burza.hr>.
Jan Keirse wrote:
>> I don't know is this a Samba or Subversion (or my faulty config) related
>
>> issue so I'll start here. I'd like to clarify that the need to have just
> one
>> working copy (and not one per user on his/her local disk) is vital here.
>
> Can we know why?
Sure, I'll lay it out:
- we're a small web development studio
- we have a development server which exposed one share to the team via Samba
- if we're developing a new site called foo.com, we create a working copy on
the server and make it available as foo.com.web in our local domain which
makes it accessible from each workstation right away
- this gives us a point to which anybody working on the site can hook up to
and we all can see exactly what's going on at any point in time
- also, the less tech-savy guys/gals (designers, copywriters, PMs) don't
need to setup their own entire work environment (server, database, virtual
hosts, etc), they just open the share and a browser and start working.
- we cannot automate the procedure because there's alot of different systems
on staff (WinXP, Win7, MacOSX, Fedora, Ubuntu, etc).
The one "working copy per user" has too high of a (time) cost here.
>> Target:
>> - check out a working copy to this directory
>> - allow only members of @Production to access it
>> - allow various Subversion clients to be used via Samba on the working
> copy
>
> Then do the checkout from the client.
Same thing, sadly. Subversion is changing my preset permissions and ruining
my working copies. :(
>> - allow for using SVN directly on the server (not via Samba, MUCH faster
> for
>> large operations like checkout) without the need to fix permissions
>> afterward (seamlessly)
>
> No, impossible. Working copies are platform dependant. Either always
> access them from windows or always access them from linux.
> If it occasionally work it's coincidence, it may fail tomorrow.
Actually, we've been working like that for years and it worked great as long
as the minor version of all the clients accessing it is the same, as soon as
the WC is upgraded, we all need to upgrade.
How we had it setup was up to now was:
- set perms for files to one user:group combo (say, developer:production)
- force user developer, force group production in Samba
and that worked, except you couldn't just go the the WC on the server itself
and run SVN commands w/o breaking permissions / working copy. Now I have the
exact opposite, it works on the server, not via Samba.
>> But, as soon as my co-worker on Win7/TortoiseSVN deleted a file (via
> Samba),
>> he gets (Q:\ points to this share):
>>
>> Commit succeeded, but other errors follow:
>> Error bumping revisions post-commit (details follow):
>> In directory 'Q:\webs\<censored>\trunk\images'
>> Error processing command 'committed' in
> 'Q:\webs\<censored>\trunk\images'
>> Can't set file
>>
> 'Q:\webs\<censored>\trunk\images\.svn\prop-base\avatar_small.png.svn-base'
>
>> read-write: Access is denied.
>
> See it can't work ;-)
Yeah :) that's why I'm here, I'm thinking there must be a way to do this.
Thanks for your reply.
--
Dado