Re: Questions about setting up Subversion Server

hello Daniel, many thanks for your answers. Best Regards, Felix On 23.11.22 22:21, Daniel Shahaf wrote: Felix Natter wrote on Tue, Nov 15, 2022 at 09:03:49 +0100: - In my svnserve wrapper I call this: exec /usr/bin/svnserve "$@" -r /repos -> Does the (Linux-) system automatically call this

Re: Questions about setting up Subversion Server

Felix Natter wrote on Tue, Nov 15, 2022 at 09:03:49 +0100: > - In my svnserve wrapper I call this: > > exec /usr/bin/svnserve "$@" -r /repos > > -> Does the (Linux-) system automatically call this with "-t"? > The -t is added by the client when it invokes the tunnel command (ssh(1)). This is d

Re: Questions about a script for regular backups

On 14.10.2019 15:25, Anton Shepelev wrote: >> See the example mentioned in the 1.8 release notes [1]: >> >> svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos > Hmm. I should also expect a simple freeze/unfreeze pair > with the caller resposible for unfreezing a fronzen r

Re: Questions about a script for regular backups

Johan Corveleyn >Just to mention another option: Since 1.8 there is the >command 'svnadmin freeze', which locks the repository for >writing while you run another command. That way, you can >use regular backup / copy commands (like rsync) to create a >consistent copy. I think `freeze' is also help

Re: Questions about a script for regular backups

On Tue, Aug 27, 2019 at 5:06 AM Johan Corveleyn wrote: > On Mon, Aug 26, 2019 at 9:01 PM Mark Phippard wrote: > > > > On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev > wrote: > >> > >> I have now set up a post-commit hook that makes an > >> --incremental hotcopy. With the destination on the sam

Re: Questions about a script for regular backups

On Mon, Aug 26, 2019 at 9:01 PM Mark Phippard wrote: > > On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev wrote: >> >> I have now set up a post-commit hook that makes an >> --incremental hotcopy. With the destination on the same >> machine's HDD, it takes about two seconds, but with a >> network s

Re: Questions about a script for regular backups

On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev wrote: > I have now set up a post-commit hook that makes an > --incremental hotcopy. With the destination on the same > machine's HDD, it takes about two seconds, but with a > network share it lasts 30 seconds. Is it expected behavior > for committ

Re: Questions about a script for regular backups

I have now set up a post-commit hook that makes an --incremental hotcopy. With the destination on the same machine's HDD, it takes about two seconds, but with a network share it lasts 30 seconds. Is it expected behavior for committing a tiny change in a text file? If not, then where shall I look

Re: Questions about a script for regular backups

Thank you for your comments, Andreas: > Literally any situation where the undesired change to be > recovered from happened before this last and single copy > was taken. I am going to prevent this by means of `svnadmin verify': > > Is it practical to call it [verify] daily with a several > > Gb,

Re: Questions about a script for regular backups

Hi, > > A hobbyist approach this this has lead to many instances > > of data loss in serious applications. > > While planning a backup strategy, one must consider the > possible malfunctions and ways to counteract them. How was > the data lost in the cases you describe? Literally any situation w

Re: Questions about a script for regular backups

Andreas Stieger to Anton Shepelev: > > No, it depends on one's purpose. If it is to keep the > > data in case of HDD crashes, a single mirror is > > sufficient. > > A hobbyist approach this this has lead to many instances > of data loss in serious applications. While planning a backup strategy,

Re: Questions about a script for regular backups

> No, it depends on one's purpose. If it is to keep the data > in case of HDD crashes, a single mirror is sufficient. A hobbyist approach this this has lead to many instances of data loss in serious applications. > again, since an SVN repository maintains its whole history, > a point-in-time

Re: Questions about a script for regular backups

Andreas Stieger to Anton Shepelev: > > Thanks to everybody for their replies. I now understand > > that -- incremental hot-copies are sufficient for > > regular backups, which can then be mirrored by content- > > aware file- synchronisation tools, but the problem > > remains of preventing an acci

Re: Questions about a script for regular backups

Hello, > that --incremental hot-copies are sufficient for regular > backups, which can then be mirrored by content-aware file- > synchronisation tools, but the problem remains of preventing > an accidental propagation of corrupt data into the backup. > How do you solve it? What the fruit do you m

Re: Questions about a script for regular backups

Thanks to everybody for their replies. I now understand that --incremental hot-copies are sufficient for regular backups, which can then be mirrored by content-aware file- synchronisation tools, but the problem remains of preventing an accidental propagation of corrupt data into the backup. How do

