On Tue, 17 Sep 2019, Richard Earnshaw (lists) wrote:
> Doing this over the new year holiday period has both advantages and
> disadvantages. On the one hand the traffic is light, so the impact to most
> developers will be quite low; on the other, it is a holiday period, so getting
> the right key folk to help might be difficult. I won't object strongly if
> others feel that slipping a few days (but not weeks) would make things
> significantly easier.
I think slipping it one week is better so more people are around to check
things at the transition time.
I'd also like to add: for any approach using a fresh, clean conversion, we
should ensure the existing commit ids and git-only branches remain
available somewhere. There are two possible approaches:
1. Keep the existing git-svn repository available, read-only, in some
(renamed) public location.
2. Put the objects and (renamed) refs into the new repository alongside
the cleanly converted history. Because most blob and tree objects should
be identical between the conversions (with it mainly being commit and tag
objects that aren't shared between the versions of the history), that
shouldn't enlarge the repository that much. I've previously suggsted a
git command (untested) along the following lines (plus repacking the
repository afterwards) to do this:
git fetch git://gcc.gnu.org/git/gcc.git \
'refs/heads/*:refs/heads/git-old/*' \
'refs/remotes/*:refs/heads/git-svn-old/*' \
'regs/tags/*:refs/tags/git-old/*'
(It is of course possible to do (1) and then decide at a later point to do
(2) as well.)
--
Joseph S. Myers
jos...@codesourcery.com
