Re: Svn server images / appliances / packages

[Nathan Hartman]

On Mon, Jan 13, 2020 at 9:00 AM Julian Foad  wrote:
> Recognizing that OS/packaging is only one small part of the issue, we
> will want to specify a reference system in terms like these...
>
> Essentials
>
>* OS and installation procedure
>  - see above
>* Subversion access methods:
>  - http, https (mod_dav_svn)
>  - svn (svnserve)
>  - domain name / IP address / ports
>* authn & authz:
>  - manually configured authn
>  - manually configured authz rules
>  - some semi-realistic examples of each
>* an automated backup, of some sort
>  - see below
>* repo organization
>  - single repo
>  - many repos
>
> Bonus extras
>
>* LDAP integration
>* an svnsync mirror configuration
>* scripted creation of repositories from templates
>* hook scripts: semi-realistic examples
>* ...
>
> Some of these -- such as "an automated backup, of some sort" -- will
> lead to us having to discuss what is going to be our best practice
> recommendation.  I think the need to deal with issues like that would be
> an important and valuable outcome of this project.

A few days ago I jotted down a few bulletpoints in my notes. The
purpose was to think about what subject headings might be found in an
administrator's reference.

Not terribly important or groundbreaking, but I'll post it for
completeness:

(1) Choosing the hardware and software platform
(2) Installation (ok the least of your worries)
(3) Configuration and security
(4) Maintenance: What specifically does the administrator need to do?
How to do these tasks? Suggested maintenance schedule? What are
the specific pitfalls and complexities? What to do about them?
(5) Backup and restore
(6) Relocating a repository

Nathan

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
> On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> > Since both 'svn ls -v' and 'svn blame' can be called on a repository
> > URL, I don't really see the point in caching the max(length(author))
> > of the working copy.
> > 
> > The output from a URL would still be mis-aligned. It would make the
> > presentation inconsistent between calling it on a working copy and on
> > a URL.
> 
> Good point. I was about to say that in most cases, these commands are
> run from a working copy. But I now think that caching should be done
> under the user's home (just like with most applications). Under Unix,
> this would be under "$XDG_CACHE_HOME/subversion".

When would data be evicted from the cache?

> The data should be associated with the URL of the repository.

I'd say UUID, but we don't have to decide this now.

Re: Svn server images / appliances / packages

[Stefan Sperling]

On Mon, Jan 13, 2020 at 02:00:15PM +, Julian Foad wrote:
> Recognizing that OS/packaging is only one small part of the issue, we will
> want to specify a reference system in terms like these...
> 
> Essentials
> 
>   * OS and installation procedure
> - see above
>   * Subversion access methods:
> - http, https (mod_dav_svn)
> - svn (svnserve)
> - domain name / IP address / ports
>   * authn & authz:
> - manually configured authn
> - manually configured authz rules
> - some semi-realistic examples of each
>   * an automated backup, of some sort
> - see below
>   * repo organization
> - single repo
> - many repos

The above list seems to have some overlap with contents of the
svn book's Server Configuration chapter and others.

> Some of these -- such as "an automated backup, of some sort" -- will lead to
> us having to discuss what is going to be our best practice recommendation.
> I think the need to deal with issues like that would be an important and
> valuable outcome of this project.

Perhaps improving relevant sections of the svn book would be a
desirable outcome?

Re: Svn server images / appliances / packages

[Julian Foad]

Julian Foad wrote:

[...] suitable "reference system" options [...]:

   * Ubuntu (server, latest LTS)
   * Docker (probably using an Alpine image, or maybe Ubuntu)


Recognizing that OS/packaging is only one small part of the issue, we 
will want to specify a reference system in terms like these...


Essentials

  * OS and installation procedure
- see above
  * Subversion access methods:
- http, https (mod_dav_svn)
- svn (svnserve)
- domain name / IP address / ports
  * authn & authz:
- manually configured authn
- manually configured authz rules
- some semi-realistic examples of each
  * an automated backup, of some sort
- see below
  * repo organization
- single repo
- many repos

Bonus extras

  * LDAP integration
  * an svnsync mirror configuration
  * scripted creation of repositories from templates
  * hook scripts: semi-realistic examples
  * ...

Some of these -- such as "an automated backup, of some sort" -- will 
lead to us having to discuss what is going to be our best practice 
recommendation.  I think the need to deal with issues like that would be 
an important and valuable outcome of this project.


- Julian

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> Since both 'svn ls -v' and 'svn blame' can be called on a repository
> URL, I don't really see the point in caching the max(length(author))
> of the working copy.
> 
> The output from a URL would still be mis-aligned. It would make the
> presentation inconsistent between calling it on a working copy and on
> a URL.

Good point. I was about to say that in most cases, these commands are
run from a working copy. But I now think that caching should be done
under the user's home (just like with most applications). Under Unix,
this would be under "$XDG_CACHE_HOME/subversion".

The data should be associated with the URL of the repository.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)