Re: [fossil-users] Merges, renames and shortest path.

[Lluís Batlle]

Hello Richard and friends,

I continue below this old thread, where I still had not found deeper
what was failing in our merges. Now I add more information.

2011/3/3 Richard Hipp d...@sqlite.org:
 2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
 Maybe the problem is in the handling of renames, then, and I mixed all
 with the
 'shortest-path' algorithm, which may have played no role. Sorry for this
 noise.

 So no wonder that with --baseline or without it, it behaves the same.
 test-find-pivot finds properly the ancestor, but I don't understand why
 it
 thinks there is no common ancestor for those files.

 There is an undocumented --debug option to merge that provides additional
 information about how the merge is trying to deal with name changes and
 whatnot.

I've hit again this problem in another merge. I've a leaf of a branch
made from trunk, that I did not merge from trunk since a long time.
Now I'm running fossil merge trunk there, and there are rename
problems.

Seeing that the merge code uses the find_name_changes, I've used the
test-name-changes and test-shortest-path to track down the problems
I'm finding.

The branch X where I am: Last commit: 2011-05-09. Last update from
trunk: 2011-03-03 (result of test-find-pivot).
Trunk: Last commit: 2011-05-23

In trunk, there are two commits, one child of the other:
e39dfeb63a1d (2011-04-29) child of
8d4432b6b9 (2011-05-02)

If I run test-name-changes e39dfeb63a1d trunk, I get no output.
If I run test-name-changes 8d4432b6b9 trunk, I get seven filename
changes. These changes *did not* happen in these commits mentioned.

And now for the shortest path, see the huge differences. Note that the
8d44 goes back to *January*, where there had happened some renames.

$ fossil test-shortest-path e39dfeb63a1d trunk
   1: e39dfeb63a1d 2011-05-02 08:07:48 is a parent of
   2: 64914698fe8f 2011-05-02 08:20:36 is a parent of
   3: b5d6bae30b30 2011-05-02 09:41:28 is a parent of
   4: 973d5fe26620 2011-05-02 10:57:27 is a parent of
   5: eb423f492c02 2011-05-02 13:53:06 is a parent of
   6: 990105642834 2011-05-04 08:23:28 is a parent of
   7: 3091adb58f30 2011-05-04 13:00:50 is a parent of
   8: 329bb13883b8 2011-05-05 08:44:17 is a parent of
   9: b42aec5d833f 2011-05-05 12:44:04 is a parent of
  10: 0efca45eb840 2011-05-05 13:10:56 is a child of
  11: b5cbbb485af5 2011-05-05 13:10:25 is a parent of
  12: 7f542fddedd9 2011-05-06 13:17:14 is a parent of
  13: a0185efc4806 2011-05-06 15:30:28 is a parent of
  14: 88ed563d9012 2011-05-09 13:39:58 is a parent of
  15: 66bafc70edeb 2011-05-16 08:58:46 is a parent of
  16: 833a1e8f8040 2011-05-16 10:25:35 is a parent of
  17: c922e75db613 2011-05-16 15:13:51 is a parent of
  18: 3016ba14a93a 2011-05-17 07:58:52 is a parent of
  19: 869d3bf69a6b 2011-05-17 10:07:39 is a parent of
  20: 9092b7884f8b 2011-05-17 13:18:05 is a parent of
  21: df749296cec0 2011-05-18 09:53:47 is a parent of
  22: 71cc67880028 2011-05-20 09:01:52 is a parent of
  23: 6adf9a899750 2011-05-20 14:07:42 is a parent of
  24: 4ecf25e9a372 2011-05-23 13:43:24 is a parent of
  25: 6c7803846985 2011-05-23 13:48:12 is a parent of
  26: f094c8032b79 2011-05-23 15:14:46

