On 5/10/06, Juergen Richtsfeld <Juergen.Richtsfeld@borland.com> wrote:
> > From: Juergen Richtsfeld [mailto:Juergen.Richtsfeld@borland.com]
> > > > > i get messages like:
> > > > >
> > > > > Error Item '<somefile>' is out of date
> > > > > Error You have to update your working copy first.
> > > > >
> i executed the svn status on a file that causes the described problems, and i get a single line like
>
> 686 3 username theproblematicfile
>
> when i execute the same on the directory that contains this file, the output contains exactly the same line. what i forgot is that the problematic file(s, there are more) are all binary (at least i didn't find a non-binary problematic file).
Sounds like for some reason you got a conflict (eg someone committed
to trunk after you checked it out, and - for some reason - you are
writing to those binary files during the 'clean build' you mentioned).
Binary files can't be merged; this would explain both the error
message and the fact that it's restricted to binaries. I don't
understand why this wasn't marked as a conflict in 'svn status'
though, so you could just fix it with svn resolve - my reading of the
mail archive suggests it should have behaved that way for a couple of
years.
While you should be able to fix things by copying out the binary
files, reverting them, and copying the files back before you commit,
it brings a couple of questions up -
- are you checking compilation products back into the repository? Is
this intentional? Its happened here sometimes that developers
accidentally commit build logs and the like, but we didn't need them
versioned.
- why aren't these marked as conflicted, so that 'svn resolve' would
fix it? (anyone?). You don't mention your svn version in the thread,
this might be relevant.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 10 18:10:31 2006