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
>> .svn/format
>> .svn/text-base/a
>> .svn/text-base/b
>> ./a
>> ./b
>> ./c
>>
>>> 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)
>> and
>> 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).
Peace,
Augie
- application/pkcs7-signature attachment: smime.p7s
Received on 2008-03-24 14:45:43 CET