Re: [fossil-users] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Steve Stefanovich 
‎Don't know if related, but I've also got unexpected results when subsequently 
merging cherrypick merges:

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg21107.html‎

(I need to come up with reproducible fossil example like you, but perhaps the 
description of the problem as is can still point someone‎ in the right 
direction.)

From: Eric Rubin-Smith‎
Sent: Tuesday, 15 September 2015 01:38
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] merge after cherrypick plus edit does not identify GCA 
as I would like


See the transcript below for gory details.  The summary is:

1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so 
cherrypick it (assume in this example that other stuff is happening on the beta 
branch that we don't want in trunk at the moment, so a normal merge is not 
appropriate).
4. edit the same file on trunk and check it in
5. the "beta" branch now wants to merge the latest from trunk to continue work

==> It's noted as a merge conflict

This is because the GCA calculation does not seem to incorporate the cherrypick 
info (at least in this case).

Perhaps there is some deeper reason for this that I'm unaware of, but for this 
case the behavior is suboptimal.

Transcript illustrating the above:

eas@little:~$ fossil version
This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC
eas@little:~$ mkdir /tmp/fossil
eas@little:~$ cd !$
cd /tmp/fossil
eas@little:/tmp/fossil$ fossil new test.db
project-id: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
server-id:  ba2bb96bf830fa680389b425fa09c5dcfd5370c2
admin-user: eas (initial password is "dc73fc")
eas@little:/tmp/fossil$ mkdir sandbox
eas@little:/tmp/fossil$ cd !$
cd sandbox
eas@little:/tmp/fossil/sandbox$ fossil open /tmp/fossil/test.db
project-name: 
repository:   /tmp/fossil/test.db
local-root:   /tmp/fossil/sandbox/
config-db:/home/eas/.fossil
project-code: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
checkout: 6bb0b6577411bd798631d137bf5b2d7d8fc3ac12 2015-09-14 15:28:16 UTC
tags: trunk
comment:  initial empty check-in (user: eas)
check-ins:1
eas@little:/tmp/fossil/sandbox$ echo 1.0 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil add VERSION
ADDED  VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Add version file"
New_Version: b6f302b927b0289feae9831c80f8b066f6e87d70
eas@little:/tmp/fossil/sandbox$ echo 1.1 > h^CRSION
eas@little:/tmp/fossil/sandbox$ set -o vi
eas@little:/tmp/fossil/sandbox$ echo 1.1b1 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit --branch beta -m "Start beta 
branch."
New_Version: ac64ec791f7be8601848e4c50a87dc54262cc659
eas@little:/tmp/fossil/sandbox$ fossil update trunk
UPDATE VERSION
---
updated-to:   b6f302b927b0289feae9831c80f8b066f6e87d70 2015-09-14 15:28:52 UTC
tags: trunk
comment:  Add version file (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge --cherrypick 
ac64ec791f7be8601848e4c50a87dc54262cc659
UPDATE VERSION
 "fossil undo" is available to undo changes to the working checkout.

eas@little:/tmp/fossil/sandbox$
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Cherrypick version number 
change."
New_Version: 8a4693e6ce2faa5cf3cd1e5a839b33ba7c590d02
eas@little:/tmp/fossil/sandbox$ echo 1.1b1.01 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "More work on the trunk."
New_Version: cee15c31915298ecce84eb0b5aa9b7520e3c8b61
eas@little:/tmp/fossil/sandbox$ fossil update beta
UPDATE VERSION
---
updated-to:   ac64ec791f7be8601848e4c50a87dc54262cc659 2015-09-14 15:29:19 UTC
tags: beta
comment:  Start beta branch. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge trunk
MERGE VERSION
* 1 merge conflicts in VERSION
WARNING: 1 merge conflicts
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ cat VERSION
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
1.1b1
=== COMMON ANCESTOR content follows 
1.0
=== MERGED IN content follows ==
1.1b1.01
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
eas@little:/tmp/fossil/sandbox$ exit




___
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Eric Rubin-Smith 

> The merge algorithm does *not* consider cherry-picks.  It looks for
> the most recent common ancestor without taking cherry-picks into
> account.

Another popular version control tool whose name I won't mention (hint: rhymes 
with "zit") behaves identically to fossil in this scenario. Is there some 
deeper reason for not using the cherry pick "arrow", or is it simply that yall 
haven't had a need to improve the behavior here yet so haven't bothered?