Re: Questions about a script for regular backups

Le ven. 23 août 2019 à 17:10, Mark Phippard a écrit : > > On Fri, Aug 23, 2019 at 11:06 AM Nathan Hartman > wrote: >> >> On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote: >>> >>> Anyway ... the only danger of a repository format is if you upgrade to >>> latest and then for some reason need

Re: Questions about a script for regular backups

On Fri, Aug 23, 2019 at 11:06 AM Nathan Hartman wrote: > On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote: > >> Anyway ... the only danger of a repository format is if you upgrade to >> latest and then for some reason need to downgrade your server binaries to >> an older version. You can alw

Re: Questions about a script for regular backups

On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote: > Anyway ... the only danger of a repository format is if you upgrade to > latest and then for some reason need to downgrade your server binaries to > an older version. You can always use an older format with a newer version. > If you did wis

Re: Questions about a script for regular backups

On Fri, Aug 23, 2019 at 4:16 AM Pierre Fourès wrote: > Hello, > > Le jeu. 22 août 2019 à 16:47, Mark Phippard a écrit : > > > > > >> Cannot they become obsolete when a new version of SVN comes > >> out? > > > > > > No. It is a valid copy of the repository. > > > >> Are they portable across op

Re: Questions about a script for regular backups

Hello, Le jeu. 22 août 2019 à 16:47, Mark Phippard a écrit : > > >> Cannot they become obsolete when a new version of SVN comes >> out? > > > No. It is a valid copy of the repository. > >> Are they portable across operating systems and >> filesystems? (I fear not) > > > Yes, they are absolutel

Re: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

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]

Re: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

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.

Re: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

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

RE: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

[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

Re: Questions about a script for regular backups

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

Re: Questions about a script for regular backups

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

Re: Questions About Backup Repository

On Sun, May 6, 2018 at 9:38 PM, wrote: > Dear > > We use TortoiseSVN to manage the code,and backup repository with svnsync. > We backup repository to remonte servicer with svnsync. > When edit anyone in the remote repository,the remote repository will be > breakdown and never to be used again. >

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

Johan Corveleyn wrote on Sat, 29 Jul 2017 11:39 +0200: > Two other things which are also not transferred by svnsync (nor by dump/load): > - locks (server-side locks, of the svn:needs-lock type): these should > be copied from $OLDREPOS/db/locks to $NEWREPOS/db/locks It would be best to do this unde

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

On Sat, Jul 29, 2017 at 1:16 AM, James H. H. Lampert wrote: > On 7/27/17, 11:15 PM, Ryan Schmidt wrote: >> >> Sounds plausible. An empty pre-revprop-change hook script would allow >> any revprop change, which you may not want. It's probably possible to >> write a more-specific script that would al

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

On 7/27/17, 11:15 PM, Ryan Schmidt wrote: Sounds plausible. An empty pre-revprop-change hook script would allow any revprop change, which you may not want. It's probably possible to write a more-specific script that would allow only the changes svnsync needs and disallow others. . . . svnsync i

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

On Thu, Jul 27, 2017 at 3:23 PM, James H. H. Lampert wrote: > Greetings. > > My employer has put me on a project of moving our SVN and Trac servers from > the old Windows Server 2003 box on which they're currently running over to a > Google Compute Engine instance. > > To that end, I've set up the

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

They recommend setting up a "pre-revprop-change" script with nothing in it but the initial "shebang", for each target repository, and then using "svnsync" to migrate the repositories. It also assumes the existence of an "svnsync" user-ID on the target system, which (at least assuming it's an o

Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance

On Jul 27, 2017, at 14:23, James H. H. Lampert wrote: > > They recommend setting up a "pre-revprop-change" script with nothing in it > but the initial "shebang", for each target repository, and then using > "svnsync" to migrate the repositories. Sounds plausible. An empty pre-revprop-change ho

Re: Questions about --pin-externals option

On 2016-04-26, Branko Čibej wrote: > Externals /are/ nested working copies as far as the client is concerned. > Sure nothing prevents you from using nested working copies that aren't > tracked as externals, but you'll have to invent your own tooling for > checkouts, updates, commits, etc. Yea, I

Re: Questions about --pin-externals option

On 26.04.2016 20:32, Grant Edwards wrote: > On 2016-04-26, Branko Čibej wrote: >> On 26.04.2016 02:09, Grant Edwards wrote: >>> Thanks again! Now I just have to decided whether to use >>> intra-repository externals or nested working copies to share >>> directories of source code among a group of p

Re: Questions about --pin-externals option

On 2016-04-26, Branko Čibej wrote: > On 26.04.2016 02:09, Grant Edwards wrote: >> Thanks again! Now I just have to decided whether to use >> intra-repository externals or nested working copies to share >> directories of source code among a group of projects. It may depend on >> how smartsvn handle

Re: Questions about --pin-externals option

On 26.04.2016 02:09, Grant Edwards wrote: > Thanks again! Now I just have to decided whether to use > intra-repository externals or nested working copies to share > directories of source code among a group of projects. It may depend on > how smartsvn handles tagging/branching that involves external

Re: Questions about --pin-externals option

On 26.04.2016 01:27, Stefan wrote: > Hi Edwards, >> A couple questions regarding "svn copy --pin-externals": >> >> 1) I thought I saw that when the --pin-externals option was being >> developed it handled things differently when the destination was a >> tag verses a branch. >> >> IIRC,

Re: Questions about --pin-externals option

On 2016-04-25, Stefan wrote: > Hi Edwards, >> A couple questions regarding "svn copy --pin-externals": >> >> 1) I thought I saw that when the --pin-externals option was being >> developed it handled things differently when the destination was a >> tag verses a branch. >> >> IIRC, copy

