Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> Yes, I'll make some archives of the Coda, LWP, RPC2 and RVM
> repositories. An interesting bit is that LWP, RPC and RVM originally
> were part of the Coda tree, but at some point got split off into their
> own repositories, I believe by copying the underlying RCS from one CVS
> repo to the new ones.

> Currently we use git-submodule to pull them back into the main source
> tree at build time. Ideally I would want them merged back into the main
> Coda repo, especially because quite often a change in LWP propagated
> all the way back up to Coda. I have some ideas on how to do this that I
> may play around with. If the library RCS files actually do contain the
> full history one approach would be to copy the ,v files back into the
> Coda CVS tree and see what fast-export/reposurgeon come up with as a
> reasonable history.

So I see this as a great divide, and ask that you think about the impact
on packaging systems, partly because I maintain package of coda in
pkgsrc, but also because I believe that almost all users of successful
software use it from a packaging system.  This is different from
developers of software, who rarely run it from a packaging system.  So
while it's important that a developer build/install be easy, it's also
important for it to be easy and straightforward to package.   So I see
two sane paths:

  Keep lwp, rpc2, rvm as separate packages, with separate repos,
  separate version numbers, and separate numbered releases with their
  own tarballs.  Expect packaging systems to keep them separate.  Allow
  coda to depend on them, meaning that to build and install coda you
  must have already built and instaled those three.   Pay attention to
  ABI compatibility in each.

  Roll them back into coda, and discontinue their existence as separate
  projects. They become integrated into the coda build, and there are no
  separate OS-level packages, no separate repo, no possibility to use
  them without coda.

Note that the above discussion does nto talk about git submodules.   I
see submodules as a way to manage repo pieces when things are sort of
independent but not really, or the repo has gotten unreasonably huge.
Users don't use git (or shouldn't) - they use release tarballs, which
have the autoconf-generated files.*    It's easy enough to run a script
that does build/install of the other three - I've been doing it since
the late 90s.   Doing submodule games only addresses the developer
build, and not the release builds, and I think that's a mistake - the
point of the project should be to produce tarballs for packaging for use
by users, and developer convenience is a means to that end.

* This is, last I checked, an issue with github, which does not have a
  way to host release tarballs.  They have a git-centric mindset which
  is that release tarballs should consist of what's in git - which the
  rest of the world thinks is broken in that generated files should not
  be checked in.

> I am pretty sure that at points in the history renames were done by
> directly moving the ,v files around, to preserve edit history for that
> particular file. But it does mean that it is quite unlikely that an old
> revision can be checked out and built.

So I guess if the git export of CVS is just as useful as CVS, that's
good enough, because the CVS repo is sort of broken from the ,v file
moves (generally, the way to do that is to copy the ,v file and then cvs
rm the old place).

> I will probably start a coda-repo-conversion repository to track scripts
> and configuration settings needed to reproducably perform the conversion.

Sounds good.

Also, if the conversion isn't quite perfect, but is reasonable for
relatively recent history (15 years :-) ?), then especially if a tarball
of the final CVS state is available in the long term, we probably have
achieved as much value as is useful.