Regarding r71352 and SubGit

[Colin Finck]

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

[Aleksey Bragin]

That's the best way to fix the issue, IMO.

Regards,
Aleksey Bragin

On 18.05.2016 19:51, Colin Finck wrote:
>   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.

[Pierre Schweitzer]

Complementary to the work already done by Colin, Fisheye backups have
been restored so that SVN cache is consistent with Colin's rollback.
Same goes to git. Todays commits will be replayed on next commit for
Git. Fisheye is already up to date.

Never ever this thing on our infra. Be glad we have backups.

Le 18/05/2016 18:51, Colin Finck a écrit :
>   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
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   

-- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.