Hi Lübbe,
> Why on earth are you sharing working copies between users?
> A working copy is something private on a local disk and not
> something you share via a network. If I don't get you completely wrong,
> you are asking for trouble here.
You are of course right, it was only after I hit send I realised I didn't
provide that information, which would help me distinguish what I'm trying to
do from the rest of the threads on this list which deal with people sharing
working copies on network drives*.
To take a step back from the immediate problem, here's what I'm trying to
do:
I have a php based web application that I work on with another developer
here (and from time to time others.)
Occasionally things break with the live site, or the 'clients' (it's an
internal app only, so they are just other staff here) spot a really basic
bug, or they need a really simple change made ASAP to the live site.
This is in addition to the general longer term development and improvement
of the web-app, which happens in each of our private working copies before
being checked into the repository.
Here's where I suspect I'm going wrong:
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, 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
3. Find another way to achieve what I'm currently achieving
For 3, I can envisage a complicated system of:
a) For syncing back live changes to the repo: creating a temporary checkout
folder, comparing it to the live site, patching the temporary checkout
folder, checking it back into the repository, removing the temporary
checkout folder.
b) For updaing the live site from the repo: creating a temporary checkout
folder, comparing it to the live site, patching the live site, removing the
temporary checkout folder.
Probably rsync set to ignore .svn folders and using the --delete option
would help with the patching/etc.
For 2, I ran some tests with a unix version of the svn client tools and ran
into the same problem, so I suspect it may be something more fundamental
with the svn protocol/working copy design. If it's for locking purposes, I
really can't see why it's necessary if SVN doesn't support shared working
copies anyway, since who else would be using the folders?! At the very
least, there could be an option to skip the permission changing parts of the
process. In any event, 2 would be really really great, but I can certainly
understand now that I've had a bit of time to clear my thoughts on this
subject why I shouldn't hold my breath for it!
Thanks again,
Jon.
* As an example, this thread:
http://svn.haxx.se/tsvn/archive-2004-10/0839.shtml
+ As previously indicated, this isn't an option for me in this case for
policy reasons.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Dec 13 07:50:56 2006