I periodically go to sites like GitHub looking for ideas on how Fossil
might be improved. So just now I was browsing the SQLite mirror that
somebody has put there. And I asked the simple question: How did this
project start? (I already know the answer, of course, but I'm curious
to see how someb
At Fri, 13 Mar 2015 20:23:51 -0400,
James Moger wrote:
> You have a great solution. If not then...
>
> 1. Corporate users/teams need client/server with a centralized/canonical
> repo. Check.
> 2. Corporate users/teams need multiple-repositories. Check, although
> configuration
> consistency/m
>
> No, I couldn't fill that role for you. I'm an independent developer
> and not associated with the core Git team.
(A bit off-topic)
I am impressed with your Blitz skin and also the relatively new skin on
the main fossil web site. Do you have any quick tips/resources on how I
can make my sites
On 3/13/15, James Moger wrote:
>
> I don't know who the intended audience of Fossil is...
Fossil was created to support the development of SQLite. All other
use (and there is more and more of that lately) is just gravy.
--
D. Richard Hipp
d...@sqlite.org
___
The SQLite mirror is GitWeb which is a Perl script that ships with Git. I
didn't name it because it is not a server like Fossil, Gitblit, Gerrit,
etc. It is usually paired with Apache & system-level SSH access. I rarely
see it anymore as there are more competent alternatives for plain viewing,
l
On Mar 13, 2015, at 4:22 PM, Graeme Pietersz wrote:
>
> On 14/03/15 03:01, Warren Young wrote:
>> I believe that once you extract the hosting services from the comparison,
>> Fossil comes out quite a bit ahead of Git.
> Even without hosted services, Git still has integration with the likes of
>
On 13.03.2015 21:55, Richard Hipp wrote:
On 3/13/15, Warren Young wrote:
Few organizations have the problem that the full power of Git solves.
And yet many organizations voluntarily take on the problems that come
with using Git. Weird.
Аnyway, Github won that game. In fact it is a good
On Fri, Mar 13, 2015 at 4:22 PM, Graeme Pietersz
wrote:
> 6. There are cases where Fossil’s single-executable philosophy really
>> matters. The ones I’ve run into amounted to cross-compiling: it’s easier
>> to build an ARM executable for a Chromebook or Raspberry Pi and copy just
>> that across
On 14/03/15 03:01, Warren Young wrote:
On Mar 13, 2015, at 6:40 AM, Graeme Pietersz wrote:
My reply to this turned out to be rather long and a bit of rant, so I turned it
into a blog post.
Some critiques:
1. The post is visually divided into two sections, pro-Fossil and pro-Git, but
the a
Hello,
here some testing result output's from tester.tcl...
I'm sorry, I could find no wiki page with instructions on how to submit bug
reports.
Thanks for your time,
Kain
DL-Version:
https://www.fossil-scm.org/download/fossil-w32-20150223162734.zip
--8<--
* Final re
On Mar 13, 2015 10:02 PM, "Andy Bradford" wrote:
, but it would seem that this is irrelevant. All that
> matters for Fossil 1.27 and older is that rid=1 is also type=ci.
The ONLY ways to get a checkin with rid 1 is for it to be the magic initial
checkin OR for it to be the first change in the re
On 3/13/15, Ron W wrote:
> On Fri, Mar 13, 2015 at 4:08 PM, Graeme Pietersz
> wrote:
>
>> I am rather stunned (and a tad concerned) that cars need 100m lines of
>> code.
>
>
> Cars don't really need that much code.
The version controlled codebase might be ~5% "running code" and ~95%
tests and do
On 3/13/15, James Moger wrote:
>> What exists in the Git world to compare to Fossil as a private,
>> self-contained, all-in-one service?
>>
>
> Feature-for-feature: GitLab
> If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash
>
Which if these (if any) is used by
http://rep
On Mar 13, 2015, at 3:37 PM, James Moger wrote:
>
>
> What exists in the Git world to compare to Fossil as a private,
> self-contained, all-in-one service?
>
> Feature-for-feature: GitLab
> If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash….
Good, thank you. Graeme, com
> What exists in the Git world to compare to Fossil as a private,
> self-contained, all-in-one service?
>
Feature-for-feature: GitLab
If you can live with less: Gitblit, Gerrit, RhodeCode, GitBucket, Stash
-J
___
fossil-users mailing list
fossil-use
On Mar 13, 2015, at 6:40 AM, Graeme Pietersz wrote:
>
> My reply to this turned out to be rather long and a bit of rant, so I turned
> it into a blog post.
Some critiques:
1. The post is visually divided into two sections, pro-Fossil and pro-Git, but
the actual prose frequently intermixes pos
sorry, forgot to say what the image is about: its the timeline after the
"swapped" the check-in on rid=1 by "reconstruct", but did not do update
before commit.
if anybody is interested, here is the git fast-export dump for a simple one
check-in:
git-one.dump
Description: Binary data
On Fri, Mar 13, 2015 at 4:28 PM, Jan Nijtmans
wrote:
> 2015-03-13 15:56 GMT+01:00 Marcel Graf :
> > Well, to kind of answer my own question: I tried it, and yes, it happens
> > too. Only using fossil version 1.27!
>
> Interesting. Thanks!
>
> Another way to trigger the 'problem' is using "fossil
>
> So are you connected to the Git community? Can you be our bridge?
>
No, I couldn't fill that role for you. I'm an independent developer and
not associated with the core Git team.
-J
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
h
Thus said Jan Nijtmans on Fri, 13 Mar 2015 16:28:47 +0100:
> Another way to trigger the 'problem' is using "fossil reconstruct".
> This function reconstructs the repository from artifacts on disk, it
> is very unlikely that the initial empty checkin is encountered as
> first artifact and
On Fri, Mar 13, 2015 at 4:08 PM, Graeme Pietersz
wrote:
> I am rather stunned (and a tad concerned) that cars need 100m lines of
> code.
Cars don't really need that much code. A luxury car could have electronic
control modules in a lot of places you might not think of. I know I was
surprised ye
On 14/03/15 01:45, bch wrote:
On 3/13/15, Graeme Pietersz wrote:
Obviously positing a link to fossil-users is a good way to have mistakes
spotted!
On 13/03/15 22:24, bch wrote:
I am sure that Git has massive advantages for some people, particularly
for large projects with huge numbers of co
On 14/03/15 01:34, Warren Young wrote:
On Mar 13, 2015, at 1:59 PM, Joerg Sonnenberger wrote:
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 eith
On Fri, Mar 13, 2015 at 4:08 PM, Jan Danielsson
wrote:
> On 13/03/15 20:55, Richard Hipp wrote:
> >> Few organizations have the problem that the full power of Git solves.
> > And yet many organizations voluntarily take on the problems that come
> > with using Git. Weird.
>
>One shouldn't und
On 3/13/15, Graeme Pietersz wrote:
> Obviously positing a link to fossil-users is a good way to have mistakes
> spotted!
>
> On 13/03/15 22:24, bch wrote:
>>> I am sure that Git has massive advantages for some people, particularly
>>> for large projects with huge numbers of collaborators. It was,
On 13/03/15 19:11, James Moger wrote:
> Hello Fossil community,
[---]
This just became my new favorite skin. Thank you for submitting this.
--
Kind Regards,
Jan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm
On 13/03/15 20:55, Richard Hipp wrote:
>> Few organizations have the problem that the full power of Git solves.
> And yet many organizations voluntarily take on the problems that come
> with using Git. Weird.
One shouldn't underestimate the power of "because everyone else does it".
--
Kind R
Obviously positing a link to fossil-users is a good way to have mistakes
spotted!
On 13/03/15 22:24, bch wrote:
I am sure that Git has massive advantages for some people, particularly for
large projects with huge numbers of collaborators. It was, after all, designed
for the Linux kernel: the
On Mar 13, 2015, at 1:59 PM, Joerg Sonnenberger wrote:
>
> 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
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 3/13/15, Warren Young wrote:
>
> Few organizations have the problem that the full power of Git solves.
>
And yet many organizations voluntarily take on the problems that come
with using Git. Weird.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-user
On 3/13/15, James Moger wrote:
> Hello Fossil community,
>
> My name is James and I am not a Fossil user, I'm a git user.
Thanks for sending in the CLA and the new skin. I announced just this
morning plans to cut a release (1.32) tomorrow morning. Even though
adding a skin is a very low-risk un
On Mar 13, 2015, at 11:38 AM, Richard Hipp wrote:
>
> not many projects have as big a
> developer base as does Linux.
The key thing about Linux’s contributor base isn’t so much its size as its
distributedness and hierarchical contribution paths. I’m sure other projects
have as many or more li
Thus said Jan Nijtmans on Fri, 13 Mar 2015 16:28:47 +0100:
> Another way to trigger the 'problem' is using "fossil reconstruct".
> This function reconstructs the repository from artifacts on disk, it
> is very unlikely that the initial empty checkin is encountered as
> first artifact and
Hello Fossil community,
My name is James and I am not a Fossil user, I'm a git user. I also happen
to run a moderately successful on-premise Git server project not unlike
Fossil, http://gitblit.com. But that is not why I am writing you.
I've long been an admirer of Fossil's integrated approach
That above quote looks to be attributed to me, but is in fact me
quoting http://pietersz.co.uk/2015/03/fossil-vs-git
:) ,
-bch
On 3/13/15, Richard Hipp wrote:
> On 3/13/15, bch wrote:
>>> I am sure that Git has massive advantages for some people, particularly
>>> for large projects with hug
On 3/13/15, bch wrote:
>> I am sure that Git has massive advantages for some people, particularly
>> for large projects with huge numbers of collaborators.
As Stephan Beal has previously pointed out, Git is *designed* to
forget things. This is a feature of Git, not a bug. Linus does not
want to
Perhaps a better reference for the cargo cult reference in my previous
post: http://en.wikipedia.org/wiki/Cargo_cult_science
:P
-bch
On 3/13/15, bch wrote:
>> I am sure that Git has massive advantages for some people, particularly
>> for large projects with huge numbers of collaborators. It wa
On 3/13/15, Andy Bradford wrote:
>
> So while Fossil 1.27 did successfully add the content (no content was
> lost) it picked the wrong file to generate the P-card.
>
> I don't know of any way to repair this.
>
There is a "parent" tag set aside for this purpose
(https://www.fossil-scm.org/
> I am sure that Git has massive advantages for some people, particularly for
> large projects with huge numbers of collaborators. It was, after all,
> designed for the Linux kernel: the largest software project ever (it is
> approaching 18 million lines of code!)
This[1] suggests otherwise.
A
Thus said Tontyna on Fri, 13 Mar 2015 13:12:25 +0100:
> A tricky SQL statement could probably create the required records...
While no content was lost, the relationship appears to have been lost,
which is why the timeline cannot figure out how to draw it.
Specifically, the problem appears t
On Fri, Mar 13, 2015 at 11:53:10AM -0400, Martin Gagnon wrote:
>
> BTW, chiselapp.com still use version 1.25 release. The same problem
> could happens easily when using the "Clone Repository" option if the
> source repo is created without initial empty check-in.
>
Sorry.. I just notice that it
On Fri, Mar 13, 2015 at 10:59:26AM +0100, Jan Nijtmans wrote:
> 2015-03-13 8:49 GMT+01:00 Stephan Beal :
> > Richard mentioned earlier that he will remove the "no initial commit" bits,
> > which will (theoretically, at least) eliminate this problem for future
> > versions. i would hate to see it go
2015-03-13 15:56 GMT+01:00 Marcel Graf :
> Well, to kind of answer my own question: I tried it, and yes, it happens
> too. Only using fossil version 1.27!
Interesting. Thanks!
Another way to trigger the 'problem' is using "fossil reconstruct".
This function reconstructs the repository from artifa
On Fri, Mar 13, 2015 at 3:35 PM, Marcel Graf
wrote:
> Hello everybody
>
> If I understood correctly from the recent discussion about repositories
> without initial check-ins (How to fix parallel timeline), the problem of
> two disconnected DAGs (and seemingly "lost" files) is triggered if
>
> A:
Hello everybody
If I understood correctly from the recent discussion about repositories
without initial check-ins (How to fix parallel timeline), the problem of
two disconnected DAGs (and seemingly "lost" files) is triggered if
A: fossil version 1.27 (or older) is used to open and work with a
B:
On 13/03/15 19:50, David Mason wrote:
You have a typo in your post:
Thanks, corrected.
"only projects I use Git on are my own"
pretty sure you meant Fossil in that phrase.
Thanks, yes. I prefer to use Fossil, but when I take over something that
is already version controlled it invariably u
You have a typo in your post:
"only projects I use Git on are my own"
pretty sure you meant Fossil in that phrase.
On 13 March 2015 at 08:40, Graeme Pietersz wrote:
>
>
> On 13/03/15 08:17, jungle Boogie wrote:
>>
>> Yes, I'm being optimistic about the userbase but we must agree Fossil
>> to mu
On 13 March 2015 at 05:59, Jan Nijtmans wrote:
> I read in this thread) with Richard's conclusion that work has been lost
> due to fossil, but David Mason should have the final word on that (the
> DELETE's in David's original story meant that those _unchanged_ files
> were removed from the working
On Fri, Mar 13, 2015 at 1:12 PM, Tontyna wrote:
> A tricky SQL statement could probably create the required records...
Nope - the db is basically just a transient cache for the manifest
(checkin) data and blobs (file content). The checkin data _is_ also in the
db, but not in a form which the db
On 13/03/15 08:17, jungle Boogie wrote:
Yes, I'm being optimistic about the userbase but we must agree Fossil
to much easier and friendlier to use.
Not always. My reply to this turned out to be rather long and a bit of
rant, so I turned it into a blog post. I hope its not spammy to post a
l
Am 13.03.2015 um 10:59 schrieb Jan Nijtmans:
If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing
reveals they are really there. Therefore, those files look as they have been
lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files
will magically
2015-03-13 8:49 GMT+01:00 Stephan Beal :
> Richard mentioned earlier that he will remove the "no initial commit" bits,
> which will (theoretically, at least) eliminate this problem for future
> versions. i would hate to see it go
+1
> (not enough to raise a fuss about it),
> but it should never h
On Fri, Mar 13, 2015 at 12:18 AM, Tontyna wrote:
> To reproduce Dave's timeline I was happy to still get Fossil 1.27 from the
> download page, but --- I think Fossil < 1.30 should be removed from there
> or at least be tagged as "don't use it with newer repos".
Richard mentioned earlier that he
On Fri, Mar 13, 2015 at 3:36 AM, Warren Young wrote:
> On Mar 12, 2015, at 7:47 PM, jungle Boogie wrote:
>>
>> Hopefully some converts will check out the Fossil project.
>
> Unlikely. They’re offering an automated migration path to GitHub:
>
> https://code.google.com/export-to-github/
Should
On Fri, Mar 13, 2015 at 3:47 AM, jungle Boogie
wrote:
> Yes, I'm being optimistic about the userbase but we must agree Fossil
> to much easier and friendlier to use.
>
FWIW, judging solely from the mailing list traffic, Fossil use seems to
have _exploded_ the past 6 months.
The most active list
56 matches
Mail list logo
