Should subversion's error log be chronological?
[26/Feb/2007:17:59:21 +0100] commit r58157
[26/Feb/2007:17:59:43 +0100] update '/trunk'
[26/Feb/2007:17:59:52 +0100] commit r58159
[26/Feb/2007:18:00:30 +0100] checkout-or-export '/trunk'
[26/Feb/2007:18:04:14 +0100] update '/trunk'
[26/Feb/2007:17:59:24 +0100] commit r58158
[26/Feb/2007:18:05:04 +0100] commit r58160
why does that commit of r58158 appear nearly five minutes later than
expacted?
cu
christian unger
On 27.02.2007, at 10:14, christian unger wrote:
>
>
> the svn server is an apache 2.2.3 running on an
> XServe G5/10.4.8/8L127 with the follwoing components installed via
> macports:
>
> apache2 @2.2.3_2+openldap+workermpm (active)
> apr @1.2.8_0 (active)
> apr-util @1.2.8_1+openldap (active)
> bash-completion @20060301_0 (active)
> buildbot @0.7.4_0 (active)
> clearsilver @0.10.3_1 (active)
> coreutils @5.97_0 (active)
> cyrus-sasl2 @2.1.21_0 (active)
> DarwinPortsStartup @1.1_0 (active)
> db4 @4.3.29_0+darwin_8 (active)
> db44 @4.4.20_0+darwin_8 (active)
> expat @2.0.0_1 (active)
> freetype @2.1.10_1 (active)
> gd2 @2.0.33_2 (active)
> gettext @0.16.1_0 (active)
> ghostscript @8.54_0 (active)
> htmldoc @1.8.24_0 (active)
> jpeg @6b_1 (active)
> libiconv @1.11_4+darwin_8 (active)
> libpng @1.2.10_2+darwin_8 (active)
> mod_fcgid @2.0_0 (active)
> neon @0.26.3_0 (active)
> openldap @2.2.28_0 (active)
> openssl @0.9.8d_0+darwin_8 (active)
> pcre @7.0_0 (active)
> perl5.8 @5.8.8_0+darwin_8 (active)
> py-bsddb @2.4.3_1 (active)
> py-ldap @2.0.8_1 (active)
> py-setuptools @0.6c3_0 (active)
> py-sqlite @2.3.3_0 (active)
> py-twisted @2.4.0_0 (active)
> py-zopeinterface @3.1.0c1_0 (active)
> python24 @2.4.3_1+darwin_8 (active)
> readline @5.1.004_0 (active)
> sqlite3 @3.3.7_0+darwin_8 (active)
> subversion @1.4.3_0+mod_dav_svn+tools (active)
> subversion-pythonbindings @1.4.3_0 (active)
> trac @0.10.3_0 (active)
> zlib @1.2.3_0 (active)
>
>
> svn client in use: 1.4.2
> error which has been encountered: 'svn: Decompression of svndiff
> data failed'
> The error renders the revision useless, making it impossible to
> check out or run svnsync on the repository any longer, because
> svnsync encounters the same error at this specific revision (r58158).
> The engineer who committed the revision killed an svn commit from
> within Xcode 2.4.1 and recommitted with svnX after doing an svn
> cleanup.
> The workaround was to delete the file on the server in a later
> revision and check in a new version of the same file.
>
>
> Now what could corrupt a file during a commit such that it is
> impossible to check out the directory the file lives in?
> and how do I get rid of that revision?
>
>
>
>
> cu
> christian unger
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Received on Tue Feb 27 13:23:56 2007