While in the freeze (my grubby little hands are now really off of the CVS,
honest!) I figured it might be a good moment to fly this by the list:
diff --git a/src/code/misc.lisp b/src/code/misc.lisp
index 8a32863..d4a7236 100644
@@ -16,4 +16,8 @@
(defun sb!xc:lisp-implementation-version ()
- #.(sb-cold:read-from-file "version.lisp-expr"))
+ #.(format nil "~A~@[.~A~]"
+ (sb-cold:read-from-file "version.lisp-expr")
+ (let ((pathname "branch-version.lisp-expr"))
+ (when (probe-file pathname)
+ (sb-cold:read-from-file pathname)))))
The idea is to keep only the mainline version information in version.lisp-expr,
and any foobranch.42.flaky.3 stuff in branch-version.lisp-expr.
With the current setup any branch that names itself in version.lisp-expr is
always going to conflict with with mainline.
This means that one cannot 1. make a patch representing the branch 2. merge
it to a new HEAD to create an updated version of the branch without manually
resolving the spurious version.lisp-expr conflict which will always be there
if the branch announces itself in there.
With CVS this doesn't have a huge payoff, but even there it removes some some
manual fiddling. With eg. Git the payoff is much greater. Imagine this
A -> B -> C(HEAD)
\-> A1 -> A2 -> A3(branch)
git-rebase is can automatically able to update the branch:
A -> B -> C(HEAD)
\-> C1 -> C2 -> C3(rebased branch)
assuming that there are no conflicts. This is really really nice for long-lived
branches, or reinvigorating stale ones. Of course manually resolving the
version.lisp-expr conflict is work of a moment, it's still work that doesn't
really need to be done. By using branch-version.lisp-expr (which would not
exist at all in the mainline) this can be automatic.
Any objections to applying the above patch to CVS during the 1.0.8 series?