Access to non SVN files via svn property - Feature request

[fr...@selex-es.com]

Hi all,

What feature do we suggest? A new svn property (aliens? :-) to reach 
"pure" http paths; during svn checkouts, when this property is followed, 
the standard http protocol is used and the resulting subtree is marked as 
"specially managed", so that svn status does not see it as a standard 
unversioned tree (this is to avoid that the user, by mistake, adds the 
tree to SVN repo. Similar ideas apply for svn export and svn commit.

Here is the background: in our company we have been managing SVN 
repositories since 2007; one of these repo has more than 800000 revisions 
and uses almost 140GB.
The reason for this large size is that, despite of the rules we stated, 
many users committed big binary files. Some were by mistake, some because 
the users found SVN the most reasonable place.
For the latter case I am referring to libraries and artifacts that are 
necessary to build the final product, that will be stored using the 
company PLM tool, not in SVN repo.
We then introduced an artifact repository manager, namely Sonatype Nexus, 
to store these artifacts;  we store in Nexus any kind of artifact, 
whichever is the programming language used to produce it.
For development trees we are used to set svn:externals property to access 
source files, possibly in other SVN repositories; we know it is "legal" to 
access binary files and libraries too, provided they are stored in a 
Subversion repository. But we strongly discourage such a behaviour and 
suggest to use Nexus instead.
What is our build process for a large project?
The modules are debugged and tested, the resulting artifact is stored (and 
versioned) on Nexus.
When programmers have to produce the final product they need to have a 
complete tree, made of sources for the main tree and of objects/libraries 
for the modules.
The problem is well known: it is impossible to access Nexus repositories 
via http through svn:externals: SVN expects to use the same protocol for 
the whole tree, externals included.

I did not find anything useful on the web, apart from the suggestion to 
use scripts to produce the correct environment, but such a solution 
depends on the development environment: for some developers it is very 
easy, for others it is not.

Thanks in advance,
Francesco Policastro
Product Data & Configuration Management
Selex ES, A Finmeccanica Company
Via Puccini 2
16154 Genova (Italia)
(Tel.) +39 010 6584092
(Email) francesco.policastro@selex-es.com
www.selex-es.com 

This email and any attachments are confidential to the intended recipient 
and may also be privileged. If you are not the intended recipient please 
delete it from your system and notify the sender. You should not copy it 
or use it for any purpose nor disclose or distribute its contents to any 
other person.
Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via 
riservata all'effettivo destinatario e possono essere soggetti a 
restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto 
il messaggio per errore siete pregati di cancellarlo dal vostro sistema e 
di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi 
titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail 
a qualunque altro soggetto.

Prima di stampare questa comunicazione consideratene, per favore, 
l'impatto ambientale
Please consider the environment before printing this email 

Re: Access to non SVN files via svn property - Feature request

[fr...@selex-es.com]

Hi Eric,

Thanks for your reply, that is similar to those I already received.
My post was long enough, so I did not say that we have hundreds of 
programmers and a lot of projects, ranging from the smallest to the 
largest you can think of.
The languages and build tools used are very many, so getting a common 
solution is not easy.
Java programmers use Maven, of course, and none of them asked for the 
feature I am requesting;  the others, i.e. the most, do not even know what 
maven is.
Ivy? Yes, it could be a good solution, but we should be prepared to spread 
its knowledge throughout the company. Training courses, as we did for SVN, 
or e-learning could be useful.
It would be hard to convince those low level programmers who manage 
firmware or those who write embedded applications for linux or android, 
anyway.
We will see...

Francesco

Re: Access to non SVN files via svn property - Feature request

[Eric Johnson <er...@tibco.com>]

Sounds like you're trying to solve the problem with the wrong tool.

What you probably want is a build system that fetches binary/built
dependencies for you. Since you're using Nexus, why not use Maven to fetch
said large binaries? You may need to spend time wrapping some of your
binaries up with Maven POM metadata, but you can get that done a lot faster
than any possible chance of success waiting for a new feature in a
Subversion client?

If you don't want Maven as your build tool, perhaps you can use Apache Ivy
to fetch your dependencies instead?

Eric.



On Fri, Oct 16, 2015 at 12:58 AM, <fr...@selex-es.com> wrote:

> Hi all,
>
> What feature do we suggest? A new svn property (aliens? :-) to reach
> "pure" http paths; during svn checkouts, when this property is followed,
> the standard http protocol is used and the resulting subtree is marked as
> "specially managed", so that svn status does not see it as a standard
> unversioned tree (this is to avoid that the user, by mistake, adds the tree
> to SVN repo. Similar ideas apply for svn export and svn commit.
>
> Here is the background: in our company we have been managing SVN
> repositories since 2007; one of these repo has more than 800000 revisions
> and uses almost 140GB.
> The reason for this large size is that, despite of the rules we stated,
> many users committed big binary files. Some were by mistake, some because
> the users found SVN the most reasonable place.
> For the latter case I am referring to libraries and artifacts that are
> necessary to build the final product, that will be stored using the company
> PLM tool, not in SVN repo.
> We then introduced an artifact repository manager, namely Sonatype Nexus,
> to store these artifacts;  we store in Nexus any kind of artifact,
> whichever is the programming language used to produce it.
> For development trees we are used to set svn:externals property to access
> source files, possibly in other SVN repositories; we know it is "legal" to
> access binary files and libraries too, provided they are stored in a
> Subversion repository. But we strongly discourage such a behaviour and
> suggest to use Nexus instead.
> What is our build process for a large project?
> The modules are debugged and tested, the resulting artifact is stored (and
> versioned) on Nexus.
> When programmers have to produce the final product they need to have a
> complete tree, made of sources for the main tree and of objects/libraries
> for the modules.
> The problem is well known: it is impossible to access Nexus repositories
> via http through svn:externals: SVN expects to use the same protocol for
> the whole tree, externals included.
>
> I did not find anything useful on the web, apart from the suggestion to
> use scripts to produce the correct environment, but such a solution depends
> on the development environment: for some developers it is very easy, for
> others it is not.
>
> Thanks in advance,
> *Francesco Policastro*
> Product Data & Configuration Management
> Selex ES, A Finmeccanica Company
> Via Puccini 2
> 16154 Genova (Italia)
> (Tel.) +39 010 6584092
> (Email) francesco.policastro@selex-es.com
> www.selex-es.com
>
> This email and any attachments are confidential to the intended recipient
> and may also be privileged. If you are not the intended recipient please
> delete it from your system and notify the sender. You should not copy it or
> use it for any purpose nor disclose or distribute its contents to any other
> person.
> Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via
> riservata all'effettivo destinatario e possono essere soggetti a
> restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto
> il messaggio per errore siete pregati di cancellarlo dal vostro sistema e
> di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi
> titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a
> qualunque altro soggetto.
> [image: Tree]
> Prima di stampare questa comunicazione consideratene, per favore,
> l'impatto ambientale
> Please consider the environment before printing this email