On Mon, Jul 14, 2014 at 10:28:48AM -0400, Greg Troxel wrote:
> 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

I did and I believe it isn't, or doesn't have to be, as great a divide
as one might think and an observation you make later on plays into that

> * 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.

And I agree with this completely so we have 2 different workflows.

- One is a developer who currently clones coda.git, then uses
  git-submodule to clone lwp, rpc2 and rvm, and finally bootstraps it
  all to create the generated files. Then all development is done within
  a nice unified source tree and development binaries link correctly
  with the development libraries etc.

  (Until you want to push changes back, because now you have to make
  sure to push lwp/rpc2/rvm updates first to their respective repos and
  then create a commit in the coda repo to pin the new library version
  and then push coda. Or when you want simply pull updates, and you need
  to not forget to update submodules. And yes this will go wrong, where
  my tree builds at work but I forgot to push an lwp change and it fails
  to build on my laptop. Throw in working with branches that cover
  changes across these 4 repositories and switching between them...)

- The second workflow is the release build/packaging, where we tag the
  source repositores and use make dist for lwp/rpc2/rvm/coda to create
  tarballs which are then built/packaged on the various platforms.

Nothing in that second workflow is supposed to change when the libraries
are pulled back into the Coda development source tree. In fact ideally
in the history it make the removal of /rvm-src look like a move to
/lib-src/rvm and addition of the configure/automake setup. I still
intend to have separate configure scripts and distribution tarballs.

The only question is what to do for tagging in the development tree. I
assume we just tag the whole tree when a new distribution tarball is
created so the git checkout of the source tree will match lwp-2.6 in the
lib-src/lwp subtree but isn't guaranteed to match anything sane in the
rest of the tree (except that you can assume that a developer most
likely has compiled them at the same time.

I haven't committed to this yet, but I am strongly leaning to this.
Looking back the libraries have not been quite as independent from Coda
releases as originally intended. Partly because there are no other users
their releases are mainly triggerend by the fact that a new Coda release
needs some API change in one of the libraries, but there was no need to
push a new version until there was an actual user of the feature.

> > 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).

Right, I also notices a few branches where only a subset of the tree was
tagged for instance only 'coda-src/venus/*.cc'. The cvs-fast-export
convertor then creates a branch that removes all other files from the
source tree. I'm sure there is a way to correct this, but it may just be
more work than is useful.

Other artifacts, CVS possibly didn't use to recurse, so there are
commits that go from directory to directory all with slightly different
log messages. File creates are often separate commit events with an
empty log message. And then syncs between branches often more resemble
cherry-picks instead merges, only when all commits are consistently
picked can it be represented as a merge.

ALso, the current git repositories actually have a much better history
because they track author information and actual commit times, the
recent CVS history only track the time when the git development tree
got synced back with CVS.

> > 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.

Yeah, we can quite reliably go back to November 1996/Coda-4.0, anything
before that seems to be mostly non-CVS history i.e. developers probably
had their own development trees some of which may have been RCS managed
and some of these have been used to populate the initial CVS archive.

Jan