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

RE: Corrupt files when quickly committing...

From: <jason_at_subversus.org>
Date: 2006-06-30 01:21:44 CEST

The reason I asked was because it sounds like the operating system may be
buffering the file output. Because of this, you can sometimes get some odd
results. I believe that you can force semi-asynchronous behavior through
the use of flags to force the files to be written to the hard drive (I don't
recall the flag name(s) off the top of my head). Of course, it may be
easier (though less reliable) to simply add some delay to your script
between file output and svn commits.

-----Original Message-----
From: Tankko [mailto:tankko@gmail.com]
Sent: Thursday, June 29, 2006 7:05 PM
To: users@tortoisesvn.tigris.org
Subject: Re: Corrupt files when quickly committing...

> This could also be dependent upon the design of the process that's
> outputting the 100 files. What kind of process is this?
>
> You could easily check if the TSVN cache process is interfering by
> killing the cache process and re-running your script. The TSVN cache
> process shouldn't restart unless you view the contents of your hard
> drive through explorer during the script run.

It's just a simple C++ program. It is using ::CreateFile(), etc, for file
IO, not fopen().

I tried killing the TSVN cache process and it doesn't seem to make any
difference, so it's something on my end or something weird with svn.

I'll keep poking...

Tankko

On 6/29/06, jason@subversus.org <jason@subversus.org> wrote:
> This could also be dependent upon the design of the process that's
> outputting the 100 files. What kind of process is this?
>
> You could easily check if the TSVN cache process is interfering by
> killing the cache process and re-running your script. The TSVN cache
> process shouldn't restart unless you view the contents of your hard
> drive through explorer during the script run.
>
>
> -----Original Message-----
> From: Tankko [mailto:tankko@gmail.com]
> Sent: Thursday, June 29, 2006 6:39 PM
> To: users@tortoisesvn.tigris.org
> Subject: Corrupt files when quickly committing...
>
> I am running into a strange problem:
>
> I am running on WinXP, with the latest versions of svn and TSVN.
>
> I have a program that runs and creates about 100 files in the 100K
> range and dumps them into a directory that is under version control.
> The 100 files already exist and most will not have changed, but some do.
>
> It takes about 2 seconds for the program to write out these 100 files.
>
> The next step in my batch file is to so a "svn commit" using the
> command line tool. Everything looks OK, the files that have changed
> are sent to the repository with no errors.
>
> Problems is, 1 to 5 files are corrupt.
>
> If I don't do the "svn commit" step in the batch file and wait 10 or
> 20 seconds, then do the svn commit, everything is fine.
>
> The program that creates these files isn't complaining about any files
> that it can't open, close or write to.
>
> Is this the TSVN background process messing something up?
>
> Tankko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Jun 30 01:23:07 2006

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

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