Toshio Kuratomi wrote:
Andreas Ericsson wrote:
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).
That's a misunderstanding of SVN.
The URL at a revision cannot change
Yes it can. Let's just say someone decided to move his project off of
sourceforge and onto some dedicated hosting. The url has changed.
without filtering the repository
(which you could do with any SCM if you understand the internal
repository format).
But with a DVCS you would then *know* that the repository has been
filtered (ie, tampered with), because the commit id would no longer
be the same, or perhaps not even exist in the upstream repository.
If you filter an SVN repository and ask for revision 10, you'll get
different stuff before and after the filtering, and there's no way
you can know that.
You're seeing URLs change between revisions. IE: revision 10 has
file:///trunk/foo/README.txt revision 11 has file:///foo/trunk/README.txt
I don't understand this example or what it's supposed to prove at all.
My conclusions on this topic is that when the upstream project is
managed by <insert-random-dscm-here>, you'd be better off building
from a local clone of upstreams dscm repository directly. If it's
managed in CVS or SVN or any other scm that cannot be cloned with
100% accuracy (including ancestry), you'd be better off using
tarballs and patches.
--
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
