> On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright > <hy...@hyrumwright.org> wrote: > > On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard > <markp...@gmail.com> wrote: > >> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright > <hy...@hyrumwright.org> wrote: > >>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard > <markp...@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
