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

Re: Scalability issue with merges in busy projects

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Wed, 15 Jan 2014 16:48:13 +0100

On Wed, Jan 15, 2014 at 1:11 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> On Tue, Jan 14, 2014 at 11:00:12PM +0100, Stefan Fuhrmann wrote:
> > 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.
> >
> > Situation:
> >
> > * 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
> > etc.).
> > * The commit will still fail if there has been another
> > commit on the merge target while merge commit
> > was transmitted.
> >
> > Problem:
> >
> > As a result, the average time between commits to the
> > target branch limits the size of data you may merge
> > (and successfully commit).
> >
> > Solution:
> >
> > 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.
> I'm not sure I fully understand what you are proposing to do.

I should have been more explicit about the fact that "svn merge"
is the use-case but the actual implementation change is in the
FS layer. Brane has explained that now.

But whatever you do, please don't auto-merge deletions of already
> deleted items. Doing so prevents some tree conflicts from being detected,
> because it hides situations where an update would result in a 'delete vs.
> delete' conflict. (I believe Subversion <= 1.4 used to allow this.)

The wc state after the commit in wc_A is the same as in
the following sequence created with an older client

svn co $repos/dir wc_A

svn co $repos/dir wc_B
svn propset someprop "some value" wc_B
svn ci wc_B -m ""

svn up wc_A --depth=empty

I assumed that this will not create a problem with tree
conflict detection in a follow-up full "svn up wc_A".

> Similarly, I don't think we want to auto-merge if a directory is locally
> deleted and a newer version has property changes in the repository.
> Rather, we want the delete vs property change to conflict in the wc.

-- Stefan^2.
Received on 2014-01-15 16:48:44 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.