You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jack Repenning <jr...@collab.net> on 2004/09/03 19:01:44 UTC
diff of scheduled copies
OK, I'm reopening a topic that's been done to death, I know. I
spelunked in the old mails, though, and I didn't spot anyone suggesting
the resolution I just came upon (with Ben C-S's help), so I'm hoping I
can be glorious and heroic, and not merely annoyingly repetitive.
OTOH, there's a lotta history here, and I probably just missed it. Oh,
well.
For the keyword matchers among us: this is not, by the way, the
question of whether diff should be sensible about diffing over
committed copies (issue 1093, now fixed in 1.1).
The problem I'm talking about is: what should diff do when the WC has
scheduled-copy (but perhaps not further modified) files?
Short form: I suggest we add two switches:
--show-copies produces lines like what "svn stat" shows ("A +
filename")
if there have been tweaks since the copy, a
diff-against-text-base
is also shown
--verbose causes a diff-against-empty-file also to appear
not sure of the right answer in the presence of
post-copy tweaks
Rationale:
There are, I believe, two basic opinions:
One opinion (held, among others, by the present implementation) is that
"svn diff" in this situation should show me "the changes I've recently
made." Since these files copied into this wc from elsewhere have not
been modified by "me", diff should not mention them. In an
over-simplification which I do *not* mean disparagingly, but only
present so I can have a simple handle on the idea, I'll call this the
"what have I typed" philosophy.
Another opinion (naturally enough, held by me), diff should show me
"the changes I'm about to inflict on the world with my commit." Since
this is my own opinion, I can be not only convenient but even
disparaging in calling this the "show me what I'm about to do"
philosophy.
Of course, there are valid reasons to want either one of these
questions answered, or there wouldn't be a difference of opinion.
Since we now have an implementation in circulation that provides one
philosophy, I do not recommend we change the default behavior. But I do
recommend we add a switch that provides the other behavior, and I
present not only the proposal and a switch name to do the deed, but
what I hope is a coherent model that will make all sides, and new users
as well, like the new "diff" even better than the old.
I think there's a common understanding of "diff" here, at a suitably
hand-wavey level, and it's in the general "what I changed"
neighborhood. The problem is that these files copied in from elsewhere
are ambiguous by this test. We may generally assume that they've
already been verified as goodness over in that other branch whence I
copied them, or I wouldn't have done the copy. And I'm not really
responsible for their detailed content. And (very important), if it
happens that I first copied them, and then tweaked them a little bit, I
really *am* responsible for the tweaks, and I think all would agree it
would be swell if diff would highlight the tweaks a bit.
So much for consensus; what shall we do, then, about the unmodified,
copied files?
I note that "svn diff"'s output does not, even today, consist solely of
"modified file text." If you've changed props, you get a delta
description modeled upon the file-delta description, but definitely
different. I propose an additional not-quite-like-file-delta output
form.
Without either switch, behavior is unchanged (good for all those people
writing scripts that parse diff output).
With only "--show-copies", we have a kind of compromise: it's "what
have I typed" enough not to bother me with those file contents I copied
over, and yet it's "what I'm about to do" enough to at least remind me
I did that. More importantly, if I've tweaked a copied file, we would
still get the text-base diff we already get today: first the "A +
filename" line, and then the additional delta.
With "--verbose", we get full file text for copies. I think (but this
is the least confident of my suggestions) that we should not also show
the text-base delta here; if there have been tweaks, we should show the
full file text as it is now, tweaks and all. I might be wrong about
that. Maybe we should show full text of the copied version (i.e., the
text-base), and then delta for tweaks. Someone who likes the "what I
typed" philosophy should probably comment here.
There is presently no "--verbose" switch to diff, and without
"--show-copies" there would continue to be no meaning to it; if this
inorthogonality bothers anyone, we might think about a broader meaning
of "--verbose" in the diff context, or we might use the (mutually
exclusive) option-pair "--show-copies" and "--show-full-copies".
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Jack Repenning <jr...@collab.net>.
On Sep 8, 2004, at 8:23 PM, Folker Schamel wrote:
> Jack Repenning wrote:
>> On Sep 4, 2004, at 5:15 AM, Folker Schamel wrote:
>>> "what I have typed (text and props)"
>>> = svn diff
>>>
>>> "show me what I'm about to do (text and props)"
>>> = svn status + svn diff
>>>
>>> -> So why a new switch?
>> "svn status + svn diff" does not show me "what I'm about to do."
>> Status shows that the files are scheduled for copy, true, but does
>> not show the content of the files. Diff is all about the file
>> content, but at present ignores scheduled-copy files (or shows only
>> the changes since the copy).
>> A concrete example: in our product, we have this hierarchy of
>> configuration files: a site-specific one, a user-specific one, and
>> the default settings (not necessarily in that order). Java
>> properties files are often handled the same way, and the java
>> Properties class supports it directly. If I copy in such a file,
>> then the file contents--the property settings--have effect that I
>> cannot fully predict merely by seeing the file name. Properties in
>> the copied file will affect the behavior of the system, even though I
>> have done no further typing in the files.
>> If I copy in a file with 20 settings, and change one, then there's a
>> legitimate question "what's the one thing I changed?", and there's
>> another equally legitimate question "what are the 20 things I'm about
>> to change?" None of your proposed combinations can tell me all those
>> things. "svn status + svn diff + cat" can, but this is too much
>> work.
>
> You not only want to know what you are going to change
> ("copy file A into B" without changing the content).
> You want to know more:
> You want to know the effect of this change onto your
> particular special system.
Sorry, I'm not following: what do you mean by "system" here? The
computer / operating system / etc. it's running on? The whole thing
that would be produced by building these sources?
> This requires also information about the current state,
> not only the "delta" you are going to apply.
>
> If I change "file1.java", I cannot fully predict the effect of this
> change
> without inspecting all other java files referring classes of
> "file1.java".
> Conclusion: Even if I only change "file1.java", "svn diff" should
> display
> the unchanged content of all other java files referring to classes of
> "file1.java"?
I think you suggest this as a "reductio ad absurdum" on my idea, right?
You're saying "of course, no one would want diff to show you the
content of all files that use any class in file1.java. So obviously,
no one would want diff to show what Jack has requested above."
This is not so obvious to me: at the least, *Jack* wants this output
;-) Others have also seemed interested.
Back in the real world, where we try to stay away from absurdities:
without question, the humans always retain the responsibility for
making sure that their changes are "OK"; the tool's job is to provide
the best info it can to assist that decision. My claim is that both
these two questions are (a) interesting, and (b) easy for diff to do:
- what am I about to commit
- what have I changed since the copy
... but we only provide one, at the moment.
> svn is and should be unaware of the your particular system.
> A system-independent definition of "what I have changed"
> is a complete description of the "changeset".
> This is what "svn status" and "svn diff" do (except for binary files).
I have already pointed out that this is not so, that the combination of
status and diff does not display the (unmodified) content of the copied
files, which is none the less a part of the "changeset," and hence is
not complete. You need some additional command, perhaps "cat", to
create a complete description.
My proposal here is to modify diff in such a way that you need only one
command, diff, instead of three.
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Folker Schamel <sc...@spinor.com>.
Jack Repenning wrote:
>
> On Sep 4, 2004, at 5:15 AM, Folker Schamel wrote:
>
>> "what I have typed (text and props)"
>> = svn diff
>>
>> "show me what I'm about to do (text and props)"
>> = svn status + svn diff
>>
>> -> So why a new switch?
>
>
> "svn status + svn diff" does not show me "what I'm about to do." Status
> shows that the files are scheduled for copy, true, but does not show the
> content of the files. Diff is all about the file content, but at
> present ignores scheduled-copy files (or shows only the changes since
> the copy).
>
> A concrete example: in our product, we have this hierarchy of
> configuration files: a site-specific one, a user-specific one, and the
> default settings (not necessarily in that order). Java properties files
> are often handled the same way, and the java Properties class supports
> it directly. If I copy in such a file, then the file contents--the
> property settings--have effect that I cannot fully predict merely by
> seeing the file name. Properties in the copied file will affect the
> behavior of the system, even though I have done no further typing in the
> files.
>
> If I copy in a file with 20 settings, and change one, then there's a
> legitimate question "what's the one thing I changed?", and there's
> another equally legitimate question "what are the 20 things I'm about to
> change?" None of your proposed combinations can tell me all those
> things. "svn status + svn diff + cat" can, but this is too much work.
You not only want to know what you are going to change
("copy file A into B" without changing the content).
You want to know more:
You want to know the effect of this change onto your
particular special system.
This requires also information about the current state,
not only the "delta" you are going to apply.
If I change "file1.java", I cannot fully predict the effect of this change
without inspecting all other java files referring classes of "file1.java".
Conclusion: Even if I only change "file1.java", "svn diff" should display
the unchanged content of all other java files referring to classes of
"file1.java"?
svn is and should be unaware of the your particular system.
A system-independent definition of "what I have changed"
is a complete description of the "changeset".
This is what "svn status" and "svn diff" do (except for binary files).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Jack Repenning <jr...@collab.net>.
On Sep 4, 2004, at 5:15 AM, Folker Schamel wrote:
> "what I have typed (text and props)"
> = svn diff
>
> "show me what I'm about to do (text and props)"
> = svn status + svn diff
>
> -> So why a new switch?
"svn status + svn diff" does not show me "what I'm about to do."
Status shows that the files are scheduled for copy, true, but does not
show the content of the files. Diff is all about the file content, but
at present ignores scheduled-copy files (or shows only the changes
since the copy).
A concrete example: in our product, we have this hierarchy of
configuration files: a site-specific one, a user-specific one, and the
default settings (not necessarily in that order). Java properties
files are often handled the same way, and the java Properties class
supports it directly. If I copy in such a file, then the file
contents--the property settings--have effect that I cannot fully
predict merely by seeing the file name. Properties in the copied file
will affect the behavior of the system, even though I have done no
further typing in the files.
If I copy in a file with 20 settings, and change one, then there's a
legitimate question "what's the one thing I changed?", and there's
another equally legitimate question "what are the 20 things I'm about
to change?" None of your proposed combinations can tell me all those
things. "svn status + svn diff + cat" can, but this is too much work.
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Folker Schamel <sc...@spinor.com>.
"what I have typed (text and props)"
= svn diff
"show me what I'm about to do (text and props)"
= svn status + svn diff
-> So why a new switch?
Jack Repenning wrote:
> OK, I'm reopening a topic that's been done to death, I know. I
> spelunked in the old mails, though, and I didn't spot anyone suggesting
> the resolution I just came upon (with Ben C-S's help), so I'm hoping I
> can be glorious and heroic, and not merely annoyingly repetitive. OTOH,
> there's a lotta history here, and I probably just missed it. Oh, well.
>
> For the keyword matchers among us: this is not, by the way, the question
> of whether diff should be sensible about diffing over committed copies
> (issue 1093, now fixed in 1.1).
>
> The problem I'm talking about is: what should diff do when the WC has
> scheduled-copy (but perhaps not further modified) files?
>
> Short form: I suggest we add two switches:
> --show-copies produces lines like what "svn stat" shows ("A +
> filename")
> if there have been tweaks since the copy, a
> diff-against-text-base
> is also shown
> --verbose causes a diff-against-empty-file also to appear
> not sure of the right answer in the presence of
> post-copy tweaks
>
> Rationale:
>
> There are, I believe, two basic opinions:
>
> One opinion (held, among others, by the present implementation) is that
> "svn diff" in this situation should show me "the changes I've recently
> made." Since these files copied into this wc from elsewhere have not
> been modified by "me", diff should not mention them. In an
> over-simplification which I do *not* mean disparagingly, but only
> present so I can have a simple handle on the idea, I'll call this the
> "what have I typed" philosophy.
>
> Another opinion (naturally enough, held by me), diff should show me "the
> changes I'm about to inflict on the world with my commit." Since this
> is my own opinion, I can be not only convenient but even disparaging in
> calling this the "show me what I'm about to do" philosophy.
>
> Of course, there are valid reasons to want either one of these questions
> answered, or there wouldn't be a difference of opinion. Since we now
> have an implementation in circulation that provides one philosophy, I do
> not recommend we change the default behavior. But I do recommend we add
> a switch that provides the other behavior, and I present not only the
> proposal and a switch name to do the deed, but what I hope is a coherent
> model that will make all sides, and new users as well, like the new
> "diff" even better than the old.
>
> I think there's a common understanding of "diff" here, at a suitably
> hand-wavey level, and it's in the general "what I changed"
> neighborhood. The problem is that these files copied in from elsewhere
> are ambiguous by this test. We may generally assume that they've
> already been verified as goodness over in that other branch whence I
> copied them, or I wouldn't have done the copy. And I'm not really
> responsible for their detailed content. And (very important), if it
> happens that I first copied them, and then tweaked them a little bit, I
> really *am* responsible for the tweaks, and I think all would agree it
> would be swell if diff would highlight the tweaks a bit.
>
> So much for consensus; what shall we do, then, about the unmodified,
> copied files?
>
> I note that "svn diff"'s output does not, even today, consist solely of
> "modified file text." If you've changed props, you get a delta
> description modeled upon the file-delta description, but definitely
> different. I propose an additional not-quite-like-file-delta output form.
>
> Without either switch, behavior is unchanged (good for all those people
> writing scripts that parse diff output).
>
> With only "--show-copies", we have a kind of compromise: it's "what have
> I typed" enough not to bother me with those file contents I copied over,
> and yet it's "what I'm about to do" enough to at least remind me I did
> that. More importantly, if I've tweaked a copied file, we would still
> get the text-base diff we already get today: first the "A + filename"
> line, and then the additional delta.
>
> With "--verbose", we get full file text for copies. I think (but this
> is the least confident of my suggestions) that we should not also show
> the text-base delta here; if there have been tweaks, we should show the
> full file text as it is now, tweaks and all. I might be wrong about
> that. Maybe we should show full text of the copied version (i.e., the
> text-base), and then delta for tweaks. Someone who likes the "what I
> typed" philosophy should probably comment here.
>
> There is presently no "--verbose" switch to diff, and without
> "--show-copies" there would continue to be no meaning to it; if this
> inorthogonality bothers anyone, we might think about a broader meaning
> of "--verbose" in the diff context, or we might use the (mutually
> exclusive) option-pair "--show-copies" and "--show-full-copies".
>
>
>
> -==-
> Jack Repenning
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> o: 650.228.2562
> c: 408.835.8090
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2004-09-08 at 23:54, C. Michael Pilato wrote:
> > Well, while were talking about 'svn diff' improvements, let me voice a
> > complaint that *I've* had with the output for a loooong time (even had
> > a patch to fix it almost finished before a disk crash took care of
> > that for me) -- I never want to see the header lines say: "Index:
> > blahblahblah".
>
> >From a brief look at the gnu patch source, it looks like the string
> "Index:" is significant to the patch command.
Oh, it is. It's one of the fallbacks (the last?) when trying to
determine the path to which the diff should be applied. So, well,
maybe we want to offer all the fallbacks we can, I guess.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-09-08 at 23:54, C. Michael Pilato wrote:
> Well, while were talking about 'svn diff' improvements, let me voice a
> complaint that *I've* had with the output for a loooong time (even had
> a patch to fix it almost finished before a disk crash took care of
> that for me) -- I never want to see the header lines say: "Index:
> blahblahblah".
From a brief look at the gnu patch source, it looks like the string
"Index:" is significant to the patch command.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by "C. Michael Pilato" <cm...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> On Sep 5, 2004, at 12:04 PM, Greg Hudson wrote:
>
> >> On Fri, 2004-09-03 at 15:01, Jack Repenning wrote:
> >> Short form: I suggest we add two switches:
> >> --show-copies produces lines like what "svn stat" shows
> >
> > Any reason we can't just make this the normal behavior? I think we
> > have
> > license to add comments to the diff output.
>
> Personally? That would be OK with me; I thought it would be a
> violation of user interface stability promises. But if that's not so,
> then sure, make my preference into the default, I won't scream!
Well, while were talking about 'svn diff' improvements, let me voice a
complaint that *I've* had with the output for a loooong time (even had
a patch to fix it almost finished before a disk crash took care of
that for me) -- I never want to see the header lines say: "Index:
blahblahblah". I want them to say "Added: blahblah" or "Removed:
blahblah" or "Copied: blahblah (from thing@REV)" like 'svnlook diff'
does.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> I'm okay with having a flag to display (a) instead of (b); it just needs
> to have a different name. --show-diff-against-empty-for-copies is a bit
> long; I wish I had a terser suggestion.
--show-copies-as-adds ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-09-08 at 22:38, Jack Repenning wrote:
> > --verbose is about
> > providing more output, not different output, and it would be bizarre to
> > provide *both* a diff against the text-base and a diff against empty
> > for
> > copied files.
>
> Uuuhhhhhhh .... think I got lost here ...
>
> Are you saying something like "neither of these diffs is necessarily a
> proper subset of the other"? The one might be not merely _more_
> output, but actually _different_?
I think so.
If we have a file which was added with copy history, then we can display
either (a) a diff against empty (as we would for a file added without
copy history) or (b) a diff against the copy source. Right now, we
display (b) (which means we display nothing at all if the file wasn't
modified after the copy).
We could display both (a) and (b), which would be consistent with
--verbose ("show me more"), but that would be weird and I don't like the
idea of displaying more than one diff for a single target. We could
display (a) instead of (b), but I don't think that's consistent with
--verbose.
I'm okay with having a flag to display (a) instead of (b); it just needs
to have a different name. --show-diff-against-empty-for-copies is a bit
long; I wish I had a terser suggestion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Jack Repenning <jr...@collab.net>.
On Sep 5, 2004, at 12:04 PM, Greg Hudson wrote:
>> On Fri, 2004-09-03 at 15:01, Jack Repenning wrote:
>> Short form: I suggest we add two switches:
>> --show-copies produces lines like what "svn stat" shows
>
> Any reason we can't just make this the normal behavior? I think we
> have
> license to add comments to the diff output.
Personally? That would be OK with me; I thought it would be a
violation of user interface stability promises. But if that's not so,
then sure, make my preference into the default, I won't scream!
I note Folker Schamel's remarks in this thread appear to like the
current way, which would be an argument for providing both somehow or
other (which is the default, which takes a switch, being perhaps
secondary).
>
>> --verbose causes a diff-against-empty-file also to
>> appear
>> not sure of the right answer in the presence
>> of
>> post-copy tweaks
>
> I don't think --verbose is the right name here, when you consider the
> case of copied files with post-copy tweaks.
Yeah, I hear you. I expressed that reservation in the proposal. I was
hoping someone would have a better idea....
> --verbose is about
> providing more output, not different output, and it would be bizarre to
> provide *both* a diff against the text-base and a diff against empty
> for
> copied files.
Uuuhhhhhhh .... think I got lost here ...
Are you saying something like "neither of these diffs is necessarily a
proper subset of the other"? The one might be not merely _more_
output, but actually _different_?
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: diff of scheduled copies
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-09-03 at 15:01, Jack Repenning wrote:
> Short form: I suggest we add two switches:
> --show-copies produces lines like what "svn stat" shows
Any reason we can't just make this the normal behavior? I think we have
license to add comments to the diff output.
> --verbose causes a diff-against-empty-file also to appear
> not sure of the right answer in the presence of
> post-copy tweaks
I don't think --verbose is the right name here, when you consider the
case of copied files with post-copy tweaks. --verbose is about
providing more output, not different output, and it would be bizarre to
provide *both* a diff against the text-base and a diff against empty for
copied files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org