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