Philip Martin <philip@codematters.co.uk> writes:
> Originally, I introduced svn_client_revision_unspecified in
> svn_client_revision_type because svn_client_diff needs to know whether
> there was a -r on the command line. This is ugly. I now think that the
> svn_client_revision_type should not have this setting, unspecified
> revisions should be limited to the application.
>
> The function svn_client_diff should be split into three functions,
> svn_client_diff_text_base_to_wc with no revision parameters,
> svn_client_diff_repository_to_wc with one revision parameter, and
> svn_client_diff_repository_to_repository with two revision parameters,
> and svn_cl__diff should decide which one to call based on the number
> of revisions specified on the command line.
Mmmm. I think I'm going to keep that logic in libsvn_client. If
every client would have to implement it anyway, then we'd be making
more work for people; but also, I feel it's libsvn_client's job to
understand what things require contacting the repository and which
things can be done with the wc. The client itself shouldn't have to
know this stuff -- it should be as independent as it can from the
questions of wc vs repository.
I do understand your motivation, but keep in mind that this logic
would all have to be repeated again with merge. Let's make it all
happen at one place in libsvn_client, rather than force all clients to
go through the formalities.
> The advantage of doing this is that the client functions do not need
> to deal with unspecified revisions. It also solves the current diff
> problem, where if -DDATE1:DATE2 has two dates that resolve to the same
> revision then diff compares the revision against the wc which is
> wrong.
+1 I'll find some other way to solve this problem, yes.
> Next, svn_client_revision_commited and svn_client_revision_current
> (and svn_client_revision_previous if included) are a little tricky. I
> was assuming that svn_client__get_revision_number would extract the
> relevant revision from the entries file, and then that revision number
> would be used as if specified explicitly on the command line. When
> operating recursively this would mean that "current" referred to the
> directory and not to the elements within which may have different
> current revision numbers. Personally I would find this acceptable, but
> it would need to be made clear to the users.
Gotcha.
> The application should reject attempts to specify two revisions for
> commands that only accept one, 'svn -r1:2 up' should fail for example.
> It should probably also reject -rREV:REV a repeated revision.
+1
> The application currently initialises start_revision to
> SVN_INVALID_REVNUM and end_revision to 1. In the case of the log
> command I see no reason for the HEAD:1 default, HEAD:0 would be
> better.
Yup, will do.
Philip, thanks so much for all the thought you've been putting into
this, it's really helpful. Please review my [upcoming] commits if you
have time to.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006