RE: Re: BUG: Wrong merge range

> -----Original Message-----
> From: phahn [mailto:pjtr.hahn_at_googlemail.com]
> Sent: Thursday, September 25, 2008 4:18 PM
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: BUG: Wrong merge range
>
>
>
> On 25 Sep., 22:09, "Fisher, John" <jfis..._at_forthrightsolutions.com>
> wrote:
> > First, even if your mental model "is that of subversion", that doesn't
> > make it the same as the mental model of common TSVN users.
> Ok, so the system has to adopt to the mental model of the user or has
> the user to understand the mental model of the system.
> Maybe I should go back to school and complain that all me not so good
> grades have to be corrected because they don't accounted for my
> different mental model?
>

Ouch. You're awfully confused about the purpose of software if you really want to argue about this from that angle.

> > Second, I've read the subversion documentation.  Things like, "Notice
> > that in general, revisions N and M of a file do not necessarily differ!"
> > indicate that the revision numbers don't store files, but something
> > else.
> Great! Now we discuss things like "indicate" and "something else".
>
> The documentation clearly says:
> "Each revision number has a filesystem tree hanging below it, and each
> tree is a "snapshot" of the way the repository looked after a commit."
>
> Just look into a .svn/text-base dir and you will see the version of
> your files at your working copy revisions. You won't see a diff here
> but a complete file.

Yup. And that in no way conflicts with the mental model relating to merging revisions, since the version of the file in the revision is different from the content stored by the system when saving the revision. The way you describe things, SVN is storing a complete new copy of the file for each revision that changes said file. Obviously, this isn't the case. SVN is storing the differences between the changed files (and likely a few other things in order to aid performance).

> So you can't apply a revision to anything because you can't apply a
> file you just can apply differences / changes between files.
> Merging revisions in the sense of the word is just not possible.
> Therefor the list shouldn't start with the first revision you want to
> merge but with the revision of the file before the change you made to
> it and now want to merge back into your trunk.

You clearly think that. Many other people clearly don't agree.

Again, SVN is storing data and giving the repository a new revision number. If you want to say that the change is "between" revisions, and someone else wants to say that the revision itself IS the change, it doesn't impact normal usage. However, it clearly relates to your concept of merging. You think that SVN *must* use the revision before and including the change that you care about. Clearly that isn't a requirement based on principle, though your favored use of the command line expects that syntax.

GUI software is typically designed to *remove labor* from users. That is exactly what has been done in this case. Why do you insist that someone change the software so the users are again forced to do this adjustment on their own?

John

---------------------------------------------------------------------
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 23:30:22 CEST