> On the other hand, the merge algorithm will usually recognize when the
> same edit is applied twice, and do the right thing.
> -- 
> 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
___
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Richard Hipp 
On 9/15/15, Eric Rubin-Smith  wrote:
>
>> The merge algorithm does *not* consider cherry-picks.  It looks for
>> the most recent common ancestor without taking cherry-picks into
>> account.
>
> Another popular version control tool whose name I won't mention (hint:
> rhymes with "zit") behaves identically to fossil in this scenario. Is there
> some deeper reason for not using the cherry pick "arrow", or is it simply
> that yall haven't had a need to improve the behavior here yet so haven't
> bothered?
>

Merge is done by a classic 3-way diff.  It looks at all the changes
that occurred on the path from A to B and applies those same changes
to C.  (A in this case would be the most recent common ancestor of B
and C).

How would cherry-picks factor into this?

-- 
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Scott Doctor 


a sideways question on this topic. Assume in my C editor I run 
the code formatter operation which indents and parses certain 
tokens for cosmetic, but not functional, changes in the file. By 
parsing I mean operations such as adding/removing linefeeds 
before/after a token such as a bracket or semicolon, and 
removing/adding blanks lines and spaces.


Will the merge and diff operations see the file as completely 
changed?




Scott Doctor
sc...@scottdoctor.com
--

On 9/15/2015 5:13 AM, Richard Hipp wrote:

On 9/15/15, Eric Rubin-Smith  wrote:

The merge algorithm does *not* consider cherry-picks.  It looks for
the most recent common ancestor without taking cherry-picks into
account.

Another popular version control tool whose name I won't mention (hint:
rhymes with "zit") behaves identically to fossil in this scenario. Is there
some deeper reason for not using the cherry pick "arrow", or is it simply
that yall haven't had a need to improve the behavior here yet so haven't
bothered?


Merge is done by a classic 3-way diff.  It looks at all the changes
that occurred on the path from A to B and applies those same changes
to C.  (A in this case would be the most recent common ancestor of B
and C).

How would cherry-picks factor into this?



___
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Richard Hipp 
On 9/14/15, Eric Rubin-Smith  wrote:
> See the transcript below for gory details.  The summary is:
>
> 1. create a new file on trunk and check it in.
> 2. edit the file and check in on a branch (let's call it "beta")
> 3. trunk decides it wants that particular change set from step (2), so
> cherrypick it (assume in this example that other stuff is happening on the
> beta branch that we don't want in trunk at the moment, so a normal merge is
> not appropriate).
> 4. edit the same file on trunk and check it in
> 5. the "beta" branch now wants to merge the latest from trunk to continue
> work
>

The merge algorithm does *not* consider cherry-picks.  It looks for
the most recent common ancestor without taking cherry-picks into
account.

On the other hand, the merge algorithm will usually recognize when the
same edit is applied twice, and do the right thing.
-- 
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Eric Rubin-Smith 
> Merge is done by a classic 3-way diff.  It looks at all the changes
> that occurred on the path from A to B and applies those same changes
> to C.  (A in this case would be the most recent common ancestor of B
> and C).
>
> How would cherry-picks factor into this?
>

Sorry, maybe I'm confused.  I'm not at the moment talking about the 3-way
diff algorithm, but the step before that in which the GCA (your 'A') is
determined.  You said that the GCA calculation does not consider
cherry-pick merges.  I'm wondering whether there is a deep reason for that,
or if it's just because no one has yet had a need for it.

Perhaps it is because if cherry-picks are considered, then you'd have to
determine a GCA for every file rather than for the check-ins as a whole,
and you believe this will be too slow?  Or maybe there is some deeper
logical problem that I haven't considered.

In my initial example, if the cherry-picks were considered then the 'beta'
leaf would be the GCA for my test file, so the merge would be a trivial one
(simply take the current 'trunk' leaf as the new file data).

Eric
___
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] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-15 Thread Stephan Beal 
Fossil knows nothing about syntax of any sort, so a merge must consider any
change as significant. Try reindenting a python script, where whitespace is
part of the syntax. Diff can be told to ignore changes in spacing, iirc. If
you switch from unix EOL to Windows EOL fossil will see the whole file
(well, the EOL bytes) as changed.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
On Sep 15, 2015 2:24 PM, "Scott Doctor"  wrote:

>
> a sideways question on this topic. Assume in my C editor I run the code
> formatter operation which indents and parses certain tokens for cosmetic,
> but not functional, changes in the file. By parsing I mean operations such
> as adding/removing linefeeds before/after a token such as a bracket or
> semicolon, and removing/adding blanks lines and spaces.
>
> Will the merge and diff operations see the file as completely changed?
>
>
> 
> Scott Doctor
> sc...@scottdoctor.com
> --
>
> On 9/15/2015 5:13 AM, Richard Hipp wrote:
>
>> On 9/15/15, Eric Rubin-Smith  wrote:
>>
>>> The merge algorithm does *not* consider cherry-picks.  It looks for
 the most recent common ancestor without taking cherry-picks into
 account.

