Getting rid of /dev/null in diff output (was Re: [MERGE][0.8] break-lock command)

[James Henstridge]

On 5/5/06, Martin Pool <mbp at sourcefrog.net> wrote:
> On  4 May 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
> > Robert Collins wrote:
> > > This is also available at http://bazaar-vcs.org/bzr/break-lock.
> > >
> > > diffstat follows: note the strange presence of 'b' in just the new
> > > files. I think think diff prefix patch is buggy :p.
> > >
> >
> > Well diffstat seems a little buggy. But the rest of the files all have > an
> a/NEWS, b/NEWS.  > I think the reason might be that you are comparing /dev/null
> to > b/bzrlib/tests/...
> >
> > And diffstat doesn't see an obvious prefix for /dev/null (but we
> > certainly shouldn't be writing it a/dev/null)
>
> diff does this by showing a diff from an empty file in a:
>
> % mkdir a b
> % date > b/foo
> % diff -Nur a b
> diff -Nur a/foo b/foo
> --- a/foo       1970-01-01 10:00:00.000000000 +1000
> +++ b/foo       2006-05-05 10:44:40.000000000 +1000
> @@ -0,0 +1 @@
> +Fri May  5 10:44:40 EST 2006
>
> And svn does something similar, though without the prefix.  I thought /dev/null
> was needed to indicate creation of new files, but perhaps not.  We may need to
> put the epoch date there for patch to do the right thing.
>
>   https://launchpad.net/products/bzr/+bug/43033

The man page for patch indicates that this it does require the
timestamp to be the epoch for it to remove the file after patching
when the diff doesn't compare to /dev/null as it does now.  I added
the relevant exerpt from the patch man page to the bug report.

If dates are going to be added to the diff output, I wonder what dates
would be appropriate to display?

When comparing to a WorkingTree the answer is pretty easy: take the
date from the file on disk.

If the comparison is against a stored revision though, there are two choices:
 1. the commit date for the revision in question
 2. the commit date for the last revision that changed the file in the
branch's history.

Either way, a bzr.tree.Tree.get_file_mtime() method is probably needed.

James.