On Thu, Mar 17, 2011 at 5:20 AM, <johnfo...@evrocom.net> 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
> 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
> 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
