[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn diff, svn merge, and vendor branches (long)

From: Alon Ziv <alonz_at_nolaviz.org>
Date: 2002-12-11 11:54:26 CET

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

This is an archived mail posted to the Subversion Dev mailing list.