Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

On 15.06.2015 20:54, Evgeny Kotkov wrote: > Branko Čibej writes: > >> Evgeny, please take a look at r1684940. >> >> I don't really like the fact that with this change and 'svnadmin >> --keep-going --quiet', the text "Error verifying revision N" gets printed >> to stderr; but I couldn't think of a

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

On 15.06.2015 20:54, Evgeny Kotkov wrote: > Branko Čibej writes: > >> Evgeny, please take a look at r1684940. >> >> I don't really like the fact that with this change and 'svnadmin >> --keep-going --quiet', the text "Error verifying revision N" gets printed >> to stderr; but I couldn't think of a

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

Branko Čibej writes: >> With that in mind, I am -0 on the corresponding backport proposal. > > I removed the backport proposal until we get this sorted out. Ack. >> I sketched the other possible option with redesigning svn_repos_verify_fs3() >> API to only report errors via the notify_func(), p

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

Branko Čibej writes: > My main objection to this approach is that it breaks all the API > patterns we've ever had: it creates a function that does not return an > error even though it clearly fails, and relies on some notification > callback to report actual errors. We have been reporting errors

FSFS7: 'svnadmin hotcopy' requires write access to the source

FSFS7 introduced a new on-disk lockfile, db/pack-lock, that allows packing a repository without completely blocking the commits. We also extended the svn_fs_fs__hotcopy() logic to take this lock for the source repository, see r1589284 and the related discussion [1, 2]. I think that this behavior

Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

On Tue, Jun 16, 2015 at 8:12 PM, Evgeny Kotkov wrote: > FSFS7 introduced a new on-disk lockfile, db/pack-lock, that allows packing > a repository without completely blocking the commits. We also extended the > svn_fs_fs__hotcopy() logic to take this lock for the source repository, see > r1589284

Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

On 16.06.2015 20:49, Stefan Fuhrmann wrote: > Once we are at it, let's detect pack operations during > hotcopy (compare pack status before & after the hotcopy). > Then we can at least warn the user of older format repos > that their hotcopy is possibly corrupt now. We should probably do that regar

Experiments with FlushFileBuffers on Windows

Hey there, One of the links recently provided by Daniel Klima pointed to a way to enable write caching even on USB devices. So, I could use my Windows installation for experiments now without the risk of brick-ing 2 grand worth of disks by pulling the plug tens of times. -- Stefan^2. TL;DR

Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

On Tue, Jun 16, 2015 at 9:38 PM, Branko Čibej wrote: > On 16.06.2015 20:49, Stefan Fuhrmann wrote: > > Once we are at it, let's detect pack operations during > > hotcopy (compare pack status before & after the hotcopy). > > Then we can at least warn the user of older format repos > > that their h

Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

On 16.06.2015 22:03, Stefan Fuhrmann wrote: > On Tue, Jun 16, 2015 at 9:38 PM, Branko Čibej > wrote: > > On 16.06.2015 20:49, Stefan Fuhrmann wrote: > > Once we are at it, let's detect pack operations during > > hotcopy (compare pack status before & after the

Re: Efficient and effective fsync during commit

On Mon, Jun 15, 2015 at 5:36 PM, Ivan Zhakov wrote: > On 12 June 2015 at 15:11, Stefan Fuhrmann > wrote: > > On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov wrote: > >> > >> On 29 May 2015 at 18:55, Stefan Fuhrmann > >> wrote: > >> > If you assume / suspect that FlushFileBuffers() only > >> > ope

Re: FSFS7: 'svnadmin hotcopy' requires write access to the source

Stefan Fuhrmann writes: > That makes we wonder how we prevent packing in old format repositories. > We know that hotcopying while packing can corrupt the destination repo. [...] > I'm -1 on reverting: Not being able to use hotcopy on an r/o repo is less > problematic than ending up with a corru

Re: Efficient and effective fsync during commit

On 15.06.2015 18:24, Mark Phippard wrote: > On Mon, Jun 15, 2015 at 12:15 PM, Branko Čibej > wrote: > > On 15.06.2015 17:36, Ivan Zhakov wrote: > > On 12 June 2015 at 15:11, Stefan Fuhrmann > > wrote: > >> To be c

Re: [Patch] apr_file_path_merge returns incorrect truepath on certain 'short paths' on Windows

On 15.06.2015 16:52, William A Rowe Jr wrote: > Great report, thanks Bert. I'll review. I verified the patch with trunk on Windows 10/VS2015; looks good. -- Brane > On Mon, Jun 15, 2015 at 7:19 AM, Bert Huijben > wrote: > > Trying yet another e-mail address... Nice

Re: [Patch] apr_file_path_merge returns incorrect truepath on certain 'short paths' on Windows

On 17.06.2015 05:28, Branko Čibej wrote: > On 15.06.2015 16:52, William A Rowe Jr wrote: >> Great report, thanks Bert. I'll review. > > I verified the patch with trunk on Windows 10/VS2015; looks good. I went ahead and committed to trunk in r1685929. I'll see about porting this to 1.5.x. -- Bra