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

[TSVN] Re: Re: Merge dialog, second attempt

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2005-01-25 23:54:21 CET

matthew ford wrote:
> Mark Phippard wrote:
>> On the N-1 issue, how long are people really going to be confused
>> about this?
>
> It is an un-necessary distraction.
> If I want to merge the changes made in Rev 100, then I should just
> say 100 If I want the changes from 90 to 100 then I should just say
> 90-100 (inclusive implied)

I can see what you want and why you want it, believe me. I was arguing
for the same thing last week. That way of looking at it works well in
that particular use case, but there are other use cases too. SVN has
chosen to take a generalised approach which requires generating a diff
between 2 revisions. Merge terminology is based on diff terminology, and
you need to points to make a diff.

> Perhaps if I want to a diff that may be different.
> diff and merger are different, so there is no reason merge cannot be a
> little easier.

But they _are_ closely related, which is why they have used the same way
of describing relationships between trees.

> Just because the command line syntax is poor does not seem a good
> reason to continue to burden the GUI user.

I did at one stage suggest having different dialogs to cover the various
use cases in different ways. But that would have introduced its own
problems of consistency too. I tried to explain this in a post about 2
hours back in the mailing list (sorry, don't have the haxx link to
hand).

I understand Will's argument about printing pages using an inclusive
list, but you are looking only at one aspect of merging. It is often
more complicated than picking from a 1-dimensional list.

Look at the feature branch merge. There you take the diff between
trunk@rev and branch@rev. There is no -1 involved. So what are the
conditions when you decide to apply a -1 automatically? Being
unpredictabe is possibly worse than being non-intuitive.

> p.s I think the command line syntax should have been
>
> svn merge -r 344 http://svn.example.com/repos/calc/trunk
> and
> svn merge -r 300:344 http://svn.example.com/repos/calc/trunk
> (inclusive)

But it _isn't_ like that. Maybe Ben Collins Sussman can explain why
better than I can if you ask on the SVN list. But that is the way it is
and has been for several years. We can't change that now.

Simon

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jan 25 23:54:19 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.