>>> Another popular version control tool whose name I won't mention (hint:
>>> rhymes with "zit") behaves identically to fossil in this scenario. Is
>>> there
>>> some deeper reason for not using the cherry pick "arrow", or is it simply
>>> that yall haven't had a need to improve the behavior here yet so haven't
>>> bothered?
>>>
>>> Merge is done by a classic 3-way diff.  It looks at all the changes
>> that occurred on the path from A to B and applies those same changes
>> to C.  (A in this case would be the most recent common ancestor of B
>> and C).
>>
>> How would cherry-picks factor into this?
>>
>>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] merge after cherrypick plus edit does not identify GCA as I would like

2015-09-14 Thread Eric Rubin-Smith 
See the transcript below for gory details.  The summary is:

1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so
cherrypick it (assume in this example that other stuff is happening on the
beta branch that we don't want in trunk at the moment, so a normal merge is
not appropriate).
4. edit the same file on trunk and check it in
5. the "beta" branch now wants to merge the latest from trunk to continue
work

==> It's noted as a merge conflict

This is because the GCA calculation does not seem to incorporate the
cherrypick info (at least in this case).

Perhaps there is some deeper reason for this that I'm unaware of, but for
this case the behavior is suboptimal.

Transcript illustrating the above:

eas@little:~$ fossil version
This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC
eas@little:~$ mkdir /tmp/fossil
eas@little:~$ cd !$
cd /tmp/fossil
eas@little:/tmp/fossil$ fossil new test.db
project-id: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
server-id:  ba2bb96bf830fa680389b425fa09c5dcfd5370c2
admin-user: eas (initial password is "dc73fc")
eas@little:/tmp/fossil$ mkdir sandbox
eas@little:/tmp/fossil$ cd !$
cd sandbox
eas@little:/tmp/fossil/sandbox$ fossil open /tmp/fossil/test.db
project-name: 
repository:   /tmp/fossil/test.db
local-root:   /tmp/fossil/sandbox/
config-db:/home/eas/.fossil
project-code: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
checkout: 6bb0b6577411bd798631d137bf5b2d7d8fc3ac12 2015-09-14 15:28:16
UTC
tags: trunk
comment:  initial empty check-in (user: eas)
check-ins:1
eas@little:/tmp/fossil/sandbox$ echo 1.0 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil add VERSION
ADDED  VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Add version file"
New_Version: b6f302b927b0289feae9831c80f8b066f6e87d70
eas@little:/tmp/fossil/sandbox$ echo 1.1 > h^CRSION
eas@little:/tmp/fossil/sandbox$ set -o vi
eas@little:/tmp/fossil/sandbox$ echo 1.1b1 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit --branch beta -m "Start beta
branch."
New_Version: ac64ec791f7be8601848e4c50a87dc54262cc659
eas@little:/tmp/fossil/sandbox$ fossil update trunk
UPDATE VERSION
---
updated-to:   b6f302b927b0289feae9831c80f8b066f6e87d70 2015-09-14 15:28:52
UTC
tags: trunk
comment:  Add version file (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge --cherrypick
ac64ec791f7be8601848e4c50a87dc54262cc659
UPDATE VERSION
 "fossil undo" is available to undo changes to the working checkout.

eas@little:/tmp/fossil/sandbox$
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Cherrypick version number
change."
New_Version: 8a4693e6ce2faa5cf3cd1e5a839b33ba7c590d02
eas@little:/tmp/fossil/sandbox$ echo 1.1b1.01 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "More work on the trunk."
New_Version: cee15c31915298ecce84eb0b5aa9b7520e3c8b61
eas@little:/tmp/fossil/sandbox$ fossil update beta
UPDATE VERSION
---
updated-to:   ac64ec791f7be8601848e4c50a87dc54262cc659 2015-09-14 15:29:19
UTC
tags: beta
comment:  Start beta branch. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge trunk
MERGE VERSION
* 1 merge conflicts in VERSION
WARNING: 1 merge conflicts
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ cat VERSION
<<< BEGIN MERGE CONFLICT: local copy shown first <<<
1.1b1
=== COMMON ANCESTOR content follows 
1.0
=== MERGED IN content follows ==
1.1b1.01
>>> END MERGE CONFLICT >
eas@little:/tmp/fossil/sandbox$ exit
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users