Re: Questions about setting up Subversion Server

[Felix Natter]

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 with "-t"?


The -t is added by the client when it invokes the tunnel command
(ssh(1)).  This is documented in the [tunnels] section of the default
~/.subversion/config file and in Chapter 6 of the book (just search for
"-t").


- If I use ssh auth (svn+ssh://), do I have to change the options in
/svnserve.conf,
  like anon-access=none? (I just want access based on file system
permissions, and no
  anon access)


If you don't run svnserve without -t, then the value of anon-access
shouldn't matter.

I'd probably still set it to «none» just in case.


- I am migrating from a 3rd party server which used a different directory
structure,
   and system users (no LDAP), but also svn+ssh://.
   Can I keep all the history, even if some old users in the 3rd party server
are not
   available in the new LDAP auth? (but of course the user names of existing
users are kept)
   In other words: does a SVN Server store the user information (history) as
strings or
   something else that is linked to accounts?


As strings, in the svn:author revprop.


- I am using strict permissions for two (LDAP-)groups in the base
directories for the repos
  (/repos/students, /repos/employees). The Howto I used [1] is using "umask
002" in the
  wrapper. I think for my case (groups) "007" is sufficient, right?

[1]https://www.startupcto.com/server-tech/subversion/setting-up-svn

Please CC: me, as I am not subscribed.

Many Thanks and Best Regards!

Felix

--

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone    :   +49 228 5348 0430
Direct   :   +49 228 4097 7118
Email    :felix.nat...@sidact.com
Web  :http://www.sidact.com/





--

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone    :   +49 228 5348 0430
Direct   :   +49 228 4097 7118
Email    : felix.nat...@sidact.com
Web  : http://www.sidact.com/



OpenPGP_signature
Description: OpenPGP digital signature

Re: Questions about setting up Subversion Server

[Daniel Shahaf]

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 documented in the [tunnels] section of the default
~/.subversion/config file and in Chapter 6 of the book (just search for
"-t").

> - If I use ssh auth (svn+ssh://), do I have to change the options in
> /svnserve.conf,
>  like anon-access=none? (I just want access based on file system
> permissions, and no
>  anon access)
> 

If you don't run svnserve without -t, then the value of anon-access
shouldn't matter.

I'd probably still set it to «none» just in case.

> - I am migrating from a 3rd party server which used a different directory
> structure,
>   and system users (no LDAP), but also svn+ssh://.
>   Can I keep all the history, even if some old users in the 3rd party server
> are not
>   available in the new LDAP auth? (but of course the user names of existing
> users are kept)
>   In other words: does a SVN Server store the user information (history) as
> strings or
>   something else that is linked to accounts?
> 

As strings, in the svn:author revprop.

> - I am using strict permissions for two (LDAP-)groups in the base
> directories for the repos
>  (/repos/students, /repos/employees). The Howto I used [1] is using "umask
> 002" in the
>  wrapper. I think for my case (groups) "007" is sufficient, right?
> 
> [1] https://www.startupcto.com/server-tech/subversion/setting-up-svn
> 
> Please CC: me, as I am not subscribed.
> 
> Many Thanks and Best Regards!
> 
> Felix
> 
> -- 
> 
> *SIDACT GmbH
> Simulation Data Analysis and
> Compression Technologies
> *
> *Felix Natter*
> /Software Developer /
> 
> Auguststraße 29
> 53229 Bonn
> Germany
> 
> Phone  :   +49 228 5348 0430
> Direct :   +49 228 4097 7118
> Email  : felix.nat...@sidact.com
> Web    : http://www.sidact.com/
> 

Questions about setting up Subversion Server

[Felix Natter]

hello SVN Users,

I have set up a basic SVN Server with svn+ssh:// auth (System users with 
LDAP)

by wrapping svnserve [1]

I have a few questions for which I could not find answers in the manual:

- In my svnserve wrapper I call this:

exec /usr/bin/svnserve "$@" -r /repos

-> Does the (Linux-) system automatically call this with "-t"?

- If I use ssh auth (svn+ssh://), do I have to change the options in 
/svnserve.conf,
 like anon-access=none? (I just want access based on file system 
permissions, and no

 anon access)

- I am migrating from a 3rd party server which used a different 
directory structure,

  and system users (no LDAP), but also svn+ssh://.
  Can I keep all the history, even if some old users in the 3rd party 
server are not
  available in the new LDAP auth? (but of course the user names of 
existing users are kept)
  In other words: does a SVN Server store the user information 
(history) as strings or

  something else that is linked to accounts?

- I am using strict permissions for two (LDAP-)groups in the base 
directories for the repos
 (/repos/students, /repos/employees). The Howto I used [1] is using 
"umask 002" in the

 wrapper. I think for my case (groups) "007" is sufficient, right?

[1] https://www.startupcto.com/server-tech/subversion/setting-up-svn

Please CC: me, as I am not subscribed.

Many Thanks and Best Regards!

Felix

--

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone    :   +49 228 5348 0430
Direct   :   +49 228 4097 7118
Email    : felix.nat...@sidact.com
Web  : http://www.sidact.com/



OpenPGP_signature
Description: OpenPGP digital signature

Re: SVN basic questions.

[Daniel Shahaf]

Daniel Sahlberg wrote on Fri, 20 Aug 2021 07:55 +00:00:
> Den fre 20 aug. 2021 kl 05:02 skrev A Z :
> > -Can multiple users add to a committed branch node, and que up
> >   adds, or is this in fact going to nothing, while granting a message?
> >   Is it the case that only the first add to the branch node will be added,
> >   queued, while others will be rejected until that first node is committed?
> 
> You can commit as you would normally do in /trunk. Any conflicts will 
> be managed when updating the working copy (before commit, if needed).

It might help to clarify the terminology here.  Subversion's own
documentation does not use the term "queueing" at all, and does not use
the term "add" except in the narrow sense of an operation that results
in a new versioned directory entry.  «add» is a local operation (doesn't
contact the server).

It's not clear to me what sense you use those two terms in.  In
particular, when you write "until that first node is committed", you
seem to be assuming some sort of interim state, a "node" that has been
"added" but not been "committed", and that affects other users.  There's
no such thing.

The repository is a versioned filesystem tree.  Changes to that tree
(commits) are made transactionally.  A commit that has not completed
does not affect other commits in any way (cf. ACID).

> (You can configure a file to require locking, but that is a separate 
> question from branching. To edit a locked file you must aquire the lock 
> from the server and only one person at a time can hold the lock to a 
> certain file. There is no locking on folder level).

Re: SVN basic questions.

[Daniel Sahlberg]

Den fre 20 aug. 2021 kl 05:02 skrev A Z :

> -Can you commit after adding, to a branch node?
>

Yes. Branches are nothing special in Subversion, just another folder
(copied from somewhere). Then you may, by convention and project
guidelines, have restrictions on what you can do and should do in a branch.


> -Can multiple users add to a committed branch node, and que up
>   adds, or is this in fact going to nothing, while granting a message?
>   Is it the case that only the first add to the branch node will be added,
>   queued, while others will be rejected until that first node is committed?
>

You can commit as you would normally do in /trunk. Any conflicts will be
managed when updating the working copy (before commit, if needed).

(You can configure a file to require locking, but that is a separate
question from branching. To edit a locked file you must aquire the lock
from the server and only one person at a time can hold the lock to a
certain file. There is no locking on folder level).

Kind regards,
Daniel

SVN basic questions.

[A Z]

-Can you commit after adding, to a branch node?

-Can multiple users add to a committed branch node, and que up
  adds, or is this in fact going to nothing, while granting a message?
  Is it the case that only the first add to the branch node will be added,
  queued, while others will be rejected until that first node is committed?

Re: Simple Trio of Questions about Apache SVN

[Daniel Shahaf]

Andreas Stieger wrote on Tue, 17 Aug 2021 08:24 +00:00:
> Hi,
>  
> > -In SVN, can you have multiple additions, queued up, marked with an A?
> 
> No queuing feature, but changelists on file granularity.
> See https://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html
> 
> > If so, can the queued edition(s) be reviewed for marked files,
> 
> Using svn diff which takes file names and changelists
> 
> > and can those marked files be examined internally for change markers too?
> 
> Yes by calling external tools or tools integrating svn.
> 
> > If so, what are the command(s) involved?
> 
> svn cl, svn diff
> 
> > Can addition(s) be deleted before any comitting?
> 
> Yes using diff tools, usually those implementing per-line reverts. Meld 
> is a generic tools, IDEs offer their own support.

The question specified "marked with an A", which makes it sound like
it's asking what's the way to cancel an uncommitted «svn add».
That'd be «svn revert» (and wouldn't need to involve changelists).

Re: SVN startup questions.

[Nico Kadel-Garcia]

On Tue, Aug 17, 2021 at 5:30 AM A Z  wrote:
>
> Just some basic getting started questions about SVN.
>
> -How can a series of different branches all be merged back into one again?
> By 'adding' their checked out, now finished code content, and then committing
> them in the right order to the trunk, one at a time?

Please study the "svn merge" command. That is precisely what it is
for. A good GUI such as TortoiseSVN will help a great deal.

> -What exactly is a Tag?  I don't understand, what is it, and what
> does it represent?  Why exactly are tags used, when, apparently,
> they are near the same as branches?

Tags and branches in SVN are just copies of content from the master.
They may include only a small part of the master, they may have any
layout people want, and often people get peculiar about this. They are
really just copies of content in folders, typically alongside the
master. People often apply rules such as "no editing or renaming a
tag!!" or "no deleting tags unless you are an admin!"

> -As an SVN administrator, I want a setup where there is a main trunk,
> and all developers start with their own branch, which they may add their
> own branches to, adding and committing their updated code to, progressively,
> on their advancing sub nodes.  Only the administrator (super?) user has the
> ability to commit to the branch, from absolutely anywhere in the tree, to 
> advance
> the trunk.  The administrator then creates a new, latest trunk node, and
> new (commencing) branches from there, all being the same as before,
> all based on the latest trunk node.  Developers may never delete their
> nodes, and must ask the administrator to do so.

What you describe as the "latest trunk node" would be a "release tag".
Review the pre-commit scripts and permissions for popular setups that
do all or nearly all of what you seek.

> Can someone send an example in reply as to how I could configure
> SVN permissions to require this, in relevant .conf file(s)?

The "Red Book" gives explicit examples of how to manage tags in just
this way, at https://svnbook.red-bean.com/ . I'd encourage you to go
to that document first for questions like "what is a tag?"

SVN startup questions.

[A Z]

Just some basic getting started questions about SVN.

-How can a series of different branches all be merged back into one again?
By 'adding' their checked out, now finished code content, and then committing
them in the right order to the trunk, one at a time?

-What exactly is a Tag?  I don't understand, what is it, and what
does it represent?  Why exactly are tags used, when, apparently,
they are near the same as branches?

-As an SVN administrator, I want a setup where there is a main trunk,
and all developers start with their own branch, which they may add their
own branches to, adding and committing their updated code to, progressively,
on their advancing sub nodes.  Only the administrator (super?) user has the
ability to comit to the branch, from absolutely anywhere in the tree, to advance
the trunk.  The administrator then creates a new, latest trunk node, and
new (commencing) branches from there, all being the same as before,
all based on the latest trunk node.  Developers may never delete their
nodes, and must ask the administrator to do so.

Can someone send an example in reply as to how I could configure
SVN permissions to require this, in relevant .conf file(s)?

Re: Simple Trio of Questions about Apache SVN

[Andreas Stieger]

Hi,
 
> -In SVN, can you have multiple additions, queued up, marked with an A?

No queuing feature, but changelists on file granularity.
See https://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html

> If so, can the queued edition(s) be reviewed for marked files,

Using svn diff which takes file names and changelists

> and can those marked files be examined internally for change markers too?

Yes by calling external tools or tools integrating svn.

> If so, what are the command(s) involved?

svn cl, svn diff

> Can addition(s) be deleted before any comitting?

Yes using diff tools, usually those implementing per-line reverts. Meld is a 
generic tools, IDEs offer their own support.

Andreas

Simple Trio of Questions about Apache SVN

[A Z]

-In SVN, can you have multiple additions, queued up, marked with an A?

-If so, can the queued edition(s) be reviewed for marked files, and can those 
marked files be examined internally for change markers too?  If so, what are 
the command(s) involved?

-Can addition(s) be deleted before any comitting?  If so, what is the command 
involved?

Z.

Re: Questions about a script for regular backups

[Branko Čibej]

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 repo...

Nope, you don't need that. If you do need a long-running,
explicitly-unfrozen freeze, you can easily implement it with a smart
enough command. Although, frankly, that way lies a ton of opportunities
for error.

-- Brane

Re: Questions about a script for regular backups

[Anton Shepelev]

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 helpful for atomic runs of `verify'
and `hotcopy' in order to ensure you do not accidentally
copy a corrupt repository.  Without `freeze', how can I make
sure that `hotcopy' applies exclusively to verified data?

>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 repo...

>Of course, in contrast with hotcopy, the original
>repository is locked for a (hopefully short) while, so
>users might experience errors/timeouts if this takes too
>long.

This is why I am going to apply it to a mirror kept in sync
with the main repo via an incremental hopcopy invoked from
the post-commit hook.  How can I skip synchronisation of the
mirror in the hook if it is currently frozen without making
other possible errors?  Does SVN provide a reliable lock
facility, or must I invent it myself in my backup
script/program using e.g. lock files?

-- 
Please, do not forward replies to the list to my e-mail.

Re: Questions about a script for regular backups

[Mark Phippard]

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 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 for the possible performance problems?  I
> >> have svn 1.8.16.
> >
> >
> > It is probably due to slowness of the IO across network to read what is
> in the target repository and then copy over the files. Other than tuning
> NFS or whatever you are using there is not much you can do.  This is why my
> first recommendation was to use svnsync. You could have a second backup
> server running and then use svnsync via https or svn protocol to that
> server.  This basically replays the commit transaction so performs
> comparably to the original commit. It also makes it a lot easier to send
> the backup around the world or to another data center since it is using a
> protocol that is meant for that sort of latency.
> >
>
> Does svnsync also copy locks and hook scripts?
>

No, neither of those are synced.  You would not want the hooks to sync
since you need to run different hooks on the backup server but locks are a
problem for people using that feature.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Johan Corveleyn]

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 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 for the possible performance problems?  I
>> have svn 1.8.16.
>
>
> It is probably due to slowness of the IO across network to read what is in 
> the target repository and then copy over the files. Other than tuning NFS or 
> whatever you are using there is not much you can do.  This is why my first 
> recommendation was to use svnsync. You could have a second backup server 
> running and then use svnsync via https or svn protocol to that server.  This 
> basically replays the commit transaction so performs comparably to the 
> original commit. It also makes it a lot easier to send the backup around the 
> world or to another data center since it is using a protocol that is meant 
> for that sort of latency.
>

