Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

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

So I guess it's an arguable call if this is a feature.  But it's not a
big deal.

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

That sounds fine then.

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

You are saying "the development tree", which I don't follow.  Surely
when releasing 2.6 of lwp then the lwp repo gets a tag, since it is
primarily an independent project.

So it might be that coda.git is the independent version, and there's a
coda-meta.git that pulls all of them in as submodules.  That seems much
cleaner.

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

Sure, I realize that the independence is somewhat illusory.  But that
illusion doesn't cause packaging problems so it doesn't bother me.

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

CVS is just messy, especially long-ago usage.

> 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 wonder if there is an easy way to merge the two histories, basically
converting until a date and then exporting all the commits from the git
repo and then replaying them.  That might not be that hard.