On Tue, Jul 31, 2012 at 5:31 AM, Mat Booth <mat.bo...@wandisco.com> wrote:
> On 30 July 2012 20:52, Fernando Gomes <fernando.go...@grupospring.com> wrote:
>> Hello all,
>>
>> I am a rather experienced developer and I’m currently trying to use SVN to 
>> back up a batch of files automatically every X hours. The problem is that 
>> some of the files are open and the commit fails entirely.
>> I have managed to invoke a non-persistent Shadow Copy over the volume but 
>> since I am not using a windows server but windows 7 the shadow copy is 
>> read-only. (I am using the vscsc.exe variant of the Shadow Copy SDK from 
>> Microsoft).
>>
>> Everything would work just fine if this Shadow Copy was write-enabled 
>> because the .svn folder files cannot be edited and because so the script 
>> (running "svn add" or "svn commit") cannot complete.
>>
>> Has anyone tried this scenario before? If so is there any way to invoke a 
>> simple "svn commit" over open files (using shadow copy or not) on an 
>> non-server based operating system?
>>
>> Thank you for any thoughts,
>>
>> Fernando M. A. Gomes
>>
>
>
> Subversion is not a backup system. Usually you would arrange for a
> separate system to backup your Subversion repositories.
>
> I can't help feeling there is a better tool out there for your use-case.

Matt, it looks like he wants to back up working copies, not
repositories. Fernando, if you can leave the working copy somewhere
else and shadow copy your relevant source material to *that*, I think
you'd be in better shape.

"Files being open" and thus unable to be copied is a typical Windows
problem in an ative system. It's potentially exacerbated if you use
svn:keywords, and the files are expected to be edited dynamically when
committted.

It's an interesting problem, and understandable. For pure backup,
rather than long-term source control, I've used rsnapshot and variants
of it. And for snapshotting Windows based filesystems I've made sure
to export them via CIFS and expose them via a more sane filesystem
structure. I don't necessarily get to copy those locked files, but it
doesn't block the whole backup procedure.

Reply via email to