Does svnsync also copy locks and hook scripts?

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. See the example
mentioned in the 1.8 release notes [1]:

svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos

Of course, in contrast with hotcopy, the original repository is locked
for a (hopefully short) while, so users might experience errors /
timeouts if this takes too long.

[1] http://subversion.apache.org/docs/release-notes/1.8.html#svnadmin-freeze

-- 
Johan

Re: Questions about a script for regular backups

[Mark Phippard]

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 committing a tiny change in a text file?  If not, then
> where shall I look for the possible performance problems?  I
> have svn 1.8.16.
>

It is probably due to slowness of the IO across network to read what is in
the target repository and then copy over the files. Other than tuning NFS
or whatever you are using there is not much you can do.  This is why my
first recommendation was to use svnsync. You could have a second backup
server running and then use svnsync via https or svn protocol to that
server.  This basically replays the commit transaction so performs
comparably to the original commit. It also makes it a lot easier to send
the backup around the world or to another data center since it is using a
protocol that is meant for that sort of latency.

That said, I have no idea what kind of performance you should be able to
get via NFS.  30 seconds seems slower than it ought to have been.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Anton Shepelev]

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 for the possible performance problems?  I
have svn 1.8.16.

-- 
Please, do not forward replies to the list to my e-mail.

Re: Questions about a script for regular backups

[Anton Shepelev]

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, several thousand-revision repository?
>
> Again, you don't need to care about how long the backup
> takes. Only about it's consistency and the time to restore
> in a restore event.

Then I propose the following strategy:

1. Maintain a repository mirror by calling
 svnadmin hotcopy --incremental
   from a post-commit hook.

2. Store the last verified hot-copy in an archive:

   a. make a hot copy of the mirror

   b. verify this secondary hot-copy in order not to lock
  the mirror for a long time,

   c. archive the secondary hot-copy in a format with error-
  correction, such as .rar.  I haven't found a free,
  stable, and easiliy available archiver with built-in
  error-correcion.

Of course, my script will notify the administrator of errors
at any step.

-- 
Please, do not forward replies to my e-mail.

Re: Questions about a script for regular backups

[Andreas Stieger]

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 where the undesired change to be recovered from 
happened before this last and single copy was taken.

[...]
> Dumps are very slow.  `svnadmin verify' emulates a dump.  Is
> it equally slow?

Pretty much, yes. But at backup time you don't care about that. And the 
recommendations against the dump format for a backup is the fact that the 
dump/load cycle is much slower, emphasis on the load part.

> Is it practical to call it daily with a
> several Gb, several thousand-revision repository?

To verify a successful backup, yes. Again, you don't need to care about how 
long the backup takes. Only about it's consistency and the time to restore in a 
restore event.

Good luck,
Andreas

Re: Questions about a script for regular backups

[Anton Shepelev]

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, one must consider the
possible malfunctions and ways to counteract them.  How was
the data lost in the cases you describe?

> > Then again, since an SVN repository maintains its whole
> > history, a point-in-time recovery is easily effected by
> > `svn up -r N'.
>
> That is application level (versioning), different from
> file level backup.

Yes, but it seems largely to withdraw the need of file-level
history.  All I need is a backup of a recent version of the
repository wihout data corruption.

> > The only potential problem is some quiet data
> > corruption, which is why I ask: will `hotcopy' propagate
> > data corruption or will it detect it via internal
> > integrity checks and fail?
>
> Your concern about silent data corruption is not
> consistent with your "a copy is a backup" statement. Why
> would you care about one while accepting the other?

As I said, it is "the only potential problem."

> That being said, hotcopy will copy corruptions that may
> have happened, even if in the incremental case will only
> do so when first processed. svnadmin verify is suitable
> for an integrity check.

Dumps are very slow.  `svnadmin verify' emulates a dump.  Is
it equally slow?  Is it practical to call it daily with a
several Gb, several thousand-revision repository?

-- 
Please, do not forward replies to my e-mail.

Re: Questions about a script for regular backups

[Andreas Stieger]

> 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 recovery is easily effected by
> `svn up -r N'.

That is application level (versioning), different from file level backup.

> The only potential problem is some quiet data corruption,
> which is why I ask: will `hotcopy' propagate data corruption
> or will it detect it via internal integrity checks and fail?

Your concern about silent data corruption is not consistent with your "a copy 
is a backup" statement. Why would you care about one while accepting the other? 
That being said, hotcopy will copy corruptions that may have happened, even if 
in the incremental case will only do so when first processed. svnadmin verify 
is suitable for an integrity check.

Andreas

Re: Questions about a script for regular backups

[Anton Shepelev]

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 accidental propagation of
> > corrupt data into the backup.  How do you solve it?
>
> What the fruit do you mean?  The whole purpose of a backup
> is that you can restore previous points in time.  That
> means multiple points in time, whenever the backup
> happened to be run.  Don't just make a copy and overwrite
> it every time. That is just copy, not a backup. Select
> backup software that can do that.

No, it depends on one's purpose.  If it is to keep the data
in case of HDD crashes, a single mirror is sufficient.  Then
again, since an SVN repository maintains its whole history,
a point-in-time recovery is easily effected by
`svn up -r N'.

The only potential problem is some quiet data corruption,
which is why I ask: will `hotcopy' propagate data corruption
or will it detect it via internal integrity checks and fail?

-- 
Please, do not forward replies to my e-mail.

Re: Questions about a script for regular backups

[Andreas Stieger]

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 mean? The whole purpose of a backup is that you can 
restore previous points in time. That means multiple points in time, whenever 
the backup happened to be run. Don't just make a copy and overwrite it every 
time. That is just copy, not a backup. Select backup software that can do that.

Andreas

Re: Questions about a script for regular backups

[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 accidental propagation of corrupt data into the backup.
How do you solve it?

-- 
Please, do not forward replies to my e-mail.

Re: Questions about a script for regular backups

[Pierre Fourès]

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 to downgrade your server binaries to 
>>> an older version.  You can always use an older format with a newer version.
>>
>>
>> If you did wish to downgrade to an older version, wouldn't a dump and load 
>> make that possible?
>>
>
> Absolutely.  Just pointing you that is the only time you would run into 
> something that would not just work and would require you to do something.
>

Thanks a lot Mark for your clarifications.

Pierre.

Re: Questions about a script for regular backups

[Mark Phippard]

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 always use an older format with a newer version.
>>
>
> If you did wish to downgrade to an older version, wouldn't a dump and load
> make that possible?
>
>
Absolutely.  Just pointing you that is the only time you would run into
something that would not just work and would require you to do something.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Nathan Hartman]

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 wish to downgrade to an older version, wouldn't a dump and load
make that possible?

Re: Questions about a script for regular backups

[Mark Phippard]

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 operating systems and
> >> filesystems? (I fear not)
> >
> >
> > Yes, they are absolutely portable across OS and FS. As is the repos
> itself.
>
> This prove to work in practice, but is it guaranteed that the fsfs
> repos format remain compatible between 1.X subsequent subversion
> releases ?
>

Yes it is.

When you upgrade your server to new version you do not have to touch
existing repositories. Think what a nightmare that would be for hosting
services or anyone with a lot of repositories.  It is not uncommon for a
new release to introduce a new repository format with some new features ...
though usually it is just some new efficiency in how the data is stored.
You need to dump/load if you are interested in getting these changes but
the server is capable of reading and writing every repository format.



>
> It appears the fsfs repos format sometime change between 1.X
> subversion releases. For example, Subversion 1.9 introduced fsfs
> format version 7. The release notes [1] mention and recommend to do a
> full dump / load cycle to be able to take benefits of this new format
> improvements.


Correct, you need to dump/load if you want to use the new format.

There is nothing wrong with having full dumps of your repository and you
need it to upgrade the format, but hot-copies are totally viable as a
backup and have a lot of advantages when it comes to the recovery process
in the event you need the backup.  I would not rush to using new formats
just because they are available. I have avoided the new format in 1.9 as
its benefits seemed tuned to scenarios that do not match my needs at all
and it has slower performance for what I think is the most common use case
which is using the Apache server hosting lots of repositories.

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.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Pierre Fourès]

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 absolutely portable across OS and FS. As is the repos itself.

This prove to work in practice, but is it guaranteed that the fsfs
repos format remain compatible between 1.X subsequent subversion
releases ?

It appears the fsfs repos format sometime change between 1.X
subversion releases. For example, Subversion 1.9 introduced fsfs
format version 7. The release notes [1] mention and recommend to do a
full dump / load cycle to be able to take benefits of this new format
improvements. Nonetheless, the notes also say that "older formats
remain supported". But this seems to be a beneficial side effect, not
a guarantee. It not seem enforced that backward compatibility will be
ensured for all 1.X subsequent subversion releases. To my
understanding, what's guaranteed to remain stable and compatible
between 1.X releases is the protocol between client and server, not
the underlying storing system. This is the reason I went to use
hot-copies for backups *and* dumps for migrations / reinstall. First
off all, it ensures that I will use the latest repos format available
for the particular instance of subversion I would run, and not miss to
upgrade it in order to take all benefits introduced by the targeted
subversion instance. Then, it ensures that in the case of un expected
situation where I would need to downgrade the subversion server
version, I wouldn't face the case of an upgraded fsfs repos format
unable to be read / handled by the said instance.

To my understanding, albeit very slow to load, dumps are absolutely
portable, meaning backward and forward compatible between subversion
server version. You mention the repos are absolutely portable across
OS and FS. Do you also mean between different subversion server
versions ? For instance, how would have it been handled if, by the
time Debian Jessie was out as the Stable Debian, and providing
subversion 1.8, I would have run subversion 1.9 on Ubuntu Xenial (and
used the repos format version 7), and then, for some external reasons
had to made the move to Debian Jessie. I doubt subversion 1.8 could be
able to read the hot-copies I would have done on the Ubuntu server. Or
would it ? If not, this means repos wouldn't be portable across OS
(while in their most current version at a specified date, for example,
early 2017 for the sake of this example). However, to my
understanding, would I have used dumps to backup my Ubuntu server, I
would have been able to restore the repos. Admittedly, I would have
lost the new functionalities introduced in subversion 1.9, but I still
would have been able to run subversion and access my repos, which
seems not to be the case in the event I would just rely on repos
hot-copies. Or would it ?

I would be really interested to get your view on all this in order to
see if I misunderstand what to expect from the hot-copies and the
dumps, and if my setup is overkill, or if it doesn't meet the
requirements I thought it would.

[1] https://subversion.apache.org/docs/release-notes/1.9

Best Regards,
Pierre.

Re: Questions about a script for regular backups

[Nico Kadel-Garcia]

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 point-in-time recovery capabilities, ->
>
> Why should I need those if SVN repositories store the
> complete history?

Because, on a bulky repository with bulky binaries, it is *butt slow*,
you can't easily prune the bulky binaries, and you will inevitably
have split-brain during time between the dump and the next dump/load.
Split-brain Is Not Your Friend(tm).

Re: Questions about a script for regular backups

[Anton Shepelev]

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

[Mark Phippard]

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 going across these
> >is managing the OS level permissions of the copy.  IOW, if
> >you run something as root the copy will tend to be owned by
> >root which might make it not ready for consumption without
> >a chown/chmod.
> >
> >I used to regular move fsfs repositories between an AS/400
> >EBCDIC server and Windows without issue.
>
> But SVN book has this:
>
>As described in the section called "Berkeley DB", hot-
>copied Berkeley DB repositories are not portable across
>operating systems, nor will they work on machines with a
>different "endianness" than the machine where they were
>created.
>

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.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Anton Shepelev]

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.  IOW, if
>you run something as root the copy will tend to be owned by
>root which might make it not ready for consumption without
>a chown/chmod.
>
>I used to regular move fsfs repositories between an AS/400
>EBCDIC server and Windows without issue.

But SVN book has this:

   As described in the section called "Berkeley DB", hot-
   copied Berkeley DB repositories are not portable across
   operating systems, nor will they work on machines with a
   different "endianness" than the machine where they were
   created.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Re: Questions about a script for regular backups

[Mark Phippard]

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 option (as of
> >1.8?).  Dump is not a great choice for backups.
>
> Thank you, but I should prefer a traditional backup
> approach.  You and other posters say that dumps are poor
> choice, so I shall backup incremental hot copies.  But the
> question remains that I have asked already in another reply:
> are hot-copies a reliable means of long-term storage.
>

Yes.  A hotcopy is basically just an intelligent backup/copy of the
repository. It is similar to what a backup/file copy tool might do except
that it is aware of in progress transactions and make sure you have a
consistent repository copy.


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 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.  IOW, if you run something as root the copy will
tend to be owned by root which might make it not ready for consumption
without a chown/chmod.

I used to regular move fsfs repositories between an AS/400 EBCDIC server
and Windows without issue.

