[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question about long commits

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Wed, 22 Jul 2009 22:09:52 +0200

On Wed, Jul 22, 2009 at 9:37 PM, David Weintraub<qazwart_at_gmail.com> wrote:
> On Wed, Jul 22, 2009 at 3:32 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>>
>> > What limitations are placed on the repository while the commit is in
>> > progress?
>>
>> None. There is a limitation placed on the commit though: if any item
>> the commit changes is also changed in the mean time, the commit may be
>> rejected with an "out-of-date" error.
>>
>
> I thought commits were serialized. Your commit has to wait for the previous
> commit to succeed or fail. At least if your commit contains the same file
> that a previous commit takes.

No better place than take it from the source (code):

  /* How do commits work in Subversion?
   *
   * When you're ready to commit, here's what you have:
   *
   * 1. A transaction, with a mutable tree hanging off it.
   * 2. A base revision, against which TXN_TREE was made.
   * 3. A latest revision, which may be newer than the base rev.
   *
   * The problem is that if latest != base, then one can't simply
   * attach the txn root as the root of the new revision, because that
   * would lose all the changes between base and latest. It is also
   * not acceptable to insist that base == latest; in a busy
   * repository, commits happen too fast to insist that everyone keep
   * their entire tree up-to-date at all times. Non-overlapping
   * changes should not interfere with each other.
   *
   * The solution is to merge the changes between base and latest into
   * the txn tree [see the function merge()]. The txn tree is the
   * only one of the three trees that is mutable, so it has to be the
   * one to adjust.
   *
   * You might have to adjust it more than once, if a new latest
   * revision gets committed while you were merging in the previous
   * one. For example:
   *
   * 1. Jane starts txn T, based at revision 6.
   * 2. Someone commits (or already committed) revision 7.
   * 3. Jane's starts merging the changes between 6 and 7 into T.
   * 4. Meanwhile, someone commits revision 8.
   * 5. Jane finishes the 6-->7 merge. T could now be committed
   * against a latest revision of 7, if only that were still the
   * latest. Unfortunately, 8 is now the latest, so...
   * 6. Jane starts merging the changes between 7 and 8 into T.
   * 7. Meanwhile, no one commits any new revisions. Whew.
   * 8. Jane commits T, creating revision 9, whose tree is exactly
   * T's tree, except immutable now.
   *
   * Lather, rinse, repeat.
   */

(found in our source tree:
subversion/libsvn_fs_fs/tree.c:svn_fs_fs__commit_txn())

HTH,

Erik.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374554

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 22:10:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.