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

RE: working copies problem on shared network drive

From: Lübbe Onken <l.onken_at_rac.de>
Date: 2006-12-13 09:35:59 CET

Hi Jon,

You wrote:

> We found it very difficult and time consuming to try and keep
> the changes we
> made to the live site in sync with our SVN repo, and also
> annoying to have
> to manually update the site three or four times a day from
> the repo. So we
> made the live site an SVN working copy that we just 'svn up'
> every time we
> want to sync changes either of us have committed

You could even run the svn up from a post-commit-hook if you are confident
that all changes are right :)

> or 'svn ci'
> every time we
> want to sync back changes we made to the live site.
>
> Previously, the other developers have been less active, and
> live changes
> were my defacto responsibility, however just yesterday when the other
> developer needed to update the site with something he was
> working on and I
> was out at lunch, we came across the access problem described
> in my original
> email (and noted elsewhere on these lists.)
>
> As I understand it, this only happens on filesystems such as
> unix which deny
> permission changing to non-owners. As far as I can tell there's three
> solutions to my problem:
>
> 1. Update samba confs on the network share to allow changing
> permissions for non-owners+
> 2. TortoiseSVN is updated to include a selectable option to gracefully
> handle these sort of errors

That won't work, because the subversion libs already give up a level below
TortoiseSVN. But you have already figured that out yourself.

> 3. Find another way to achieve what I'm currently achieving
>
> For 3, I can envisage a complicated system of:

Too complicated. :)

I'd try to get the samba permissions right. IIRC, you can force group and
user plus file/folder permissions for a samba share. This way it cannot
happen that a file is owned by JonD which was created by DonJ. Especially
when your live system is updated automatically by a post-commit hook, all
files/folders should belong to svn:users or whatever you svn servers id is.

From your other mail:
> File permissions as shown on the unix server are:
>
> rw-rw-r-- UserA Group blah.php
>
> Directory permissions are:
>
> rwxrwsr-x UserA Group .
>
> TortoiseSVN seems to work fine until UserB comes along, edits
> the file, and
> in doing so ends up with ownership of it (or ends up owning
> it via some
> other method:)
>
> rw-rw-r-- UserB Group blah.php

Are you sure that 'Group' is the same for 'UserA' and 'UserB'? Is it
possible that you are not in 'Group' when you access the share from windows?

> I've read around the web that setting dos filemode parameters
> to true in my
> samba conf may fix this issue by artificially working around
> unix's block on
> an attempt to change permissions on a file I don't own, however:
>
> a) I don't have access to this flag, and my systems
> administrators won't
> change them.

Now thats a real problem. What is their reason for not changing the flag?

> b) A lot of people are also reporting that this flag didn't
> fix the issue

IIRC this flag maps some Unix attributes to dos attributes. I set it on my
Server at home ages ago and it works for me. Otherwise my wife and me would
run into permission conflicts on our shares :). But I also have the force
user/group set.

I guess you need your admins help. That would be the easiest solution.

Cheers
-Lübbe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Dec 13 09:36:12 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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