Hello all,
As most of you know, I have been busy setting up a two-way Git mirror of
our ReactOS repository using SubGit.
Testing was done in the recent weeks by multiple people using a sandbox
repository and the results looked pretty well. Therefore, SubGit was
considered ready for prime time and I started a first import of our
ReactOS repository.
The only problem with this: Even without mirroring branches, the Git
repository became a 5.5GB monster (from the 750MB of our current git-svn
mirror). This size was totally not clonable as shown in testing.
The proposed solution: Git offers a garbage cleaner using "git gc
--aggressive". And hell yeah, it reduced the size to a nice 500MB repo.
While that optimization was running and SubGit was not syncing, two
revisions were committed: r71350 and r71351.
Without expecting any problems, I resumed SubGit mirroring and then
things started to get weird: Apparently, SubGit totally lost traction of
the SVN repository and instead of syncing the two new revisions, it
committed one in r71352 that _replaces_ trunk by r71349.
This is one of the worst commits possible, as it forces SVN clients to
redownload everything when updating their working copies.
Even more, it shows me that a clear separation of permissions for the
SVN Server and SubGit isn't sufficient. SubGit can and actually did harm
to our repository this way. This is exactly what I was warned of and
what now happened...
I'm sure everybody can understand that I cannot continue with the SubGit
installation under these circumstances. We cannot put our repository at
risk, especially now that we're in the mid of GSoC.
This way, SubGit has definitely shown that it's not ready for our
repository.
I deeply apologize for this trouble and especially to the critics who
remained right. And of course to Hermes, whose name SubGit abused for
making the guilty commit.
Right now, I'm restoring the repository to r71351 using backups and
"svnadmin dump". This effectively erases r71352 from SVN history.
As r71352 was only online for 10 minutes, I believe it's better to get
rid of that commit in SVN history rather than having everyone suffer
from it.
Again, I deeply apologize!
With best regards,
Colin