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

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

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2006-01-18 14:11:45 CET

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
Received on Wed Jan 18 15:50:01 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.