Dump/Reload Fails to Delete on Move

[Greg Gibeling-2]

        Just to be clear, this is a new error, unrelated to old problems.
My overall goal with this complex procedure is to verify the backup system
for a 30GB repository with ~21000 revisions and some fairly critical code.

        Revision 6857 in my "public" repository consists of a directory
rename from "/GettingStarted" to "/GettingStarted-trunk".  Revision 6858
consists of an add of a new "/GettingStarted" directory.  Reloading rev 6858
causes an error as explained below.
        I can dump (svn 1.4.4, RHEL4) this repository and reload it (svnkit
1.3.0, Java 1.6, Win2K8) just fine, to create a copy of the repository named
"public-remote".
        I also maintain a backup (svnsync from svnkit over many revisions)
copy of the repository called "public-local", which I can dump (svnkit 1.3.0
clean dump just yesterday) and reload (svnkit 1.3.0) to create a repository
named "public-reload".  However reloading revision 6858 fails, as the move
in 6857 has instead been reloaded as a copy, leaving "/GettingStarted"
behind when it should have been deleted.

        I'll happily provide a zipfile to you privately with the following,
if you like.

        The db/revs files from the correct and broken repositories:
        "6857 (rev file from public-remote, correct)"
        "6857 (rev file from public-local, correct)"
        "6857 (rev file from public-reload, error)"

        A dump of just the revision in question, produced by my SVNKit
filter based tool and by the python script:
        "6857 (filter based).dump"
        "6857 (python script).dump"

        The tail end of the ANT log showing the load attempt which failed at
6858.  It's in a pretty verbose mode obviously.
        "log.txt"

        Given that the reload of the remote dump using SVNKit succeeds but
the reload of the local dump fails, I'm guessing that SVNKit is dumping the
files rather than failing to load them properly.
        Thanks for all your continuing help on this problem.

-Greg


---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Alexander Sinyushkin]

Hello Greg,

we seem to have found and fixed the bug.
I committed the fix in trunk in revision 5859.

Can you please try the latest SVNKit from trunk for dump-loading and
approve, that the problem does not reproduce again?
----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

Greg Gibeling wrote:

> Just to be clear, this is a new error, unrelated to old problems.
> My overall goal with this complex procedure is to verify the backup system
> for a 30GB repository with ~21000 revisions and some fairly critical code.
>
> Revision 6857 in my "public" repository consists of a directory
> rename from "/GettingStarted" to "/GettingStarted-trunk".  Revision 6858
> consists of an add of a new "/GettingStarted" directory.  Reloading rev 6858
> causes an error as explained below.
> I can dump (svn 1.4.4, RHEL4) this repository and reload it (svnkit
> 1.3.0, Java 1.6, Win2K8) just fine, to create a copy of the repository named
> "public-remote".
> I also maintain a backup (svnsync from svnkit over many revisions)
> copy of the repository called "public-local", which I can dump (svnkit 1.3.0
> clean dump just yesterday) and reload (svnkit 1.3.0) to create a repository
> named "public-reload".  However reloading revision 6858 fails, as the move
> in 6857 has instead been reloaded as a copy, leaving "/GettingStarted"
> behind when it should have been deleted.
>
> I'll happily provide a zipfile to you privately with the following,
> if you like.
>
> The db/revs files from the correct and broken repositories:
> "6857 (rev file from public-remote, correct)"
> "6857 (rev file from public-local, correct)"
> "6857 (rev file from public-reload, error)"
>
> A dump of just the revision in question, produced by my SVNKit
> filter based tool and by the python script:
> "6857 (filter based).dump"
> "6857 (python script).dump"
>
> The tail end of the ANT log showing the load attempt which failed at
> 6858.  It's in a pretty verbose mode obviously.
> "log.txt"
>
> Given that the reload of the remote dump using SVNKit succeeds but
> the reload of the local dump fails, I'm guessing that SVNKit is dumping the
> files rather than failing to load them properly.
> Thanks for all your continuing help on this problem.
>
> -Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svnkit-users-unsubscribe@...
> For additional commands, e-mail: svnkit-users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Greg Gibeling-2]

        I'll start the process now and get back to you probably in a few
days as I'll be away from computers for a bit.  Thanks as always for fixing
things so quickly.

-Greg

