Greg Hudson wrote:
> On Mon, 2002-12-09 at 12:55, Ben Collins-Sussman wrote:
>> Once we've implemented this, it's simply a matter of making the two
>> modes available to 'svn diff' and 'svn merge'. I don't really care
>> which behavior is the default; we can add options to toggle
>> ancestry-sensitivity on or off.
>
> This bugs me because of the axiom:
>
> You can't solve usability problems by adding more switches and
> knobs.
>
> I wonder if the right answer isn't to just punt the (distance == -1)
> check from delta_dirs(). Is there a real penalty for expressing a
> file as a delta against something unrelated?
I wrote a huge mail and blabbered my mind off on it. I'll leave it at
the end and summarise here what I really had to say:
In my *mind*, svn diff with history and svn diff by only looking at
names and contents, are *separate* concepts - for separate uses. I
would not wish them to be combined together automatically any more
I'd like 'svn fetch'.
That's it. Now here comes the long part, you can stop reading now :-)
***
Well, I'll stick my nose in this one, hopefully a bit more as an
outsider to the process.
When I started using Subversion for the first time, one of the things
that got me a warm and fuzzy feeling inside was that Subversion
behaved like I expected it to behave. Just simply reading what was
written on the website frontpage gave me a very good idea of how it
behaved. Then ofcourse I stuck my nose in for real and noticed that
just about everything was still unimplemented :-) Luckily that has
changed since then.
Now, when I hear phrases like "ancestry-sensitive", "preserving
history", "directory versioning", I get an idea in my head about what
it might be about. Then when I see how Subversion behaves with regard
to adding, removing and moving files in a directory for example, it
rhymes with that inner feeling. I see the files branching in two,
joining again somewhere in the future and branching off again. Then
ofcourse I yet again notice that we do not really record ancestry, yet
:-)
Now, when I run 'svn diff' on two unrelated files (I might not know
myself that they are unrelated), the output of the whole being deleted
and another being created feels... correct. That is what I expected,
since the files are not related. Hey, this is not CVS where only the
file name matter - a file with exactly the same name and the same
contents is not the same file, necessarily. And I honestly believe
that this is the way I thought it to be from the start.
The output of 'svn diff' serves two purposes. The first is the mostly
uninteresting case where the output is used only to be fed to 'patch'
later on. There as the only issue I see the edge case of having local
edits to a file that is entirely removed and added in the diff: if the
diff truly has this operation, then it will all end up as a reject -
if the diff just contains the actual changed, no rejects will appear.
The second is user display. When I say 'svn diff', I want to see the
_changes_. I want to know what has changed. And it matters if the file
was removed and an identical file was added in it's place. But, there
also occasions where I want to tell the version system that "Yes, I
know these files are not related, but show me what are the
differences." This is however separate - I know that I specifically
wish to tell the version system to behave differently from what I'd
expect. I would not wish for it to automatically guess for me what I
want to do.
Then ofcourse there is the 'svn merge' case, where you don't see the
differences yourself either. There I think that conceptually 'svn
merge' should always respect ancestry, for real. But since import is
what it is, and people at times have to do things where they are
unable to preserve history - in reality there should be way to either
fix what is wrong (specify history after commits? weird) or work
around it (check only filenames, good enough).
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 9 23:20:17 2002