Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]

On 2006-01-16 00:38:31 +0000, Julian Foad wrote:
> "svn diff" is similar to part of the operation of "svn merge". If we
> extend "svn merge" in this way, we ought for consistency to extend "svn
> diff" in the same way. What exactly would it do? I see two possibilities:
>
> (a) Try to combine the given changes in the same way that "merge" does, and
> possibly report conflicts.
>
> (b) Output a sequence of independent diffs in turn; any conflicts among
> them will be found at "patch" or "svn merge" time.
>
> I suspect (b) would be more useful, but haven't thought deeply about it.

I also think that (b) would be more useful, as a conflict here is
not necessarily an error: the user may just want to look at the
differences, but not apply any patch.

More precisely, concerning "svn diff" and "svn merge", we would
not have a set of revisions, but a set of couples of revisions
(representing oriented intervals). Am I right? With "svn diff",
there could be an option to decide how the changes are combined:

  * The changes are fully combined; this would be (a), with a
    possible error.

  * The changes are combined in independent diffs, with a minimal
    set of patches.

  * There is a patch per change. In particular, this would allow to
    see the successive changes on one or several files (it would be
    a good complement to "svn blame").

-- 
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org