$ fossil test-shorest-path 8d4432b6b9 trunk
   1: 8d4432b6b920 2011-04-29 13:29:52 is a child of
   2: 3f8e8f1ad0cd 2011-04-29 12:59:37 is a child of
   3: 8b49bc80c2ca 2011-04-29 12:49:06 is a child of
   4: 81df7a7a981e 2011-04-29 10:35:08 is a child of
   5: b36179b7064b 2011-04-29 08:57:49 is a child of
   6: 29563ee1421c 2011-04-29 08:41:18 is a child of
   7: 50c3d39e6740 2011-04-29 08:26:28 is a parent of
   8: f494a26577c3 2011-04-29 09:41:15 is a child of
   9: 87b7e612b780 2011-04-12 09:55:30 is a child of
  10: 2eff6425fdaa 2011-03-30 10:16:58 is a child of
  11: 4e2fde4f6daa 2011-03-07 11:27:44 is a child of
  12: b1681a484058 2011-01-24 11:55:03 is a child of
  13: a642cc1d3533 2011-01-24 09:53:54 is a child of
  14: cc0d4a0911cf 2011-01-21 15:26:28 is a child of
  15: 8f39373df19c 2011-01-21 14:42:50 is a child of
  16: 4754938581cf 2011-01-21 11:26:14 is a parent of
  17: 5c5d328c2ff8 2011-01-21 14:34:09 is a parent of
  18: d9ab1f85c154 2011-01-21 15:00:00 is a parent of
  19: 88a8eb3f7dff 2011-01-21 15:27:21 is a parent of
  20: f4958b90f229 2011-01-21 16:46:21 is a parent of
  21: 0bae47c6456d 2011-02-15 10:38:12 is a parent of
  22: e13ccbeea9f0 2011-02-24 12:01:27 is a parent of
  23: 4ecf25e9a372 2011-05-23 13:43:24 is a parent of
  24: 6c7803846985 2011-05-23 13:48:12 is a parent of
  25: f094c8032b79 2011-05-23 15:14:46

Do you know how to get this solved?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Lluís Batlle]

Hello back,

just to add something to the letter I just sent with all the details,
at the first letter of this thread
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg03883.html

we mentioned this next proposal as a solution to the problem:
So we propose that, for the merge between two branches, it should be calculated
through the *shortest path* that (additional condition) goes through the
*common ancestor*.

We consider that wrong, because the shortest paths involved always
include P (P-V and P-M).

So, to propose a solution, I'd add the requirement (for the
merge/renames case) that the path should start from P to its child,
instead that allowing a path from P to the parent of P. And of course,
that path never going back to a parent of P. Somehow, forcing a
direction from P.

Did I express this clear enough? Please ask if it looks uncomprehensible.

Regards,
Lluís.

2011/5/24 Lluís Batlle virik...@gmail.com:
 Hello Richard and friends,
 In trunk, there are two commits, one child of the other:
 e39dfeb63a1d (2011-04-29) child of
 8d4432b6b9 (2011-05-02)

 If I run test-name-changes e39dfeb63a1d trunk, I get no output.
 If I run test-name-changes 8d4432b6b9 trunk, I get seven filename
 changes. These changes *did not* happen in these commits mentioned.

 Do you know how to get this solved?

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Richard Hipp]

2011/3/3 Lluís Batlle i Rossell virik...@gmail.com

 Hello,

 we had an issue merging with renames here. The 'test-shortest-path' takes
 what
 we think is a *WRONG* path for the merge to happen.

 We had two long-standing branches, that both were updated from trunk from
 time
 to time. One was merged into trunk only recently, altough it has been there
 for
 two months.

 We once did in branch A a fossil merge trunk at the end of
 January. We worked a lot in trunk after that. This gave the current common
 ancestor between A and trunk.

 Recently we did in branch B a fossil merge trunk, and then in trunk,
 fossil
 merge B.


 It came the day when whe decided to do, in branch A, refresh it from trunk:
 fossil merge trunk. Then it went wrong, because it found the
 shortest-path
 *THROUGH* branch A, that went to trunk and branch A back in mid december.
 We had
 little changes in A, and lots of changes in trunk. Through 'A' was the
 *shortest
 path*.

 So in this case, the shortest path (smallest number of commits) was not
 going
 through the common ancestor between A and trunk (of end of January), but
 through
 some common ancestor one month older.

 This could have worked, if the first merge of the end of January did not
 have
 any rename. It had renames, and due to this, the last merge attempt
 complained
 about this like this:
 WARNING - no common ancestor:  file1
 WARNING - no common ancestor:  file2
 WARNING - no common ancestor:  file3
 WARNING - no common ancestor:  file4
  


