Graeme Geldenhuys schrieb: > On 18 July 2010 22:35, Florian Klämpfl wrote: >> is: what happens if branch and trunk/another branch change the same >> line/tokens of code and then those branches are merged. A good vcs comes >> up with a conflict, a vcs trying to be too clever merges maybe both >> lines creating nonsense code or whatever. > > Of course git will also raise a conflict it that case. My point is > that say you made a change in your branch, and in another branch that > exact same change was also made, if you merge the two branches, git > will resolve it without conflict because the code is identical in both > branches. SubVersion is a bit brain-dead in that regard and will still > raise a conflict - it apparently only looks at the line number, not > the content of that line.
I never encountered this and doubt it :) because svn recognizes also things like the same change made in the repository and the wc and just ignores it. It's more likely that some changes regarding spaces was done. Anyways, why do you want to do the same change twice? Just make it once and merge. > > This was told to me by Vincent and Jonas a little while back, where I > wanted to change the code in cpstrnew branch to match that of Trunk - > but without Why would one do so? This causes only confusion because nobody can reconstruct what has been merged so far. > using svnmerge. We don't use svnmerge anymore but native svn merge because svn has a good merge tracking for several years now. > Even though the code would end up being > identical, subversion raises a conflict. That sounds pretty stupid to > me. In the end Jonas had to revert my commit, and resync the cpstrnew > branch with Trunk - which now doesn't compile any more for me under > Linux. Well, I would have expected this. trunk changed a lot since cpstrnew was created. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
