Yep, your the first one that got my point.
As I said several times yet, the big problem is not to have a
different mental model of something in principle. But to have a
different interpretation of a fixed definition in a mental model you
refer to and not making clear you have a different interpretation.
Just don't pretend your talking about the same thing by calling it a
range of revisions. Thats all.
One Problem of this is that TSVN is not consistent withhin the
different possible ways of mergin in TSVN.
1.) "Merge a range of revisions" is the equivalent to svn merge -
r:M //source/url/ //wc/path
2.) "Merge two different trees" is the equivalent to svn merge //
sourceA/url_at_N //sourceA/url_at_M //wc/path
1.) and 2.) should be equivalent if both source urls point to the same
place. In fact 2.) is the basic merge command in svn and all others
are just shortcuts and therefor 1.) and 2.) are equivalents in svn.
In TSVN this is not true, so you have different meanings of revision
numbers within the same process.
On Sep 26, 7:52 am, "Jean-Marc van Leerdam"
<j.m.van.leer..._at_gmail.com> wrote:
> On 25/09/2008, phahn <pjtr.h..._at_googlemail.com> wrote:
>
> > cite:
> > "If you have already merged some changes from this branch, hopefully
> > you will have made a note of the last revision merged in the log
> > message when you committed the change. In that case, you can use Show
> > Log for the Working Copy to trace that log message. Use the end point
> > of the last merge as the start point for this merge. For example, if
> > you have merged revisions 37 to 39 last time, then the start point for
> > this merge should be revision 39."
>
> > The example says: 37-39, 39- .... and not 37-39, 40- ...
>
> You have a point here. The TSVN documentation should indicate here
> that TSVN expects the next revision, so the start point for the second
> merge should be 40 (or the next higher applicable number).
>
> Perhaps the TSVN documentation could use a call-out in this chapter to
> indicate the difference from the subversion command line parameters,
> but OTOH we must not feel obliged to keep track of *all* available
> subversion clients and point out differences in parameters between
> them and TSVN.
>
> > The more I think about this the more it hurts *G*
>
> Yep, paradigm shifts can to that to you :-)
>
> You have some valid points in saying a revision is a snapshot and
> changes occur between revisions, but another valid viewpoint is that a
> revision number represents a changeset.
>
> Look at it as the possible different interpretations of light
> (particles ws. waves). Neither is right or wrong, neither is good or
> bad, but sometimes people prefer to think of them in one way and
> sometimes the other way.
>
> TSVN has chosen the 'revision number == changeset' as the
> interpretation that is usually easiest for its users to understand.
>
> --
> Regards,
>
> Jean-Marc
>
> ----------------
> ___
> // \\ @@ "De Chelonian Mobile"
> / \_/ \/._) TortoiseSVN
> <\_/_\_/ / The coolest Interface to (Sub)Version Control
> /_/ \_\ Check outhttp://tortoisesvn.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
---------------------------------------------------------------------
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-26 10:13:03 CEST