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

Scalability issue with merges in busy projects

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 14 Jan 2014 23:00:12 +0100

Hi all,

We do have a "usage race" in SVN that I will commit
a fix to in a few minutes. This is mainly to document
the problem and maybe get feedback in case I over-
looked something.


* We track merges in properties at the top-level dir
  (usually the branch / trunk root). To commit a merge,
  the user must update to HEAD and then commit.
  TXNs based on older revs will be rejected by
  lib_repos/commit.c: change_dir_prop().
* Transmitting the merge result may take minutes in
  the case of a large merge (many files, large artwork
* The commit will still fail if there has been another
  commit on the merge target while merge commit
  was transmitted.


As a result, the average time between commits to the
target branch limits the size of data you may merge
(and successfully commit).


We can't do much about the first and second points
in the list above but wc updates after small commits
should be much faster. i.e. much less of a limitation.

The conflict handling in our commit code will be
extended such that simple bubble-up directory changes
merge cleanly with property changes on that directory.
We verify that the entries in the target directory are
still the same as in the txn base modulo some version
bumps. That way, the working copy will look like the
directory being up-to-date and some of the sub-dirs
being updated to an older revision.

-- Stefan^2.
Received on 2014-01-14 23:00:45 CET

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

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