The problem with dumps is that they have to be loaded to become usable and
it also only copies the repository content not other things like locks and
hook scripts.  The hotcopy is copying the repository files directly so you
have everything and you could even be serving the hotcopy from a
hotswappable server.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Anton Shepelev]

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 you, but I should prefer a traditional backup
approach.  You and other posters say that dumps are poor
choice, so I shall backup incremental hot copies.  But the
question remains that I have asked already in another reply:
are hot-copies a reliable means of long-term storage.
Cannot they become obsolete when a new version of SVN comes
out?  Are they portable across operating systems and
filesystems? (I fear not)

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Re: Questions about a script for regular backups

[Pierre Fourès]

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 recovery capabilities, ->
>
> >Just make sure you take a consistent snapshot, which can be
> >achieved by briefly locking it (svnadmin lock) or operating
> >on a consistent copy (svnadmin hotcopy).
>
> Is a hot-copy portable between SVN versions?  How safe is it
> to rely on a hot copy instead of a dump?
>

Indeed, I've encountered the problem that of restoring dumps was way
too slow and I ended up with a "belt and suspenders" solution
consisting of doing hot-copies to guarantee timely restoration time
(on systems with same software configurations), but also dumps to
guarantee restoration (on systems where the software configurations
would differs). For one reason or an other, but mainly if I need to
upgrade subversion and a breaking change would occurs, if the
hot-copies restorations wouldn't work, I would admittedly screw up to
restore it timely, but I would be able to restore it eventually.
However, while I do hot-copies every night, I intended to do dumps
only on week-ends. Up to now, the systems (svn-master and the storage
solution) handle the extra load of doing both solution every night, so
I let it that way (but might reconsider it in the future).

Admittedly, this situation should be very unlikely, but I feel more at
ease to have took it into account. More over, I also set it up it in
the event to handle two use case situation : the first is to complete
timely restoration in case of emergencies, this is handled with
hot-copies ; the second is to handle server upgrades (with software
upgrades), this is handled with dumps. For this second use case,
clearly, this shouldn't be done in emergency situations, so the dump
solution fit fine in this use case while also ensuring (and being
designed for) smooths upgrades between distinct software revisions. Of
course, if not implemented in the backup solution, I would never have
a dump ready when required for a server upgrade. Having integrated it
in the nightly (or weekly) backups, I know I always have a fresh dump
ready for when I intend to upgrade my server. BTW, I talk here of
logical server (the https://svn.company.com/), not physical (or
virtual) instances. I usually never upgrades production running
server. I prefer to install the "upgraded one" from a fresh install
and take the opportunity to do a full restoration to double-check
everything is fine and recoverable. In this particular pursuit, I find
the dumps to be very valuable.

Best Regards,
Pierre

RE: Questions about a script for regular backups

[Bo Berglund]

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 is not a great choice for backups.
>
>The main advantage of svnsync is you can push the change via HTTP or SVN to
>a different system where as hotcopy needs FS access so the only way to get
>the repos on to a second server is if you can mount the FS via NFS or
>something.

That is also what I did!
Our main server runs on a Windows Server on the corporate LAN.
The backup server is a Linux box in a different location altogether.
Both locations have fiber access to the Internet.

The backup server is set up with https access (thanks to LetsEncrypt and 
Certbot) 
through the router.

I have synced the servers after first loading the backup server from dump files 
so 
as not to have to use Internet bandwidth for the original data transfer.

On the Windows man server I have set up a nightly task that uses svnsync to 
synchronize the two servers. It has been running just fine for 18 months 
without fail.
Recommended solution.

Bo Berglund

Re: Questions about a script for regular backups

[Anton Shepelev]

