The problem is not because fossil doesn't track the individual files base
version, but 
because fossil fails to determine properly the nearest common ancestor of
the file.

In my example, after the update, the nearest common ancestor, in fact, is
[18a3dfdd], 
but when fossil makes merge, it continues to consider [0a5a95eb] as
nearest common ancestor. 

IMHO, that is why it fails to merge properly. On the other hand, when I
browse the file history, 
the graph is correct:
https://chiselapp.com/user/johnfound/repository/bad_update_test/finfo?name=A.txt
It means fossil knows the history of the file and still consider "nearest"
common 
ancestor to be the wrong file.

...or I still can't understand something? So, please explain then.

Regards


On Thu, 17 Mar 2011 07:56:35 -0400, Richard Hipp <d...@sqlite.org> wrote:
> On Thu, Mar 17, 2011 at 5:20 AM,  wrote:
> 
>  I am pretty sure it is a bug.
>  When you update some file using "update" command,
> By "update some file", I am guessing you mean that you did
> 
>     fossil update VERSION FILE1
> 
> Rather than just
> 
>      fossil update VERSION
> 
> If so, then you are right - the "base" version number is not changed
when
> you update individual files.  All that a file-update does is make edits
> to the file.  
> 
> I am not inclined to "fix" this.  If it is confusing, my preferred fix
> would be to take away the ability to "update" individual files.
> 
> Fossil could, in theory, be enhanced to keep track of the base version
> for individual files.  But that would be a rather large and complex
> change and would be difficult to test.  You can accomplish the same
> thing by doing a "commit" in between your file-update and your
additional
> merges.  Make it a "commit --private" if you don't want to share the
> intermediate results with the world.
> 
>   fossil does not account
>  this relation later, when it searches for the nearest common ancestor.
>  As a result, it counts the update as an "edit" and later fails to merge
>  the files properly.
>  This behavior is illustrated in the test repository here:
> 
https://chiselapp.com/user/johnfound/repository/bad_update_test/timeline
> [2]
>  It contains only one file "A.txt". Two branches, containing the test
>  ground - "trunk" and "Br2", and the branch "BadMergeResults" that
> contains
>  the conflicting files after the last "merge" attempt.
> 
>  Regards
> 
>  _______________________________________________
>  fossil-users mailing list
>  fossil-users@lists.fossil-scm.org [3]
>  http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> [4]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to