Greg Hudson <ghudson@MIT.EDU> writes:
> On Mon, 2005-03-28 at 10:07, Ben Collins-Sussman wrote:
> > Years ago, we deliberately decided that get_commit_editor() should
> > *not* create a txn. We felt it was overoptimization.
>
> I don't think "overoptimization" is a valid criticism. Creating a
> transaction in get_commit_editor() wouldn't be any faster.
>
> > we didn't like the ide aof empty transactions lying aroud (for
> > hours? days?) just because commit editors were fetched.
>
> Is that any different from them lying around just because commit editors
> were fetched and open_root was called? Either way, they will be cleaned
> up by abort_edit.
That depends on whether editor semantics imply that abort_edit() must
be called on all editors that get instantiated irrespective of whether
or not they were actually *driven*.
> > How about a different approach: why not just 'rev' the existing API?
> > Create svn_repos_get_commit_editor2(), and have it take an optional
> > pre-existing txn parameter? If the new parameter is NULL, then
> > open_root() will create a new txn. If the new parameter is non-NULL,
> > then open_root() will do nothing.
>
> I don't think that accomplishes what clkao needs. With his new API, he
> can specify NULL for the txn, and (a) receive a txn ID which he can use
> to set revision properties, and (b) know that he can abort the commit
> and then reuse the transaction later.
>
> With your suggestion, specifying NULL as the txn would not accomplish
> either of these things.
Right, with (what was actually) my suggestion, passing NULL would not
accomplish either of these things. That's ... the point (that makes
the code behave exactly as it does today). Clkao's code would instead
make his own txn, then pass that (non-NULL) txn to this commit editor.
The commit editor would recognize that it was provided a txn, that it
doesn't "own" that txn, and so would neither create a new txn, nor
destroy the one provided it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 28 20:12:39 2005