On Mar 24, 2008, at 6:11 AM, Stefan Sperling wrote:
> On Mon, Mar 24, 2008 at 11:19:51AM +0100, Karl Heinz Marbaise wrote:
>> Hi Stefan,
>>> stsp_at_ted [wc] $ svn cp a b
>>> A b
>>> stsp_at_ted [wc] $ svn diff
>>> stsp_at_ted [wc] $ svn st
>>> A + b
>>> stsp_at_ted [wc] $ echo c > c
>>> stsp_at_ted [wc] $ svn add c
>>> A c
>> Have you ever tried this:
>> find -type f | xargs ls -al
>> than you see things like this:
>> .... .svn/entries
>>> Why isn't the diff for b shown?
>>> Was this a deliberate design decision?
>> And this is reason why svn diff will only print information for "c",
>> cause it's building the difference between the pristine copy (.svn)
>> your working area. You see the missing "c" under .svn/text-base ?
> OK, thanks for pointing that out.
> So that is the way it's currently being done.
> Augie and I were wondering why we don't compare files marked as
> added-with-history against an empty file instead of the copy source?
> Cause in essence, this would more accurately reflect the changes
> that are about to be committed.
> Was there a conscious decision behind this or did it simply evolve
> from the facts you stated?
Right on - it makes code review more difficult (not impossible,
obviously) when diff doesn't actually show you what will be committed.
For what it's worth, Mercurial does behave as I expected. That's the
only other VCS I have handy and already running. I see why it happens,
I'm just curious if the UI is intentional or if I should try to fix
this (realizing I'll need to insert workarounds for existing versions
in the review tool I want to use).
Received on 2008-03-24 14:45:43 CET
- application/pkcs7-signature attachment: smime.p7s