chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Another DVCS to look at: fossil


From: F. Wittenberger
Subject: Re: [Chicken-users] Another DVCS to look at: fossil
Date: Fri, 15 Oct 2010 21:55:45 +0200

my 0.02$ on this

a) this is a chicken mailing list, VCS's are a terrible matter - at
least for me - since they are a matter of taste (and I have none); So
better we are aware that we are off-topic!

b) every vcs I found until now was able to start a religious war even
*within* myself

c) so far I lost my nerves at at least a dozen of vcs - and if I'd ever
start to work it my own way, I would be very aware of that one fact

Continuing with the off topic for a second..

(((NB: I recently migrated all the actually used vcs of my sources to
fossil.  Not because I love it so much.  But it's kind of close.)))

So far I can subsume that whatever vcs whichever project uses, I'll find
myself merging regular directory trees (whereby I need brainpower to
exclude derived files), just because either the upstream source uses
something which confuses me, or the cvs in question does not support two
diverging trees too much, or ...eventually there is probably always a
reason for manual intervention.

I'd like to be sure, that different source trees are easily used as the
"current diff to whatever upstream vcs is in use" (i.e. no records to my
diff tool about current check out).  Including different repositories of
the same project using the same vcs.  This is probably the most
important difference to the systems I'm aware of.

Next I'd want to be able to "check in this dirtree right now" and later
tag it, *forget it* or keep it for whatever reason.  (Though if there's
someone keeping a reference to forgotten stuff, they automatically
may&should (at there expenses, e.g. hard disk). -- This "someone" would
include any other machine no matter of owner/admin).




Right now I've got most of the necessary ingredients working.  A WebDAV
mountable file system which stored as a
http://en.wikipedia.org/wiki/Merkle_tree
keeping references to whatever object was there (and throwing away the
rest during garbage collection), a sqlite3 data base storing it's block
the same way and a Scheme scripting language to control the stuff.  All
working on a byzantine replicated network.  And all implemented in
chicken (and for me, who's more a Schemer, that a Chickener, also in
RScheme, where it has been developed mostly).  (see askemos.org for more
"advertising")

Reminding to the fact that we are off-topic: I'd love to collect ideas
about what's really doing *bad* and (to lesser extend good) to you about
the vcs's you know.  Not to pollute the list, please send them my
personal way.

/Jörg

Am Freitag, den 15.10.2010, 12:47 -0400 schrieb John Gabriele:
> On Fri, Oct 15, 2010 at 9:57 AM, Christian Kellermann
> <address@hidden> wrote:
> > Hi there,
> >
> > I just noticed the fossil scm a couple of weeks ago and I wanted
> > to have a look at it. I have converted the chicken-core git repo
> > to it for fun and I have put the database online at
> > http://pestilenz.org/~ckeen/chicken.fossil.
> 
> Ah, I just remembered seeing something about fossil recently:
> http://sheddingbikes.com/posts/1276624594.html

I 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]