(Illustration by Gaich Muramatsu)
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. JanReceived on 2014-07-14 12:50:17