Jon,
why not simply write some script which "svn export"s the files to be
published into the deployment area and let this script be called
automagically via an "at" command? This way you could ensure that any
change one makes will be published and, on the other hand, guarantee a
clean flow of information.
I personally dislike situations where development/hacking and deployment
happen in one place...
Thomas
> -----Original Message-----
> From: Jon Kloske [mailto:jkloske@itee.uq.edu.au]
> Sent: Wednesday, December 13, 2006 12:19 AM
> To: dev@tortoisesvn.tigris.org
> Subject: Re: working copies problem on shared network drive
>
> 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
>
>
>
---------------------------------------------------------------------
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:18:30 2006