Can you use the --baseline option to merge to specify the common ancestor
checkin that you want the merge to use?





 So we propose that, for the merge between two branches, it should be
 calculated
 through the *shortest path* that (additional condition) goes through the
 *common ancestor*.

 What do you think?


 Here is how the test-shortest-path trunk A looks like:
   1: c844ce6d50e0 2011-03-03 14:14:51 is a child of  (trunk)
   2: a43678fc9ca0 2011-03-03 14:12:18 is a child of
   3: 828a14d063c4 2011-03-03 11:54:30 is a child of
   4: edb41e5c230b 2011-03-03 11:13:09 is a child of
   5: e1b7b9c9aabc 2011-03-03 09:48:33 is a child of
   6: 6426c87f9132 2011-02-24 08:22:45 is a child of
   7: 3ce0d541f673 2011-02-23 21:12:02 is a child of
   8: 99319ca24ef5 2011-02-23 15:15:59 is a child of
   9: deda6f59bdd4 2011-02-23 13:55:02 is a child of
  10: c0d55468828c 2011-02-23 10:29:18 is a child of
  11: b664b5b18bcd 2011-02-23 09:11:10 is a child of
  12: 241698eda20c 2011-02-23 09:06:37 is a child of
  13: d892a84a853b 2011-02-22 09:13:40 is a parent of
  14: 1d669cc444e7 2011-02-22 13:43:04 is a child of   (branch B)
  15: c788f28c5660 2010-12-22 15:09:28 is a child of
  16: 8ed57277e997 2010-12-22 13:20:11 is a child of
  17: 87c26be24920 2010-12-22 13:18:27 is a child of
  18: 6478caeac746 2010-12-22 10:03:02 is a child of
  19: 6a13f33daba8 2010-12-22 09:41:06 is a child of   (trunk again)
  20: b215075e199d 2010-12-21 15:03:20 is a parent of  (branch A)
  21: aa1588e4ffc3 2010-12-22 11:41:32 is a parent of
  22: 799ee1a58db1 2010-12-22 13:27:11 is a parent of
  23: 75a94cb02cd6 2010-12-22 15:11:03 is a parent of
  24: ed258cef647f 2010-12-22 16:20:38 is a parent of
  25: 0bcba8b051c6 2010-12-22 16:21:18 is a parent of
  26: e793f744c587 2010-12-23 09:18:59 is a parent of
  27: b1681a484058 2011-01-24 11:55:03

 The common ancestor between A and trunk dates from 2011-01-24, two hours
 earlier
 to the last element of the test-shortest-path above.
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Lluís Batlle i Rossell]

On Thu, Mar 03, 2011 at 10:39:11AM -0500, Richard Hipp wrote:
 2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
  This could have worked, if the first merge of the end of January did not
  have
  any rename. It had renames, and due to this, the last merge attempt
  complained
  about this like this:
  WARNING - no common ancestor:  file1
  WARNING - no common ancestor:  file2
  WARNING - no common ancestor:  file3
  WARNING - no common ancestor:  file4
   
 
 
 Can you use the --baseline option to merge to specify the common ancestor
 checkin that you want the merge to use?

It gives exactly the same behaviour as without it, if we set the --baseline to
the output of fossil test-find-pivot A trunk.

I always thought the merge used always the 'shortest path', instead of what the
description of --baseline says about: ... instead of the nearest common
ancestor.

Thank you,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Richard Hipp]

2011/3/3 Lluís Batlle i Rossell virik...@gmail.com

 On Thu, Mar 03, 2011 at 10:39:11AM -0500, Richard Hipp wrote:
  2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
   This could have worked, if the first merge of the end of January did
 not
   have
   any rename. It had renames, and due to this, the last merge attempt
   complained
   about this like this:
   WARNING - no common ancestor:  file1
   WARNING - no common ancestor:  file2
   WARNING - no common ancestor:  file3
   WARNING - no common ancestor:  file4

  
 
  Can you use the --baseline option to merge to specify the common
 ancestor
  checkin that you want the merge to use?

 It gives exactly the same behaviour as without it, if we set the --baseline
 to
 the output of fossil test-find-pivot A trunk.

 I always thought the merge used always the 'shortest path', instead of what
 the
 description of --baseline says about: ... instead of the nearest common
 ancestor.


