Greg Stein <email@example.com> writes:
> These changes don't make sense... the close_edit() is the key factor here.
> You want to call close_edit() just once per operation. So if you have
> multiple roots, then you must use editor navigation rather than ROOT_PATH.
> $ svn commit some/dir another/dir
> $ svn update some/dir another/dir
> The repository URL corresponding to "." is passed when the session is
> opened. Then you fetch the appropriate editor (no root path!). Then navigate
> down to each of "some/dir" and "another/dir" and start the commit/update
> operation. When both are complete, then you call close_edit().
> With the model below, you would expect the client to call
> get_commit_editor() twice -- once with "some/dir" and once with
> "another/dir", but then you lose the atomicity of the commit operation
> implied by the single close_edit() call.
I know what you're worried about, but that's not the expectation, and
it's my fault for writing too simplistic a doc comment there. :)
In the case of
$ svn commit path1 path2 path3
The client needs to compute the, er...um... "nearest common ancestor
path" of all three paths. It first hands this parent dir to RA, and
gets back a commit_editor. Then it calls replace_root(). Then it
magically calls the local_mod_crawler three times as appropriate, each
invocation still driving the same commit editor. Finally, it calls
close_edit() at the very end.
If at any point the commit editor returned an error, then the whole
task bails. So we still get atomicity for committing N paths from the
The trick: I just haven't done all this yet. I have all the details
spelled out in a long comment at the very bottom of adm_crawler.c if
you want to look. :)
So, in summary: trust the client. It knows where to start a commit
from, and it knows to call replace_root() and close_edit() only once.
For milestone 2, we're just not going to allow multiple paths on the
Received on Sat Oct 21 14:36:17 2006