On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov
<flatw...@users.sourceforge.net> wrote:
> On Thu, 17 Mar 2011 15:05:13 +0200
> <johnfo...@evrocom.net> wrote:
> 
>> 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.
> 
> I think a typical DVCS finds common ancestor using whole check-ins and
> it appears that fossil is no different in this regard.  So if you did a
> local edit to your file and then committed this change, fossil simply
> does not record the fact your local edit resulted from [fossil update]
> and not from direct modification using a text editor or by some other
> means.
> 
> That is, my understanding is that it's check-ins (changesets) that are
> versioned, not files, and so it's the relations between check-ins which
> are considered when doing merges.

If so, then using "fossil update ?VERSION? ?FILES" syntax violate the
"Principle of least astonishment".
It looks like the file is updated by fossil (so fossil have to track this
update in the future),
but actually it later acts like the file is edited by the user...
So, this option would be better to be removed from the "update" command.
On the other hand I would like to have option to say to fossil not to
"copy" group of files from one
branch to another and not to try to merge.
_______________________________________________
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