record_iter_changes and subtrees

[John Arbash Meinel]

-----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. 
> 
> Cheers,
> 
> Jelmer
> 

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.

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.

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.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknKbc4ACgkQJdeBCYSNAAOIowCfXAy5cdhT7YR90ag54hP9VYW7
flwAn2rbQQ3t/b4L0Hvr5t4ovt5htmx+
=vKeC
-----END PGP SIGNATURE-----