Kevin Kofler wrote:
Andreas Ericsson <ae <at> op5.se> writes:
Are you trying to imply that KDE has "extremely poor project policy"?
If a the code corresponding to a particular version can be changed once
released publicly, then yes.
What's your definition of "publicly"? KDE's definition of a public release is
when the tarballs are synced to official KDE mirrors. But we packagers get
access to the tarballs a few days earlier, and of course the releases are
tagged in SVN before the first tarballs are produced. Any respins happen in the
time period when the tarballs are available to us packagers, but not the
general public (in principle... of course with packagers working in public SCMs
like our CVS, source and binary packages tend to leak out early, but that's
another can of worms). So as far as KDE is concerned, the versions are
not "released publicly" when the changes happen, but as they _are_ released to
us (packagers), we have to be able to handle the possibility of a respin.
I still think it's slightly crazy. The respin must happen due to bug-reports,
so people will be reporting the same version but actually be talking about
different code. That's a bit off-topic though, so let's just agree to disagree
and leave it at that, shall we?
If you have a history looking like this:
A--B--C--D
\
E
You can't have such a history in a centralized SCM. You can have a branch off
C, but that means a different branch (= URL in SVN's case, where branches are
just directories) where C is branched (= copied in SVN) to. At a given SVN URL,
you only see A-B-C-D or A-B-C-E as the history. That's kinda the definition
of "centralized". Therefore, URL+revision uniquely identifies a SVN fileset.
But the URL is not immutable. You wouldn't believe the number of people that
have come to the git-list to complain about git-svn not properly importing
svn repositories simply because the layout has changed since the repository
was first started, or because it was moved one directory up, or some branch
was deleted after having been used to tag something from. SVN is fragile and
has no way of canonically naming a commit. URL+Rev doesn't cut it, since
URL can change (and so can rev, but only in insane cases).
True that. Current maths suggests that with the current commit-tempo to the
kernel (10487 commits between 2.6.25 and 2.6.26, most of them merges), we'll
run into the first SHA1 collision a mere 16 billion years after the
calculated end of the universe. I can see how that's a real problem....
All this is probabilistic, so nothing guarantees we won't run into a collision
today, as unlikely as it is. I consider this a major design flaw in the concept
of distributed SCMs.
The odds of accidentally hitting a collision is 1 to
1461501637330902918203684832716283019655932542976 with SHA1. Oh, and here's a
neat thing; If you actually find such a collision, nothing bad happens to the
data.
In short; There's a much higher chance that every piece of hardware containing
a full copy of the SVN repository stop working at the same time than there is
of accidentally stumbling upon a collision with SHA1. I'd go so far as to say
it's not even odd for an SVN repo to get completely wiped off the face of the
earth, since sloppy backup routines make it possible for it to happen in
something so mundane and simple as a building burning down.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
