On Mon, Sep 01, 2014 at 05:29:41PM +0200, Stephan Beal wrote:
Okay, more git bashing...
Yeah. It's too easy _not_ to do.
Git is just another steaming Linux-centric pile that makes me so thankful
there are people like Dr. Hipp and you and all the fossil guys.
Consider the following points:
1)
On Mon, Sep 1, 2014 at 11:49 PM, Scott Robison sc...@casaderobison.com
wrote:
Based on reading {Stephan's message}, what do you agree or disagree with?
FWIW: i am in the small minority of my colleagues who regularly have
problems with git. They seem to be able to do the same things, click the
On Tue, Sep 2, 2014 at 10:08 AM, John Long codeb...@inbox.lv wrote:
specific shells like bash or any other proprietary (yes, I said it!) gnu
LOL!
8) Source control is not a hobby for normal healthy people.
Hey! ;)
You guys scored a huge win by creating fossil and basing it on
On Tue, 2 Sep 2014 08:08:41 +
John Long codeb...@inbox.lv wrote:
8) Source control is not a hobby for normal healthy people.
It's not something to become an expert in for chest-banging purposes.
It's a critical tool that's supposed to stay the hell out of the way
and let you write and
2014-09-02 5:44 GMT-03:00 Gour g...@atmarama.net:
10) Considering 9) (above) it's a proof that those serving God, serve
other people as well.
As a atheist I protest that this is deeply unsettling and off-topic.
You believers have almost ALL the other existing forums for
yourselves. Can you
On Tue, Sep 2, 2014 at 8:57 AM, Marcelo richiead...@gmail.com wrote:
2014-09-02 5:44 GMT-03:00 Gour g...@atmarama.net:
10) Considering 9) (above) it's a proof that those serving God, serve
other people as well.
As a atheist I protest that this is deeply unsettling and off-topic.
I
On Tue, Sep 2, 2014 at 2:44 AM, Gour g...@atmarama.net wrote:
9) Source control system is not only for keeping the code - here it's
used for very general writings (even non-computer-related). (too)
specific = selfish, universal = broad-minded.
Interesting you should write this. One of my
Well said and yes, Fossil is a non-tedious, benevolent lifesaver. My
reservation being scalability of large repo support. While I am unaffected,
those professionals charged with release and maintenance of large code
bases look past Fossil and its SQLite core.
Questions:
Will Fossil ever seek to
On Tue, Sep 2, 2014 at 4:18 PM, sky5w...@gmail.com wrote:
My reservation being scalability of large repo support. While I am
unaffected, those professionals charged with release and maintenance of
large code bases look past Fossil and its SQLite core.
Questions:
Will Fossil ever seek to
On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote:
Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB
here)?
Fossil is not the first DVCS to use SQLite for local storage. That
distinction belongs to Monotone (http://www.monotone.ca/) which in addition
to being
On 2 September 2014 10:08, John Long codeb...@inbox.lv wrote:
7) A source control system should be sensible from the point of view of the
person using it to manage source code. It should not be Linux-centric. It
should not require you to understand its internals to use it effectively
I was working in Admin - Tickets - Common and realized that the lists
there are just TH1 code. I asked myself, would it work if I changed this:
set type_choices {
Code_Defect
Build_Problem
Documentation
Feature_Request
Incident
}
to this?
set type_choices {
Code Defect
On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote:
Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB
here)?
I think that the only way this will happen would be to fork Fossil into a
new project. This would be because of the overall underlying goals of the
Fossil
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 think you do.
Apparently many advanced git users have their
On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison sc...@casaderobison.com
wrote:
It certainly wouldn't work in the same way git is used by the linux kernel
team.
Git was originally created by the Linux Kernel team, including Linus. It's
hardly surprising that git would be a better fir for them
On Tue, Sep 02, 2014 at 02:02:39PM -0400, Ron W wrote:
On Tue, Sep 2, 2014 at 10:18 AM, sky5w...@gmail.com wrote:
Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB
here)?
I think that the only way this will happen would be to fork Fossil into a
new project. This
On Sep 2, 2014 12:10 PM, Ron W ronw.m...@gmail.com wrote:
On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison sc...@casaderobison.com
wrote:
It certainly wouldn't work in the same way git is used by the linux
kernel team.
Git was originally created by the Linux Kernel team, including Linus.
It's
On 9/2/14, 8:02 PM, Ron W wrote:
[...]
I think that the only way this will happen would be to fork Fossil into a
new project. This would be because of the overall underlying goals of the
Fossil project vs a Fossil-saurus project.
It may be plausible to simply implement a RDBMS wrapper library
In one of my fossil repos, I edited the tickets table by adding a column.
I wanted to pull the new column definition into a repo clone, so I said
fossil config pull all
from the other repo, to no avail. New reports, the New Ticket and Edit
Ticket pages and so on were properly synchronized,
On 9/1/2014 15:49, Scott Robison wrote:
the reasons I use fossil
have little to do with its distributed nature (though I'm using it more
often that way as time goes by).
A DVCS can be useful even to a lone developer. Several times since
switching from svn to Fossil, I've spent some of my
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
You have to run
fossil rebuild
on _all_ repositories with the new definition.
This rebuilds the derived tables (TICKET, TICKETCHNG) from the actual
tickets, and ensures that they actually have the new column you
defined.
On Tue, Sep 2, 2014 at 11:36 AM, Eric Rubin-Smith eas@gmail.com
Andreas Kupries wrote:
You have to run
fossil rebuild
on _all_ repositories with the new definition.
This rebuilds the derived tables (TICKET, TICKETCHNG) from the actual
tickets, and ensures that they actually have the new column you
defined.
Works like a charm -- thank you sir!
On Tue, Sep 2, 2014 at 10:27 AM, Stephan Beal sgb...@googlemail.com wrote:
but by very large source control i envision something akin to git's
octopus model, reaching fractally out into the universe
Fossil uses the octopus model as well. I just don't know of any projects
using Fossil that
On Tue, Sep 2, 2014 at 2:35 PM, David Given d...@cowlark.com wrote:
Perforce handles very, very large repositories very well. (Repositories
too large for git.) e.g.:
One of my clients uses Perforce. Yes, it can handle huge repositories very
well. The company has a few projects that benefit
On 9/2/2014 12:38, Joerg Sonnenberger wrote:
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.
Linus Torvalds is unique. No one else on the planet has a
On 9/2/2014 08:27, Stephan Beal wrote:
On Tue, Sep 2, 2014 at 4:18 PM, sky5w...@gmail.com
mailto:sky5w...@gmail.com wrote:
Will Fossil ever seek to address very large source control?
Fossil's main target is sqlite (it's a cyclic relationship), and in my
humble (but quite fallible) opinion
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 Tue, Sep 2, 2014 at 2:35 PM, Warren Young war...@etr-usa.com wrote:
If you have more than one computer connected to a VCS and at least one is
mobile, you should be using a DVCS. Fossil vs Git is a side issue, when it
comes to that.
I do and I use Fossil (no surprise there, right?)
On 9/2/2014 14:47, Joerg Sonnenberger wrote:
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
While disabling checksums helps with speed
http://www.fossil-scm.org/index.html/help?cmd=settings
It does not help with redundant binary images in the repo.
For that, you have to shun and rebuild.
If you could flag a file as Keep latest only, that would be less
painless. I don't mind the artifact
On Tue, Sep 2, 2014 at 5:04 PM, Warren Young war...@etr-usa.com wrote:
On 9/2/2014 14:47, Joerg Sonnenberger wrote:
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
On 9/2/2014 14:53, Ron W wrote:
On Tue, Sep 2, 2014 at 2:35 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
(This is also why I've been advocating for the uber-patch feature.
My experience with submitting patches (several different projects) has
been (a) each patch
On Tue, Sep 2, 2014 at 5:07 PM, sky5w...@gmail.com wrote:
While disabling checksums helps with speed
http://www.fossil-scm.org/index.html/help?cmd=settings
It does not help with redundant binary images in the repo.
For that, you have to shun and rebuild.
If you could flag a file as Keep
On 9/2/2014 15:07, sky5w...@gmail.com wrote:
If you could flag a file as Keep latest only, that would be less
painless.
That wouldn't work for me. I want the past versions of the image. [*]
The branch I made of the web app three years ago won't run right with
the current bitmaps. The new
On 9/2/2014 15:11, Richard Hipp wrote:
(1) Fossil *does* store binary files as diffs from their predecessor, if
they are sufficiently similar (that is, if the diff is smaller than the
file itself). the problem is that with compressed images, changing a
single pixel can potentially change most
(2) Fossil's purpose is to be able to recreate historical versions of the
project - exactly. It cannot do that if historical images have been
deleted.
I understand the purity intended, but continue to be frustrated by it. :) I
merely seek an automated way within Fossil to manage garbage.
Given the discussion in the other thread(s), I have been thinking about
pull requests. (I've also had a beer. You Have Been Warned.)
I rather like the pull request workflow from github and Bazaar, and it's
something that I rather miss from Fossil. However, given Fossil's
different philosophy, I
On Tue, Sep 2, 2014 at 5:09 PM, Warren Young war...@etr-usa.com wrote:
I've been running an open source project for a decade now, so I can tell
you from experience that a lot of patches come in that do multiple things.
Apparently, the projects I've submitted patches to have stricter rules.
Let me see
On Tue, Sep 2, 2014 at 2:49 PM, David Given d...@cowlark.com wrote:
1) C clones M's repository.
2) C does some work in multiple checkins.
3) C points the Magic Pull Request tool at a commit. This spits out a
bundle containing everything that's needed to add that commit (and its
On Tue, Sep 2, 2014 at 5:49 PM, David Given d...@cowlark.com wrote:
I rather like the pull request workflow from github and Bazaar, and it's
something that I rather miss from Fossil.
Last time I actualy used github (as opposed to simply getting the latest
sources for one thing or another), a
On Tue, Sep 2, 2014 at 3:36 PM, Ron W ronw.m...@gmail.com wrote:
Your proposal for automatically calculating a list of commits to treat as
already exported is a very good idea. Would definitely make the incremental
export much easier to use.
Your proposal to automatically strip (or rename)
On 9/2/2014 16:07, Ron W wrote:
On Tue, Sep 2, 2014 at 5:09 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
I've been running an open source project for a decade now, so I can
tell you from experience that a lot of patches come in that do
multiple things.
Proposed plan of action:
(1) Modify private branch processing to avoid the private tag and
instead simply rely on the private artifacts residing in the PRIVATE table,
which should survive a fossil rebuild. (A fossil deconstruct; fossil
reconstruct will make all private branches public since
44 matches
Mail list logo
