>
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
-----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: 11 June 2009 11:57
> To: Giulio Troccoli
> Cc: users_at_subversion.tigris.org
> Subject: Re: Unexpected conflict that resolves intself
>
> On Thu, Jun 11, 2009 at 11:39:55AM +0100, Giulio Troccoli wrote:
> > Hello guys, I hope you can help me with this becuase it's
> really annoying.
> >
> > I am testing SVN 1.6.2. At the moment we have 1.4.4.
> >
> > Our repository doesn't use the classic trunk/branches/tags
> layout, although we do have something similar.
> >
> > For each supported relase we have two streams: test and
> cand. Developers work in the test stream. When a change needs
> to go on an old release we have a script that automatically
> merges the changes into the next test stream. So, for
> example, if a developer commits some changed into 1.40/test,
> then the script will merge those changes into 1.51/test, then
> from 1.51/test to 1.60/test and finally from 1.60/test to 1.61/test.
> >
> > The script, smerge, has to be run manully by the developer
> on the SVN server box. This is becuase we didn't have (with
> 1.4.4) automatic conflict resolution and we don't want it now
> with 1.6.2. So, developers will need to manually resolve the
> conflicts during the merging process. And yes, we do keep a
> WC of the whole repository on the server just for this.
> >
> > With 1.4.4 everything worked fine. With 1.6.2 however,
> almost always I
> > have a conflict on the root of the tree, e.g. 1.61/test/src (src is
> > the only directory in test and it's there for legacy
> reasons). Oddily
> > though the conflict is not during the merge, which
> developers would be
> > asked to fix, but during the commit
>
> Conflicts are only flagged during update and merge.
>
> So commit complains about conflicts which were flagged during
> update and merge but have not yet been resolved.
Of course. I should have known that. And since I check only for conflicts in the content (i.e. the first column of the svn status result) I miss the conflict in the properties.
> > svn: Commit failed (details follow):
> > svn: Conflict at '/dip/1.61/test/src'
>
> What do these commands print?
>
> svn status /dip/1.61/test/src
> svn info /dip/1.61/test/src
And of course, as per Murphy's Law, I cannot reproduce the problem anymore. However, svn status shows something like
M src
M src/dip/client/dipClientMain.c
Which confirms to me that it's a property conflict, i.e. mergeinfo as we don't have any other properties on directories.
BTW, my merge command was
svn merge -c<revision> --accept postpone <REPO_URL> src
But I have also tried with
svn merge --non-interactive -c<revision> <REPO_URL> src
> > Even more weird is the fact that if I don't do anything and
> simply try
> > the merging again then everything is fine.
>
> Conflicted items are skipped if you try to merge again.
True, but. When the commit fails my script does an error recovery too, i.e. issues
svn revert --non-interactive --depth=infinity src
svn update --non-interactive --depth=infinity src
And then it removes all unversioned files (which theoretically are new files added by the merge)
So, I don't see how the next time the conflict does not happen again. In my view the WC is returned to the exact same state as before the merging, so whatever cause the conflict should still be there. Clearly I'm missing something.
> > I thought that maybe I had the conflict because the WC for
> > /dip/1.61/test/src was not up-to-date but I do issue an 'svn update'
> > before merging.
> >
> > As anyone have any idea why the conflict? And how to resolve it?
>
> We may be able to tell you more if you post the output of the
> above commands.
Why do you need the svn info too? I'm just asking becuase I'm testing on a VM and AFAIK I cannot copy and paste, so if I know what you're after I can tell you.
Thanks for your help
Giulio
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2361275
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-11 15:28:22 CEST