[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 SVN repositories store the
complete history?

>-> and few people implement backup usability checks by
>loading the dump.

Is not a dump guarranteed to be usable if `svn dump'
succeeded?  If not, how do I load that dump without
intefering with the current work?

>If you have content-aware file based backup software
>available use that in the on-disk repository format.

The Unison file synchroniser, to work efficeintly on
Windows, has an option to use file size and modification
date to detect changes.  Would that work with SVN?

Do you suggest that I backup the contents of

  csvn\data\repositories

>Just make sure you take a consistent snapshot, which can be
>achieved by briefly locking it (svnadmin lock) or operating
>on a consistent copy (svnadmin hotcopy).

Is a hot-copy portable between SVN versions?  How safe is it
to rely on a hot copy instead of a dump?

-- 
Please, do not forward replies to the list to my e-mail.

Re: Questions about a script for regular backups

[Mark Phippard]

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 "Repository Maintenance":
>
>http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html
>
> where I found the following interesting paragraph:
>
>Another neat trick you can perform with this
>--incremental option involves appending to an existing
>dump file a new range of dumped revisions. For example,
>you might have a post-commit hook that simply appends the
>repository dump of the single revision that triggered the
>hook. Or you might have a script that runs nightly to
>append dump file data for all the revisions that were
>added to the repository since the last time the script
>ran. Used like this, svnadmin dump can be one way to back
>up changes to your repository over time in case of a
>system crash or some other catastrophic event.
>
> The book unfortunately does not seem to give any examples of
> this usage, leaving the following questions:
>
>   1.  Is "appending" to be understood literally, that is
>   using the >> operator on a previously existing dump
>   file, or is it a figure of speach describing a
>   supplementary dump file that shall be applied "on top"
>   of a previous one?
>
>   2.  How does one determine the revision range for a
>   routine incremental dump -- by calling
>   `svnlook youngest' before dumping?
>
>   3.  Must the backup script somehow store the last revision
>   in the dump between calls?  If so, I shall have to
>   keep in a file and not let anybody touch it.
>
>
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.

The main advantage of svnsync is you can push the change via HTTP or SVN to
a different system where as hotcopy needs FS access so the only way to get
the repos on to a second server is if you can mount the FS via NFS or
something.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Questions about a script for regular backups

[Andreas Stieger]

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 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, and few 
people implement backup usability checks by loading the dump. If you have 
content-aware file based backup software available use that in the on-disk 
repository format. Just make sure you take a consistent snapshot, which can be 
achieved by briefly locking it (svnadmin lock) or operating on a consistent 
copy (svnadmin hotcopy).

Andreas

Questions about a script for regular backups

[Anton Shepelev]

[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.reposadmin.maint.html

where I found the following interesting paragraph:

   Another neat trick you can perform with this
   --incremental option involves appending to an existing
   dump file a new range of dumped revisions. For example,
   you might have a post-commit hook that simply appends the
   repository dump of the single revision that triggered the
   hook. Or you might have a script that runs nightly to
   append dump file data for all the revisions that were
   added to the repository since the last time the script
   ran. Used like this, svnadmin dump can be one way to back
   up changes to your repository over time in case of a
   system crash or some other catastrophic event.

The book unfortunately does not seem to give any examples of
this usage, leaving the following questions:

  1.  Is "appending" to be understood literally, that is
  using the >> operator on a previously existing dump
  file, or is it a figure of speach describing a
  supplementary dump file that shall be applied "on top"
  of a previous one?

  2.  How does one determine the revision range for a
  routine incremental dump -- by calling
  `svnlook youngest' before dumping?

  3.  Must the backup script somehow store the last revision
  in the dump between calls?  If so, I shall have to
  keep in a file and not let anybody touch it.

-- 
Please, do not forward replies to the list to my e-mail.

Re: Svnadmin —incremental hotcopy (and other questions)

[Ryan Schmidt]

On Jun 19, 2018, at 08:31, Tom Browder> wrote:

> On Tue, Jun 19, 2018 at 06:31 Mark Phippard wrote:
> 
>> On Jun 19, 2018, at 7:25 AM, Tom Browder wrote:
>> ...
>> Finally, now that version 1.10 is out, will the redbook be made current and 
>> turned into a printed book?
> 
> The book is open source.  It is kept somewhat current but it is a volunteer 
> effort.  I think it is extremely unlikely that O'Reilly would ever do another 
> printing.
> 
> Hm, I wonder. I believe it’s been over 10 years since the second edition, and 
> lots of changes.  Maybe worth asking O’Reilly?

The book is a separate project. You should ask them. Scroll down to 
"Feedback/Contributing" on this page:

http://svnbook.red-bean.com

Re: Svnadmin —incremental hotcopy (and other questions)

[Tom Browder]

On Tue, Jun 19, 2018 at 06:31 Mark Phippard  wrote:

>
> > On Jun 19, 2018, at 7:25 AM, Tom Browder  wrote:

...

> > Finally, now that version 1.10 is out, will the redbook be made current
> and turned into a printed book?
>
> The book is open source.  It is kept somewhat current but it is a
> volunteer effort.  I think it is extremely unlikely that O'Reilly would
> ever do another printing.


Hm, I wonder. I believe it’s been over 10 years since the second edition,
and lots of changes.  Maybe worth asking O’Reilly?

Thanks, Mark.

Best regards,

-Tom

Re: Svnadmin —incremental hotcopy (and other questions)

[Mark Phippard]

> On Jun 19, 2018, at 7:25 AM, Tom Browder  wrote:
> 
> When an incremental hotcopy runs on REPO to BACKUPREPO is BACKUPREPO then 
> always a full backup of REPO?  That is,  could I do a full dump of BACKUPREPO 
> and copy it somewhere else for safekeeping of the full, current REPO?

It is a full backup up to whatever revision it now contains.  Yes you could 
take dumps off the backup.

> 
> Another question, is there any reason an incremental hotcopy could not be 
> used in a post commit hook?

No reason.  I think it would be a solid plan.

> 
> Finally, now that version 1.10 is out, will the redbook be made current and 
> turned into a printed book?

The book is open source.  It is kept somewhat current but it is a volunteer 
effort.  I think it is extremely unlikely that O'Reilly would ever do another 
printing.

Mark

Svnadmin —incremental hotcopy (and other questions)

[Tom Browder]

When an incremental hotcopy runs on REPO to BACKUPREPO is BACKUPREPO then
always a full backup of REPO?  That is,  could I do a full dump of
BACKUPREPO and copy it somewhere else for safekeeping of the full, current
REPO?

Another question, is there any reason an incremental hotcopy could not be
used in a post commit hook?

Finally, now that version 1.10 is out, will the redbook be made current and
turned into a printed book?

Thanks so much for any help.

Best regards,

-Tom

Re: Questions About Backup Repository

[Nico Kadel-Garcia]

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.
>

Never permit this if you expect scnsync to maintain a current copy of the
master repository. This is called "split-brain", and any working copies
from that modified svnsync repository should be considered corrupt.
Unfortunately, tracking down all the working copies can be very difficult,
since even logging on that server doesn't necessarily reveal who and what
made copies, especially local "file:///" based working copies.

We have no idea to revert it only to created a new remote repository.
> Is there any idea to revert the damaged repository ?
> Please  recommend some current ideas for me to backup the repository.
>

Create an entirely new svnsync based repository from scratch. Discard the
old one, and replace it.

It may be possible to simply delete all recent transactions from the
svnsync copy if you can identify when the inappropriate changes were made
on the new repository, especially if you have a good record of what the
last appropriate committed transaction was. But it's generally not worth
the work, and much safer to make a new svnsync repository from the old
master.

The big risk, I think, is not one that you can solve by fixing the damaged
svnsync repository. It's that you may have corrupted working copies based
on that corrupted svnsync copy. I'd strongly consider discarding whatever
URL you used to use for the old svnsync copy and switching to a new URL, to
help prevent any confusion about what the new valid read-only svnsync
repository is.

Nico Kadel-Garcia



> Hopes your replay.
> Thanks so much.
>
>
>
>
>
> *张虹*
> 信息科技部 科技管理处
> 工银安盛人寿保险有限公司
> 上海市黄浦区安澜路8号6楼
> 
> 电话：021-60392672
> 邮箱：hong.zh.zh...@icbc-axa.com
>

Questions About Backup Repository

[Hong . ZH . Zhang]

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.
We have no idea to revert it only to created a new remote repository. 
Is there any idea to revert the damaged repository ?
Please  recommend some current ideas for me to backup the repository.

Hopes your replay.
Thanks so much. 






张虹
信息科技部 科技管理处
工银安盛人寿保险有限公司
上海市黄浦区安澜路8号6楼
电话：021-60392672
邮箱：hong.zh.zh...@icbc-axa.com

Re: SVNSYNC questions

[Andreas Stieger]

Please consider stopping to top-post.


On 05/02/2018 10:43 PM, Paul Greene wrote:
> Ok, thanks, I was hoping I wouldn't have to manually create 110
> folders and set permissions, but it is what it is.

Is that not something what a shell is usually happy to do for you in a loop?

Anyway, as you may have already read from the documentation, svnsync can
be initialized on non-empty destination repositories which represent a
past state of the on-disk data. One would normally use the hotcopy
operation to get such a consistent copy. However,  if you can stop
commits for a bit this can be done using file system level tools such a
cp/tar/rsync/lvm, some of which can preserve permissions. This has the
added benefit of bypassing the initial sync time, which can be
significant for repositories of non-trivial size.

Andreas

Re: SVNSYNC questions

[Nico Kadel-Garcia]

On Wed, May 2, 2018 at 5:13 PM, Bo Berglund  wrote:
> On Wed, 2 May 2018 16:43:06 -0400, Paul Greene
>  wrote:
>
>>Ok, thanks, I was hoping I wouldn't have to manually create 110 folders and
>>set permissions, but it is what it is.
>
> And additionally since you have 110 repositories you need to run
> svnsync against each of these every time you want the sync to
> happen...
>
> I have structured my repos (9 of them) to contain the projects as top
> level directories, so there is only one command to run per repo to
> sync it with all of the upwards of 50-100 projects in each repo.

This is a very common but increasingly dangerous optimization as the
number of repositories grows. It makes all repositories dependent on a
single system, and makes rmanaging accidental bulky or high frequency
commits much harder to backup or cleanup.

Re: SVNSYNC questions

[Bo Berglund]

On Wed, 2 May 2018 16:43:06 -0400, Paul Greene
 wrote:

>Ok, thanks, I was hoping I wouldn't have to manually create 110 folders and
>set permissions, but it is what it is.

And additionally since you have 110 repositories you need to run
svnsync against each of these every time you want the sync to
happen...

I have structured my repos (9 of them) to contain the projects as top
level directories, so there is only one command to run per repo to
sync it with all of the upwards of 50-100 projects in each repo.


-- 
Bo Berglund
Developer in Sweden

Re: SVNSYNC questions

[Paul Greene]

Ok, thanks, I was hoping I wouldn't have to manually create 110 folders and
set permissions, but it is what it is.

On Wed, May 2, 2018 at 4:40 PM, Geoff Rowell  wrote:

> 1. Create the destination repositories.
> 2. Configure the destination repository access rights.
> 3. Use "svnsync init" on each destination repository.
> 4. Run "svnsync sync" on each to copy content.
>
> On Wed, May 2, 2018 at 4:16 PM, Paul Greene 
> wrote:
>
>> /data/subversion *contains* the repositories - it is not a repository
>> itself.
>>
>> So, will the /data/subversion/repo01, /data/subversion/repo02, ...
>> /data/subversion/repo110 automatically be created, or do I have to make
>> them myself?
>>
>> On Wed, May 2, 2018 at 4:09 PM, Andreas Stieger 
>> wrote:
>>
>>> Hello,
>>>
>>>
>>> On 05/02/2018 10:02 PM, Paul Greene wrote:
>>> > Prior to running svnsync, do I need to create the same folder
>>> > structure on the destination as on the source?
>>>
>>> no, just an empty, randomly named repository.
>>>
>>> > i.e. the source has 110 repositories located under /data/subversion. I
>>> > have a folder named /data/subversion on the destination as well where
>>> > I want the mirror to go.
>>>
>>> You need to have as many repositories on the far side as you need
>>> mirroring for. The on-disk data will look like this: conf  db  format
>>> hooks  locks  README.txt
>>> Each of these is a synchronization unit and needs to be set up
>>> separately. svn does not help you above that level, and below that any
>>> structure only exists inside the repository tree which is replicated.
>>>
>>> >
>>> > Do I need to manually create all the subversion repository folders
>>> > under /data/subversion before syncing, along with the same user
>>> > permissions/ownership? Or does subversion automatically create the
>>> > folders?
>>>
>>> Depends if /data/subversion IS the repository, or CONTAINS repositories.
>>>
>>> Andreas
>>>
>>
>>
>
>
> --
> Geoff Rowell
> geoff.row...@gmail.com
>

Re: SVNSYNC questions

[Geoff Rowell]

1. Create the destination repositories.
2. Configure the destination repository access rights.
3. Use "svnsync init" on each destination repository.
4. Run "svnsync sync" on each to copy content.

On Wed, May 2, 2018 at 4:16 PM, Paul Greene 
wrote:

> /data/subversion *contains* the repositories - it is not a repository
> itself.
>
> So, will the /data/subversion/repo01, /data/subversion/repo02, ...
> /data/subversion/repo110 automatically be created, or do I have to make
> them myself?
>
> On Wed, May 2, 2018 at 4:09 PM, Andreas Stieger 
> wrote:
>
>> Hello,
>>
>>
>> On 05/02/2018 10:02 PM, Paul Greene wrote:
>> > Prior to running svnsync, do I need to create the same folder
>> > structure on the destination as on the source?
>>
>> no, just an empty, randomly named repository.
>>
>> > i.e. the source has 110 repositories located under /data/subversion. I
>> > have a folder named /data/subversion on the destination as well where
>> > I want the mirror to go.
>>
>> You need to have as many repositories on the far side as you need
>> mirroring for. The on-disk data will look like this: conf  db  format
>> hooks  locks  README.txt
>> Each of these is a synchronization unit and needs to be set up
>> separately. svn does not help you above that level, and below that any
>> structure only exists inside the repository tree which is replicated.
>>
>> >
>> > Do I need to manually create all the subversion repository folders
>> > under /data/subversion before syncing, along with the same user
>> > permissions/ownership? Or does subversion automatically create the
>> > folders?
>>
>> Depends if /data/subversion IS the repository, or CONTAINS repositories.
>>
>> Andreas
>>
>
>


-- 
Geoff Rowell
geoff.row...@gmail.com

Re: SVNSYNC questions

[Paul Greene]

/data/subversion *contains* the repositories - it is not a repository
itself.

So, will the /data/subversion/repo01, /data/subversion/repo02, ...
/data/subversion/repo110 automatically be created, or do I have to make
them myself?

On Wed, May 2, 2018 at 4:09 PM, Andreas Stieger 
wrote:

> Hello,
>
>
> On 05/02/2018 10:02 PM, Paul Greene wrote:
> > Prior to running svnsync, do I need to create the same folder
> > structure on the destination as on the source?
>
> no, just an empty, randomly named repository.
>
> > i.e. the source has 110 repositories located under /data/subversion. I
> > have a folder named /data/subversion on the destination as well where
> > I want the mirror to go.
>
> You need to have as many repositories on the far side as you need
> mirroring for. The on-disk data will look like this: conf  db  format
> hooks  locks  README.txt
> Each of these is a synchronization unit and needs to be set up
> separately. svn does not help you above that level, and below that any
> structure only exists inside the repository tree which is replicated.
>
> >
> > Do I need to manually create all the subversion repository folders
> > under /data/subversion before syncing, along with the same user
> > permissions/ownership? Or does subversion automatically create the
> > folders?
>
> Depends if /data/subversion IS the repository, or CONTAINS repositories.
>
> Andreas
>

Re: SVNSYNC questions

[Andreas Stieger]

Hello,


On 05/02/2018 10:02 PM, Paul Greene wrote:
> Prior to running svnsync, do I need to create the same folder
> structure on the destination as on the source?

no, just an empty, randomly named repository.

> i.e. the source has 110 repositories located under /data/subversion. I
> have a folder named /data/subversion on the destination as well where
> I want the mirror to go.

You need to have as many repositories on the far side as you need
mirroring for. The on-disk data will look like this: conf  db  format 
hooks  locks  README.txt
Each of these is a synchronization unit and needs to be set up
separately. svn does not help you above that level, and below that any
structure only exists inside the repository tree which is replicated.

>
> Do I need to manually create all the subversion repository folders
> under /data/subversion before syncing, along with the same user
> permissions/ownership? Or does subversion automatically create the
> folders?

Depends if /data/subversion IS the repository, or CONTAINS repositories.

Andreas

SVNSYNC questions

[Paul Greene]

Hello Subversion gurus,

I need to create a mirror of a subversion repository.

Prior to running svnsync, do I need to create the same folder structure on
the destination as on the source?

i.e. the source has 110 repositories located under /data/subversion. I have
a folder named /data/subversion on the destination as well where I want the
mirror to go.

Do I need to manually create all the subversion repository folders under
/data/subversion before syncing, along with the same user
permissions/ownership? Or does subversion automatically create the folders?

Thanks,

PG

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

[Daniel Shahaf]

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 under 'svnadmin freeze'.  Currently, the
failure mode of a non-atomic copy is harmless, but we don't promise
it'll always be this way.

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

[Johan Corveleyn]

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 allow only the changes
>> svnsync needs and disallow others.
>
> . . .
>>
>> svnsync is probably best, since it allows you to easily incrementally
>> mirror a live read/write repository to another server. It can be slow
>> but once it's done it makes it very quick to switch from the old
>> server to the new one with minimal downtime. Some of the other
>> methods require you to make the source repository read-only or take
>> it offline for the duration of the migration, which could take hours
>> or days depending on how large your repository is.
>
> . . .
> and Arwin and Nico said similar things.
>
> Thanks, Ryan, Arwin, and Nico.
>
> It took a bit of futzing around, but as I type this, I'm replicating a
> repository (the smallest and currently least-active one).
>
> It took me a while to realize that the hooks with .tmpl extensions were
> templates, not live hooks, and I was right on the verge of asking for help
> when I looked at the instructions again, and realized that instead of
> setting up the required null hook, I'd overwritten a template (DUH!)

Indeed, you only need to copy the files under $REPOS/hooks which are
not ending in .tmpl :-). And for the custom hook scripts you have:
maybe review them and compare the comments section at the beginning
with the new corresonding template to see if there are new features
(perhaps copy over the new comment block to your custom hook script).

Two other things which are also not transferred by svnsync (nor by dump/load):
- config files (under $REPOS/conf), for instance authz
- locks (server-side locks, of the svn:needs-lock type): these should
be copied from $OLDREPOS/db/locks to $NEWREPOS/db/locks

FWIW, I've documented some of these things in an extended answer in
our FAQ, about dump/load (some of these things also apply to svnsync):
http://subversion.apache.org/faq.html#dumpload

For the record, you can also perform an incemental dump/load with
minimal downtime (I explained this procedure in the FAQ). But svnsync
is still a lot easier, because of the automatic normalization of
properties (which is not done automatically by 'svnadmin load' at the
moment, which will error out on non-LF line endings in svn:log
messages and things like that, possibly giving a lot of headaches ...
see FAQ).

-- 
Johan

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

[James H. H. Lampert]

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 is probably best, since it allows you to easily incrementally
mirror a live read/write repository to another server. It can be slow
but once it's done it makes it very quick to switch from the old
server to the new one with minimal downtime. Some of the other
methods require you to make the source repository read-only or take
it offline for the duration of the migration, which could take hours
or days depending on how large your repository is.

. . .
and Arwin and Nico said similar things.

Thanks, Ryan, Arwin, and Nico.

It took a bit of futzing around, but as I type this, I'm replicating a 
repository (the smallest and currently least-active one).


It took me a while to realize that the hooks with .tmpl extensions were 
templates, not live hooks, and I was right on the verge of asking for 
help when I looked at the instructions again, and realized that instead 
of setting up the required null hook, I'd overwritten a template (DUH!)


--
JHHL

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

[Nico Kadel-Garcia]

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 instance using Bitnami's canned Trac image,
> which includes SVN 1.9.5 (r1770682) and Trac 1.0.15 (our old SVN server is
> 1.5.0, r31699, and our old Trac server is 1.0).
>
> I've got a test repository set up, and I've arranged access via both https:
> and svn+ssh: protocols, which I then spent a few hours testing from Eclipse.
>
> But I'm not the one who set up the original SVN and Trac environments in the
> first place, and so what little I know about administration on these
> products is what I've picked up over the past few weeks.
>
> Now, Trac's wiki page on the process of a dual migration,
>https://trac.edgewall.org/wiki/TracMigrate
> seems to be pretty straightforward on the subject of migrating Trac, but the
> section on migrating SVN is not so.

That page is good stuff.

> 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
> operating system user-ID) we don't currently have.

That is just the account name of the user who has access to the
upstream repository. If you don't have access to that upstream
repository via Subversion https://, or some CIFS mounted filesystem
access ot the filesystem, or a local filesystem copy or *something*
it's going to be very difficulty to copy the repository. And https://
access or svn+ssh:// or a CIFS mount gets you access to the live
upstream repository for updates.

> Everything else I've read, especially The SVN Book, says to use "svnsync"
> only for mirroring, and instead migrate using some combination of "svnadmin
> dump," "svnadmin load," "svnrdump," and "svnrload."

svnsync has gotten popular because it lets you keep the new repo
up-to-date until you're ready to switch. svnadmin dump, etc. are more
useful when you want to make an offline backup, or when you want to
filter out content. Note that this is about the *only* chance you're
going to get to clear out old content switching to a new repository.
If you have a cluttered "branch" layout, or bulky iso images someone
accidentally committed, or old passwords embedded in files you want to
clear, here is your chance with dump, filter, and load operations. .
I'm not sure how much that kind of filtering would do to Trac, just
saying.

> I'm not seeing a lot about copying configuration files or hook scripts. Is
> that just a matter of sending them over?

Going from Windows 2003 to a Google Compute Engine? You *wish*. In
theory, yes, but in practice, if they've been locally customized, they
may have hardcoded dependencies on particular scripting languages. One
step that may help is if you have access to the old box and can run
"svnadmin hotcopy", to get a copy to play with containing all the old
scripts so you can set it aside and play with it separately.

> And I don't quite understand how this whole business impacts the authors of
> commits. Does SVN care whether the author of a commit is a user known to SVN
> or to the operating system? I've already copied an "authz" file from one of
> the existing repositories into the test repository, and given the current
> users Apache user-IDs and passwords, but that's all, so far.

It Depends(tm). For HTTPS access, the author of a commit is known to
the httpd daemon as an authenticated user. The httpd daemon needs
write access to the file system of the server. For svn:// access,
ditto, the author is known to the svnserve protocol, not the local
filesystem, and the svnserve daemon user needs write access. For
svn+ssh://, the author is typically *set* in the configuration for the
SSH key, and the user designated for the SSH access or SSH key access
is local and needs write access. For file:/// access, the user would
need to exist in some way and have write access to the filesystem.

What you have seems quite correct. The httpd daemon needs write
access, and httpd cares about their credentials for https:// and for
Trac software. (I'm picky about Apache being apache-1.x, and release
2.x being renamed httpd, which is why I don't call it Apache.)

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

[Arwin Arni Nandagopal]

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 operating system 
user-ID) we don't currently have.

This doesn't refer to a unix user id, just the username and password used to 
authenticate to the source repository. It can be any username (not necessarily 
'svnsync'). Just make sure that it has read access to the entire repository 
that you are svnsync'ing
Everything else I've read, especially The SVN Book, says to use "svnsync" only 
for mirroring, and instead migrate using some combination of "svnadmin dump," 
"svnadmin load," "svnrdump," and "svnrload."

While svnadmin dump/load is the recommended path for migrating repos to a newer 
version, svnsync does pretty much the same thing. You just need to use the 
newer versions of the svnadmin and svnsync binaries (which are installed in 
your target system).
I'm not seeing a lot about copying configuration files or hook scripts. Is that 
just a matter of sending them over?

Neither svnsync nor svnadmin dump/load will take care of things like hook 
scripts/configuration files. You will have to copy these over manually and 
place them in their appropriate paths.
And I don't quite understand how this whole business impacts the authors of 
commits. Does SVN care whether the author of a commit is a user known to SVN or 
to the operating system?

While svnsync'ing you don't need to worry about authz at all, because I see 
that the document you posted suggests init over file:// . This will not involve 
authz. You will however need to set up and configure authentication and 
authorization just like it is in the old system when you want to start using 
the new system.

Regards,
Arwin

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

[Ryan Schmidt]

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 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.

> It also assumes the existence of an "svnsync" user-ID on the target system, 
> which (at least assuming it's an operating system user-ID) we don't currently 
> have.

svnsync doesn't care what system user account you use. You would probably want 
to pick the username that the server process will use. If you're serving with 
Apache, that'll be a username like nobody or httpd or apache.

> Everything else I've read, especially The SVN Book, says to use "svnsync" 
> only for mirroring, and instead migrate using some combination of "svnadmin 
> dump," "svnadmin load," "svnrdump," and "svnrload."

svnsync is probably best, since it allows you to easily incrementally mirror a 
live read/write repository to another server. It can be slow but once it's done 
it makes it very quick to switch from the old server to the new one with 
minimal downtime. Some of the other methods require you to make the source 
repository read-only or take it offline for the duration of the migration, 
which could take hours or days depending on how large your repository is.

> I'm not seeing a lot about copying configuration files or hook scripts. Is 
> that just a matter of sending them over?

Pretty much. You may need to edit the files if the setup of the new server 
differs from the old one. New versions of Subversion may also offer more 
features than old versions, which may affect your scripts or configuration.

> And I don't quite understand how this whole business impacts the authors of 
> commits. Does SVN care whether the author of a commit is a user known to SVN 
> or to the operating system? I've already copied an "authz" file from one of 
> the existing repositories into the test repository, and given the current 
> users Apache user-IDs and passwords, but that's all, so far.

If you're using Apache to serve the Subversion repository, on both the old and 
new systems, then you're right, Subversion users don't care about server system 
user accounts; they only care about user accounts as defined in whatever 
authentication you've set up for the repository in Apache.

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

[James H. H. Lampert]

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 instance using Bitnami's canned Trac image, 
which includes SVN 1.9.5 (r1770682) and Trac 1.0.15 (our old SVN server 
is 1.5.0, r31699, and our old Trac server is 1.0).


I've got a test repository set up, and I've arranged access via both 
https: and svn+ssh: protocols, which I then spent a few hours testing 
from Eclipse.


But I'm not the one who set up the original SVN and Trac environments in 
the first place, and so what little I know about administration on these 
products is what I've picked up over the past few weeks.


Now, Trac's wiki page on the process of a dual migration,
   https://trac.edgewall.org/wiki/TracMigrate
seems to be pretty straightforward on the subject of migrating Trac, but 
the section on migrating SVN is not so.


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 operating system user-ID) we don't currently have.


Everything else I've read, especially The SVN Book, says to use 
"svnsync" only for mirroring, and instead migrate using some combination 
of "svnadmin dump," "svnadmin load," "svnrdump," and "svnrload."


I'm not seeing a lot about copying configuration files or hook scripts. 
Is that just a matter of sending them over?


And I don't quite understand how this whole business impacts the authors 
of commits. Does SVN care whether the author of a commit is a user known 
to SVN or to the operating system? I've already copied an "authz" file 
from one of the existing repositories into the test repository, and 
given the current users Apache user-IDs and passwords, but that's all, 
so far.


--
James H. H. Lampert
Touchtone Corporation

Re: Questions about --pin-externals option

[Grant Edwards]

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 can't really imagine any advantage to the "non-externals"
method except you don't have the opportunaty to accidentally tag a
version with an externals link pointing to wherever@HEAD and then
check it out later and build something incorrectly without realizing
what happened.

Both approches require people to follow some new workflow rules, but
the externals route seems to require fewer.

-- 
Grant Edwards   grant.b.edwardsYow! Didn't I buy a 1951
  at   Packard from you last March
  gmail.comin Cairo?

Re: Questions about --pin-externals option

[Branko Čibej]

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 projects. It may depend on
>>> how smartsvn handles tagging/branching that involves externals. I see
>>> that tortoisesvn has something akin to --pin-externals, but haven't
>>> figured out if smartsvn has something like that. 
>> It does. The first version of SmartSVN that migrated off SVNKit to
>> JavaHL (from Subversion 1.8) had a two-step process for updating the
>> externals. The latest version should be using the atomic pin-externals
>> capability.
> Cool, thanks for the info.  I'm going to set up a couple test projects
> and try out externals vs. nested working copies to make sure I
> understand the differences.

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.

-- Brane

Re: Questions about --pin-externals option

[Grant Edwards]

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 handles tagging/branching that involves externals. I see
>> that tortoisesvn has something akin to --pin-externals, but haven't
>> figured out if smartsvn has something like that. 
>
> It does. The first version of SmartSVN that migrated off SVNKit to
> JavaHL (from Subversion 1.8) had a two-step process for updating the
> externals. The latest version should be using the atomic pin-externals
> capability.

Cool, thanks for the info.  I'm going to set up a couple test projects
and try out externals vs. nested working copies to make sure I
understand the differences.

-- 
Grant Edwards   grant.b.edwardsYow! My EARS are GONE!!
  at   
  gmail.com

Re: Questions about --pin-externals option

[Branko Čibej]

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 externals. I see
> that tortoisesvn has something akin to --pin-externals, but haven't
> figured out if smartsvn has something like that. 

It does. The first version of SmartSVN that migrated off SVNKit to
JavaHL (from Subversion 1.8) had a two-step process for updating the
externals. The latest version should be using the atomic pin-externals
capability.

-- Brane

Re: Questions about --pin-externals option

[Branko Čibej]

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, copy --pin-externals to a "tag" destination just pinned the
>> revision to the current one (leaving the path the same), but if the
>> destination was a "branch" and the source was relative, it would
>> leave the version floating and change the path so it too pointed to
>> a branch (or something like that).
>>
>> Did the branch handling stuff get dropped?
> That would be news to me. As far as I'm aware SVN does not treat
> tags/branches special in any case.
> To keep externals "floating" simply use externals without pinning them
> to a certain revision, or am I getting your question wrong?


There is no difference between "branches" and "tags." The
--pin-externals option applies to the 'svn copy' command, there's no
extra magic beyond that.


>> 2) Are there server-side version dependancies for use of the
>> --pin-externals option?  Or will it work with any server version?
> This client-side feature works with any server but requires a client
> >= 1.9.
> Note that the feature to specify externals with peg revisions was
> actually added in 1.5 already [1].
> That said, if you use that feature all clients which access the
> repository should be >= 1.5 to understand the syntax correctly.
> 1.9 only added that command line option to simplify working with
> externals.

That's not the case at all. The old externals format prior to 1.5 did
have a revision parameter that was in fact interpreted as a peg
revision. 'svn copy --pin-externals' detects the format of the externals
reference does not change it even when adding a revision specifier.
Clients older than 1.5 will continue to work with branches and tags that
were created with the --pin-externals option.

-- Brane

Re: Questions about --pin-externals option

[Grant Edwards]

On 2016-04-25, Stefan <luke1...@posteo.de> 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 --pin-externals to a "tag" destination just pinned the
>> revision to the current one (leaving the path the same), but if the
>> destination was a "branch" and the source was relative, it would
>> leave the version floating and change the path so it too pointed to
>> a branch (or something like that).
>>
>> Did the branch handling stuff get dropped?
>
> That would be news to me. As far as I'm aware SVN does not treat 
> tags/branches special in any case.

My bad.  I spent some time repeating my Google searchs and it looks
like I was conflating the "svn copy --pin-externals" feature with some
features of the "svncopy" script (which I may have misunderstood just
to make the situation worse).

>> 2) Are there server-side version dependancies for use of the
>> --pin-externals option?  Or will it work with any server version?

> This client-side feature works with any server but requires a client
> >= 1.9. Note that the feature to specify externals with peg revisions
> was actually added in 1.5 already [1]. That said, if you use that
> feature all clients which access the repository should be >= 1.5 to
> understand the syntax correctly. 1.9 only added that command line
> option to simplify working with externals.

Thanks, that's what I thought, but wanted to make sure.

>> Where does one find documentation for 1.9 versions (the book only
>> covers versions up to 1.8)?

> The SVN book for 1.8 is the most resent version available atm. Most of 
> the information should still apply to SVN 1.9. A good source for the 
> newly added features would be the release notes [2].
>
> [1]: https://subversion.apache.org/docs/release-notes/1.5.html
> [2]: https://subversion.apache.org/docs/release-notes/1.9.html

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 externals.  I see that tortoisesvn has
something akin to --pin-externals, but haven't figured out if smartsvn
has something like that.

-- 
Grant

Re: Questions about --pin-externals option

[Stefan]

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 pinned the
revision to the current one (leaving the path the same), but if the
destination was a "branch" and the source was relative, it would
leave the version floating and change the path so it too pointed to
a branch (or something like that).

Did the branch handling stuff get dropped?
That would be news to me. As far as I'm aware SVN does not treat 
tags/branches special in any case.
To keep externals "floating" simply use externals without pinning them 
to a certain revision, or am I getting your question wrong?



2) Are there server-side version dependancies for use of the
--pin-externals option?  Or will it work with any server version?

This client-side feature works with any server but requires a client >= 1.9.
Note that the feature to specify externals with peg revisions was 
actually added in 1.5 already [1].
That said, if you use that feature all clients which access the 
repository should be >= 1.5 to understand the syntax correctly.

1.9 only added that command line option to simplify working with externals.

Where does one find documentation for 1.9 versions (the book only
covers versions up to 1.8)?
The SVN book for 1.8 is the most resent version available atm. Most of 
the information should still apply to SVN 1.9. A good source for the 
newly added features would be the release notes [2].


[1]: https://subversion.apache.org/docs/release-notes/1.5.html
[2]: https://subversion.apache.org/docs/release-notes/1.9.html

Regards,
Stefan

Questions about --pin-externals option

[Grant 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 pinned the
   revision to the current one (leaving the path the same), but if the
   destination was a "branch" and the source was relative, it would
   leave the version floating and change the path so it too pointed to
   a branch (or something like that).

   Did the branch handling stuff get dropped?

2) Are there server-side version dependancies for use of the
   --pin-externals option?  Or will it work with any server version?

Where does one find documentation for 1.9 versions (the book only
covers versions up to 1.8)?

-- 
Grant Edwards   grant.b.edwardsYow! I didn't order any
  at   WOO-WOO ... Maybe a YUBBA
  gmail.com... But no WOO-WOO!

Re: Authentication Questions

[Philip Martin]

jt.mil...@l-3com.com writes:

 I guess there's no caching of credentials since the path-based
 authentication file can change at any time?

I'm not clear what you mean by caching of credentials.  Subversion
typically sends multiple HTTP requests over a single connection.  Each
HTTP request has its own authn credentials and caching those would not
make sense, although Apache may cache any data used to validate the
credentials.  Subversion's authz file is parsed when first needed and
cached for use by any subsequent HTTP requests on the same connection.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: Authentication Questions

[JT . Miller]

Thanks Philip, what you explained for the authz/authn caching makes sense. We 
recently performed a major upgrade of our IT infrastructure and I took the 
opportunity to upgrade our very old Subversion configuration (old physical 
server with Apache 2.2/SVN 1.4 to virtual server with 2.4/1.8). We have had 
some pretty significant latency issues (due to my ignorance of a proper 
configuration). I was searching for performance bottlenecks and was (unduly) 
concerned by what I saw in the logs with debug enabled. Mostly I wanted to 
verify that the traffic pattern I showed was typical, and it doesn't sound like 
it's anything out of the ordinary.

I think the culprit for us was the default AcceptFilter directive. Changing 
this to AcceptFilter http none seems to have cleared up all the latency issues.

Thanks again for your explanation.

-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com] 
Sent: Thursday, January 08, 2015 9:17 AM
To: Miller, JT @ SSG - PE - MT
Cc: users@subversion.apache.org
Subject: Re: Authentication Questions

jt.mil...@l-3com.com writes:

 I guess there's no caching of credentials since the path-based 
 authentication file can change at any time?

I'm not clear what you mean by caching of credentials.  Subversion typically 
sends multiple HTTP requests over a single connection.  Each HTTP request has 
its own authn credentials and caching those would not make sense, although 
Apache may cache any data used to validate the credentials.  Subversion's authz 
file is parsed when first needed and cached for use by any subsequent HTTP 
requests on the same connection.

--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Authentication Questions

[JT . Miller]

Debugging other issues, I turned on verbose logging and was curious if the 
below traffic was typical. This may well be correct, as we have path-based 
authentication requiring valid NTLM users. Server is Windows 2008 R2, Apache 
2.4, NTLM, and SVN 1.8. 

[Tue Jan 06 15:18:28.378306 2015] [authz_core:debug] [pid 15392:tid 16884] 
mod_authz_core.c(799): [client USER_IP:9] AH01626: authorization result of 
Require valid-user : denied (no authenticated user yet)
[Tue Jan 06 15:18:28.378306 2015] [authz_core:debug] [pid 15392:tid 16884] 
mod_authz_core.c(799): [client USER_IP:9] AH01626: authorization result of 
RequireAny: denied (no authenticated user yet)
[Tue Jan 06 15:18:28.378306 2015] [authnz_sspi:debug] [pid 15392:tid 16884] 
mod_authnz_sspi_authentication.c(439): [client USER_IP:9] SSPI1: 
Entering authenticate_sspi_user()
[Tue Jan 06 15:18:28.378306 2015] [authnz_sspi:debug] [pid 15392:tid 16884] 
mod_authnz_sspi_authentication.c(544): [client USER_IP:9] SSPI9: 
Authenticated user: USER_NAME
[Tue Jan 06 15:18:28.378306 2015] [authz_svn:debug] [pid 15392:tid 16884] 
mod_authz_svn.c(400): [client USER_IP:9] Path to authz file is 
D:/svn/config/svnaccess.conf
[Tue Jan 06 15:18:28.378306 2015] [authz_svn:info] [pid 15392:tid 16884] 
[client USER_IP:9] Access granted: 'USER_NAME' GET REPO:/PATH_TO_FILE

There are hundreds to thousands of the above entry pattern for each user as 
they browse the repository (over 6 hours log is ~420MB with ~2.4M entries). 

I guess there's no caching of credentials since the path-based authentication 
file can change at any time?

Regards,

JT Miller
L-3 Mustang Technology

svn mergeinfo and svn merge - questions

[Z W]

 Hi All

 We are using 1.6 SVN.
 We like to svn merge from our branch A to trunk.
 We have been diligent in svn merge from trunk to A.
 These svn merges from trunk to branch A also include --record-only merges
 too, in addition to regular merges.
 Development on branch A has stopped.
 Now we like to merge branch A to trunk using --reintegrate option.
 But we dont know what to expect if using this option fails on us.

 1) Suppose svn merge --reintegrate fails on us on a working copy that has
 all the mergeinfo list information.
 Could we perform a clean co of branch A into another working copy and then
 perform svn merge --reintegrate to trunk there ?
 Will we get more conflicts simply because the new working copy doesnt have
 the mergeinfo list like the first working copy of branch A ?
 Will this plan B work ?



 2) How do we resolve conflicts during svn merge --reintegrate process ?
 Would you share the steps for us to make the merge go smoothly ?


3) Is mergeinfo a global or local property ? it seems that whenever a new
checkout is done, mergeinfo list matches up with other working copies of
the same branch.



 Any help is appreciated.
 Sincerely

RE: svn mergeinfo and svn merge - questions

[Tati, Aslesh : Barclaycard US]

1. You can use svn merge --dry-run if you are using command line or if you 
are using a client like tortoise then a test merge option should be available. 
This won't actually merge but show if there will be any failure in case an 
actual merge was performed.


2. Do the re-intergrate merges on your local copies and once it is complete 
(re-intergrate merge shouldn't most likely fail during the actual operation 
itself) you can resolve the conflicts during the commit to your subversion 
repositories (SVN Red Bean book for resolving conflicts explains things in 
detail)



3. Not sure about this



From: Z W [mailto:mpc8...@gmail.com]
Sent: Thursday, October 17, 2013 3:37 PM
To: users@subversion.apache.org
Subject: svn mergeinfo and svn merge - questions

Hi All

We are using 1.6 SVN.
We like to svn merge from our branch A to trunk.
We have been diligent in svn merge from trunk to A.
These svn merges from trunk to branch A also include --record-only merges too, 
in addition to regular merges.
Development on branch A has stopped.
Now we like to merge branch A to trunk using --reintegrate option.
But we dont know what to expect if using this option fails on us.

1) Suppose svn merge --reintegrate fails on us on a working copy that has all 
the mergeinfo list information.
Could we perform a clean co of branch A into another working copy and then 
perform svn merge --reintegrate to trunk there ?
Will we get more conflicts simply because the new working copy doesnt have the 
mergeinfo list like the first working copy of branch A ?
Will this plan B work ?

2) How do we resolve conflicts during svn merge --reintegrate process ?
Would you share the steps for us to make the merge go smoothly ?

3) Is mergeinfo a global or local property ? it seems that whenever a new 
checkout is done, mergeinfo list matches up with other working copies of the 
same branch.


Any help is appreciated.
Sincerely


Barclaycard
www.barclaycardus.com 

This email and any files transmitted with it may contain confidential and/or 
proprietary information. It is intended solely for the use of the individual or 
entity who is the intended recipient. Unauthorized use of this information is 
prohibited. If you have received this in error, please contact the sender by 
replying to this message and delete this material from any system it may be on.

RE: svn mergeinfo and svn merge - questions

[Bob Archer]

 Hi All
 
 We are using 1.6 SVN.
 We like to svn merge from our branch A to trunk.
 We have been diligent in svn merge from trunk to A.
 These svn merges from trunk to branch A also include --record-only merges
 too, in addition to regular merges.
 Development on branch A has stopped.
 Now we like to merge branch A to trunk using --reintegrate option.
 But we dont know what to expect if using this option fails on us.
 
 1) Suppose svn merge --reintegrate fails on us on a working copy that has all
 the mergeinfo list information. Could we perform a clean co of branch A into
 another working copy and then perform svn merge --reintegrate to trunk
 there ? Will we get more conflicts simply because the new working copy
 doesnt have the mergeinfo list like the first working copy of branch A ?
 Will this plan B work ?

I'm not sure I follow. To reintegrate a branch into a trunk your merge target 
(the working copy) is the trunk. Having a branch checked out doesn't change 
this.

 
 2) How do we resolve conflicts during svn merge --reintegrate process ?
 Would you share the steps for us to make the merge go smoothly ?

It depends on the conflict. Generally, if it is a content conflict you use a 
3-way merge tool to resolve the conflict. This is no different than if there is 
a conflict when you do an update. 

The other type is a tree conflict. Generally, these occur when the path that 
has a change in the repository doesn't exist in your merge target working copy. 
Resolving them depends on the conflict and you. For example, in branch you 
edited foo.cs, but in trunk that file is deleted. So, when you try to merge the 
edit you get a tree conflict.

 
 3) Is mergeinfo a global or local property ? it seems that whenever a new
 checkout is done, mergeinfo list matches up with other working copies of the
 same branch.

I'm not sure what you are asking here. Merge info is a subversion property, so 
of course it will exist whenever you check out. Just like and svn:mime-type 
property. 


BOb

 
 
 Any help is appreciated.
 Sincerely

A couple of questions, please... (UNCLASSIFIED)

[Doughty, Stefan J CTR (US)]

Classification: UNCLASSIFIED
Caveats: NONE



Hi,

 

I've been tasked to get a Certificate of Networthiness (CON) from the U.S.
government so we can use Apache Subversion for version control. I've been
using it for several years at home and I love it.

 

1.   Is there perhaps a CON already? I've looked and saw an older one
for Collabnet Subversion.

2.   I'm filling out the form to apply for the CON, and I need a phone
number and an address. Is that possible?

 

That's it for now. Thank you in advance for your time and help.

 

Respectfully,

Stefan

 

Stefan Doughty

GaN Contractor

254-288-1914

stefan.doug...@gancorp.com

stefan.j.doughty@mail.mil

 


Classification: UNCLASSIFIED
Caveats: NONE




smime.p7s
Description: S/MIME cryptographic signature

Re: A couple of questions, please... (UNCLASSIFIED)

[Ryan Schmidt]

On Jun 6, 2013, at 11:01, Doughty, Stefan J CTR (US) 
stefan.j.doughty@mail.mil wrote:

 I’ve been tasked to get a Certificate of Networthiness (CON) from the U.S. 
 government so we can use Apache Subversion for version control. I’ve been 
 using it for several years at home and I love it.
  
 1.   Is there perhaps a CON already? I’ve looked and saw an older one for 
 Collabnet Subversion.
 2.   I’m filling out the form to apply for the CON, and I need a phone 
 number and an address. Is that possible?

Hello,

I'm not familiar with certificates of networthiness or other government 
requirements for software use. Do they only cover a specific version of the 
software? If so, and if the one you have is for an older version than the one 
you want to use, can you cite it in your request for an updated CON?

A Google search found this message about a CON having been obtained by the Army 
for Apache HTTPD Server 2.2.x:

https://groups.google.com/forum/?fromgroups#!msg/mil-oss/8SSDWbuUbY4/enkC_MYVRw0J

Since version 1.7.0, Subversion is also part of the Apache Foundation, so 
perhaps it will help you to know that another Apache project has already been 
approved.

I'm not aware of a phone number for the Apache Foundation, but there is a 
central address:

http://www.apache.org/foundation/contact.html

Writing to the Legal Affairs Committee's mailing list might be fruitful:

http://www.apache.org/legal/

Re: questions about subversion secondary development

[Alagazam.net Subversion]

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 ( Win32Svn
http://sourceforge.net/projects/win32svn/ ,
svn-win32-1.6.21_dev.zip) to run the example code named
minimal_client.c(located in the directory of
subversion-1.6.21\tools\examples),  I get an access
violation on calling svn_cmdline_init(minimal_client, stderr).
  My build tool is Visual Studio 2008 on Windows 7(or
Windows xp).How to solve this problem? Please help me.
   
Thanks a lot and look forward to hearing from you soon.

Best Regards,
Cunchao Cheung


In the absence of the maintainer answering, I believe that the sourceforge 
win32svn package you are using is built using Vicual C++ 6 (e.g. for 
compatability with the VC6 binaries of httpd that apache.org used to host).

If you want to use it with Visual Studio 2008 you will need to find a different 
binary, built using VS2008.  Both CollabNet and WANdisco (amongst others) also 
provide binaries, try some of those...

Cheers,

~ mark c


Hi all

That's correct Mark (thanks for answering in my absence).
My build is using VC++6 and I suppose that's the reason it doesn't work.

Although I have tried using the Apache modules in my build on in newer 
versions of xampp (which includes httpd) that is build using newer 
compilers (VC9/VS2008) and it's working. But I think it might be that 
the apache modules have nice clean interfaces.


/David  a.k.a. Alagazam

svn:ignore and svn merge - quick questions

[Z W]

Hi All

We like to ignore a set of jar files under our working copy root directory:

working copy root dir: /scratch/testMerge
working copy jars dir: /scratch/testMerge/build/jars

We tried to perform merging from a trunk to our working copy branch and it
failed because   one of the jar inside /scratch/test/build/jars is causing
a conflict.

(eg /scratch/testMerge/build/jars/a.jar)

We like to use svn:ignore to ignore the jar files so that the conflict
would go away in the next merge.
What's the correct syntax to svn:ignore using it at the root directory.
We have /scratch/testIgnorePropSetList.txt containing the line

/scratch/testMerge/build/jars/*.jar

We tried

svn propset svn:ignore -F /scratch/testIgnorePropSetList.txt
/scratch/testMerge
svn propget svn:ignore /scratch/testMerge
/scratch/testMerge/build/jars/*.jar

But conflict still shows for a.jar when merging from trunk to working copy
branch.

--- Merging r555 into '/scratch/testMerge':

   C /scratch/build/artifacts/jars/a.jar

How do we set it right ?
Can svn:ignore be used with svn merge or is svn:ignore only used for svn
checkout as a typical use case for svn:ignore ?

Thank you
Sincerely

Re: svn:ignore and svn merge - quick questions

[Thorsten Schöning]

Guten Tag Z W,
am Samstag, 27. April 2013 um 18:51 schrieben Sie:

 How do we set it right ?  
 Can svn:ignore be used with svn merge or is svn:ignore only used
 for svn checkout as a typical use case for svn:ignore ? 

svn:ignore only works on the current versioned directory and only for
objects not under version control in the current working copy.

In your case, you may simply delete the build-folder contents, if you
don't need them in your repo. If you need them, shouldn't they be
merged at all?

http://svnbook.red-bean.com/en/1.1/ch07s02.html
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: svn:ignore and svn merge - quick questions

[Johan Corveleyn]

On Sat, Apr 27, 2013 at 6:51 PM, Z W mpc8...@gmail.com wrote:
 Hi All

 We like to ignore a set of jar files under our working copy root directory:
 working copy root dir: /scratch/testMerge
 working copy jars dir: /scratch/testMerge/build/jars

 We tried to perform merging from a trunk to our working copy branch and it
 failed because   one of the jar inside /scratch/test/build/jars is causing a
 conflict.

 (eg /scratch/testMerge/build/jars/a.jar)

 We like to use svn:ignore to ignore the jar files so that the conflict would
 go away in the next merge.
 What's the correct syntax to svn:ignore using it at the root directory.
 We have /scratch/testIgnorePropSetList.txt containing the line

 /scratch/testMerge/build/jars/*.jar

 We tried

 svn propset svn:ignore -F /scratch/testIgnorePropSetList.txt
 /scratch/testMerge
 svn propget svn:ignore /scratch/testMerge
 /scratch/testMerge/build/jars/*.jar

 But conflict still shows for a.jar when merging from trunk to working copy
 branch.

 --- Merging r555 into '/scratch/testMerge':

C /scratch/build/artifacts/jars/a.jar


 How do we set it right ?
 Can svn:ignore be used with svn merge or is svn:ignore only used for svn
 checkout as a typical use case for svn:ignore ?

 Thank you
 Sincerely

Hi Z W,

[ Small meta-suggestion: please drop the quick question suffix from
your future posts. It's distracting, and often the answers aren't that
quick to come up with :-). And because of this, you scare away some
potential helpers, when some of us think hey, I have to think more
than 10 seconds about this 'quick question', so I'm probably not the
right guy ... perhaps other list-people will answer this one. ]

That said, the answer to your current question is straightforward:
what you want to do won't work. svn:ignore doesn't work for items you
put in subversion, it's specifically for ignoring unversioned items
(avoiding to pick them up for addition to subversion).

See: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

--
Johan

Re: meta-suggestion Re: svn:ignore and svn merge - quick questions

[Daniel Shahaf]

Johan Corveleyn wrote on Sat, Apr 27, 2013 at 20:18:07 +0200:
 [ Small meta-suggestion: please drop the quick question suffix from
 your future posts. It's distracting, and often the answers aren't that
 quick to come up with :-). And because of this, you scare away some
 potential helpers, when some of us think hey, I have to think more
 than 10 seconds about this 'quick question', so I'm probably not the
 right guy ... perhaps other list-people will answer this one. ]

Well, I would suggest those list-people to doubt themselves a little less
and answer anyway:

- They probably know that part of Subversion better than the poster

- Posters often get some things wrong (example: I want to use
  global-ignores to avoid merge conflicts, Why doesn't 'svn ps -F
  .gitignore svn:ignore' work (slashes in the pattern))

- Worst case, someone else will come along and corrects their answer

questions about subversion secondary development

[Edwin Cheung]

Dear sir or madam:
   When I use the binary packages (
Win32Svnhttp://sourceforge.net/projects/win32svn/,
svn-win32-1.6.21_dev.zip) to run the example code named
minimal_client.c(located in the directory of
subversion-1.6.21\tools\examples),  I get an access violation on calling
svn_cmdline_init(minimal_client, stderr).
 My build tool is Visual Studio 2008 on Windows 7(or Windows xp).How to
solve this problem? Please help me.

Thanks a lot and look forward to hearing from you soon.
Best Regards,
Cunchao Cheung

SVN status code and server/client responses - quick questions

[Z W]

Hi All

We're new to SVN.
We think we got the basics but like to know more.

We having been using SVN updates with Hudson and it uses the SVNkit as
a SVN client.
We notice that sometimes zip file is NOT updated from the SVN server.

On another occasion, we're not sure why when someone checks in their
jars, the SVN client sees that as a conflict.
We could see that the SVN status code is not a U but a C or a M.

We like to know
1) why is the zip file not updatable by the client
2) How does the server or the client determine the SVN status code and
then determine its action whether to update or requires manual
conflict resolution.
3) When the client shows an  M or something else other than U, A or
AU, do we have to worry about any conflicts not resolved. At this
point, we know C is bad news.
4) How does AU differ from A; we see this when we do a fresh checkout.


Thanks All
Sincerely

svn info and svnlook - quick questions

[Z W]

Hi All

We're new to subversion.

We like to make sure we get the latest svn revision number from the
svn repository on the remote server.
We are confused as to which command to use to find our latest revision number.
Questions
1-
Which is correct -
svn info url or
svnlook youngest

2-
We thought svnlook is only available for the remote svn server but it
seems we can execute it.
We thought svnlook is a svn server command and not a svn client
command - are we correct ?

3-
How do we know if the host we're running on is an svn server and not a
svn client ?
How do we know from the installation perspective that we have a local
svn server ?

4-
Is a working copy trunk after checking out from a remote server trunk
be considered a repository ?
We ask because we're not sure when notes on the internet that says
repository, do they mean on the server or the local copy.

Thanks for helping to clarify.
Sincerely

Re: svn info and svnlook - quick questions

[Prabhu Gnana Sundar]

Z W mpc8...@gmail.com wrote:

Hi All

We're new to subversion.

We like to make sure we get the latest svn revision number from the
svn repository on the remote server.
We are confused as to which command to use to find our latest revision
number.
Questions
1-
Which is correct -
svn info url or
svnlook youngest


Both are fine. But svnlook is a server side command.

2-
We thought svnlook is only available for the remote svn server but it
seems we can execute it.
We thought svnlook is a svn server command and not a svn client
command - are we correct ?


AFAIK, svnlook is just a server side command. From client side we may have to 
use log, diff, info, etc.

3-
How do we know if the host we're running on is an svn server and not a
svn client ?
How do we know from the installation perspective that we have a local
svn server ?


Svnadmin --version should let know that it has the svnadmin executable.
To know if the host is a svn server, check if apache server is running and 
check httpd.conf for location ... directive and subversion settings in it.

4-
Is a working copy trunk after checking out from a remote server trunk
be considered a repository ?

No, it can not be considered as a repo.

We ask because we're not sure when notes on the internet that says
repository, do they mean on the server or the local copy.



--prabhugs

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: svn info and svnlook - quick questions

[Thorsten Schöning]

Guten Tag Z W,
am Sonntag, 20. Januar 2013 um 00:56 schrieben Sie:

 2-
 We thought svnlook is only available for the remote svn server but it
 seems we can execute it.
 We thought svnlook is a svn server command and not a svn client
 command - are we correct ?

Look at the help or manpage for svnlook and compare it to svn help co,
for example, svnlook needs a path to a repo, svn co URLs. svnlook may
just be available in whatever you installed to use Subversion, as some
distribution provide client and server binaries in one package.

 3-
 How do we know if the host we're running on is an svn server and not a
 svn client ?
 How do we know from the installation perspective that we have a local
 svn server ?

I think you can't be sure, you can only guess after checking all
different methods to run an svn server: httpd, svnserve and whatever
is available. What's the reason behind this question?

 4-
 Is a working copy trunk after checking out from a remote server trunk
 be considered a repository ?

No, it's a working copy as everything client side which was fetched
from a server and is still under version control is a working copy. In
contrary to an export for example, which is fetched from a
server/repo, but is not under version control anymore.

 We ask because we're not sure when notes on the internet that says
 repository, do they mean on the server or the local copy.

Repository means server, but as always sometimes people use terms
wrongly or one just misunderstands the context, as repositories of
course can be local to the server serving the repos. Most of the time
it's clear in the context, else just ask the list. :-)

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: SVN Usage Questions

[Ulrich Eckhardt]

Am 08.11.2012 23:39, schrieb Ahmed, Omair (GE Oil  Gas):

I am looking for some guidance on where to store build artifacts in SVN.


Generally, the advise is not to store build artifacts. Compiled binaries 
can't be merged or diffed meaningfully, which makes them dead ends as 
far as their handling is concerned.


That said, there are cases where this really makes sense, and that is in 
particular when making a release who's binary results are shipped to 
customers. In that case, it isn't really important that this is an 
endpoint in development and not further modified. The important point is 
rather that you can retrieve the exact binaries that were shipped to 
customers if/when they report problems etc. If you then need to change 
anything, you simply create a second release that has a similar base but 
is not directly derived from the earlier one. These releases are very 
similar to what is customary called a tag in SVN.




Our proposed process calls for the build engineer to copy the code from
the SVN repo to the build server. When a build has been executed, where
should we copy the artifacts (the executables) back to? Is the /release
directory appropriate or is the another standard way to store the
artifacts?


Firstly, I would use a working copy instead of manually copying things. 
This should also be the approach for making a nightly build (for 
continuous integration), except that you don't store the nightly build 
results. In order to make a release, I would first assemble the required 
sources by copying or linking (via svn:external) them into a working 
copy. Alternatively, check out a working copy of the sources, if they 
only consist of a single project folder. Then, build the sources. If the 
build succeeds (and perhaps after some testing), I would add the build 
artifacts and commit this to a new release folder. Make sure that you 
don't commit this to the regular development folder but instead copy the 
whole working copy including the added binaries to the new location. 
This can and should be scripted, so that the script knows exactly which 
source versions you use and to avoid avoid error-prone human interaction.


Note: Copying things is cheap in SVN, concerning both time and space, 
since representations are shared and only differences take up space. 
Creating a copy of several hundred MB of sources is therefore not a big 
deal. You should refrain from checking out a whole repository as a 
working copy though!




Secondly, if we check-in to the /release folder, what mechanism is there
to readily identify the artifacts. Do we create a /release/rel_1 type
structure or is there some labeling convention  available in SVN? Unless
I am I missing something very obvious, I don't see a way to apply labels
in SVN.


Applying labels? SVN just versions file trees. All other things like the 
trunk/branches/tags structure are purely by convention. Further, you can 
also set custom properties (svn propset ..) on items in the 
repository, which you can also use internally. All you have to do is 
decide on a convention how the meaning you attach to some things is 
represented in SVN.


Good luck!

Uli



**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den 
Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte 
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte 
Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf 
weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht 
verantwortlich.
**

Two questions about svn log of a deleted file

[Niemann, Hartmut]

Hello!

(This is TortoiseSVN's command line client
   svn, version 1.7.7 (r1393599)
   compiled Oct  8 2012, 18:39:05, 
 belonging to 
   TortoiseSVN 1.7.10, Build 23359 - 32 Bit , 2012/10/08 11:46:26
 on Windows XP, if that makes a difference)

I deleted a file a.txt in revision 1186.
 
svn log a.txt 
gives 
svn: E160013: File not found: revision 1197, path '/...
which is not surprising.
 
But what is the canonical way of getting the latest log of this file?
 
svn log a.txt@1100 gives me the history up to rev. 1100
svn log a.txt@1185 gives me the history up to rev. 1185 (which ends at rev 
1132, no newer changes)
svn log a.txt@1186 gives me a file not found error.

Question 1:
How do I get the complete newer history for a.txt@1100?

From the help text I thought 
svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
as the file is not present in HEAD I get a file not found error for all
-r parameters involving HEAD that I tried.


Question 2:
Tortoise SVN has a log view where all files changed in a revision, 
including this deleted one, are shown. (At the moment I do not need to know
how this can be done with command line svn.)
I can get a log for this file from there, but this log stops at revision 1132.

Is my observation correct that the log information for a file
does not include it's deletion?

Is this a good idea? Or am I missing something?

How would one answer the question when was file a.txt deleted, which 
was present in revision 1100 and is missing now?

I would expect that the lifecycle of a file in subversion starts with it's 
addition and stops with it's deletion, and that the full log includes both,
but this does not seem to be the case?

Thank you for your time.

Hartmut

 

 
 

Mit freundlichen Grüßen
Dr. Hartmut Niemann 

Siemens AG 
Infrastructure  Cities Sector
Rail Systems Division
Locomotives and Components 
IC RL LOC EN LE 8 
Werner-von-Siemens-Str. 67 
91052 Erlangen, Deutschland 
Tel.: +49 9131 7-34264 
Fax: +49 9131 7-26254 
mailto:hartmut.niem...@siemens.com 

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; 
Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus 
Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter 
Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, 
Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 
6684; WEEE-Reg.-Nr. DE 23691322 

Re: Two questions about svn log of a deleted file

[Stefan Sperling]

On Thu, Nov 08, 2012 at 03:15:49PM +0100, Niemann, Hartmut wrote:
 Hello!
 
 (This is TortoiseSVN's command line client
svn, version 1.7.7 (r1393599)
compiled Oct  8 2012, 18:39:05, 
  belonging to 
TortoiseSVN 1.7.10, Build 23359 - 32 Bit , 2012/10/08 11:46:26
  on Windows XP, if that makes a difference)
 
 I deleted a file a.txt in revision 1186.
  
   svn log a.txt 
 gives 
   svn: E160013: File not found: revision 1197, path '/...
 which is not surprising.
  
 But what is the canonical way of getting the latest log of this file?
  
 svn log a.txt@1100 gives me the history up to rev. 1100
 svn log a.txt@1185 gives me the history up to rev. 1185 (which ends at rev 
 1132, no newer changes)
 svn log a.txt@1186 gives me a file not found error.
 
 Question 1:
 How do I get the complete newer history for a.txt@1100?
 
 From the help text I thought 
 svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
 as the file is not present in HEAD I get a file not found error for all
 -r parameters involving HEAD that I tried.

This is because the default peg revision is HEAD with such an
invocation. See http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
(I'm just mentioning this for completeness -- given what you're saying
above you seem to understand this already.)

 Question 2:
 Tortoise SVN has a log view where all files changed in a revision, 
 including this deleted one, are shown. (At the moment I do not need to know
 how this can be done with command line svn.)
 I can get a log for this file from there, but this log stops at revision 1132.
 
 Is my observation correct that the log information for a file
 does not include it's deletion?

Yes, a deletion of a node is an operation on the node's parent because
of the way Subversion's repository is structured.
Recall that files and directories are both versioned explicitly, and
that the list of children is one versioned component of a directory.

 Is this a good idea? Or am I missing something?
 
 How would one answer the question when was file a.txt deleted, which 
 was present in revision 1100 and is missing now?

The current answer isn't very satisfying.
It is to run 'svn log -v' on a parent directory which has not been deleted
yet and search the log output for the filename. In the extreme case this
means running svn log on the repository root and searching all revisions.

In my opinion, the best answer is currently using TortoiseSVN's log
search feature and search for the name of the deleted file, simply
because it is faster.

In Subversion 1.8, 'svn log' will have a roughly similar feature.
It will allow filtering log messages based on search patterns matching
log message attributes and contents, including the list of changed paths
if the -v option is given. So in Subversion 1.8 you'll be able to run
something like 'svn log -v --search a.txt ^/trunk' which will only show
log messages which contain a.txt somewhere. This is still suboptimal
because it doesn't directly answer the question of when a.txt was deleted.
But at least you'll have a shorter list of log message to plough through.
And maybe the list can be made shorter by using a more precise search pattern.

SVN Usage Questions

[Ahmed, Omair (GE Oil Gas)]

Hi,

 

I am looking for some guidance on where to store build artifacts in SVN.
Our projects are organized in the typical fashion:

 

/trunk/Customer1/

../../src

../../database

/branch

/tags

/release

 

Our official build server is a QNX system, a Unix-like OS.  

 

Our proposed process calls for the build engineer to copy the code from
the SVN repo to the build server. When a build has been executed, where
should we copy the artifacts (the executables) back to? Is the /release
directory appropriate or is the another standard way to store the
artifacts? 

 

How are other people handling this? 

 

Secondly, if we check-in to the /release folder, what mechanism is there
to readily identify the artifacts. Do we create a /release/rel_1 type
structure or is there some labeling convention  available in SVN? Unless
I am I missing something very obvious, I don't see a way to apply labels
in SVN.

 

Please advise.

Re: SVN Usage Questions

[Richard Cavell]

Just my two cents, but I think that release should only refer to builds that 
have been shipped to the end-user and are in usage.

 Why not have a top-level directory:

 /build

 And if it's automated to build every night, it could have:

 /build/9 November 2012/...
 /build/8 November 2012/...
 /build/7 November 2012/...

 And dump all build artifacts in there.

 Richard

- Original Message -
From: Ahmed, Omair (GE Oil  Gas)
Sent: 11/09/12 08:39 AM
To: users@subversion.apache.org
Subject: SVN Usage Questions

 Hi,
 I am looking for some guidance on where to store build artifacts in SVN. Our 
projects are organized in the typical fashion:
 /trunk/Customer1/
 ../../src
 ../../database
 /branch
 /tags
 /release
 Our official build server is a QNX system, a Unix-like OS. 
 Our proposed process calls for the build engineer to copy the code from the 
SVN repo to the build server. When a build has been executed, where should we 
copy the artifacts (the executables) back to? Is the /release directory 
appropriate or is the another “standard” way to store the artifacts?
 How are other people handling this?
 Secondly, if we check-in to the /release folder, what mechanism is there to 
readily identify the artifacts. Do we create a /release/rel_1 type structure or 
is there some labeling convention available in SVN? Unless I am I missing 
something very obvious, I don’t see a way to apply labels in SVN.
 Please advise.

Re: SVN Usage Questions

[Thorsten Schöning]

Guten Tag Ahmed, Omair (GE Oil  Gas),
am Donnerstag, 8. November 2012 um 23:39 schrieben Sie:

 Our proposed process calls for the build engineer to copy the code
 from the SVN repo to the build server. When a build has been
 executed, where should we copy the artifacts (the executables) back
 to?

In my opinion that highly depends on what you need the executables
for. Are they available to customers and each customer can download
them from a server in the version he needs? Are you pushing specific
releases to specific customers, resulting in each customer has it
slightly different version?

 Is the /release directory appropriate or is the another
 “standard” way to store the artifacts? 

Per default the tags folder is for things which can be released and
are (normally) immutable. I for example have a specific repo
containing only the binaries of one of your products, were trunk is
the current development and tags consists of a customer specific
directory structure because we push slightly different versions to
different customers.

One of our other products is more generalized for all customers,
therefore I have another repo for that where tags consists of
directories with simple version names like /tags/1.2.3, tags/1.2.4 and
so on and each customer just downloads the version he wants.

 Secondly, if we check-in to the /release folder, what mechanism is
 there to readily identify the artifacts. Do we create a
 /release/rel_1 type structure or is there some labeling convention 
 available in SVN? Unless I am I missing something very obvious, I
 don’t see a way to apply labels in SVN.

Directory and file names itself are the labels and from my point of
view their naming convention heavily depends on the targets you like
to address with the names. rel_1 may not be as readable for
customers as 1.2.3 or Windows 98, Windows 98 SE etc.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: general questions

[John Maher]

Tortoise is pretty cool, the best out of what I tried, and I haven't
tried much.  But there are some things it can not do.

 

John

 



From: David Chapman [mailto:dcchap...@acm.org] 
Sent: Monday, September 10, 2012 4:17 PM
To: John Maher
Cc: Mark Phippard; users@subversion.apache.org
Subject: Re: general questions

 

On 9/10/2012 12:31 PM, John Maher wrote:

Thanks Dave, that was helpful.

 

I saw the svn prefix in the book but didn't know what it meant.
Your explanation was good.

 

The scripts are a good idea, but I was thinking about a gui for
the client side, kinda like Subversion Edge; basically a wrapper for the
command line.  Even though my first computer didn't have a mouse (or
hard drive) the gui is the way to go, typing commands is just not the
future.  I may start something to make my job easier.  I think HTML
would benefit the most people.  But I need to learn a lot more first.


Hmm, my first personal computer had a hexadecimal keypad and 256 bytes
(not even kilobytes!) of memory.  :-)

Scripts (aka typing) allow repeatability.  A GUI that allows you to
specify a set of options for every repository can be helpful, but down
inside it will be doing the same thing as a script - and a script is
easier to customize or debug when the existing tools don't do what you
need.  Also, scripts don't disappear if the GUI goes down.  For this
reason many sysadmins prefer scripts over GUI-based tools, and I don't
see this ever changing.  As a result, I can't help you find a GUI that
will help you administer your repositories.

TortoiseSVN is a client-side GUI for Windows-based machines but I
haven't used it.  I don't know how close it comes to meeting your needs.



-- 
David Chapman  dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

RE: general questions

[John Maher]

Interesting discussion.  It appears you have not had the chance to work
with a good wrapper, or maybe you shun guis or something because there
appears to be a strong bias to your statements.  I have been a
programmer AND user on both sides, gui and command line, so I am not
making things up.


 I'm not saying GUIs don't work.  Just that they are generally a subset
 of what can be done with commands.

This is simply not true.  Expose every function and every parameter and
there is nothing the gui can not do.  Add some automation, and the gui
can actually do more.


 You are making some assumptions about scale and locality here.  I have
 most of the world at my fingertips in the form of URLs.

Of course I am.  I must make some assumptions or there is nothing to
talk about.  Don't forget a gui can have a box where a URL is entered so
it can do everything you can by just typing in stuff plus anything else
that gets added.


 OK, but if I regularly work with 44 repositories, I'm likely to have
 their URLs in a file where a script can extract them a lot faster than
 you can navigate the world in a picklist.

Now you're making assumptions, that's OK though.  Makes for a good
discussion.  And you are right.  Nothing works best 100% of the time.
Now think of the reverse of that.  What if you wish to do something to
44 repositories once?  Whats better typing them all in or clicking on
them.  You can type, I'll click.


 Let's assume the list of choices won't fit on a screen...

See above reply.


 But it can only be a good design after you already now what I'm going
 to do.   Until then you can only offer the bazillion choices.

Again, not true.  With experience comes wisdom.  Although you can never
predict a user 100% of the time, you can learn to be spot on 50% (or
better) of the time.  And you seem to be forgetting a gui can do
anything text can do by offering a textbox.  There's a bazillion right
there.  You also have a bazillion at the command line.  I think what you
are picturing is nothing like what I am planning.  lol.  At least I
would never use the same words to describe it as you do.


John

-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com] 
Sent: Monday, September 10, 2012 4:29 PM
To: John Maher
Cc: David Chapman; Mark Phippard; users@subversion.apache.org
Subject: Re: general questions

On Mon, Sep 10, 2012 at 3:15 PM, John Maher jo...@rotair.com wrote:
 I don't 100% agree.  I've designed lots of guis.  And there were times
 users discovered a feature I never intended.  And I'm not talking
about
 a bug called a feature.  While true that the programmer has a lot to
 think about (fortunately I am one), the gui can be designed in such a
 way to empower the user.

I'm not saying GUIs don't work.  Just that they are generally a subset
of what can be done with commands.

 Simply presenting the choices in a list will
 speed use by avoiding typing in long paths and the occasional type.

You are making some assumptions about scale and locality here.  I have
most of the world at my fingertips in the form of URLs.

 Having a multi-selectable list allows any command ease of application
to
 many targets with a loop you spoke of.  I never have to think of every
 possibility the user can enter, just every possibility of a command I
 will execute.  They are not the same.

OK, but if I regularly work with 44 repositories, I'm likely to have
their URLs in a file where a script can extract them a lot faster than
you can navigate the world in a picklist.

 You are right where a script is more suitable for a sequence on many
 things.  My gui will never be able to compete with that.  On a single
 operation on many things, if the gui can do it, it will win every
time.
 I can out-click a very fast typer, probably not the fastest.

Let's assume the list of choices won't fit on a screen...

 And if it requires a bazillion mouse clicks, it is a poor design.

But it can only be a good design after you already now what I'm going
to do.   Until then you can only offer the bazillion choices.

-- 
   Les Mikesell
  lesmikes...@gmail.com

RE: general questions

[John Maher]

On our server we have 21 repositories.  One of those repositories contains 44 
projects (dlls).  Each project needs the svn:ignore property set.

You're right, it is not common.  But several times I had to leave tortoise to 
go to the command line.  It's just one more pain.  I feel there is a better 
way, I am just not sure what that way is, yet.

John

-Original Message-
From: Bob Archer [mailto:bob.arc...@amsi.com] 
Sent: Monday, September 10, 2012 5:59 PM
To: John Maher; Thorsten Schöning; users@subversion.apache.org
Subject: RE: general questions

 If you think it would require 44 click paths then that is indeed a poor 
 design.
 

Do you really have 44 repositories? Or 44 projects in a single repository? 

 1 click to select the repository, 1 click to select all.  I just turned 44 
 click paths
 into 2 clicks.  Sounds like your vision is nothing like mine.
 
 What other guis are out there besides tortoise?  If there's something I like, 
 I'll
 use it.  Otherwise I'll make one if only to illustrate what seems difficult 
 for me
 to explain and others to grasp.

Tortoise is the best GUI for Windows I think. There are others. But, what you 
are doing is not a COMMON use case. The common use case it to add your ignores 
when you set up a new project in your repository. Doing 44 after the fact is 
not a standard use case. 

Here is a list to some of the others:

http://svn-ref.assembla.com/windows-svn-client-reviews.html

BOb


 
 John

Re: general questions

[Mark Phippard]

On Tue, Sep 11, 2012 at 8:32 AM, John Maher jo...@rotair.com wrote:

 On our server we have 21 repositories.  One of those repositories contains
 44 projects (dlls).  Each project needs the svn:ignore property set.

 You're right, it is not common.  But several times I had to leave tortoise
 to go to the command line.  It's just one more pain.  I feel there is a
 better way, I am just not sure what that way is, yet.


You can set properties using TortoiseSVN:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props

You can also set properties on folders recursively.  The problem with doing
this for svn:ignore is that it is a multi-line property and it would be
fairly uncommon to want an identical property value for every folder.  If
that is what you want, setting it would be very easy to do.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: general questions

[John Maher]

Thanks Mark!!!  That might be exactly what I was looking for.  Now I have an 
unusual question I don't know if anyone knows the answer.  I may just try it 
anyway.  What happens if I have more ignores than I need.  Will it hurt 
performance much?  For example, my setup looks like this:

 

Reporitory/Project1

Reporitory/Project1/bin

Reporitory/Project1/Graphics

Reporitory/Project1/My Project

Reporitory/Project1/obj

Reporitory/Project1/sql

Reporitory/Project2
...

Reporitory/Project44

 

What if I set this property recursively svn:ignore *.sou *proj.user bin obj?  
I know it will get applied to many directories unnecessarily.  For example, 
only the top level directory (Project1) will contain any *.sou files.  The 
ignore will get applied everywhere, even where it is not needed.  Can this 
cause any major issues?  I like the idea of entering the property once.  
Although I can go down the line and paste the property where it is supposed to 
go.  Is it worth the extra effort?

 

That is what I was looking for Mark, thanks.

 

John

 

 



From: Mark Phippard [mailto:markp...@gmail.com] 
Sent: Tuesday, September 11, 2012 8:41 AM
To: John Maher
Cc: Bob Archer; Thorsten Schöning; users@subversion.apache.org
Subject: Re: general questions

 

On Tue, Sep 11, 2012 at 8:32 AM, John Maher jo...@rotair.com wrote:

On our server we have 21 repositories.  One of those repositories 
contains 44 projects (dlls).  Each project needs the svn:ignore property set.

You're right, it is not common.  But several times I had to leave 
tortoise to go to the command line.  It's just one more pain.  I feel there is 
a better way, I am just not sure what that way is, yet.

 

You can set properties using TortoiseSVN:

 

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props

 

You can also set properties on folders recursively.  The problem with doing 
this for svn:ignore is that it is a multi-line property and it would be fairly 
uncommon to want an identical property value for every folder.  If that is what 
you want, setting it would be very easy to do.

 

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: general questions

[Mark Phippard]

On Tue, Sep 11, 2012 at 9:38 AM, John Maher jo...@rotair.com wrote:

  Thanks Mark!!!  That might be exactly what I was looking for.  Now I
 have an unusual question I don’t know if anyone knows the answer.  I may
 just try it anyway.  What happens if I have more ignores than I need.  Will
 it hurt performance much?  For example, my setup looks like this:

 ** **

 Reporitory/Project1

 Reporitory/Project1/bin

 Reporitory/Project1/Graphics

 Reporitory/Project1/My Project

 Reporitory/Project1/obj

 Reporitory/Project1/sql


If this were me, I would have an svn:ignore on my Project1 folder that
ignores the bin and obj folder.  That would cause everything inside those
folders to also be ignored.

For other folders, I could then add specific file patterns only if needed.
Odds are I would have all my build output in bin and obj though so probably
not a lot else to ignore.

What if I set this property recursively “svn:ignore *.sou *proj.user bin
 obj”?  I know it will get applied to many directories unnecessarily.


I do not think it will cause any performance issues at all.  That said, it
seems like those ignores would only need to be applied on the project root
folder.  If you have bin and obj folders being created all over the place
it seems like you ought to fix that.


 For example, only the top level directory (Project1) will contain any
 *.sou files.  The ignore will get applied everywhere, even where it is not
 needed.  Can this cause any major issues?


No.


   I like the idea of entering the property once.  Although I can go down
 the line and paste the property where it is supposed to go.  Is it worth
 the extra effort?


Setting svn:ignore is pretty much a one-time deal. That is why you are not
going to find many tools to automate.  There is no payoff in spending the
time to write such a tool.  I personally do not like seeing the property
set where it is not needed or with values that are not needed.  It does not
cause performance problems, it just adds noise.  I do not believe
manually setting up the property is a lot of work.  Even if it is 44
projects.  I would just set it up and deal with it as needed.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/