On Fri, Mar 18, 2011 at 12:12 PM, John Found johnfo...@evrocom.net 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
-- 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, at 11:00 AM
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 in
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
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
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
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
On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote:
On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
That is, my understanding is that it's check-ins (changesets) that are
versioned, not files, and so it's the relations between
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 jos...@letterblock.com:
On Mar 17, 2011, at 11:00 AM, johnfound
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 info
10 matches
Mail list logo
