I think the key is that what is done to merge for 1.8 have significant
substance not just be a "nice to have". Users aren't indicating
confusion so much as they are indicating performance issues and
mishandled or unhandled use cases. Better information is good, but real
progress on the items giving
On Mon, Sep 12, 2011 at 10:08 AM, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad
> wrote:
>
>> Heh, well, I did present the thread as "the current behaviour is a
>> problem". I guess I did it that way because it was a bit of detail (in
>> Subversion's overall merge behavio
Julian Foad wrote on Mon, Sep 12, 2011 at 15:54:40 +0100:
> whereas the larger topic that I'm really interested in is currently
> quite hand-wavy open-ended thinking about what we *could* do, and thus
> harder to email about.
It seems you just described 'obliterate' :)
On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad wrote:
> Heh, well, I did present the thread as "the current behaviour is a
> problem". I guess I did it that way because it was a bit of detail (in
> Subversion's overall merge behaviour) that was easy to latch on to and
> easy to say something spec
On Mon, 2011-09-12 at 10:47 -0400, C. Michael Pilato wrote:
> On 09/12/2011 09:58 AM, Julian Foad wrote:
> > I take some offence at that. Sure it's a not a problem that's been
> > proven to need solving -- and I agree it quite likely is low on the
> > priority list in pragmatic terms. I DON'T ASK
On Mon, 2011-09-12 at 15:33 +0100, Julian Foad wrote:
> On Mon, 2011-09-12 at 10:00 -0400, Mark Phippard wrote:
> > On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad
> > wrote:
> > >> If merge brought in legitimate
> > >> > changes to the svn:mergeinfo property. diff is supposed to show the
> > >>
On Mon, 2011-09-12 at 10:41 -0400, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard wrote:
> > I have a working copy of trunk and I do the merge shown as r14 (which
> > is what will be created when I commit this merge). Here is the
> > command I run and the diff output of th
On 09/12/2011 09:58 AM, Julian Foad wrote:
> I take some offence at that. Sure it's a not a problem that's been
> proven to need solving -- and I agree it quite likely is low on the
> priority list in pragmatic terms. I DON'T ASK YOU TO FIX IT. But I'm
> interested more in the theory and the pot
On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard wrote:
> I have a working copy of trunk and I do the merge shown as r14 (which
> is what will be created when I commit this merge). Here is the
> command I run and the diff output of the mergeinfo:
>
> $ svn merge ^/branches/b .
> --- Merging r10 th
On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
> Paul Burba wrote:
>> If diff is going to take
>> inherited mergeinfo into account (which in a nutshell is really what
>> you are proposing...I think) then *every* child path under an
>> (inheritable) explicit mergeinfo change should show a diff
On Mon, Sep 12, 2011 at 10:00 AM, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
>>> If merge brought in legitimate
>>> > changes to the svn:mergeinfo property. diff is supposed to show the
>>> > changes, and those are changes.
>>
>> I said this is a choice, and tha
On Mon, 2011-09-12 at 10:00 -0400, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
> >> If merge brought in legitimate
> >> > changes to the svn:mergeinfo property. diff is supposed to show the
> >> > changes, and those are changes.
> >
> > I said this is a choice, an
On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
>> If merge brought in legitimate
>> > changes to the svn:mergeinfo property. diff is supposed to show the
>> > changes, and those are changes.
>
> I said this is a choice, and that if we want to display raw changes to
> the property then that
On Mon, 2011-09-12 at 09:48 -0400, C. Michael Pilato wrote:
> On 09/12/2011 09:24 AM, Paul Burba wrote:
> >>> I'm currently looking at merging from a high-level POV, looking at what
> >>> clues and information we give the users about what they're doing, that
> >>> hopefully guide them in doing the
Paul Burba wrote:
> If diff is going to take
> inherited mergeinfo into account (which in a nutshell is really what
> you are proposing...I think) then *every* child path under an
> (inheritable) explicit mergeinfo change should show a diff right?
No, only if you choose to display that information
On 09/12/2011 09:24 AM, Paul Burba wrote:
>>> I'm currently looking at merging from a high-level POV, looking at what
>>> clues and information we give the users about what they're doing, that
>>> hopefully guide them in doing the Right Thing and don't mislead and
>>> distract them.
>
> Do we have
On Mon, Sep 12, 2011 at 8:52 AM, Mark Phippard wrote:
> On Thu, Sep 8, 2011 at 4:39 PM, Julian Foad wrote:
>> On Thu, 2011-09-08 at 12:37 -0400, Paul Burba wrote:
>>> On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad
>>> wrote:
>>> > Can I file an issue for this?
>>>
>>> Hi Julian,
>>>
>>> What prob
On Mon, Sep 12, 2011 at 8:47 AM, Julian Foad wrote:
> Hi Paul.
>
> Hmm, it's not quite as simple a matter as I first thought.
>
> On Thu, 2011-09-08, Julian Foad wrote:
>> So in "diff" we have a choice. Do we tell the user the physical
>> difference of a particular mergeinfo property, or do we in
On Thu, Sep 8, 2011 at 4:39 PM, Julian Foad wrote:
> On Thu, 2011-09-08 at 12:37 -0400, Paul Burba wrote:
>> On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad
>> wrote:
>> > Can I file an issue for this?
>>
>> Hi Julian,
>>
>> What problem(s) is the current behavior causing? I understand your
>> poi
Hi Paul.
Hmm, it's not quite as simple a matter as I first thought.
On Thu, 2011-09-08, Julian Foad wrote:
> So in "diff" we have a choice. Do we tell the user the physical
> difference of a particular mergeinfo property, or do we interpret and
> display what it means? It appears from the wor
On Thu, 2011-09-08 at 12:37 -0400, Paul Burba wrote:
> On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad wrote:
> > Can I file an issue for this?
>
> Hi Julian,
>
> What problem(s) is the current behavior causing? I understand your
> point, but I hesitate to add merge tracking awareness to diff unle
On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad wrote:
> Can I file an issue for this?
Hi Julian,
What problem(s) is the current behavior causing? I understand your
point, but I hesitate to add merge tracking awareness to diff unless
there is some benefit.
> Philip said the server makes (or used
Can I file an issue for this?
Philip said the server makes (or used to make?) the same mistake
internally when processing mergeinfo - presumably in the guts of the
ra_get_mergeinfo2 API?
I assume the deletion (elision) of a mergeinfo prop would generate an
all-revs-unmerged diff output, but haven
If Subversion creates subtree mergeinfo on a path that previously didn't
have any, then "svn diff" incorrectly shows all the source revs in that
mergeinfo as newly "merged".
In a Subversion trunk WC, using 1.7.0-rc2:
$ svn merge -c 100 ^/subversion/branches/1.6.x/INSTALL INSTALL
--- Merging r
24 matches
Mail list logo
