Karl Fogel <kfogel@newton.ch.collab.net> writes:
> 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.
As I noted on the phone, currently this is not much of a loss since
the commit-trace editor uses absolute paths in its output (through no
fault of its own ... it's opened with an absolute root path). The one
argument I can think of for sticking with a URL output is for
consistency among commit-y things. Actions like 'svn mkdir REPOS_URL',
'svn delete REPOS_URL', 'svn mv REPOS_URL REPOS_URL' and
'svn cp REPOS_URL REPOS_URL' have no working copy to talk about at
all, so it seems weird to have some commit-y things show URLs and
some show working copy paths.
Hm...note the CVS commit output, showing *both* pieces of data...
Checking in .bbdb-data;
/usr/local/cvs/cmpilato/.bbdb-data,v <-- .bbdb-data
new revision: 1.25; previous revision: 1.24
> > 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...
Ooooh...I did so forget about this. Hm...this would mean the RA layer
wouldn't need a bump function at all...nice...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 19 18:27:24 2002