> On Jan 28, 2016, at 1:54 AM, Gert Kello wrote:
>
> I have a svn 1.9 repository, created with svnsync, that has ~15 revisions
> and size about 45 GB. Due to some issues in svn-all-fast-export I wanted to
> have svn 1.8 version repository so I downgraded it by doing svnadmin (v 1.9)
> dum
Hi,
rosa scarz wrote:
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you were trying to do.
You did not do that.
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.9.2\ext\subversion\subversion\libsvn_client\cleanu
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list
Gert Kello writes:
> The revision file write times:
> 91448 -> 13:16:44
> 91449 -> 13:16:44
> 91450 -> 13:16:44
> 91451 -> 13:16:48
> 91452 -> 13:16:48
> 91452 -> 13:17:00
>
> 91450 was the last one that has data is sqlite database.
> 91451 has nothing in 1.8 db neither
> 91452 has one entry in 1
I managed to replay only to Philip first, so I have a chance to write
changed/better answer to list :)
> Should I look at some svn oog information about the revisions where is
> > started to fail? Anything special to look for? Or should we assume
> > "antivirus or something else opened the file s
> > Which method did you use to write during sync:
> > > file, svn or http?
> > >
> >
> > file:///
>
> This makes me wonder if you used file:// on top of a network drive of
> some kind? SQlite is known to have problems with network drives (as
> hinted at in http://sqlite.org/faq.html#q5).
>
Well,
On Fri, Jan 29, 2016 at 12:42:53PM +0200, Gert Kello wrote:
> Anything special to look for? Or should we assume
> "antivirus or something else opened the file so that svnsync was unable to
> write it"?
>
> > Which method did you use to write during sync:
> > file, svn or http?
> >
>
> file:///
T
Gert Kello writes:
> They are identical up to rev 91450. And then there's a large gap between
> revisions 91450 and 155838. 155838 seems to be where new "svnsync" was
> started, there's gap of time stamps in revision files.
> 91450 does not seem to be special in term of sync sequence. About 60
>
On 29 January 2016 at 11:52, Philip Martin
wrote:
> > How can I test if the 1.9 has really corrupt sqlite db file? For me it
> > seems that it still gets updates (i.e. when I bring in new revisions with
> > svnsync.)
>
> Check the index with:
>
> sqlite3 db/rep-cache.db "pragma integrity_check"
> I have a svn 1.9 repository, created with svnsync, that has ~15
> > revisions and size about 45 GB.
>
> 300kB/rev is quite large, like >1 MB of changes before
> compression - on average. Are these office documents,
> large xml / html files or simply many files per commit?
>
>
The content is
Gert Kello writes:
> You are correct, there are 341378 entries in 1.9 file vs 499837 in 1.8
>
> And the failing de-duplication seems to be reason indeed. I have located
> one revision which is 112 MB in 1.9 repository but 15 kB in 1.8 repo. The
> commit is "add" (without history) of several files
Cameron Sours wrote on Wed, Jan 27, 2016 at 20:32:45 +:
> The windows Crypto API was attempting to connect to Windows Update to
> retrieve Certificate revocation information (CRL - certificate
> revocation list). The default timeout for CRL retrieval is 15 seconds.
> The timeout for authenticat
On 29 January 2016 at 02:40, Philip Martin
wrote:
> > rep-cache.db files are different, 39.7 MB in 1.9 and 58.4 MB in 1.8
>
> The rep-cache is an SQLite file that contains a map of checksums to
> revisions and if stops working then Subversion will continue to allow
> commits but will do less, or
13 matches
Mail list logo
