From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-sysadm/2010-November/000190.html | 113 ++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 zarb-ml/mageia-sysadm/2010-November/000190.html (limited to 'zarb-ml/mageia-sysadm/2010-November/000190.html') diff --git a/zarb-ml/mageia-sysadm/2010-November/000190.html b/zarb-ml/mageia-sysadm/2010-November/000190.html new file mode 100644 index 000000000..2583c4173 --- /dev/null +++ b/zarb-ml/mageia-sysadm/2010-November/000190.html @@ -0,0 +1,113 @@ + + + + [Mageia-sysadm] Packages SVN + + + + + + + + + +

[Mageia-sysadm] Packages SVN

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Nov 4 15:57:35 CET 2010 +

+
+ +
On Thu, 04 Nov 2010, Luca Berra wrote:
+
+> 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.
+
+I'm not sure we need to keep history from N-1 to N (which is previous
+cooker versions), maybe we can erase it. And only have history from
+N (release date) to N + updates.
+
+>> 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...
+
+Yes.
+
+> I wonder why use svn at all in order to store blobs
+> IMHO it does not give any advantage
+
+The advantage is that it is easier to implement, and already implemented
+now in a repsys branch on git. But it is still possible to replace the
+SVN binary repositories with something else later.
+
+> 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
+
+Removing something from SVN is not very difficult, if removing all
+history before a commit (and not only some of the files).
+
+> 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.
+
+It can be a good idea, but it requires some work to implement it. I
+think it's something that can be done later.
+
+
+ + +
+

+ +
+More information about the Mageia-sysadm +mailing list
+ -- cgit v1.2.1