Log and blame will not be problems. My proposal does not change log
or blame. They will still work fine if you apply newmerge. The
revisions and authors and commit messages are still in the repository in
the same place, and log and blame will still show them.
There are only two cases that seem relevant to the newmerge proposal:
* If you do a move, you lose history prior to the move. This is not
new. This is a problem with the existing subversion implementation of
file moves. So, if people are living with it now, they will live with
the same thing in the future. It only becomes more obvious if merge can
follow these changes, but log and blame cannot. You could upgrade log
and blame to follow the changes, and then the system will be better than
it is now.
* If you have foreign merges, you can lose some detail about individual
commits that were done in the foreign repository. Instead, you might
get information about the merge commit that included them. This is
graceful degradation, and it's less than people are already tolerating
with moves. There are ways to get the information back if you want to
do some work on merge and log and blame.
On 7/12/2011 12:58 PM, Mark Phippard wrote:
> 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.
>
> 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.
>
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Received on 2011-07-12 19:06:20 CEST