On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
And a fork that ends in being merged is also no longer a fork.
I disagree. While it might be the most common case, merging does not
explicitly state any
On Fri, Apr 17, 2015 at 01:07:50PM +0200, Jan Nijtmans wrote:
2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger jo...@britannica.bec.de:
On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org
...
I disagree. While it might
On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
Forks add little value but have a potentially high cost because they can be
so confusing when they happen.
I completely disagree on this. Forks add a lot of value and getting
complains for every single action would be extremely
On Wed, Apr 08, 2015 at 06:55:17AM -0400, Martin Gagnon wrote:
Sometimes, Fork are inevitable. User should understand the concept of a
distributed SCM. Fossil have a nice timeline graph that will show you
the FORK clearly.
Also: fossil leaves --bybranch
Joerg
On Sun, Apr 05, 2015 at 02:59:27PM -0700, Matt Welland wrote:
I understand (mostly) why git
doesn't have this problem, it makes no pretense about being centralized and
it doesn't allow the fork to happen by blocking the push that is behind
the tip. How do the other DSCM systems handle this
On Sun, Apr 05, 2015 at 01:56:06PM -0700, Matt Welland wrote:
On Sun, Apr 5, 2015 at 12:48 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
The auto fork merge is the same as the automatic merge that one of the
fork
On Sun, Apr 05, 2015 at 12:39:28PM -0700, Matt Welland wrote:
The auto fork merge is the same as the automatic merge that one of the fork
creators would have experienced if they had done their commit a few minutes
later. They would have gotten a fossil would fork message, done fossil
update
On Thu, Mar 19, 2015 at 06:22:52PM -0600, Scott Robison wrote:
I can't answer for Abilio, but given my recent increased experience with
git due to workplace changes: the git folk seem to prefer the staging area
because you're less likely to accidentally commit something you didn't mean
to.
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length: 1516
So the question becomes: Should the Content-Length be the length of
the content before or after compression?
Before aka
On Thu, Mar 19, 2015 at 12:56:02PM -0400, Ron W wrote:
I think there is some confusion of Content-Encoding vs Transfer-Encoding
Content-Encoding is gzip, Transfer-Encoding should be unset as Fossil
doesn't do HTTP/1.1 Chunked Transfers.
Joerg
___
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length
On Mon, Mar 16, 2015 at 11:01:21PM +0100, mario wrote:
Social network is a nice metaphor. But it's also just a side-effect
of having a data silo.
Actually, I think that's the far bigger item. GitHub has managed
something which SourceForge never had -- a stable service.
Most developer
On Fri, Mar 13, 2015 at 01:50:19PM -0600, Warren Young wrote:
The thing about most other large projects is that they do not have this
highly-distributed hierarchical contribution model. You’re either one
of the trusted few with a commit bit, or you are not.
Actually, I think it is the other
On Wed, Mar 11, 2015 at 01:53:36AM -0500, Andy Goth wrote:
On 3/11/2015 12:15 AM, jungle Boogie wrote:
I created a test repo with a few commits:
The commit of the 100 MB files took about 300 seconds but this ran on
a single core 512MB-1gig RAM machine.
I know this is unscientific
On Tue, Mar 10, 2015 at 04:52:05PM -0400, Ron W wrote:
I suspect the main reason was the problem with large files, whatever his
threshold for large is. Not a limit I've run into, yet.
Unless large files means larger than 2GB, I don't believe there is
one. I haven't run into a case where I
On Tue, Mar 10, 2015 at 06:14:10PM -0400, Ron W wrote:
On Tue, Mar 10, 2015 at 5:54 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Unless large files means larger than 2GB, I don't believe there is
one. I haven't run into a case where I wanted to use version control
systems
On Mon, Mar 02, 2015 at 07:30:44AM -0500, Richard Hipp wrote:
So I was thinking, could Fossil 2.0 be enhanced in ways to support
scaling to the point where it works on really massive projects?
I think the single biggest practical issue right now still goes back to
the baseline manifests not
On Mon, Mar 02, 2015 at 11:38:38AM -0500, Richard Hipp wrote:
On 3/2/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Mon, Mar 02, 2015 at 07:30:44AM -0500, Richard Hipp wrote:
So I was thinking, could Fossil 2.0 be enhanced in ways to support
scaling to the point where it works
On Wed, Feb 25, 2015 at 11:13:22PM +0300, Sergei Gavrikov wrote:
If we all were paleontologists, we could use the names of fossil animals
for significant milestones of Fossil SCM
What fossil are of interested other than Trilobites?!
Joerg
___
On Wed, Feb 11, 2015 at 09:39:06AM +0100, Gour wrote:
which is very strange considering that on the remote server the Fossil
binary is in $HOME/bin which is in my $PATH.
Non-interactive ssh doesn't process .profile, only the PATH list in
ssh_config.
Joerg
On Tue, Feb 10, 2015 at 06:38:02PM -0800, bch wrote:
For the record, what Mr Beal is talking about is called a scheme
relative URI -- which I know about since an HTTP parser I work with
handles them so poorly. However, if your browser works w/ (eg)
Wikipedia, you are already using
On Tue, Feb 03, 2015 at 01:48:52PM +0100, Jan Danielsson wrote:
In terms of the type of data, our data and fossil's data is very
different, but in terms of the time it takes to synchronize large data
stores/repositories, we're in the exact same situation. We don't expect
synchronizations
On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote:
On Feb 1, 2015, at 7:08 AM, Jan Danielsson jan.m.daniels...@gmail.com
wrote:
The annoying thing is that when it fails, it wipes away whatever
progress it has made.
Yes, well, that’s the nature of transactional DB
On Mon, Feb 02, 2015 at 03:35:13PM -0700, Warren Young wrote:
On Feb 2, 2015, at 3:28 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote:
Are you seriously asking for Fossil to allow a local clone
On Sun, Jan 25, 2015 at 12:11:53PM +0100, Michai Ramakers wrote:
On 25 January 2015 at 00:09, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Sat, Jan 24, 2015 at 04:57:17PM -0500, Richard Hipp wrote:
But another problem emerged during testing. It seems that Michai's
machine
On Sat, Jan 24, 2015 at 04:57:17PM -0500, Richard Hipp wrote:
But another problem emerged during testing. It seems that Michai's
machine is not accepting the certificate on
https://www.fossil-scm.org/. It is giving me an error:
Does it work with sqlite.org? If yes, the problem is likely a
On Sat, Jan 24, 2015 at 04:27:55PM -0500, Richard Hipp wrote:
On 1/24/15, Andy Bradford amb-fos...@bradfords.org wrote:
Should Fossil have such a
selection mechanism in an option that indicates whether IPv6 should be
preferred, with the default falling to IPv4?
I would hope that
On Tue, Jan 13, 2015 at 10:46:27PM +, Kelly Dean wrote:
When you're committing new files to a local repository, obviously you
do have both the current data (in the repository) and the new files
that you need to ensure don't collide with the current data. In this
case, comparing by content
On Tue, Jan 13, 2015 at 11:32:21AM -0500, Ron W wrote:
On Tue, Jan 13, 2015 at 5:21 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
The much more interesting case is
getting wrong data send from a 3rd party matching an existing (signed)
manifest. Comparing content is not an option
On Tue, Jan 13, 2015 at 01:46:05AM +, Kelly Dean wrote:
If you have files foo and bar with different content but the same hash
(i.e. there's a hash collision), and you commit foo, then bar, and
dedup by hash (which Fossil does, just like Git), then do a checkout
and try to verify by
On Mon, Jan 12, 2015 at 12:43:28PM +0100, Stephan Beal wrote:
However, Fossil puts both filenames (which are content), and the indicator
of whether delta compression is used, in the same structure, and changes
that structure depending on whether delta compression is used, and the hash
of
On Mon, Jan 12, 2015 at 11:24:58AM +, Kelly Dean wrote:
Git does compare-by-hash. This is a mistake, because Valerie Hansen
said so. It seems Fossil makes the same mistake.
I have no idea who Valerie Hansen is or why I should care about him.
Comparing by content is generally not an option
On Mon, Jan 12, 2015 at 11:24:13AM +, Kelly Dean wrote:
That makes no sense. To avoid common-mode failures in the
implementation, you just need a different implementation.
You don't need a different algorithm.
It is easier to pick a different algorithm than to find another (unique)
On Mon, Jan 12, 2015 at 11:32:57AM -0500, Ron W wrote:
BTW, FYI, SHA1 and SHA2 are, as of recently, also considered insecure.
I'm not aware of any attacks against SHA2, just general concerns that it
is too similar to SHA1.
Joerg
___
fossil-users
On Thu, Jan 08, 2015 at 07:13:17PM -0500, Ron W wrote:
Does the check-out DB record the mtime and size of the files in the
check-out? If so, you have at least some defence against false negatives.
It does and to go back to the slow update, it will truncate that table
and populate it from
On Thu, Jan 08, 2015 at 07:29:53PM +0100, Stephan Beal wrote:
The number of files is the primary factor, if i'm not sorely mistaken.
Correct, but not in the way you expect :) For day to day operation, the
most annoying part is fossil update, which rewrites the mtime table
completely. If you have
On Mon, Jan 05, 2015 at 09:31:00AM -0800, Christopher M. Fuhrman wrote:
On Mon, 5 Jan 2015 at 9:19am, Jungle Boogie wrote:
Dear Christopher,
From: Christopher M. Fuhrman cfuhr...@pobox.com
Sent: Mon, 5 Jan 2015 08:20:10 -0800 (PST)
To:
On Wed, Dec 31, 2014 at 04:40:11PM -0800, bch wrote:
I've been pulling down huge batches of changes in NetBSDs pkgsrc repo
lately (as Q4 freeze/branch occurs (Round-trips: 300 Artifacts sent:
0 received: 62286)), and the current stats for that repo are:
That's somewhat of a side issue with
On Tue, Dec 23, 2014 at 03:15:41PM +0200, Baruch Burstein wrote:
I just discovered that the JS I used is not supported in IE=9. What is the
policy on supporting older browsers?
I would normally draw the line at IE 8. Depending on the specific code,
IE 7 can be reasonable, older normally is not.
On Fri, Oct 31, 2014 at 03:08:25PM -0700, E. Timothy Uy wrote:
$ fossil export --git ../../../sqlite.fossil | git fast-import
fatal: mark :60713 not declared
I bet that is one of the timewarps. Those are currently not handled in a
way git agrees with...
Joerg
On Mon, Nov 03, 2014 at 08:41:24PM +0100, Stephan Beal wrote:
In short, provide it a list of branch names and it returns the tip (most
recent) version in each of those branches:
There is a table for the leaves, which likely is quitea bit faster.
Joerg
On Fri, Oct 17, 2014 at 08:10:10PM +0200, Jan Danielsson wrote:
On 17/10/14 20:01, Jan Danielsson wrote:
[.. -wal -shm remain after ctrl-c:ing out of fossil ui ..]
A quick grep through the source leads me to believe that there is no
registered signal handler to handle SIGINT apart from
On Tue, Sep 02, 2014 at 12:08:22PM -0600, Warren Young wrote:
On 9/2/2014 09:00, Dömötör Gulyás wrote:
This is the main issue I have: git does not follow the principle of
least surprise. I'm sure it *can* do everything, if you know all of
the switches and gotchas. But you don't, even if you
On Tue, Sep 02, 2014 at 02:45:13PM -0600, Warren Young wrote:
Fossil currently wants to do a cryptographically strong checksum on
every version of every graphic file I've ever created on every
checkin. Consequently, a checkin takes several seconds here.
There was a recent proposal that you
On Sat, Aug 09, 2014 at 09:46:37AM +, org.fossil-scm.fossil-us...@io7m.com
wrote:
If you open too many ssh connections in too short a time, they'll
throttle and close connections.
Have you tried using Master mode? Try running:
ssh -v -MN -o ControlPath=/tmp/socket remote
and in a
On Sat, Aug 09, 2014 at 10:45:14AM +, org.fossil-scm.fossil-us...@io7m.com
wrote:
I've not used master mode before. From what I can make out from the
ssh_config manual page, this causes ssh to open a single long-running
connection to the server which is re-used by anything connecting to
On Tue, Jul 29, 2014 at 07:37:24PM +0200, Stephan Beal wrote:
i'm looking for a simple, shell-scriptable way to get the tip version uuid
from a checkout. Currently i've got this beast:
fossil descendants?
Joerg
___
fossil-users mailing list
On Sat, Jul 05, 2014 at 10:19:54AM -0700, Matt Welland wrote:
I'd like to automate a clone but I think I'd prefer the password not be in
the URL. The concern is that the password in the URL might be visible in
the webserver logs.
Passwords are not passed in the request via URL, but as part of
On Wed, Apr 23, 2014 at 09:12:28AM -0700, Andreas Kupries wrote:
I am wondering if the rebuild will also redo the cluster artifacts.
No, but it does rebuild the phantom table, a.k.a. the missing artifacts.
Joerg
___
fossil-users mailing list
On Thu, Apr 17, 2014 at 10:12:44AM -0500, Rich Neswold wrote:
The first few times that my pulls failed, there was no obvious
change to the timeline so I assumed none of the data was being saved.
After the last timeout, however, there were some new entries from the
NetBSD project. So maybe new
On Thu, Apr 17, 2014 at 11:13:38AM -0400, Richard Hipp wrote:
Would this really require a big change? Seems like about all you have to
do is COMMIT after each round-trip to the server, rather than waiting to
COMMIT at the very end. Or, just COMMIT instead of ROLLBACK after getting
a server
On Wed, Apr 16, 2014 at 06:26:49PM +0200, Stephan Beal wrote:
Ah, right - i didn't think that through to the next step. That does indeed
sound like it would be an improvement. This weekend is a four-day one for
us in southern Germany (for Easter), so i'll see if i can tinker with this
if
On Tue, Apr 01, 2014 at 10:24:44PM -0500, Andy Goth wrote:
The attached script imports an RCS repository into Fossil. It
doesn't support branching nor symbolic names, and it has a few
peculiarities designed to accommodate the RCS repository I just
processed.
You might consider
On Wed, Mar 26, 2014 at 01:36:46PM +0200, Baruch Burstein wrote:
Out of curiosity, in the tcl repository I found 2 8-long collisions. I
don't have anything bigger to test. This is what I used:
select substr(uuid, 1, 8) a, count(*) b from blob group by a having b1
order by b;
By that test, I
On Fri, Feb 07, 2014 at 05:17:23PM +0100, Stephan Beal wrote:
i'd be interested in seeing the output of 'dbstat' on your repo, except
that it could take some time for it to finish generating its output (so
don't feel obligated to try it). Here's the info for the current fossil
core repo:
On Sat, Dec 21, 2013 at 09:21:25PM +, David Given wrote:
I have found a rather unpleasant-looking bug where if a file's content
changes too quickly, and its size does not change, it's not considered
to have changed. It smells as if Fossil is using a combination of the
file length and
On Sat, Dec 21, 2013 at 09:34:45PM +, David Given wrote:
On 21/12/13 21:24, Joerg Sonnenberger wrote:
[...]
Yes, it certainly uses mtime by default to skip the much more expensive
hashing step. You can disable that from the settings.
You mean it's *supposed* not to do the SHA1 hash
On Mon, Sep 02, 2013 at 06:36:42PM +0200, Stephan Beal wrote:
i'm looking to prioritize some work on libfossil and i got the idea to try
to find out which commands people use most often, and use that to help me
prioritize.
Recursive add and revert would be the biggest item :)
Joerg
On Thu, Aug 29, 2013 at 04:50:19PM -0400, Richard Hipp wrote:
The database corruption was caused by scenario 1.1 at
http://www.sqlite.org/howtocorrupt.html.
Apparently, file descriptor 2 was closed.
The question for me would be why. That should not happen and any code
should at most re-open
On Thu, Aug 22, 2013 at 06:41:58AM +0300, Ron Aaron wrote:
So I tried to find a way to discern whether or not a repo was *really*
different, and I hit upon the following. I think it would be nice if
there were an easier way.
echo 'select uuid from blob order by blob' | fossil sqlite | fossil
On Sun, Aug 18, 2013 at 01:59:14PM +0200, Stephan Beal wrote:
i don't yet understand the benefit of a delta manifest except that they
save a few hundred (or thousand) lines of F-cards.
Exactly. This sums up a lot if you look at something like
http://pkgsrc.sonnenberger.org. You can fetch a copy
Hi all,
in case someone has time to fix this, let me write up the most annoying
performance issue for larger repositories. When running fossil update,
it will rewrite vfile table in .fslckout from scratch, even though most
entries should not change on merges. If the working copy contains a few
On Tue, Jul 16, 2013 at 08:46:06AM -0400, Richard Hipp wrote:
On Tue, Jul 16, 2013 at 8:37 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Hi all,
in case someone has time to fix this, let me write up the most annoying
performance issue for larger repositories. When running fossil
On Tue, Jul 16, 2013 at 03:17:10PM +0200, Stephan Beal wrote:
On Tue, Jul 16, 2013 at 2:51 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Just a matter of scale :) Essentially, the problem is that t(fossil
update) = O(files in the working copy), when it should be O(files
changed
On Mon, Jul 01, 2013 at 12:08:42AM +0200, Isaac Jurado wrote:
After the results, the conclusion is obvious: the generic artifact delta
compression is outperforming the delta manifest convention.
So the question is, what is the rationale behind delta manifests? After
checking Fossil's
On Mon, Jul 01, 2013 at 05:18:40PM +0200, Isaac Jurado wrote:
On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger
Delta manifests are not meant to reduce the repository size, but the
amount of parsing to be done.
That sounds intriguing. What kind of operations can complete without
having
On Mon, Jun 17, 2013 at 04:40:09PM +0200, Michai Ramakers wrote:
On 17 June 2013 15:36, Richard Hipp d...@sqlite.org wrote:
checksum mismatch on artifact 15: wanted
91058d6d3dd1df16e04942a59bc970c7bcc04b61 but got
da39a3ee5e6b4b0d3255bfef95601890afd80709
That's an empty artifact.
Joerg
On Fri, Mar 08, 2013 at 09:09:56AM -0500, Martin Gagnon wrote:
I know someone recently test with the NetBSD port tree, but port tree is a
bit less realistic since it contain a incredible huge number of small files
with an incredible number of commits.
http://netbsd.sonnenberger.org
On Tue, Feb 05, 2013 at 04:47:37PM +, David Given wrote:
(Could someone explain the relationship between rids and UUIDs?)
rids are the integer primary keys of the blob table. UUIDs are the
global persistent unique key of the same table. UUIDs stay the same
across repositories, rids depend on
On Wed, Jan 30, 2013 at 01:33:24PM -0500, Richard Hipp wrote:
For example, OpenSSL seems to not support static linking.
OpenSSL only needs dynamic linkage for additional engines, e.g. to
interact with hardware acceleration devices. Otherwise it is perfectly
fine to statically link it.
Joerg
On Thu, Jan 31, 2013 at 10:02:59PM +, K. Fossil user wrote:
in another word it is not possible to link staticly...
For little project, no hardware acceleration devices does not hurt.
But, for projects that need secure connections with numerous users, it will
be crucial.
Let imagine
On Thu, Jan 31, 2013 at 08:34:13PM +, K. Fossil user wrote:
Can't we use GnuTLS instead of openSSL ?
Wget decided to use GnuTLS instead of openSSL...
The only real improvement GNU TLS provides over OpenSSL is GPL
compatibility for Linux distributions. Otherwise it is just as messy as
On Wed, Jan 30, 2013 at 11:10:46AM +0100, Jan Nijtmans wrote:
and encountered 2 minor problems on Linux:
- strcmp from the static C library cannot be used, it should be
replaced by fossil_strcmp everywhere. (that's a good idea
anyway, as strcmp is locale-dependant)
No, it isn't. That's
On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
The regular expression matching in
www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it
supports | and it is usually as fast or faster than grep in my tests
(though there are some cases for which grep is
On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
The regular expression matching in
www.fossil-scm.org/fossil/artifact
On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote:
On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
jo
On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote:
this would not prevent,
that people run into the exponential run time problem when using the
naive pattern instead the anchored one, but this could be
explained by a FAQ entry making
the problem practically irrelevant. or do I
On Wed, Jan 16, 2013 at 12:46:51AM +0100, Joerg Sonnenberger wrote:
the attached patch against 1.23 limits the time a single client can
consume for one pull request on the server.
I've pushed a version of this to the experimental patch. Testing
especially on Windows is appreciated.
Joerg
Hi all,
the attached patch against 1.23 limits the time a single client can
consume for one pull request on the server. The problem here is that
with background IO and larger delta chains, I often see transactions
with 2min or more runtime on my server. The NGINX instance in front is
configured
On Thu, Jan 10, 2013 at 10:19:31AM +, Michai Ramakers wrote:
Hello,
On Thu, Jan 10, 2013 at 1:03 AM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
On Wed, Jan 09, 2013 at 05:02:14PM +, Michai Ramakers wrote:
apart from the question whether cloning from localhost makes sense
On Wed, Jan 09, 2013 at 05:02:14PM +, Michai Ramakers wrote:
apart from the question whether cloning from localhost makes sense or
not (I use this from a script to make work from localhost or remote
transparent), I experienced very slow network traffic - but no hang -
while cloning like
On Tue, Jan 08, 2013 at 02:59:10PM +0100, Gilles wrote:
How do we cancel the result of add, ie. tell Fossil to *not* add
such and such new file the next time the user runs fossil commit?
fossil revert. Arguably, it is a bug that fossil rm doesn't work.
Joerg
On Tue, Jan 08, 2013 at 03:55:05PM +0100, Gilles wrote:
On Tue, 8 Jan 2013 15:50:10 +0100, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
On Tue, Jan 08, 2013 at 02:59:10PM +0100, Gilles wrote:
How do we cancel the result of add, ie. tell Fossil to *not* add
such and such new file
On Sun, Dec 30, 2012 at 02:05:38PM -0600, Nico Williams wrote:
I repeat: git rebase does not manipulate the pre-existing tree, it
does not destroy any history already in the tree. The only
destructive action that git rebase does is change the commit that a
branch _name_ points to, and from a
On Fri, Dec 21, 2012 at 12:30:25PM +0100, Stefan Bellon wrote:
In total, the Subversion repositories hold over 45000 revisions. The
first 5000 revisions were converted in a quite acceptable time. But
then things started to slow down. At the moment (at revision 8150) one
Fossil commit takes
On Fri, Dec 21, 2012 at 09:33:26AM -0500, Richard Hipp wrote:
On Fri, Dec 21, 2012 at 8:25 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Fri, Dec 21, 2012 at 12:30:25PM +0100, Stefan Bellon wrote:
In total, the Subversion repositories hold over 45000 revisions. The
first
On Thu, Jul 26, 2012 at 07:49:45PM +0200, Stephan Beal wrote:
On Thu, Jul 26, 2012 at 7:43 PM, Doug Currie doug.cur...@gmail.com wrote:
It's saying that you are only clearing the first pointer of struct path
rather than the whole structure; it should be:
memset(path, 0,
On Thu, Jul 26, 2012 at 10:46:52PM +0100, David Given wrote:
On 26/07/12 22:05, Joerg Sonnenberger wrote:
[...]
It's a popular CP error. Don't know how many instances of it I fixed in
various OSS projects...
FWIW, there's a little-known wrinkle in the C spec that states that
while *un
On Fri, Jun 15, 2012 at 11:13:57AM +0200, Gour wrote:
I'd like to export one repo from Fossil to Bazaar but it fails with:
[gour@atmarama task.git] fossil export --git ../task.fossil| git
fast-import fatal: mark :711 not declared
fast-import: dumping crash report to
On Tue, May 15, 2012 at 06:20:28PM +0200, Stephan Beal wrote:
1.5) If you happen to know of a *flat-rate* mobile internet provider in
Germany, please let me know!
BILD.mobil might be the best option. They have pre-paid data cards for
around 7EUR / week, 1GB high speed. You might need someone in
On Wed, Jan 25, 2012 at 12:16:51PM +0100, Antoine Chavasse wrote:
I have the same issue with one of my repo and I used bisect to
pinpoint it to this commit:
http://fossil-scm.org/index.html/info/bc8d368b66053450c7f323b4e479fb5b4a878684
I don't know how the git export works though, so no
On Sun, Jan 08, 2012 at 12:42:17PM -0800, Russ Paielli wrote:
I am wondering about fossil/git interaction. Everyone else seems to be
using git and github. I see that fossil can import from, and export to,
git. If I understand it correctly, however, that is only for creating a new
fossil or git
On Mon, Jan 09, 2012 at 03:52:02PM -0800, Andreas Kupries wrote:
On 1/9/2012 12:16 PM, Joerg Sonnenberger wrote:
On Sun, Jan 08, 2012 at 12:42:17PM -0800, Russ Paielli wrote:
I am wondering about fossil/git interaction. Everyone else seems to be
using git and github. I see that fossil can
On Fri, Nov 25, 2011 at 11:17:20AM -0700, Matt Welland wrote:
sync via ssh
=
From my comments in another thread: I knew that ssh access did not work
with fsecure but I just tested it and can't get it to work with openssh. If
someone can confirm that using ssh as a transport mechanism
On Fri, Nov 25, 2011 at 01:36:43PM -0700, Matt Welland wrote:
Regarding the use of ftp as a model for URLs - seems like a poor choice to
me but whatever works is fine. I didn't find the /// in any of the rfc's
for ftp - maybe it is a windowsism?
Anyhow, passwordless ssh works fine for me but
On Sun, Nov 13, 2011 at 05:15:59PM -0500, Richard Hipp wrote:
2011/11/13 Lluís Batlle i Rossell vi...@viric.name
It should be quite tricky C code for a
C compiler to generate bad-aligned accesses for a given platform. I'd like
to
know where is that bad access; I've not checked, but I'd
On Fri, Nov 04, 2011 at 11:31:26AM +0200, Zeev Pekar wrote:
1) if I have 2 projects do I have to a) create 2 separate repositories
or do I b) put both source trees in one repository? if a), how do I run
fossil server to make both repositories accessible at the same time from
outside?
Create
On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote:
The only problem with binary files is that you cannot merge them.
Even that is not necessarily true. You can't merge binary files like
text files -- sure. But it doesn't mean that for a specific binary
format, a merge algorithm isn't
On Mon, Oct 17, 2011 at 12:59:00PM +1100, Christopher Vance wrote:
To do this properly, you need to be aware that some operating systems
(including OpenBSD, which I'm using) which do not allow IPv4 traffic
on IPv6 sockets, therefore requiring separate sockets for IPv4 and
IPv6. (Specificially,
On Mon, Oct 03, 2011 at 05:13:35PM +0100, Ben Summers wrote:
Might be best to also add in 'private'
Cache-Control: private, no-cache
for a more explicit description of the intent of only showing content to the
user who requested it.
That's wrong. It should have a Vary header to
101 - 200 of 250 matches
Mail list logo