Re: Questions about --pin-externals option

Hi Edwards, A couple questions regarding "svn copy --pin-externals": 1) I thought I saw that when the --pin-externals option was being developed it handled things differently when the destination was a tag verses a branch. IIRC, copy --pin-externals to a "tag" destination just pinne

Re: questions about subversion secondary development

On 2013-04-29 10:36, Cooke, Mark wrote: -Original Message- From: Edwin Cheung [mailto:edoka...@gmail.com] Sent: 27 April 2013 07:55 To: users@subversion.apache.org Subject: questions about subversion secondary development Dear sir or madam: When I use the binary packages ( Win32S

RE: questions about subversion secondary development

> -Original Message- > From: Edwin Cheung [mailto:edoka...@gmail.com] > Sent: 27 April 2013 07:55 > To: users@subversion.apache.org > Subject: questions about subversion secondary development > > Dear sir or madam: >When I use the binary packages ( Win32Svn >

Re: Questions about importing data into the Subversion repository on a WINDOWS 2003 Server platform

Anastasio, David M CTR USAF AFMC ESC/HNID wrote: >I have installed Apache Subversion on a Windows 2003 Server desktop, >along with the TortoiseSVN client. >[...] >My question is how to use the subversion import utility to place my >source files under source code control. TSVN comes with documentat

Re: Questions about importing data into the Subversion repository on a WINDOWS 2003 Server platform

On Fri, Feb 24, 2012 at 11:21:54AM -0500, Anastasio, David M CTR USAF AFMC ESC/HNID wrote: > The Subversion documentation references UNIX command line examples (svn > import) but I'm working on a WINDOWS desktop; how do I invoke the > Subversion commands on a WINDOWS platform? If you install Tort

Re: Questions

Geoff Hoffman wrote: >Why remove the Id keyword? Just delete the file (not svn delete, OS level >delete) then svn up. > > >On Mon, Jun 13, 2011 at 11:08 PM, Lorenz wrote: >[...] >> you can just remove the svn:keywords property -- Lorenz

Re: Questions

Why remove the Id keyword? Just delete the file (not svn delete, OS level delete) then svn up. On Mon, Jun 13, 2011 at 11:08 PM, Lorenz wrote: > Richard Cavell wrote: > >[...] > > How do I get my "$Id$" back? > > if there are no local changes to the file, you can just remove the > svn:keywords

Re: Questions

Richard Cavell wrote: >[...] > How do I get my "$Id$" back? if there are no local changes to the file, you can just remove the svn:keywords property, delete the file and then perform an update on the wc. That will give you the state of the $Id$ keyword as it was initialy committed. -- Lorenz

Re: Questions

On Jun 13, 2011, at 05:12, Richard Cavell wrote: >>> Now, how do I turn it off? >> > >> svn propdel svn:keywords myfile >> svn ci -m "Turn off Id keyword" myfile >> > > cat myfile gives: > > > $Id: myfile 102 2011-06-13 08:54:02Z richardcav...@mail.com $ > > How do I get my "$Id$" back?

Re: Questions

On Jun 13, 2011, at 10:00, Daniel Shahaf wrote: > Ryan Schmidt wrote on Mon, Jun 13, 2011 at 04:06:21 -0500: >> On Jun 13, 2011, at 03:55, Richard Cavell wrote: >>> 2. Someone suggested creating a repository by installing DropBox on every >>> computer and doing: >>> >>> svnadmin create ~/DropB

Re: Questions

Ryan Schmidt wrote on Mon, Jun 13, 2011 at 04:06:21 -0500: > On Jun 13, 2011, at 03:55, Richard Cavell wrote: > > 2. Someone suggested creating a repository by installing DropBox on every > > computer and doing: > > > > svnadmin create ~/DropBox > > > > Does this seem like a workable idea (for

Re: Questions

Thanks for your reply, but... > 4. I've managed to get keyword substitution working. But once it's working, > how do I turn it off for that file type? eg > > Create myfile, containing > $Id$ > svn add myfile > svn propset svn:keywords "Id" myfile > svn ci -m > "Turn on Id keyword" myfile >

Re: Questions

On Jun 13, 2011, at 03:55, Richard Cavell wrote: > 1. Is svn resolved foo the same as svn resolve --accept working foo ? "svn help resolved" says yes: Note: this subcommand does not semantically resolve conflicts or remove conflict markers; it merely removes the conflict-related artifac

Re: Betr.: RE: Betr.: RE: Questions about svn:externals

Johan Corveleyn wrote on Thu, Jan 20, 2011 at 13:40:49 +0100: > If someone decides to put a lot of effort in this for a custom > solution, you may want to consider another option: to take a good look > at issue http://subversion.tigris.org/issues/show_bug.cgi?id=2662 > (authz with wildcards), and t

Re: Betr.: RE: Betr.: RE: Questions about svn:externals

On Thu, Jan 20, 2011 at 10:41 AM, Jan Keirse wrote: >  David Aldrich schreef op 20/01/2011 10:24:28: > >> Hi Jan >> >> > I've changed my mind, there is something that may be better than >> > externals, although it requires a little trick. >> > You should be able to create a commit hook that check

Betr.: RE: Betr.: RE: Questions about svn:externals

David Aldrich schreef op 20/01/2011 10:24:28: > Hi Jan > > > I've changed my mind, there is something that may be better than > > externals, although it requires a little trick. > > You should be able to create a commit hook that checks if the authz file > > reflects the restrictions you want

RE: Betr.: RE: Questions about svn:externals

Hi Jan > I've changed my mind, there is something that may be better than > externals, although it requires a little trick. > You should be able to create a commit hook that checks if the authz file > reflects the restrictions you want on a specific folder > (*/thesecretfolder/*) for the branch >

Betr.: RE: Questions about svn:externals

Jan Keirse schreef op 19/01/2011 10:58:24: > David Aldrich schreef op 19/01/2011 10:42:15: > > > Hi > > > > I'd like to explain my high level problem, which I hoped externals > > would solve. Maybe someone will have a suggestion how to properly > > address this. > > > > Our source code is u

RE: Betr.: RE: Questions about svn:externals

Hi Jan > In the future hopefully an authz file with wildcards will solve the > problem: > http://subversion.tigris.org/issues/show_bug.cgi?id=2662 > > Right now I don't there's anything better than externals. Thanks, I think that this is what we need. However, I can't see this on the svn roadm

Betr.: RE: Questions about svn:externals

David Aldrich schreef op 19/01/2011 10:42:15: > Hi > > I'd like to explain my high level problem, which I hoped externals > would solve. Maybe someone will have a suggestion how to properly > address this. > > Our source code is used by several developer groups. A few files > need to be conf

RE: Questions about svn:externals

Hi I'd like to explain my high level problem, which I hoped externals would solve. Maybe someone will have a suggestion how to properly address this. Our source code is used by several developer groups. A few files need to be confidential to one group. We can set access permissions on these fil

Re: Questions about svn:externals

Hi again, never to old to learn something ... ;-) Am 19.01.2011 10:26, schrieb Martin Rabl: Am 19.01.2011 10:02, schrieb David Aldrich: > to do this, so how can we prevent such commits being made? IMHO there is no way to prevent external commits - it would be contrary to the principles of svn,

RE: Questions about svn:externals

Hi Martin and Jan > You mean: not to the repository, where the other repository is linked > into via svn:external? Sorry, I have misunderstood the manual. I thought that commits to a file in the folder that has the svn:external property would not be reflected in the source repo. This is not tru

Re: Questions about svn:externals

Hi, Am 19.01.2011 10:02, schrieb David Aldrich: 1) Subversion allows you to commit a change within the > directory that uses the svn:external property. > This change will not be committed to the referenced > (source) directory/repo. You mean: not to the repository, where the other repository is