Without --baseline, merge uses the nearest common ancestor, as determined by
the same algorithm used for test-find-pivot.  The test-find-pivot command is
(as its name suggests) a test procedure used to test and debug the algorithm
for finding the nearest common ancestor.

So you are saying that test-find-pivot is not finding the ancestor you think
it ought to be finding?



 Thank you,
 Lluís.




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Lluís Batlle i Rossell]

On Thu, Mar 03, 2011 at 10:57:06AM -0500, Richard Hipp wrote:
 2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
 
  On Thu, Mar 03, 2011 at 10:39:11AM -0500, Richard Hipp wrote:
   2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
This could have worked, if the first merge of the end of January did
  not
have
any rename. It had renames, and due to this, the last merge attempt
complained
about this like this:
WARNING - no common ancestor:  file1
WARNING - no common ancestor:  file2
WARNING - no common ancestor:  file3
WARNING - no common ancestor:  file4
 
   
 
 Without --baseline, merge uses the nearest common ancestor, as determined by
 the same algorithm used for test-find-pivot.  The test-find-pivot command is
 (as its name suggests) a test procedure used to test and debug the algorithm
 for finding the nearest common ancestor.
Ah, the test-shortest-path may be for the bisect. I mixed things.

 So you are saying that test-find-pivot is not finding the ancestor you think
 it ought to be finding?

Maybe the problem is in the handling of renames, then, and I mixed all with the
'shortest-path' algorithm, which may have played no role. Sorry for this noise.

So no wonder that with --baseline or without it, it behaves the same.
test-find-pivot finds properly the ancestor, but I don't understand why it
thinks there is no common ancestor for those files.


A   trunk
c4|   =  At this point we're running fossil merge trunk, saying those 
WARNINGS
|...   
| |
| |
c3|  = the rename got into the branch A through fossil merge trunk
\ |
|\|
| \__c3  = Common ancestor found by test-find-pivot
| |
| |
| |
|c2  = rename of files
\ |
 \|
  \   |
   \_c1

Do you see what may be going wronG?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Merges, renames and shortest path.

[Richard Hipp]

2011/3/3 Lluís Batlle i Rossell virik...@gmail.com

 On Thu, Mar 03, 2011 at 10:57:06AM -0500, Richard Hipp wrote:
  2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
 
   On Thu, Mar 03, 2011 at 10:39:11AM -0500, Richard Hipp wrote:
2011/3/3 Lluís Batlle i Rossell virik...@gmail.com
 This could have worked, if the first merge of the end of January
 did
   not
 have
 any rename. It had renames, and due to this, the last merge attempt
 complained
 about this like this:
 WARNING - no common ancestor:  file1
 WARNING - no common ancestor:  file2
 WARNING - no common ancestor:  file3
 WARNING - no common ancestor:  file4
  

 
  Without --baseline, merge uses the nearest common ancestor, as determined
 by
  the same algorithm used for test-find-pivot.  The test-find-pivot command
 is
  (as its name suggests) a test procedure used to test and debug the
 algorithm
  for finding the nearest common ancestor.
 Ah, the test-shortest-path may be for the bisect. I mixed things.

  So you are saying that test-find-pivot is not finding the ancestor you
 think
  it ought to be finding?

 Maybe the problem is in the handling of renames, then, and I mixed all with
 the
 'shortest-path' algorithm, which may have played no role. Sorry for this
 noise.

 So no wonder that with --baseline or without it, it behaves the same.
 test-find-pivot finds properly the ancestor, but I don't understand why
 it
 thinks there is no common ancestor for those files.


There is an undocumented --debug option to merge that provides additional
information about how the merge is trying to deal with name changes and
whatnot.





 A   trunk
 c4|   =  At this point we're running fossil merge trunk, saying
 those WARNINGS
 |...
 | |
 | |
 c3|  = the rename got into the branch A through fossil merge trunk
 \ |
 |\|
 | \__c3  = Common ancestor found by test-find-pivot
 | |
 | |
 | |
 |c2  = rename of files
 \ |
  \|
  \   |
   \_c1

 Do you see what may be going wronG?




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users