After asking and discussions at stackoverflow,
comp.software.config-mgmt, debian-russ...@lists.debian.org, I
make decision create FRS (file release service) from SVN.
FRS (like in SourceForge) allow anonymous download and
authenticated upload of files.
Main purpose is to share build artifacts (libraries, art,
installers, etc) between in house projects to achieve modularity
and allow repetition of build configuration (when user report bug
in version x.y.z you always have this binary in FRS).
Currently we use FTP.
I plan recommend storing build artifacts in SVN in hierarchy:
/frs/[vendor]/[product]/[version]/[platform]
with [version] in form of [MAJOR].[MINOR].[REV] with versioning
semantic like in 'libtool' documentation.
With SVN you can get a LOT of benefits:
* SVN prevent concurrent submission (FTP/sftp/scp also allow this).
* Atomic upload (FTP/sftp/scp does not allow this).
* Easy maintain access:
* 'svn.authz' have simple format.
* Apache can reuse existing LDAP (with FTP/SSH this is not
possible directly).
* SVN client allow password caching (with FTP we store
password in build files, with SSH/SCP/SFTP we need public
keys management).
* Safety:
* You can not completely delete file without possibility
get it back (FTP/SSH does not allow this).
* By hooks you can be notified about new file
submission (FTP/SSH does not allow this).
* By hook you can prevent from file overwriting, so one
[version] is one thing, your test team always can refer to
version as synonym of entity (with FTP this is not possible,
with SSH you need set tricky +s bit on directories).
* History: who, what and when (FTP usually accessed by single
account so does not store who, by SSH you need add as many
users as you have developers and you ignore existing LDAP DB).
Also I propose workflow:
With 'dav_svn' you allow anonymous downloads by HTTP protocol,
this is possible from GNU Make and Apache Ant environment.
Before first project upload (manual step) you create path:
/frs/[vendor]/[product]/
and grant write permission to it.
In every project you maintain VERSION and CHANGES files. Before
releasing you increment VERSION and update content of CHANGES.
Commit changes to favorite VCS. Create tag in this VCS.
Tag creation can hooking auto build. Or manually get tagged
sources, build and release as follow:
$ cd dist
$ ls
proj.jar
$ svn co -N https://$HOST/frs/[vendor]/[product]/ [vendor]-[product]
$ mkdir [vendor]-[product]/[version]
$ cp proj.jar [vendor]-[product]/[version]
$ cd [vendor]-[product]
$ svn add [version]
$ svn propset svn:mime-type application/octet-stream [version]/proj.jar
$ svn ci -m "Release [product] of [vendor] in v[version]."
That is all!
Note that with DVCS you can not get efficient submission because
DVCS does not allow partial checkout.
Any comment welcome.
How is good to use SVN in such way?
Are there already exist any ready solution?
