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 sin
On 9/2/2014 16:07, Ron W wrote:
On Tue, Sep 2, 2014 at 5:09 PM, Warren Young 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.
Apparently, the projec
On Tue, Sep 2, 2014 at 3:36 PM, Ron W 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) branch/tag info i
On Tue, Sep 2, 2014 at 5:49 PM, David Given 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 oull was a an
Let me see
On Tue, Sep 2, 2014 at 2:49 PM, David Given 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
> ancestors) to
On Tue, Sep 2, 2014 at 5:09 PM, Warren Young 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.
Now that I think
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 th
(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. Re-repo
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 b
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 Tue, Sep 2, 2014 at 5:07 PM, 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 latest only", tha
On 9/2/2014 14:53, Ron W wrote:
On Tue, Sep 2, 2014 at 2:35 PM, Warren Young 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 must be limited to on
On Tue, Sep 2, 2014 at 5:04 PM, Warren Young 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 create
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 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 he
On Tue, Sep 2, 2014 at 2:35 PM, Warren Young 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?) because of the simpli
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
On 9/2/2014 08:27, Stephan Beal wrote:
On Tue, Sep 2, 2014 at 4:18 PM, 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 that project won'
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
p
On Tue, Sep 2, 2014 at 2:35 PM, David Given 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 both from the a
On Tue, Sep 2, 2014 at 10:27 AM, Stephan Beal 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 have more than 2 "
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 yo
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 wrote:
> In one of
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
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 disc
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 libr
On Sep 2, 2014 12:10 PM, "Ron W" wrote:
> On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison
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
On Tue, Sep 02, 2014 at 02:02:39PM -0400, Ron W wrote:
> On Tue, Sep 2, 2014 at 10:18 AM, 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 b
On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison
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 than Fossil or
any othe
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 subset
On Tue, Sep 2, 2014 at 10:18 AM, 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 project vs a "F
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 2 September 2014 10:08, John Long 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
>and it must no
On Tue, Sep 2, 2014 at 10:18 AM, 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 the first DVCS to
On Tue, Sep 2, 2014 at 4:18 PM, 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 address very large
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 add
On Tue, Sep 2, 2014 at 2:44 AM, Gour 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 newest uses for f
On Tue, Sep 2, 2014 at 8:57 AM, Marcelo wrote:
> 2014-09-02 5:44 GMT-03:00 Gour :
>
> > 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 think that Gour's comment was ap
2014-09-02 5:44 GMT-03:00 Gour :
> 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 keep your exhibit
On Tue, 2 Sep 2014 08:08:41 +
John Long 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 keep track of cod
On Tue, Sep 2, 2014 at 10:08 AM, John Long 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 sqlite.
That was 1
On Mon, Sep 1, 2014 at 11:49 PM, Scott Robison
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
same buttons, and ge
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)
44 matches
Mail list logo
