On Wed, Jan 15, 2014 at 1:11 PM, Stefan Sperling <[email protected]> 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.
