You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Enno Rehling <en...@despammed.com> on 2004/09/14 13:03:26 UTC
Subversion on a samba share
We have a couple of people who insist on using a shared checked out copy of
subversion. E.g. they have a samba share that they all use together (with
default permissions for new files 660 and all users in the same group).
svn update and other commands access the .svn directory and try to modify
permissions there. The problem with taht is that only the owner of a file is
allowed to change permission, it's not enough to be in the correct group.
Is there a way to tell subversion not to play with the permission of files?
The alternative, of forcing all samba users to the same user on the
filesystem, isn't exactly nice.
Enno.
Re: Subversion on a samba share
Posted by Bret Hughes <bh...@elevating.com>.
On Tue, 2004-09-14 at 09:06, Enno Rehling wrote:
> m christensen wrote:
>
> > What are they doing with this "shared working copy"?
> >
> > If they are "working" in it and making changes, I think the correct
> > answer is not the one you asked for, but DON'T DO THAT.
> >
> > Shared Working copies subvert the whole idea of revision control.
>
> I know that. Beleive me, I know that... We had a long discussion about the
> whole thing, and it fails. It's the way people in that department have
> always worked. All their process and tools are built around that way of working.
>
> We want the stuff they produced in our asset control, which is why we're
> making them use subversion. To the rest of us, that whole department is
> basically one user, because of the way they work. However, to samba, they
> are not just one user - and our network department is refusing to let them
> all be one samba user either.
>
> And poor me is stuck between all those conflicting sides, and the only thing
> that is technically in my way is that subversion is trying to make a file
> read-write and complains about not being allowed).
>
> Even when I tell the samba server to always keep all files with read-write
> permissions, SVN will still try to set the permissions on those files and
> fail because it's not the right user.
can you use the force user on the share?
from man smb.conf:
force user (S)
This specifies a UNIX user name that will be assigned as the
default user for all users connecting to this service. This is
useful for sharing files. You should also use it carefully as
using it incorrectly can cause security problems.
This user name only gets used once a connection is established.
Thus clients still need to connect as a valid user and supply a
valid password. Once connected, all file operations will be per-
formed as the "forced user", no matter what username the client
connected as. This can be very useful.
I do not know why this won't work, but have never tried it.
Bret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion on a samba share
Posted by Brad Kittenbrink <br...@windwardmark.net>.
Enno Rehling wrote:
> I know that. Beleive me, I know that... We had a long discussion about
> the whole thing, and it fails. It's the way people in that department
> have always worked. All their process and tools are built around that
> way of working.
>
> We want the stuff they produced in our asset control, which is why we're
> making them use subversion. To the rest of us, that whole department is
> basically one user, because of the way they work. However, to samba,
> they are not just one user - and our network department is refusing to
> let them all be one samba user either.
It sounds to me that this department is just way too inflexible to be
migrated to version control, so I would suggest that you hide it from
them. Let this department just access the working copy as a samba
shared directory and tell them never to use any subversion commands.
Then have some cron script run every so often on the server that does
svn status, svn add, and svn ci as necessary. That way this problem
department gets to act like they're not being version controlled, and
they won't even need to be given read access to the .svn dirs, and you
get to see their content checked in to your repository with whatever
frequency you want.
The disadvantage of this method is that you of course lose the
concurrent access protections that subversion gives you, but it sounds
like this isn't an option for this department anyway.
The advantage is that on the samba side, it's pretty much just as easy
to configure as any shared dir and the access controls can follow
whatever policies that your network department wants. On the svn side,
the whole department looks like the single user that the cron script
executes as.
-Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion on a samba share
Posted by Enno Rehling <en...@despammed.com>.
m christensen wrote:
> What are they doing with this "shared working copy"?
>
> If they are "working" in it and making changes, I think the correct
> answer is not the one you asked for, but DON'T DO THAT.
>
> Shared Working copies subvert the whole idea of revision control.
I know that. Beleive me, I know that... We had a long discussion about the
whole thing, and it fails. It's the way people in that department have
always worked. All their process and tools are built around that way of working.
We want the stuff they produced in our asset control, which is why we're
making them use subversion. To the rest of us, that whole department is
basically one user, because of the way they work. However, to samba, they
are not just one user - and our network department is refusing to let them
all be one samba user either.
And poor me is stuck between all those conflicting sides, and the only thing
that is technically in my way is that subversion is trying to make a file
read-write and complains about not being allowed).
Even when I tell the samba server to always keep all files with read-write
permissions, SVN will still try to set the permissions on those files and
fail because it's not the right user.
Enno.
Re: Subversion on a samba share
Posted by m christensen <df...@xmission.com>.
What are they doing with this "shared working copy"?
If they are "working" in it and making changes, I think the correct
answer is not the one you asked for, but DON'T DO THAT.
Shared Working copies subvert the whole idea of revision control.
Marc
Enno Rehling wrote:
> We have a couple of people who insist on using a shared checked out
> copy of subversion. E.g. they have a samba share that they all use
> together (with default permissions for new files 660 and all users in
> the same group).
>
> svn update and other commands access the .svn directory and try to
> modify permissions there. The problem with taht is that only the owner
> of a file is allowed to change permission, it's not enough to be in
> the correct group.
>
> Is there a way to tell subversion not to play with the permission of
> files? The alternative, of forcing all samba users to the same user on
> the filesystem, isn't exactly nice.
>
> Enno.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion on a samba share
Posted by Eric Hanchrow <of...@blarg.net>.
Let me give you another potential reason why they shouldn't have their
working copy on a Samba share:
http://subversion.tigris.org/project_faq.html, the section titled
``Should I store my repository / working copy on a NFS server?'', says
We've had at least one report of working copies getting wedged
after being accessed via SMB. The server in question was running a
rather old version of Samba (2.2.7a). The problem didn't recur
with a newer Samba (3.0.6).
That report was me. It sucked. `svn cleanup' didn't work; we had to
rebuild the working copy by hand.
If you're using a new enough Samba, you probably won't be bitten ...
but who knows?
--
Tobacco: It's not just for killing children anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org