aboutsummaryrefslogtreecommitdiff
path: root/devel/Makefile
diff options
context:
space:
mode:
authorSean Chittenden <seanc@FreeBSD.org>2003-08-17 22:01:07 +0000
committerSean Chittenden <seanc@FreeBSD.org>2003-08-17 22:01:07 +0000
commit0d3e362811c30c359091847e87a39f74a8812588 (patch)
treec8548cf578b8c91e6c3274c91ce00e0b7c28c6ca /devel/Makefile
parentd100383ce723d0fa91b8777fe02651e97bc75120 (diff)
downloadports-0d3e362811c30c359091847e87a39f74a8812588.tar.gz
ports-0d3e362811c30c359091847e87a39f74a8812588.zip
Add tla, an arch CLI written in C.
Arch is a really nifty revision control system. It's "whole-tree changeset based" which means, roughly, that it can handle (with atomic commits) file and directory adds, deletes, and renames cleanly, and that it does branching simply and easily. Arch is also "distributed" which means, for example that you can make arch branches of your own from remote projects, even if you don't have write access to the revision control archives for those projects. This looks to be as close to an open source p4 replacement as one could hope without being p4. I'll go so far as to suggest that if this SCM was employed by the BSD crowd, merging changes between dragonfly (post source repo reorog), NetBSD, and OpenBSD would be radically less painful. It is very possible that the dragonfly fork may not have happened under the arch SCM development methodology, but if it did, at the very least it would be possible to incorporate dillion's reorg work in a single patch set, no cvs admin repo surgery needed. WWW: http://arch.fifthvision.net/bin/view
Notes
Notes: svn path=/head/; revision=87145
Diffstat (limited to 'devel/Makefile')
-rw-r--r--devel/Makefile1
1 files changed, 1 insertions, 0 deletions
diff --git a/devel/Makefile b/devel/Makefile
index 50d6501bde4a..8bb8fbcb5722 100644
--- a/devel/Makefile
+++ b/devel/Makefile
@@ -1000,6 +1000,7 @@
SUBDIR += tkcvs
SUBDIR += tkp4
SUBDIR += tkref
+ SUBDIR += tla
SUBDIR += tmake
SUBDIR += tnt
SUBDIR += towitoko