> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 14 maart 2014 15:17
> To: Bert Huijben
> Cc: Branko Čibej; Subversion Development
> Subject: Re: Mergeinfo overwritten from successive merges
> Bert Huijben <bert_at_qqmail.nl> writes:
> > The base revision for out of date checks could be different per
> > node... (E.g. Mixed revision working copies). At which revision we
> > open the transaction shouldn't really matter if we check the revision
> > for the individual nodes.
> > For content changes we supply the baseline rev for v2 via an
> > header... And my guess would be that we forgot to do that for the
> > proppatch.(v1 supplied base URL). Most tests in our test suite would
> > check for out of date via the root of the commit editor... So that
> > would explain things.
> The PROPPATCH looks like:
> PROPPATCH /obj/repo/!svn/txr/4-4/B HTTP/1.1\r
> Host: localhost:9630\r
> User-Agent: SVN/1.9.0-dev (x86_64-unknown-linux-gnu) serf/1.3.4\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/depth\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo\r
> DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops\r
> X-SVN-Version-Name: 3\r
> Transfer-Encoding: chunked\r
> <?xml version="1.0" encoding="utf-8"?><D:propertyupdate xmlns:D="DAV:"
> So we are sending X-SVN-Version-Name and in this case it does indicate
> that the resource is out-of-date as B was modified in r4.
> It seems that the do_out_of_date_check is not working properly:
> #0 do_out_of_date_check (comb=0x7faeaeb210b8, r=0x7faeaeb590a0)
> at ../src/subversion/mod_dav_svn/repos.c:1794
> 1794 if (comb->priv.version_name < created_rev)
> (gdb) p r->the_request
> $14 = 0x7faeaeb5a610 "PROPPATCH /obj/repo/!svn/txr/4-4/B HTTP/1.1"
> (gdb) p comb->priv.version_name
> $15 = 3
> (gdb) p created_rev
> $16 = -1
> SVN_INVALID_REVNUM is less than the baseline revision but the check
> makes no sense.
I haven't gotten to the full details yet, but...
The check would make sense for a 'checkout' that is required before any
change in a subtree, which is exactly what happens in http v1.
And it also works for leaves of the tree, BUT NOT for parent directories
when one of its descendants is already modified... which is what happens in
I added a python test for this issue in r1577739.
(Based on Brane's script, but using just one working copy)
Received on 2014-03-14 23:14:47 CET