On Thu, Aug 22, 2019 at 9:52 AM Anton Shepelev wrote:
>
> [replying via Gmane]
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses
Gosh,
that means updating the production server as well as the Ubuntu backup server
then...
The production server is on Windows Server 2016 or maybe later and is using
VisualSvnServer.
Oh, well...
Best Regards,
Bo Berglund
From: Nathan Hartman [mailto:ha
On Thu, Aug 22, 2019 at 7:03 AM Bo Berglund wrote:
> It runs svn 1.9.7 as does the production server at the company.
1.9.7 has a bug related to files whose size is an exact multiple of 16,384
or 65,536 or something. I don't remember the exact details or whether
that's client or server side. But
Mark Phippard:
>Almost no one uses the BDB repository format. The fsfs
>format became the default in SVN 1.1 or 1.2 and it is the
>only format used anymore.
Phew. We do have FSFS. Thank you.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
On Thu, Aug 22, 2019 at 10:55 AM Anton Shepelev wrote:
> Mark Phippard to Anton Shepelev about hot copies:
>
> >>Are they portable across operating systems and
> >>filesystems? (I fear not)
> >
> >Yes, they are absolutely portable across OS and FS. As is
> >the repos itself. The only issue when
Mark Phippard to Anton Shepelev about hot copies:
>>Are they portable across operating systems and
>>filesystems? (I fear not)
>
>Yes, they are absolutely portable across OS and FS. As is
>the repos itself. The only issue when going across these
>is managing the OS level permissions of the copy.
On Thu, Aug 22, 2019 at 10:38 AM Anton Shepelev wrote:
> Mark Phippard:
>
> >My first choice option would be to setup a repository on a
> >second server and use svnsync from a post-commit hook
> >script to sync the change. After that, I would use
> >svnadmin hotcopy with the new --incremental op
Mark Phippard:
>My first choice option would be to setup a repository on a
>second server and use svnsync from a post-commit hook
>script to sync the change. After that, I would use
>svnadmin hotcopy with the new --incremental option (as of
>1.8?). Dump is not a great choice for backups.
Thank
Hello,
Le jeu. 22 août 2019 à 15:52, Anton Shepelev a écrit :
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses point-in-time r
Hello,
Le jeu. 22 août 2019 à 13:46, Andreas Stieger a écrit :
>
> The only extra consideration that would need to be made is when using
> write-through proxying (SVNMasterURI). Merely noting for completeness that
> you would need an extra Location block in your httpd configuration. But your
>
On Thu, 22 Aug 2019 09:38:02 -0400, Mark Phippard wrote:
>My first choice option would be to setup a repository on a second server
>and use svnsync from a post-commit hook script to sync the change. After
>that, I would use svnadmin hotcopy with the new --incremental option (as of
>1.8?). Dump
[replying via Gmane]
Andreas Stieger:
>The dump format is not the best option for backups. The
>restore time is much too slow as you need to recover from a
>serialized format. In many hand-baked scripts the dump
>method misses point-in-time recovery capabilities, ->
Why should I need those if SV
On Thu, Aug 22, 2019 at 9:16 AM Anton Shepelev wrote:
> [Having failed to post this message via Gmane, I am sending it by e-mail]
>
> Hello, all
>
> In order to write a backup script in the Windows batch
> language, I was reading the section "Migrating Repository
> Data Elsewhere" from "Repositor
Hello,
> In order to write a backup script in the Windows batch
> language, I was reading the section "Migrating Repository
> Data Elsewhere" from "Repository Maintenance":
>
>http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html
The dump format is not the best option for backups. The
[Having failed to post this message via Gmane, I am sending it by e-mail]
Hello, all
In order to write a backup script in the Windows batch
language, I was reading the section "Migrating Repository
Data Elsewhere" from "Repository Maintenance":
http://svnbook.red-bean.com/en/1.7/svn.reposadmi
On Thu, 22 Aug 2019 13:45:52 +0200, "Andreas Stieger"
wrote:
>Hello,
>
>> If I create a "Private" repository on this server and store my projects
>> in that repository, can it interfere with the backed up repos?
>
>This works without issues as long as the repository names are separate.
>
>> AFAI
Hello,
> If I create a "Private" repository on this server and store my projects
> in that repository, can it interfere with the backed up repos?
This works without issues as long as the repository names are separate.
> AFAIK you cannot write anything in a synced repository except via
> svnsync
I have a fully updated Ubuntu Server 18 LTS sitting in my home LAN
acting as a subversion backup server for my company via svnsync.
It runs svn 1.9.7 as does the production server at the company.
So I have set it up with the same repositories as on the production
server (which is on Windows Serve
Hello!
We are attempting to run `svn info` against a working copy as a
service user on Windows Server 2019. The user in question has never
actually logged onto the server, therefore there is no existing user
profile for that user.
We were previously using svn.exe from the 1.7 branch; we noticed t
19 matches
Mail list logo
