Conclusion

It appears that any end-user changes are likely to be rejected. It also appears that any changes to bsd.*.mk are likely to be rejected. My best bet is to add a script to Tools/ - this is something that maintainers already do on their own...

Proposal

I'd like to see the ports system let you use svn (or other SCMs) fetch the code instead of using a tarball

Solved Concerns

Subversion does not have to be part of the base system for my patch to work

I could easily code a svn-to-tarball script and the maintainers would upload the code to freefall

It is possible to track port updates which this method. The only change occurs in the /fetch/ stage so versioning works.

Distfiles can be (by default?) saved into the normal distfile directory and be updated with a fresh export or update.

SVN checkout would not be signed; only the tarball would be checked.

Unsolved Concerns

Many users may want the program they are installing but not svn

What about SCM's other than svn?

(possibly add something like SCM=svn and add some checks for how to properly checkout code from other SCMs)

A update to this feature might be dynamic plist generation - this an unsolved problem unless the maintainer does this...

(the freeBSD handbook has this - possibly add this to bsd.maintainer.mk...)

Please verify: Some existing tools like patchtool also needs to be modified which rely for the presence of 'distinfo' file in the port directory, which in this case will never be present.I'm not sure if this is still true.

svn checkout vs svn export: speed of checkout vs speed of update

Things the system should do (AKA a spec)

Provide a target for any user to checkout from a specific revision

(be careful that svn is build with proper support for http:// or svn://

a) Tar the checkout and perform the checksum on the tarball (Build tar without timestamps because otherwise checksums will fail)

b) Do a checksum on the checkout itself and only make the tarball when BOOTSTRAP is defined

(Doesn't svn have a key that it asks you to trust -> maybe check against that)

Either way provide a fallback for users who can't or don't want svn

(does svn use $? to tell us when it failed)

Possibilities

Use SVN to fetch for the user directly (my preferred option)

Use SVN to let maintainers upload source as a tarball (bootstrapping like comms/wspr)

Write a script to do bootstrapping (instead of making it part of bsd.ports.mk

Running "make fetch" would perform an svn export/checkout, and would generate a tarball from this in ${DISTDIR} named as ${PORTNAME}-${PORTVERSION}.t[gb]z.