[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: It's time to fix Subversion Merge

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 12 Jul 2011 16:51:56 -0400

> On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright
> <hyrum_at_hyrumwright.org> wrote:
> > On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard
> <markphip_at_gmail.com> wrote:
> >> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> <hyrum_at_hyrumwright.org> wrote:
> >>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard
> <markphip_at_gmail.com> wrote:
> >>>>
> >>>> Finally, in your new design do not forget about things like
> log -g and
> >>>> blame -g, as well as the mergeinfo command.  These features
> are all
> >>>> necessary parts of a merge tracking plan and must have answers
> from
> >>>> the first release.
> >>>
> >>> Really?  I think we should take whatever improvements we can
> get,
> >>> rather than saying "oh, and you need to support all this legacy
> >>> baggage as well."  While they are useful to some folks, I don't
> think
> >>> they are can't-live-without-absolutely-must-have features.  I'm
> mean,
> >>> if we're thinking outside the box, let's think Outside the BOX,
> and
> >>> try not to pigeon hole ourselves.
> >>>
> >>> It would be interesting to see the usage of 'log -g' and 'blame
> -g'.
> >>> I believe Tortoise uses them as the default under-the-hood, so
> that
> >>> probably inflates the actual usage numbers quite a bit.
> >>
> >> A new merge tracking design that does not support these
> features, or
> >> at least have a very definite plan for supporting then, would be
> dead
> >> on arrival.  If the design does not support these options then
> go back
> >> to the drawing board.
> >>
> >> These are absolute must have features.
> >
> > With all due respect, that's not your decision to make.  This
> > consensus-based community gets to determine what are must-have
> > features and what aren't.
> >
> > In reading this thread, it almost feels like there are two
> classes of
> > merge users: power users and others, and they have different sets
> of
> > requirements.  Certainly it's not a discrete set, but a
> continuum.
> > Unfortunately, Subversion tries to serve the needs of both with a
> > single paradigm, and it's not working too well.
> I see us heading down the path of a classic engineering anti-
> pattern.
> There is a tough problem to solve, so you decide to rewrite and
> focus
> on that problem and along the way you toss aside existing things
> you
> already support because you think they are not important.

This is so true... one persons important is another person's too complex.

> Users of Subversion before we had merge tracking, and users of
> Subversion since we have had merge tracking have made it very clear
> that these options are important to them. You cannot come up with
> a
> new merge design that does not account for these needs.

This has been much talk on this list on finding a way to define a project root and only allowing certain commands to work at root, or work as if they were issued at root. Actually, I expect (I could be wrong) that many subtree merges are just a mistake. People say, but I just want to merge the changes in this one file. Ok, so just merge that one changeset... oh, the didn't realize they could do that.

I wonder to if majority of people also want to copy/branch from project roots too.

So, should there be consideration of only allowing merge/branch from project root... or defaulting to project root if you are in a child node? There would probably need to be some type of marker property on a project root. I'm not sure how that would get onto a project. Perhaps when you import or something. Or perhaps those command would give a warning:

svn merge /branch/version1.2.5
(if your target isn't a project root or one isn't found walking up the tree)
 error: No project root defined in merge target
(if your merge source isn't a target root)
error: No project root defined in merge source

Then copy/merge could have a -force command that would allow them to not work on a project root (current behavior).

The issue of cylic merges seems highly complicated. I don't see an easy way you guys could solve that.

Granted, I haven't done and svn coding... but from reading the dev list for a while and as a user it seems that there could be much less change to the code base if:

1. There was a way to designate a project root
2. svn copy and merge only worked on a project root walking up the WC tree to find one.
3. --force on svn copy / merge would work as it does now, no project root needed
4. Automatically add merge info to a merge source when you do a reintegrate merge from it so the branch is still usable.

I guess the above goes into the forcing people into the pit of success when they are branching and merging. But the --force command still allowing them to point that gun at their foot.

Received on 2011-07-12 22:52:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.