> -----Original Message-----
> From: Alexander Sinyushkin [mailto:Alexander.Sinyushkin@...]
> Sent: Friday, May 22, 2009 9:22 AM
> To: svnkit-users@...
> Subject: Re: Dump/Reload Fails to Delete on Move
>
> Hello Greg,
>
> we seem to have found and fixed the bug.
> I committed the fix in trunk in revision 5859.
>
> Can you please try the latest SVNKit from trunk for dump-loading and
> approve, that the problem does not reproduce again?
> ----
> Alexander Sinyushkin,
> TMate Software,
> http://svnkit.com/ - Java [Sub]Versioning Library!
>
> Greg Gibeling wrote:
> > Just to be clear, this is a new error, unrelated to old problems.
> > My overall goal with this complex procedure is to verify the backup
> system
> > for a 30GB repository with ~21000 revisions and some fairly critical
> code.
> >
> > Revision 6857 in my "public" repository consists of a directory
> > rename from "/GettingStarted" to "/GettingStarted-trunk".  Revision
> 6858
> > consists of an add of a new "/GettingStarted" directory.  Reloading
> rev 6858
> > causes an error as explained below.
> > I can dump (svn 1.4.4, RHEL4) this repository and reload it
> (svnkit
> > 1.3.0, Java 1.6, Win2K8) just fine, to create a copy of the
> repository named
> > "public-remote".
> > I also maintain a backup (svnsync from svnkit over many
> revisions)
> > copy of the repository called "public-local", which I can dump
> (svnkit 1.3.0
> > clean dump just yesterday) and reload (svnkit 1.3.0) to create a
> repository
> > named "public-reload".  However reloading revision 6858 fails, as the
> move
> > in 6857 has instead been reloaded as a copy, leaving
> "/GettingStarted"
> > behind when it should have been deleted.
> >
> > I'll happily provide a zipfile to you privately with the
> following,
> > if you like.
> >
> > The db/revs files from the correct and broken repositories:
> > "6857 (rev file from public-remote, correct)"
> > "6857 (rev file from public-local, correct)"
> > "6857 (rev file from public-reload, error)"
> >
> > A dump of just the revision in question, produced by my SVNKit
> > filter based tool and by the python script:
> > "6857 (filter based).dump"
> > "6857 (python script).dump"
> >
> > The tail end of the ANT log showing the load attempt which failed
> at
> > 6858.  It's in a pretty verbose mode obviously.
> > "log.txt"
> >
> > Given that the reload of the remote dump using SVNKit succeeds
> but
> > the reload of the local dump fails, I'm guessing that SVNKit is
> dumping the
> > files rather than failing to load them properly.
> > Thanks for all your continuing help on this problem.
> >
> > -Greg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: svnkit-users-unsubscribe@...
> > For additional commands, e-mail: svnkit-users-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svnkit-users-unsubscribe@...
> For additional commands, e-mail: svnkit-users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Greg Gibeling-2]

        You'll be happy to hear that the fix did indeed solve my problem.
Thank you very much, that would have been a real pain for me to fix on my
own.  Hopefully you won't hear from me again for quite some time....

-Greg

> -----Original Message-----
> From: Alexander Sinyushkin [mailto:Alexander.Sinyushkin@...]
> Sent: Friday, May 22, 2009 9:22 AM
> To: svnkit-users@...
> Subject: Re: Dump/Reload Fails to Delete on Move
>
> Hello Greg,
>
> we seem to have found and fixed the bug.
> I committed the fix in trunk in revision 5859.
>
> Can you please try the latest SVNKit from trunk for dump-loading and
> approve, that the problem does not reproduce again?
> ----
> Alexander Sinyushkin,
> TMate Software,
> http://svnkit.com/ - Java [Sub]Versioning Library!
>
> Greg Gibeling wrote:
> > Just to be clear, this is a new error, unrelated to old problems.
> > My overall goal with this complex procedure is to verify the backup
> system
> > for a 30GB repository with ~21000 revisions and some fairly critical
> code.
> >
> > Revision 6857 in my "public" repository consists of a directory
> > rename from "/GettingStarted" to "/GettingStarted-trunk".  Revision
> 6858
> > consists of an add of a new "/GettingStarted" directory.  Reloading
> rev 6858
> > causes an error as explained below.
> > I can dump (svn 1.4.4, RHEL4) this repository and reload it
> (svnkit
> > 1.3.0, Java 1.6, Win2K8) just fine, to create a copy of the
> repository named
> > "public-remote".
> > I also maintain a backup (svnsync from svnkit over many
> revisions)
> > copy of the repository called "public-local", which I can dump
> (svnkit 1.3.0
> > clean dump just yesterday) and reload (svnkit 1.3.0) to create a
> repository
> > named "public-reload".  However reloading revision 6858 fails, as the
> move
> > in 6857 has instead been reloaded as a copy, leaving
> "/GettingStarted"
> > behind when it should have been deleted.
> >
> > I'll happily provide a zipfile to you privately with the
> following,
> > if you like.
> >
> > The db/revs files from the correct and broken repositories:
> > "6857 (rev file from public-remote, correct)"
> > "6857 (rev file from public-local, correct)"
> > "6857 (rev file from public-reload, error)"
> >
> > A dump of just the revision in question, produced by my SVNKit
> > filter based tool and by the python script:
> > "6857 (filter based).dump"
> > "6857 (python script).dump"
> >
> > The tail end of the ANT log showing the load attempt which failed
> at
> > 6858.  It's in a pretty verbose mode obviously.
> > "log.txt"
> >
> > Given that the reload of the remote dump using SVNKit succeeds
> but
> > the reload of the local dump fails, I'm guessing that SVNKit is
> dumping the
> > files rather than failing to load them properly.
> > Thanks for all your continuing help on this problem.
> >
> > -Greg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: svnkit-users-unsubscribe@...
> > For additional commands, e-mail: svnkit-users-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svnkit-users-unsubscribe@...
> For additional commands, e-mail: svnkit-users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...