From: "Branko Čibej" <brane@xbc.nu>
> >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.
>
I do recall several threads about this... Most starring Tom Lord :-)
> >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.
>
I'm not sure this is all that is needed, but it's a good start.
And, _assuming_ we are going to use properties for merge-related metadata,
this should also be able to capture history.
> >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.
>
Right, on Unix-like boxes. And 'svn patch' will always be able to read it,
even on non-Unixes.
I like the idea of having a 'shell-compatible' format, as it can be parsed
by non-svn-users without any additional tool (it is borrowed, mostly, from
Perl's "makepatch" tool). Iif we go a different route, the format has to be
simple enough so someone can write a parser for it which is not svn (for
interoperability with other VC tools).
> >Example output will look like:
> >
...
> >
>
> 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.
>
I'm assuming only the current metadata, and we don't have intrinsic 'move'
right now... And consistently guessing the real meaning is beyond any tool.
> > likewise, if a file is copied *into* the
> >diff'd area, the diff _must_ include its complete contents.
> >
> _and_ history.
>
Hmm... Yes, OK. (This allows e.g. to have a branch-merge as an 'external'
patch).
> >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 "standard"
> 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.
Maybe we should make sure a patch that requires moving files _will_ break
ordinary 'patch'?
> 3. The enhanced diff should not in any way depend on any feature of
> any operating system/shell/whatever.
Sure.
(By the way, what happened to the internal 'diff' library? Using it should
make custom-diff formatting much easier, I believe...)
-az
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 11 14:43:48 2002