Hi Karl,
today I had the time to reproduce the thing. Here's the - shortened -
output:
C:\>svn ci d:\tmp\internet.test -m "did one change on 2104 files for test" > d:\
tmp\test3.log
Sending D:\Tmp\Internet.Test\ridinger\agb.htm
.
[snipped 2102 further files, to the total of 2104 files]
.
Sending D:\Tmp\Internet.Test\ridinger\wintter\index.htm
Transmitting file data ........................................................................................
[following further dots, to the total of 2104]
svn: RA layer request failed
svn: Commit failed (details follow):
svn: MERGE request failed on '/svn/testrepos/trunk/internet/ridinger'
svn: MERGE of '/svn/testrepos/trunk/internet/ridinger': timed out waiting for se
rver (http://inspiron)
C:\>
If I now try to commit again I am told my working is out of date and
needs to be updated before:
C:\>svn ci d:\tmp\internet.test -m "test for committing again"
Sending D:\Tmp\Internet.Test\ridinger\agb.htm
svn: Merge conflict during commit
svn: Commit failed (details follow):
svn: Your file or directory 'agb.htm' is probably out-of-date.
svn:
The version resource does not correspond to the resource within the transaction.
Either the requested version resource is out of date (needs to be updated), or
the requested version resource is newer than the transaction root (restart the
commit).
If I do so all 2104 files I just committed from d:\tmp\internet.test are
copied back to d:\tmp\internet.test and flagged as "merged".
In case the commit included not just changes of files already
existing in the repository, but files scheduled for adding or deletion,
this update fails for either the added file already exists in the
working copy or the deleted file no longer exists in the working
working copy. The only workaround is to remove those added files
in the working copy and restore the deleted ones from a thirdparty
backup or to delete the whole folder or even the whole working
copy and checkout a new working copy.
The repository shows no pending transaction and is fully
accessible. A cleanup on the working copy makes no difference.
To my understanding the commit is complete and successful as far
as the repository/Berkeley are concerned (I interpret "Sending ..."
as computing and writing down the diffs in a "todo list", and the
dots after "Transmitting data" as the actual sending/writing to the
database, one dot for each file).
But then the timeout causes the administrative files within the
working copy not to be updated accordingly. So the working copy
still thinks it is in the state *before* the commit and thus tries to
commit the files again / during the forced update merges files that
in fact are identical and considers those added or deleted files as
still scheduled for addition/deletion.
I keep the complete output just in case 2102 more Sending lines
let the crystal ball shine brighter ;-) but for posting it on the list it is
a little tooooo large. And the essentials are in the listing above.
And while here it is caused by lack of memory a/o slow processor
(144MB/P200) there can be many other reasons for a final timeout
(slow network, server overload). BTW I had to run Homesite and
Total Commander in the background to get the timeout, without
these further apps the timeout did not "work" ...
Thanks for looking through this stuff.
Jan Hendrik
(since this thread is a little aged by now I quote the full message
below)
Concerning Re: server timeout
kfogel@collab.net wrote on 20 Oct 2003, 8:59, at least in part:
> "Jan Hendrik" <jan.hendrik@bigfoot.com> writes:
> > In a sort of local scalability test (wanted to know with what number
> > of files in a single commit this would fail or corrupt the repos;
> > with 2100 in a 128MB environment it does not) I got an SVN server
> > timeout.
> >
> > This was after all postfix messages and obviously while the
> > administrative files in the working copy were - or should have been
> > - updated.
> >
> > So with the next attempt to commit thereafter SVN told me to
> > update first for the files in the working copy were out of date
> > though there had not been any changes, this second commit was just
> > to see how things were after the SVN timeout. This update copied all
> > files just committed back to the working copy and reported them as
> > merged.
>
> I *think* I follow you here... But an exact transcript (or even one
> from memory) would be very helpful.
>
> > This looked like a nuisance only till SVN came upon files added or
> > deleted with the previous timed out commit. It would not update the
> > "added" files nor would it delete or restore the "deleted" files. I
> > had to delete the respective folders to finally get around this.
> > Cleanup on the working copy had no effect.
> >
> > I know there is a setting for SVN to timeout. But this can be
> > approximate at best. One never knows what happens - a slow or
> > very busy machine, too many files in one commit, broken network
> > connection. So I would think that cleanup should handle this, too.
>
> Jan, can you file an issue for this? I think there's a way we can
> write a reproduction script, by using a pre-commit hook that just
> blocks for N minutes, where N > client-timeout-threshold. I'm not
> sure we absolutely need a repro script, if we have a transcript and a
> description, even...
>
> Thanks,
> -Karl
---------------------------------------
Freedom quote:
We've gone astray from first principles.
We've lost sight of the rule
that individual freedom and ingenuity
are at the very core of everything
that we've accomplished.
Government's first duty is to protect the people,
not run their lives.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 27 11:37:27 2003