Toshio Kuratomi <a.badger <at> gmail.com> writes:
> This specific implementation would be a bad thing. Instead of having a
> nice, SCM abstract method of communicating to koji what to build from
> (the tag) you'd be resorting to CVS specific knowledge.
That whole trick is only needed with CVS. In all the newer SCMs (SVN and all
the distributed stuff), you have a revision ID (a monotonically increasing
number in the case of SVN, a checksum in the distributed systems) which you can
trivially refer to. Only CVS needs a revision number per file, and that's
exactly what the Entries file contains. All the envisioned replacement SCMs
will only need a number (be it an incremental ID or a checksum), so it will be
trivial to add support for those.
In the case of SVN, you could also upload .svn/entries, which is the equivalent
file, however only the first few lines (which contain the revision number and
the directory's URL) are needed to recreate the revision.
Another trivial SVN-based implementation would be to run "svn info >Entries"
(which is a local operation and thus very fast). But only the revision ID is
really needed, the URL is trivial to figure out and the rest of the svn info
output is not needed to recreate the revision.
I'm sure the situation is similar for the distributed systems and their
checksum-based IDs.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
