Checksum mismatch errors on newly added files

[Jeremy Aston]

Hi,

I know this topic has been mentioned several times over the years on the list but it does not appear that the problem has been fully solved.

I regularly have problems committing files (typically binary files of 2 or more MB) to my repository as I keep getting errors such as the following:

Commit failed (details follow):

Checksum mishmatch, file: 'some file':

expected: e42d35e8e05762e7585aff281d2e8c1f

Actual: b57111e7f6c531daf0868f30d202f00e

These errors sometimes occur on files that have been in the repository for a while but I notice them alot with files that have not even been committed yet.

I have seen the various solutions such as hacking the svn local files and copying the file to a temp file, rechecking out the original and over writing the repo copy with the local temp file but that cannot work with a file that has not even be committed as yet.

These are workarounds, not solutions and I am seeing this all the time and is rendering svn a massive pain to use.  I've upgraded to the latest version and am still seeing the problem.  

Does anyone have a proper solution or reason why this happening?

Best regards

jez

[Jeremy Aston]

> Hi,
>
> I know this topic has been mentioned several times over the years on  
> the list but it does not appear that the problem has been fully  
> solved.
>
> I regularly have problems committing files (typically binary files  
> of 2 or more MB) to my repository as I keep getting errors such as  
> the following:
>
> Commit failed (details follow):
> Checksum mishmatch, file: 'some file':
> expected: e42d35e8e05762e7585aff281d2e8c1f
> Actual: b57111e7f6c531daf0868f30d202f00e
>
> These errors sometimes occur on files that have been in the  
> repository for a while but I notice them alot with files that have  
> not even been committed yet.
>
> I have seen the various solutions such as hacking the svn local  
> files and copying the file to a temp file, rechecking out the  
> original and over writing the repo copy with the local temp file but  
> that cannot work with a file that has not even be committed as yet.
>
> These are workarounds, not solutions and I am seeing this all the  
> time and is rendering svn a massive pain to use.  I've upgraded to  
> the latest version and am still seeing the problem.
>
> Does anyone have a proper solution or reason why this happening?
>
> Best regards
>
> jez
>

Just wondering if anyone has any comments on this?  I am getting  
increasingly frustrated with this as I work with alot of binary files  
(CAD drawings etc.) and am hitting it all the time.  Doing these work  
arounds is simply not a long term option for productivity.

Would a move from FSFS to Berkeley make any difference?

Rgds

Jeremy

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413467

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Konstantin Kolinko]

2009/11/1 Jeremy Aston <jeremy.aston@...>:

>> Hi,
>>
>> I know this topic has been mentioned several times over the years on
>> the list but it does not appear that the problem has been fully
>> solved.
>>
>> I regularly have problems committing files (typically binary files
>> of 2 or more MB) to my repository as I keep getting errors such as
>> the following:
>>
>> Commit failed (details follow):
>> Checksum mishmatch, file: 'some file':
>> expected: e42d35e8e05762e7585aff281d2e8c1f
>> Actual: b57111e7f6c531daf0868f30d202f00e
>>
>> These errors sometimes occur on files that have been in the
>> repository for a while but I notice them alot with files that have
>> not even been committed yet.
>>
>> I have seen the various solutions such as hacking the svn local
>> files and copying the file to a temp file, rechecking out the
>> original and over writing the repo copy with the local temp file but
>> that cannot work with a file that has not even be committed as yet.
>>
>> These are workarounds, not solutions and I am seeing this all the
>> time and is rendering svn a massive pain to use.  I've upgraded to
>> the latest version and am still seeing the problem.
>>
>> Does anyone have a proper solution or reason why this happening?
>>
>> Best regards
>>
>> jez
>>
>
> Just wondering if anyone has any comments on this?  I am getting
> increasingly frustrated with this as I work with alot of binary files
> (CAD drawings etc.) and am hitting it all the time.  Doing these work
> arounds is simply not a long term option for productivity.
>
> Would a move from FSFS to Berkeley make any difference?
>

> Would a move from FSFS to Berkeley make any difference?

I'm sure it won't.

>> Checksum mishmatch, file: 'some file':
>> expected: e42d35e8e05762e7585aff281d2e8c1f
>> Actual: b57111e7f6c531daf0868f30d202f00e

Just wondering:
If you know, what the file it was,
if you independently calculate md5sum for that 'some file', what will
be the value?

Do you have:
a) on the server: pre-commit hooks, that try modify the file before the commit?
b) proxies
c) on you local PC: something, that modifies the *.svn-base files?

