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
>
Received on 2012-01-20 03:24:43 CET