Andrey Repin wrote:
> >
> Fifth step is to make these changes available to public.
> Here is the problem.
> 1. Making public server another (readonly) working copy... not wise. It
> increase filesystem load, and if it is a shared server, it would cost you
> additional money to extend the disk space to necessary size.
> 2. Continuous export's of the whole directory tree... not wise. Projects tend
> to grow in size, and every export, even if only few files were changed, would
> take alot of time and bandwidth.
>
> My problem so far, and what I can't find out myself.
> If there's a way to determine, which files in a repository has been changed
> since revision REV, and how to tell export to only pull these changed files?
>
> export does not take the --tergets switch, and I can't find out, how to alter
> the built-in diff command output. It's hard to read for me at first and not
> doing what I need (in this specific case) at last.
>
> Suggestions? Alternate ways?
One approach is to use a working copy as a staging location. Do an
update to the revision or switch to the tag that you want to push to
production, then use rsync or something similar to update the production
machine(s) to match the staging copy. Rsync will only copy the
changed parts and will copy under a temporary file name, renaming only
when complete, and the -C option will make it skip the .svn metadata as
well as cvs.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1521456
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-02 19:22:09 CEST