Re: Issue-2897 Branch

On Jan 29, 2008 9:46 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
> David Glasser wrote:
> > On Jan 29, 2008 7:42 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
> >> I found the following differences(will add them as and when I find them).
> >>
> >> 1)If feature branch is not fully up-to-date with trunk(having sparse
> >> merges), we will get faulty behavior.
> >> a)have /trunk/test.c (r1)
> >> tline1
> >> tline2
> >> tline3
> >> tline4
> >> tline5
> >> b)branch /b1 from /trunk(r2)
> >> c)In trunk change 'tline1'->'Tline1' and commit(r3)
> >> d)In trunk change 'tline2'->'Tline2' and commit(r4)
> >> e)merge r4 from trunk to /b1 and commit(r5)
> >> f)merge /b1 to /trunk <-This gives a spurious conflict
> >>
> >> Issue-2897 branch does merge at f) correctly(Though it is broken due to
> >> missing sqlite data, which I am *still* making a progress to implement
> >> the FS based solution).
> >
> > Kamesh, that's a set of merge operations which does one (arguably more
> > correct) thing with your branch and another thing without it. But
> > that's not really a "use case"... what is the motiviation here? Why
> > did the user only merge r4 but not r3, and then later try to
> > bulk-merge back? Is the user trying to merge "all but a few specific"
> > revisions, in which case a record-only merge of r3 could have happened
> > (which would then allow reintegrate to work)?
>
> David, does this scenario really surprise you all that much? I run into
> this kind of thing all the time. The story goes like this:
>
> I make a branch from trunk to rework the libsvn_fs_base implementation of
> some functionality. But while my code lives out in space, my email reader
> does not, and so I happen to notice that someone else has done some trivial
> code formatting change that I know will cause a conflict with my branch
> work. I'd like to resolve that now while my code is freshly in mind rather
> than deal with it later at merge-back time. So I have a choice to make --
> do I merge to my branch all the changes in the trunk since my branchpoint (a
> large merge, a large commit, etc.) or do I just cherry-pick the revision
> that I know will cause the problem?

Sure, that's a real use case, but I don't think that the 2897 work
fixes that. As far as I understand it, as soon as any diff causes a
conflict anywhere the 2897 branch gives up on trying to do anything
special. I'm still trying to find a real use case that isn't
completely trivial that 2897 helps with. (I'm not saying I don't
believe they exist. I just haven't seen a convincing one yet.)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org