On Fri, Mar 18, 2011 at 12:12 PM, John Found wrote:
> For me "least astonishment" means simply: If the file is changed by VCS,
> then later, VCS must knows about this fact and must take it into account.
> If the user changed the file by any other way (edit, copy paste, etc.) VCS
> should
> consid
On Fri, Mar 18, 2011 at 12:12 PM, John Found wrote:
> I have very little experience with any version control systems.
> For me "least astonishment" means simply: If the file is changed by VCS,
> then later, VCS must knows about this fact and must take it into account.
> If the user changed the fil
-- Original Message --
To: fossil-users@lists.fossil-scm.org (fossil-users@lists.fossil-scm.org)
From: Joshua Paine (jos...@letterblock.com)
Subject: Re: [fossil-users] Fossil omits the updates through "update"
command.
Date: 17.3.2011 18:59:54
>On Mar 17, 2011
Fossil update will 'move' your changes as well, if you have any. Revert
will just overwrite the file, and you will lose the changes.
I also agree that the difference between "fossil update" and "fossil
update files" is a bit confusing. But rather then removing the feature, I'd
just print an inf
What can you do with:
fossil update ?VERSION? FILES...
That you cannot do easily with?
fossil revert ?-r REVISION? ?FILE ...?
Or I am missing something or "fossil update files..." is redundant.
RR
2011/3/17 Joshua Paine :
> On Mar 17, 2011, at 11:00 AM, "johnfound" wrote:
>> On Thu, 17
On Mar 17, 2011, at 11:00 AM, "johnfound" wrote:
> On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov
> wrote:
>>
>> 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 doin
On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov
wrote:
> On Thu, 17 Mar 2011 15:05:13 +0200
> 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.
On Thu, 17 Mar 2011 15:05:13 +0200
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
> fac
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 contin
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
I am pretty sure it is a bug.
When you update some file using "update" command, 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 i
11 matches
Mail list logo