record_iter_changes and subtrees

[Jelmer Vernooij]

On Wed, Mar 25, 2009 at 12:45:51PM -0500, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Jelmer Vernooij wrote:
> > On Wed, Mar 25, 2009 at 10:55:41AM -0400, Aaron Bentley wrote:
> >>> Note that the commit in the child trees should be "pending", until the
> >>> top level commit finishes. (A 2-phase commit sort of action.)

> >> I think that's an additional requirement for foreign branches that may
> >> be unworkable.  Jelmer?

> > I understand the idea would be to have a two-phase commit, where the
> > first phase would already return the revision id, and the second phase
> > would finish the commit ?

> > If so, this would indeed be an issue for foreign branches, Subversion
> > in particular. it wouldn't work for Subversion, as we don't know the final
> > Subversion revnum until the commit is finalized, and that revnum is a
> > part of the returned revision id. 
> Except I think these are generating a bzr revision id that is getting
> put into the subversion revision property so that bzr-svn can then map
> the revision back into bzr transparently.
Yes, that would work, but *only* if we're committing a round-tripped
revision (we can also exclude any bzr-specific metadata) and if we
explicitly specified the revision id to the commit builder. 

> So while we wouldn't know the final number in SVN, we *would* know the
> revision in bzr.

> Going further, dpush would have to rewrite these anyway, and I think at
> that time it could know the revnum. I certainly thought it was possible
> to lock a repo so someone else won't change your revnum on you.
> Or stage it so the lock is taken out for a short time, but if the number
> changes when you don't expect, then you abort and start over again.
No, there is no way to lock the repository or be able to predict the
revnum of your commit other than making every commit change the
repository root. The only locks that Subversion supports are on files,
and there are transacations for commits (if two people open a commit
on /trunk then one will succeed and the next will get a OutOfDate
error).

> I'm not stuck that it has to be done as 2-phase-commit. It just seems
> like the "right" way. Aaron is arguing that it isn't the "right" way at
> all, because it gets complex for error handling, etc.

> I believe I disagree on what the "ideal" would be, versus what just
> happens to be the current implementation. I'm fine if 'bzr commit' does
> a recursive non-2-phase commit right now, but it seems like it would be
> nice if it *could* do a 2-phase commit. It feels like Aaron doesn't
> think that is a goal. Which is why we have this debate.

Would it be possible for a CommitBuilder to indicate 
"sorry, I don't do 2-phase commits", in which case bzr could fall back
to the current implementation, and use 2-phase otherwise?

Cheers,

Jelmer