This has already been hashed to death several times...
What's needed is to add a list of file-level operations to be done before
the diffs are applied.
A possible format (which I'd started working on, long ago, then abandoned)
is
* Each file-level operation is represented by the appropriate Unix shell
command
* diff's are prefixed with a "patch" line
... so the whole thing looks just like a shell script, and can even be run
as one.
Example output will look like:
set -e
cp ./File1.txt ./File2.txt
rm ./File1.txt
patch -p0 <<'EOF'
--- ./File2.txt (old)
+++ ./File2.txt (new)
@ 8,12
Line 8
Line 9
-Line 10
+New Line 10
Line 11
Line 12
EOF
The problem with the whole subject, IIRC, was handling of copies outside the
diff'd area. (There's also a minor problem re ordering of operations, but I
believe it is solvable using a simple topological sort). For example, if I
move a file out of the current directory, the 'diff' output will include its
removal but not the new location; likewise, if a file is copied *into* the
diff'd area, the diff _must_ include its complete contents. FWIW, I don't
believe any of those problems to be really hard. Just annoying :-)
I'm tempted to go back to hacking this...
-az
----- Original Message -----
From: "Branko Čibej" <brane@xbc.nu>
To: "Ben Collins-Sussman" <sussman@collab.net>
Cc: "SVN Dev List" <dev@subversion.tigris.org>
Sent: Wednesday, December 11, 2002 8:33 AM
Subject: Re: svn diff, svn merge, and vendor branches (long)
> Ben Collins-Sussman wrote:
>
> >Greg Hudson <ghudson@MIT.EDU> writes:
> >
> >
> >
> >>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?
> >>
> >>
> >
> >Well, I was pondering this question too. We use dir_delta all over
> >the place... svn diff, svn merge, svn up, svn switch. Is there ever a
> >time where we definitely *should* see a delete+add instead of a patch?
> >I think cmpilato had an example.
> >
> >
>
> There is obviously a big difference betweena modification and a
delete+add.
>
> "svn diff" should, as far as possible, attempt to document repository
> changes. For the moment, let's ignore the fact that there isn't a
> symmetric "svn patch" comand that could actually recreate those
> differences. Assuming "svn patch" existed, a "svn diff" + "svn patch"
> sequence should ideally do the same thing as a "svn merge" with
> appropriate arguments
>
> Now, whether "svn diff" could represent a delete+add in a more compact
> way than it does now is debatable, but I don't think that the current
> diff format can rescribe the complete removal of a file other than as a
> removal of its contents.
>
> So I see two solutions: the short term is to change (_not_ fix!) "svn
> diff" to produce output that "makes sense" the way Eric wants. The
> not-so-short-term solution is to leave the "svn diff" semantics alone --
> or even make it behave more like svn merge -- and start thinking about
> the diff output instead. Specifically: What are the changes necessary to
> the "standard" -- whatever that means -- diff output, to make it
> possible to represent rename, move, and delete/add new file?
>
> --
> Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
>
>
> ---------------------------------------------------------------------
> 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
Received on Wed Dec 11 11:56:29 2002