On Wed, Mar 16, 2011 at 11:40 PM, Ron Wilson ronw.m...@gmail.com wrote:
I need to read up on ~/.fossil and _FOSSIL_ though to see if there's
any risk of accidental information leak when pushing/pulling. The
question is if the client key should be stored in the database, or if
it's safer to
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
In the Admin/Settings area via the web interface there is a data entry field
marked bin-glob. Enter a data like *.jar,*.zip,*.gif,*.jpg ... Fossil
actually does a good job of guessing binary data. I just like marking things
explicitly.
Fossil can support binary data but I don't there is a size
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
On Thu, Mar 17, 2011 at 2:46 AM, Jan Danielsson
jan.m.daniels...@gmail.com wrote:
On Wed, Mar 16, 2011 at 11:40 PM, Ron Wilson ronw.m...@gmail.com wrote:
Even the public certs. The public certs you use are your means for
authenticating who you trust. You want to be very careful accepting
them.
Hi,
Leading // are reduced to /, I consider this a bug as in that way it's not
possible
to access files sitting on a server, e.g
fossil open //server/repo.fossil
is not possible.
Also I'd REALLY like to extend the server acting on a directory full of
repos.
I'd like to be able to also handle
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
Hi,
I asked for this topic already a few weeks ago. I also have this problem
with opening a fossil repo on a file server. I'll be glad to see this
bug fixed in one of the next fossil binaries. Thanks in advance.
Christian
Am 17.03.2011 20:57, schrieb tr...@tekwissusa.com:
Hi,
Leading // are
On Thu, Mar 17, 2011 at 3:57 PM, tr...@tekwissusa.com wrote:
Leading // are reduced to /, I consider this a bug as in that way it's not
possible
to access files sitting on a server, e.g
fossil open //server/repo.fossil
is not possible.
Have you tried:
fossil open
14 matches
Mail list logo
