Alon Ziv wrote:
>This has already been hashed to death several times...
>
Obviously not, since we don't have a design doc -- which should be the
output of any such hashing-to-death. We don't even have a clear set of
requirements yet.
>What's needed is to add a list of file-level operations to be done before
>the diffs are applied.
>
Are you sure? Understand me, I'm not saying that's not so, but I'm not
at all sure myself. This _is_ a can of worms, and the worms have teeth.
>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.
>
Yikes. On Unix-like boxes, perhaps.
>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
>
I understand this is an example, but it's funcamentally wrong -- the
pre-diff operation should be "svn mv", not filesystem cp + rm. But never
mind.
>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).
>
"svn merge" solves that.
> For example, if I
>move a file out of the current directory, the 'diff' output will include its
>removal but not the new location;
>
The same problem exists in a merge of a subtree. The solution should be
the same, too.
> likewise, if a file is copied *into* the
>diff'd area, the diff _must_ include its complete contents.
>
_and_ history.
> FWIW, I don't
>believe any of those problems to be really hard. Just annoying :-)
>
Well, that can be said of most, if not all, problems in Subversion. :-)
>I'm tempted to go back to hacking this...
>
I'd much, much, _much_ rather see a long design discussion happen first.
Startimg with a clear statement of the requirements. Those could be
something along these lines:
1. "svn diff" + "svn patch" have the same effect as an equivalent
"svn merge". To wit, patching a tree with "svn diff" output should
be indistinguishable from merging from a "meta" branch that
contains the changes that generated the diff.
2. The enhanced "svn diff" output should be similar to "atandard"
diff output, should be at least as human readable, and plain
"patch" should be able to do something sane with it, for a
reasonable definition of "sane". Obviously ordinary "patch" can't
know about Subversion file renames and such.
3. The enhanced diff should not in any way depend on any feature of
any operating system/shell/whatever.
I'm offering these as an input to the discussion, not laying down the
law, of course.
--
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
Received on Wed Dec 11 12:23:59 2002