You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@apache.org> on 2016/04/17 13:30:26 UTC
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
On 17.04.2016 18:54, Stefan Fuhrmann wrote:
> stsp wrote:
>
>> * STATUS: r1721285 nomination needs a backport branch
>
> This is what I get:
>
> $ svn --version
> svn, version 1.7.9 (r1462340)
> compiled Oct 15 2013, 12:40:34
> ...
>
> $ svn merge -c1721285 ^/subversion/trunk .
> --- Merging r1721285 into '.':
> U subversion/libsvn_fs_fs/caching.c
> --- Recording mergeinfo for merge of r1721285 into '.':
> U .
>
> Maybe a typo on your part?
Worksforme with 1.9.3 on the 1.9.x branch.
-- Brane
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
Posted by Branko Čibej <br...@apache.org>.
On 17.04.2016 14:20, Stefan Sperling wrote:
> On Sun, Apr 17, 2016 at 01:30:26PM +0200, Branko Čibej wrote:
>> On 17.04.2016 18:54, Stefan Fuhrmann wrote:
>>> stsp wrote:
>>>
>>>> * STATUS: r1721285 nomination needs a backport branch
>>> This is what I get:
>>>
>>> $ svn --version
>>> svn, version 1.7.9 (r1462340)
>>> compiled Oct 15 2013, 12:40:34
>>> ...
>>>
>>> $ svn merge -c1721285 ^/subversion/trunk .
>>> --- Merging r1721285 into '.':
>>> U subversion/libsvn_fs_fs/caching.c
>>> --- Recording mergeinfo for merge of r1721285 into '.':
>>> U .
>>>
>>> Maybe a typo on your part?
>>
>> Worksforme with 1.9.3 on the 1.9.x branch.
>>
>> -- Brane
> Funny. It works with 1.9.x indeed.
>
> Now try the same with a trunk client.
> Is this a regression? Or a new feature?
>
> $ svn merge -cr1721285 ^/subversion/trunk
> --- Merging r1721285 into '.':
> C subversion/libsvn_fs_fs/caching.c
> --- Recording mergeinfo for merge of r1721285 into '.':
> U .
> Summary of conflicts:
> Text conflicts: 1
> Conflict discovered in file 'subversion/libsvn_fs_fs/caching.c'.
> Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
> (mc) my side of conflict, (tc) their side of conflict,
> (s) show all options: q
> Summary of conflicts:
> Text conflicts: 1
> $ svn --version
> svn, version 1.10.0-dev (under development)
> compiled Apr 15 2016, 10:34:49 on x86_64-unknown-openbsd5.9
So what's the actual conflict? Paste it here, then we can decide if it's
a bug or a feature. :)
-- Brane
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Apr 21, 2016 at 10:57:34AM +0100, Philip Martin wrote:
> Stefan Sperling <st...@elego.de> writes:
>
> > Funny. It works with 1.9.x indeed.
> >
> > Now try the same with a trunk client.
> > Is this a regression? Or a new feature?
>
> This is caused by the deliberate change, r1739263, to the way our merge
> algorithm handles adjacent changes.
Thanks, that explains it.
BTW, it looks like some of the Ruby tests were relying on this behaviour
and are now failing:
https://ci.apache.org/builders/bb-openbsd/builds/363/steps/Test%20bindings/logs/testlog-swig-rb
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
Posted by Philip Martin <ph...@codematters.co.uk>.
Stefan Sperling <st...@elego.de> writes:
> Funny. It works with 1.9.x indeed.
>
> Now try the same with a trunk client.
> Is this a regression? Or a new feature?
This is caused by the deliberate change, r1739263, to the way our merge
algorithm handles adjacent changes.
2003 discussion about merging without a conflict:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=35014
2016 discussion about raising a conflict:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C87wppw3bgz.fsf_-_@wandisco.com%3E
A clean merge is "correct" in my example from 2003 and for this backport
proposal. In other cases a conflict is better see the user report that
lead to the r1739263 change:
https://mail-archives.apache.org/mod_mbox/subversion-users/201602.mbox/%3CBLUPR0601MB738480182C1642DE3B2EAA385A80@BLUPR0601MB738.namprd06.prod.outlook.com%3E
--
Philip
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
Posted by Stefan Fuhrmann <eq...@web.de>.
On 17.04.2016 14:20, Stefan Sperling wrote:
> On Sun, Apr 17, 2016 at 01:30:26PM +0200, Branko Čibej wrote:
>> On 17.04.2016 18:54, Stefan Fuhrmann wrote:
>>> stsp wrote:
>>>
>>>> * STATUS: r1721285 nomination needs a backport branch
>>>
>>> This is what I get:
>>>
>>> $ svn --version
>>> svn, version 1.7.9 (r1462340)
>>> compiled Oct 15 2013, 12:40:34
>>> ...
>>>
>>> $ svn merge -c1721285 ^/subversion/trunk .
>>> --- Merging r1721285 into '.':
>>> U subversion/libsvn_fs_fs/caching.c
>>> --- Recording mergeinfo for merge of r1721285 into '.':
>>> U .
>>>
>>> Maybe a typo on your part?
>>
>>
>> Worksforme with 1.9.3 on the 1.9.x branch.
>>
>> -- Brane
>
> Funny. It works with 1.9.x indeed.
>
> Now try the same with a trunk client.
> Is this a regression? Or a new feature?
>
> $ svn merge -cr1721285 ^/subversion/trunk
> --- Merging r1721285 into '.':
> C subversion/libsvn_fs_fs/caching.c
> --- Recording mergeinfo for merge of r1721285 into '.':
> U .
> Summary of conflicts:
> Text conflicts: 1
> Conflict discovered in file 'subversion/libsvn_fs_fs/caching.c'.
> Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
> (mc) my side of conflict, (tc) their side of conflict,
> (s) show all options: q
> Summary of conflicts:
> Text conflicts: 1
> $ svn --version
> svn, version 1.10.0-dev (under development)
> compiled Apr 15 2016, 10:34:49 on x86_64-unknown-openbsd5.9
>
I can confirm the problem with 1.10.0-dev.
It seems that the diff hunks contain an extra
line that causes the conflict:
@@ -430,7 +430,15 @@
svn_fs_fs__deserialize_dir_entries,
sizeof(pair_cache_key_t),
apr_pstrcat(pool, prefix, "DIR", SVN_VA_NULL),
+<<<<<<< .working
SVN_CACHE__MEMBUFFER_DEFAULT_PRIORITY,
+||||||| .merge-left.r1721284
+ SVN_CACHE__MEMBUFFER_DEFAULT_PRIORITY,
+ has_namespace,
+=======
+ SVN_CACHE__MEMBUFFER_HIGH_PRIORITY,
+ has_namespace,
+>>>>>>> .merge-right.r1721285
fs,
no_handler,
fs->pool, pool));
@@ -804,9 +812,17 @@
svn_fs_fs__serialize_dir_entries,
svn_fs_fs__deserialize_dir_entries,
APR_HASH_KEY_STRING,
+<<<<<<< .working
apr_pstrcat(pool, prefix, "TXNDIR",
SVN_VA_NULL),
0,
+||||||| .merge-left.r1721284
+ prefix,
+ 0,
+=======
+ prefix,
+ SVN_CACHE__MEMBUFFER_HIGH_PRIORITY,
+>>>>>>> .merge-right.r1721285
fs,
TRUE,
pool, pool));
-- Stefan^2.
Re: svn commit: r1739263 - /subversion/branches/1.9.x/STATUS
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Apr 17, 2016 at 01:30:26PM +0200, Branko Čibej wrote:
> On 17.04.2016 18:54, Stefan Fuhrmann wrote:
> > stsp wrote:
> >
> >> * STATUS: r1721285 nomination needs a backport branch
> >
> > This is what I get:
> >
> > $ svn --version
> > svn, version 1.7.9 (r1462340)
> > compiled Oct 15 2013, 12:40:34
> > ...
> >
> > $ svn merge -c1721285 ^/subversion/trunk .
> > --- Merging r1721285 into '.':
> > U subversion/libsvn_fs_fs/caching.c
> > --- Recording mergeinfo for merge of r1721285 into '.':
> > U .
> >
> > Maybe a typo on your part?
>
>
> Worksforme with 1.9.3 on the 1.9.x branch.
>
> -- Brane
Funny. It works with 1.9.x indeed.
Now try the same with a trunk client.
Is this a regression? Or a new feature?
$ svn merge -cr1721285 ^/subversion/trunk
--- Merging r1721285 into '.':
C subversion/libsvn_fs_fs/caching.c
--- Recording mergeinfo for merge of r1721285 into '.':
U .
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'subversion/libsvn_fs_fs/caching.c'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
(mc) my side of conflict, (tc) their side of conflict,
(s) show all options: q
Summary of conflicts:
Text conflicts: 1
$ svn --version
svn, version 1.10.0-dev (under development)
compiled Apr 15 2016, 10:34:49 on x86_64-unknown-openbsd5.9