[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Re: problems when merging branches

From: Juergen Richtsfeld <Juergen.Richtsfeld_at_borland.com>
Date: 2006-05-11 07:41:11 CEST

 

> -----Original Message-----
> From: Baz [mailto:brian.ewins@gmail.com]
> Sent: Wednesday, May 10, 2006 6:09 PM
> To: Juergen Richtsfeld
> Cc: users@subversion.tigris.org
> Subject: Re: RE: Re: problems when merging branches
>
> 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,

this did not happen. i checked this multiple times.

> and - for some reason - you are
> writing to those binary files during the 'clean build' you mentioned).

this does also not happen. i even tried it without the build step, and
it didn't solve anything. besides of that, my build doesn't change the
files in the repository.

> 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.

ok, i'll give this a try. BUT what i'm wondering why there is no
conflict (as you said). the files that are created when you have a
conflict are also missing (the copies of both revisions).

>
> 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?

No, it's a java project, and i'm talking about 3rd party jars here.

> Is
> this intentional?

yes ;)

> 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.

i'm using subversion 1.3.0 on the clients (windows) and 1.3.0-4 on the
server (debian etch amd64).

>

ok, so i'll fix the problems manually by replacing the files from the
other branch. this isn't really what i expected to do when i'm using a
merge tool. what i don't understand here is, that my merge affects lot's
of binary files, but it doesn't happen for all of them. only a few. i'll
go and check what's necessary for this problem to occur.

should we file an issue for this?

juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 11 07:46:10 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.