Re: [Sbcl-devel] dealing with sbcl-0.7.0-unicode prerelease

[William H. N. <wil...@ai...>]

On Sun, Apr 21, 2002 at 02:01:34AM +1000, Brian Spilsbury wrote:
> William Harold Newman wrote:
> >You wrote elsewhere that you'd like to have the code in the SBCL CVS
> >codebase. That's entirely understandable after you had to drag the
> >patch through all the 0.pre7.* rearrangement (though hopefully that's
> >a one-time event, or at least a once-in-a-decade event, not a regular
> >event). Anyway, it seems to me that most of the benefit there would
> >follow from part 1, for more or less the loose-coupling reasons
> >discussed below.
> >
> What I'd really prefer is to have a side-branch in the SBCL CVS, which 
> can be used to bring this code into line with the main branch.

(You mentioned this "side branch" idea elsewhere, too.)

Do you just mean an ordinary CVS branch where changes from the main
branch are periodically merged? If so, it seems to me that this would
be very nearly equivalent to you maintaining your own CVS repository
for a +Unicode variant of SBCL, and periodically doing "cvs diff"
between versions of the main SBCL and applying the resulting patches
to your repository version. The main difference I can see would be
that when the repositories were the same, then the administrative
issues -- syncmail issues, commit permissions, and maybe other stuff
like URLs and the schedule for freezes and releases -- would tend to
interact more, while if the repositories were separate, the
administrative issues would tend to be independent.

If this is what you mean, my first impulse would be to keep the
+Unicode repository separate, instead of a branch in the main
repository, because the administrative interaction could easily be
more of a nuisance than a benefit.

-- 
William Harold Newman <wil...@ai...>
Users like this are like a mongoose backed into a corner: with its back to
the wall and seeing certain death staring it in the face, it attacks
frantically, because doing something has to be better than doing nothing.
This is not well adapted to the type of problems computers produce.
  -- <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C