On Mon, Sep 04, 2006 at 04:45:42PM +0200, Erik Huelsmann wrote:
> On 9/4/06, Jens Seidel <jensseidel@users.sf.net> wrote:
> >On Thu, Aug 03, 2006 at 10:38:30PM +0200, Jens Seidel wrote:
> >Again: I performed a big merge and after this did a "svn up". I got:
> >
> >> > >svn: Checksum mismatch for 'dir/.svn/text-base/file.cc.svn-base';
> >> > >expected: 'bc0c5b04db8bb787c25b95a61e372452', actual:
> >> > >'d46738f6464df5a5ec690101b85664bc'
> >
> >The following is essential to understand this problem:
> >$ svn status dir/file.cc
> >R + dir/file.cc
> >
> >The file dir/file.cc is replaced and the checksum of the wrong file is
> >probably
> >used for comparison.
>
> I doubt that. But it's a bug (in the client), yes.
Using RC4 I got the same error for a different file (it's also possible that
I performed a slightly different action the last time) but it had the same
status "R +" so I thought it's related.
> Though I have 1 question: given that the file is locally replaced,
> what do you expect to happen to any updates you receive for the -now
> deleted- file? (Because I think you're receiving updates for that file
> in your scenario)
Good question :-) I just hope to get the BASE version of the file (at least for
the content, the history might be slightly different). Details:
> PS: Could you describe *exactly* what your merge does, then what your
> update is supposed to do, what you expect subversion to do and what
> you're actually observing? (I already saw what you're observing, but
> not what you expect update to do: which files should be updated, which
> ones left alone, any ones removed or added?).
That's very difficult but I can at least explain the main facts:
I have a branch of trunk which contains an additional directory compared to
trunk and only a few changed files. At some time many changes occurred to
trunk.
I manually merged all changes from trunk to the branch in revision r10 by
copying the content of trunk to the branch and manually adapting/restoring the
few modified files in the branch. At this time this behaviour seemed optimal to
me since I was afraid of using svn merge for the really large change which
happend in trunk.
A few commits later I tried to verify my manual merge by checking out r9 of
the branch (the version before my merge) and merging using svn merge:
$ svn merge svn+ssh://repo@trunk_rev1 svn+ssh://repo@trunk_rev2
Now I tried svn update and hoped to get my latest version r10 since all
changes are already contained in the repository.
I found a few existing files, which svn update tried to create, deleted
those duplicated files to be able to continue with svn up until I get the
checksum error for a file.
Now I checked this file again and noticed that it was not added or copied
during trunk_rev1 to trunk_rev2 and r9 to r10 so the "replaced" status seems
to be wrong.
It's really hard to debug it since the code tree is large. svndumpfilter
could be helpful, but it isn't useable at the moment because of the
mentioned bug in it ...
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 4 17:58:48 2006