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

Re: how to contribute feature of unknown popularity

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 15 Jul 2010 07:27:57 -0400

On Thu, Jul 15, 2010 at 6:34 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jul 14, 2010 at 10:03:53PM +0000, svnusertemp_at_href.com wrote:
>> Re: export --skipfilesmatchingsize
>> Prior thread link: <http://svn.haxx.se/users/archive-2010-06/0040.shtml>http://svn.haxx.se/users/archive-2010-06/0040.shtml
>>
>>
>> Hi, I am the person who wanted this feature and worked on testing it
>> over recent months.  It has been working well for some time, and I
>> use it often.  I use it because I build a lot of deployment servers
>> where, on a daily or weekly basis, much (often more than 90%) of a
>> system stays as-is and a small amount needs to be brought in from
>> subversion.  I use export (as opposed to update) to avoid having
>> .svn files scattered throughout production machines.  The main
>> reason I like the skip feature is that it lets me deal with DLLs and
>> other files that are (a) unchanging and (b) in use at the time of
>> export.  The normal export feature aborts when it encounters a
>> pre-existing file that cannot be overwritten because it is in use;
>> with the skip option, I can still export that branch of the
>> repository and pick up any new/additional/changed files.
>> Originally, I thought the skip feature would be a good way to save
>> bandwidth and time.  In the end, that was not as critical for me as
>> being able to skip over in-use, unchanged DLLs.
>
> Hi Ann,
>
> Why don't you use rsync, which was designed to solve exactly this problem?
> rsync avoids unnecessary transfers of file data over the network,
> by transmitting only the changes necessary to sync two data sets.
>
> You could do a local export on the machine where the Subversion repository
> is located, and then use rsync to sync the exported result to your
> deployment servers.
>
> You can run rsync on windows using cygwin, or you can use one of the
> Windows ports (google mentions DeltaCopy and cwrsync on the first page,
> there are probably more). rsync is free software, licensed under the GPL.
> See http://en.wikipedia.org/wiki/Rsync for more details.

And, at last check as part of an attempt at an rsnapshot based backup
system, it hangs on open files. I had to do it my original way, which
was to export the filesystem via CIFS, mount it and do the backups on
the relevant rsnapshot server, because the hanging rsync issue was
deadly.

> If you require encryption, rsync traffic can be encrypted using SSH or
> stunnel (see stunnel.org). If your server runs Linux, SSH is probably
> the easier solution. With a Windows server, stunnel might be the better
> option since running an SSH server on Windows requires cygwin.

There are some commercial SSH servers and toolkits as well. If you
need both rsync and SSH services on the same windows server, CygWin is
the way to go.

>
> As I've said before, I object to a feature that is not general enough
> to be useful to a lot of our users. What if the next person wants svn
> export to skip files containing java code, for instance? By your logic,
> we'd then add another option called --skip-files-containing-java-code.
> Proliferation of option flags like this is a wrong approach in my opinion.

It also won't work against files that are open, for example in a text
editor, but don't happen to be ".dll" files.

> I think that using a high-quality sync tool such as rsync is definitely
> a better solution to the problem you're trying to solve.

I'm mystified about using export on his core server. Do a checkout and
svn update to a something like "SRCDIR" on the core server, to avoid
the "this file is locked" issue, and use "rsync -av --exclude=.svn
/SRCDIR/ REMOTEHOST:/TARGETDIR/" syntax to push only that updated
code.

>
> Thanks,
> Stefan
>
Received on 2010-07-15 13:28:39 CEST

This is an archived mail posted to the Subversion Users mailing list.

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