Branko Čibej wrote on Thu, Jan 19, 2012 at 20:11:25 +0100: > On 19.01.2012 15:38, Julian Foad wrote: > > Branko Čibej wrote: > > > >> Instead of trying to invent ways to not make current reintegrate suck > >> rocks, I'd suggest taking a look at how other tools handle such repeated > >> merges between branches. Specifically, since git afficionados have so > >> much to say about how good merging in git is, especially compared to > >> Subversion, I'd be really interested to see if -- when you get down to > >> cases -- it can actually do anything that analyzing the diff3 results > >> (or, more likely, using diff4) can't already do. > > I have to ask, are you writing from a point of view of having a mental > > model in which simply analyzing diffs *could* achieve the requisite > > tracking results? Because I can't begin to see how. > > No, I'm just trying to wrap my head around the concept of --reintegrate > in the first place. :) > What I mean is, no other tool I've ever used -- and I include CVS with > all its problems in this list -- has had or needed this concept. So I > must assume that something must be fundamentally wrong with our model of > merge tracking if we ended up having to add --reintegrate. I really > don't know /what/ could be wrong, but comparing what svn does to what > others do (I pushed git as an example because of its vocal proponents, > of course) might give a hint. >
To rule out the common case: are you familiar with Stefan's post giving a reasons for this? His argument is that 'cd trunk-wc && svn merge ^/branches/feature-branch' and 'cd 1.7.x-wc && svn merge ^/trunk' are syntactically indistinguishable but need to execute a semantically different algorithm each. > I grant it could turn out that there's nothing really wrong with the > model and that --reintegrate simply masks implementation problems that > you're tackling on a more fundamental level now. > > -- Brane >
