On 25 Sep., 18:26, Stefan Küng <tortoise..._at_gmail.com> wrote:
> We're not counting, we're merging revisions.
No, we are merging the CHANGES that happened between revisions! That
is an important difference and I think this is the cause you are
missunderstanding my point. Maybe this is also the cause this is
preferred by TSVN because people seam to think of a revision of
something to click on in a list.
>
> > Revisions are no entities, they are points in time which represent a
> > state.
> > What we are interested in when we want to merge are not states but
> > changes that occur between them and got us from A to B.
> No, but I would give you the meter readings for 2000, 2001, 2002, 2003,
> 2004, 2005, 2006, 2007 and 2008.
> With your analogy, you would omit the year 2000.
Ok, that example wasn't that good because I omited a date.
The point here was that there is a difference between printing pages
which are distinct entities and merging revisions ranges there
revisions are nothing but states at timepoints. The entities here are
changes occuring between them and summarized as changesets
You can't compare that.
Printing page 1-1 makes sense. Merging revisions 1-1 does not.
> > To get back to the changeset example.
> > How would you specify -c in that system?
> > -r6:8 in TSVN is 5-8, -r7:8 is 6-8 -- so to get something equivalent
> > to -c8 you have to say -r8:8 if you want a consistent formulation.
>
> Wrong.
> -r6:8 in TSVN is 7-8, -r7:8 is 8
Ok, I wasn't clear. The numbers are revisions in the sense of design
of subversion.
Maybe thats our major source of misunderstanding here.
In my opinion subversion is a theoretical model - a system design.
Revision in that world is a fixed definition. No room for
interpretation. Writing a client and interpreting this numbers
different is like writing a mathbook with a different interpreation of
2+2.
Changesets: |-1-|-2-|-3-|-4-|
Revisions: 0---1---2---3---4
The fact the revision numbers have to be translated back to the svn
meaning profs that this is true.
> Also, have you seen the checkbox 'reverse merge' ?
> If the merge dialog would work as you want, that checkbox would have to
> go away.
Why should that not work? Where is the problem with that?
It should work the same way like svn merge -r200:199 or svn merge -c
-200.
> Also, selecting revisions to merge from the log dialog also wouldn't
> work: how could the log dialog know whether the user wants to merge or
> reverse-merge the selected revisions?
Why is it necessary for the log dialog to know this?
Just select 199 and 200 and you can merge eihter way, back and forth
and round.
I'm not completely against the way the changes to merge are specified
in TSVN but this isn't a range of revisions -- it's a list of
changesets like your list of printing pages.
This is not just small minded nitpicking, but a huge difference.
Calling it a revisions range is confusing everyone familiar with
subversion but not with the specific interpretation used by TSVN. This
is BAD. This is especially bad as it is nowhere state clearly that it
has a different interpretation at all.
I don't want the school of my childs to give them a math book
interpreting integers like 2+2 = 5.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-09-25 21:28:53 CEST