[Mageia-sysadm] Packages SVN

Thu Nov 4 07:48:40 CET 2010

On Wed, Nov 03, 2010 at 11:12:53PM +0100, Olivier Blin wrote:
+>nicolas vigier <boklm at mars-attacks.org> writes:
+>
+>> We can also remove history on cauldron binary branch, although it will
+>> require to stop new commits for a few minutes/hours, doing something like
+>> this :
+>> http://robmayhew.com/delete-parts-of-subversion-history/
+>
+>Right, we could do in such a way.
+>Each N distro branch could contain binary history from N-1 to N.
+>
+>For example when we release 2011.1, we would have binary history in the
+>2011.1 distro branch from 2011.0 to 2011.1, and start cauldron from a
+>one-revision copy.
+>
+>Though, there is a disadvantage that could get problematic, when we do
+>backports, we would have to copy the binaries to all target distros, and
+>it would not be a cheap SVN copy anymore.
+>This could get pretty big with games and OOo...
+
+I wonder why use svn at all in order to store blobs
+IMHO it does not give any advantage
+source tarballs in packages are usually compressed, so no delta is
+possible, besides that sources are usually removed and the new one is
+added, so it wont be even tried.
+removing something from SVN is a PITA
+creating a branch for each distro will waste enormous amounts of space,
+and will create the issue pointed above by blino.
+
+why not just use flat files to store flat files?
+iirc redhat is doing this to store files
+
+if i were to design this i would index flat files by sha
+and modify repsys/mdvsys in order to commit a file containing the sha in
+svn://specrepo/package/SOURCES/foo-0.0.1.tar.xz instead of the real blob
+and checkout the real file from file://binrepo/hashed_dir/sha instead of
+the dummy.
+
+Cleanup can be done programmatically by retrieving dummy files from the
+specrepo, with a set criteria (eg stuff tagged with a distro release
+number), and killing the unreferenced ones.
+
+This would also be useful spacewise, because we could safely kill blobs
+that were never released: when in cauldron we upload a svn/git version
+of foo to test, but in the release a real version is included. After a
+while killing all the foo-0.0.1.svn203892 that never went into a release
+would be nice and noone will miss them.
+
+It would also allow to share the same blob beetween two different
+packages, maybe less useful, but it would come for free.
+
+L.
+
+-- 
+Luca Berra -- bluca at vodka.it
+