> 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.
BOb
Received on 2011-07-12 22:52:35 CEST