Is the error reproducible?

Best regards,
Konstantin Kolinko

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413483

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Jake Stone]

Hello all,

I am working on a few small Java projects, and we are trying to switch
to test-driven development in the near future. We have a relatively
standard branches/dist/tags/trunk layout, inside of trunk is just the
java package folders ("com/website/project..."). I was wondering how
project managers tend to handle the organization of unit testing code.

A few ideas occurred to us:
1) Just have a "test" folder in each project, which replicates the
project directory (ugly). Store any unit tests for the project there,
and simply exclude that folder when creating a JAR or other distribution.

This one is easy to work with, but a little ugly when working with the
unit tests.

2) Change the repository to have "src" and "tests" folder, organized
with the same java packaging layout. Each category goes in it's own
folder; to run tests, you checkout your projects "src" and "tests."

I'd think this makes it too complicated to run tests on a project, and
therefore they wouldn't get run often enough.


I also someday want to set up a Hudson continuous integration server
("https://hudson.dev.java.net/"), so I'd want to keep that in mind as well.
A few Google searches haven't turned up anything interesting, what are
your thoughts?

Thanks for your help!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413557

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stephen Connolly-2]

Have a look at Maven and the standard directory layout.  (I'm not
suggesting that you change your build process to Maven (although IMHO
that could well be a good thing) but the standard directory layout is
what most projects are moving towards whether they build with Maven or
with something else.

2009/11/2 Jake Stone <jake.the.stone@...>:

> Hello all,
>
> I am working on a few small Java projects, and we are trying to switch
> to test-driven development in the near future. We have a relatively
> standard branches/dist/tags/trunk layout, inside of trunk is just the
> java package folders ("com/website/project..."). I was wondering how
> project managers tend to handle the organization of unit testing code.
>
> A few ideas occurred to us:
> 1) Just have a "test" folder in each project, which replicates the
> project directory (ugly). Store any unit tests for the project there,
> and simply exclude that folder when creating a JAR or other distribution.
>
> This one is easy to work with, but a little ugly when working with the
> unit tests.
>
> 2) Change the repository to have "src" and "tests" folder, organized
> with the same java packaging layout. Each category goes in it's own
> folder; to run tests, you checkout your projects "src" and "tests."
>
> I'd think this makes it too complicated to run tests on a project, and
> therefore they wouldn't get run often enough.
>
>
> I also someday want to set up a Hudson continuous integration server
> ("https://hudson.dev.java.net/"), so I'd want to keep that in mind as well.
> A few Google searches haven't turned up anything interesting, what are
> your thoughts?
>
> Thanks for your help!
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413557
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413632

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].

[Stephen Connolly-2]

2009/11/2 Stephen Connolly <stephen.alan.connolly@...>:

> Have a look at Maven and the standard directory layout.  (I'm not
> suggesting that you change your build process to Maven (although IMHO
> that could well be a good thing) but the standard directory layout is
> what most projects are moving towards whether they build with Maven or
> with something else.
>
> 2009/11/2 Jake Stone <jake.the.stone@...>:
>> Hello all,
>>
>> I am working on a few small Java projects, and we are trying to switch
>> to test-driven development in the near future. We have a relatively
>> standard branches/dist/tags/trunk layout, inside of trunk is just the
>> java package folders ("com/website/project..."). I was wondering how
>> project managers tend to handle the organization of unit testing code.
>>
>> A few ideas occurred to us:
>> 1) Just have a "test" folder in each project, which replicates the
>> project directory (ugly). Store any unit tests for the project there,
>> and simply exclude that folder when creating a JAR or other distribution.
>>
>> This one is easy to work with, but a little ugly when working with the
>> unit tests.
>>
>> 2) Change the repository to have "src" and "tests" folder, organized
>> with the same java packaging layout. Each category goes in it's own
>> folder; to run tests, you checkout your projects "src" and "tests."
>>
>> I'd think this makes it too complicated to run tests on a project, and
>> therefore they wouldn't get run often enough.
>>
>>
>> I also someday want to set up a Hudson continuous integration server
>> ("https://hudson.dev.java.net/"), so I'd want to keep that in mind as well.
>> A few Google searches haven't turned up anything interesting, what are
>> your thoughts?
>>
>> Thanks for your help!
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413557
>>
>> To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].
>>
>

Apologies for top posting... it's been a month or two since I have
posted on this list and I forgot the bottomposting zealous nature of
this list... ;-)

-Stephen

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2413633

To unsubscribe from this discussion, e-mail: [users-unsubscribe@...].