cmpilato@collab.net writes:
> The trace-commit editor is responsible for printing the path which is
> being committed, and a verb to go with it:
>
> Adding /home/cmpilato/tests/wc/boo
> Sending /home/cmpilato/tests/wc/bah
> ...
>
> Now, this particular editor could be switch to talk about repository
> URLs, instead. So instead of seeing absolute disk paths, you'd see:
>
> Adding http://servername.com/svn/cmpilato/boo
> Sending http://servername.com/svn/cmpilato/bah
> ...
>
> Alternatively, we could lose the trace-commit editor altogether and
> simply have a custom callback vtable that would take WC paths, and
> while those paths wouldn't necessarily be in depth-first order, they
> would still be present.
>
> Other ideas are welcome.
Personally prefer the current way. It conserves rightward space
enough so that one can usually fit the whole path on one line. If we
switched to URLs, many more lines would wrap past 80 cols.
> The commit-track editor is responsible for keeping track of what
> things changed as part of a commit so that revisions can be bumped to
> the new revision after the commit has succeeded. It lives inside the
> RA layer, and is composed with the commit editor.
>
> Now, I admit to not really understanding why this information has to
> be kept inside of the RA layer. That is, why couldn't the working
> copy just keep track of what it had committed, have the RA layer
> simply answer the question "What is the new revision?", and then the
> working copy bump its own revisions? But then again, I can't think of
> a good way for the RA layer to answer that question, either.
Doesn't the RA layer already answer this question, in the *NEW_REV
argument to ra_lib->get_commit_editor()?
svn_error_t *(*get_commit_editor) (void *session_baton,
const svn_delta_editor_t **editor,
void **edit_baton,
svn_revnum_t *new_rev,
const char **committed_date,
const char **committed_author,
svn_stringbuf_t *log_msg);
So after the commit, libsvn_client knows the new revision, and could
call pass it to some libsvn_wc post-commit function...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 19 17:57:03 2002