[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: Branch root identification -- a (really) simple proposal
From:       Mark Phippard <markphip () gmail ! com>
Date:       2009-09-29 17:10:59
Message-ID: ff892c5d0909291010p20aa8b1bvc749196f9d0cdf18 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Sep 29, 2009 at 12:41 PM, Paul Burba <ptburba@gmail.com> wrote:

> For the sake of discussion let's hand-wave on the problems of mixed
> revision WCs, switched subtrees, and incomplete (no root) "branch"
> checkouts.  Let's just assume we don't allow any of that and recording
> mergeinfo at the root of the branch for a subtree merge is feasible.
>
> What if subtree merge is not done by TruMerge and so may represent
> only a partial application of some change?  If we record that
> (partial) merge in the branch root's mergeinfo we would need a way to
> flag that it is not in fact a whole-branch merge; something akin to
> '*', but with the meaning "we have merged this revision to some
> subtree(s) but it effects other subtrees and we have not merged it to
> those".  This would add even great complexity to mergeinfo and merge
> tracking, something I'm hesitant to do.  Or am I misunderstanding what
> you suggest?

Basically, I am saying we would ignore these issues, assume the user
knows what they are doing, and track the merge in a way that is more
convenient to that user (at the branch root).  When you do a subtree
merge, I think there are four possible reasons:

1) Convenience.  You have some reason to do the merge at the subtree,
and you know that what you are merging only impacts that subtree.  (I
have this a lot with Subclipse where I my trunk has several Eclipse
projects beneath it).

2) Intentional - common. You only want the changes that happened to
that subtree.  You might use --record-only at the root to block the
rest of the merge and elide the mergeinfo.  Or you might know that you
are never going to accidentally merge the rest and leave it.  Ideally,
you would rather not pay the price for subtree mergeinfo.

3) Intentional-rare. You only want the changes that happened to that
subtree right now.  But sometime in the future you will want to merge
the rest.  The whole subtree and elision concepts were based around
the idea that this was going to be common.  It does not seem to be the
case.

4) Accident/ignorance.  You just do not know any better.  Merge misses
some stuff, but thankfully you can rerun the merge later to get the
rest and fix the subtree mergeinfo.

Of these #4 is the hardest to judge.  This could be a rare scenario,
it could be really, really common.  Of the other three, we handle #3.
If there was a named branch/mergeingo root we could possibly offer
better support for #1 and 2 as an alternative.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2401710

[prev in list] [next in list] [prev in thread] [next in thread]