Hi. This is a combined reply to both of your messages.
Yes. I'm interested. Excuse me, briefly, while I core dump
at you:
There are some very good ideas in Arch that are being lost.
Could you sum them up ? I'm not good enough with tla so it's clear to me.
I think I can but not in a sentence or two and not off the cuff.
An example area of the problems: the Arch concept of file identity
and the way that Arch handles renames, etc.
I have a pretty decent (not perfected, just "actionable") idea of
what Arch 2.0 should be and how revc fits in.
Is there any written form ?
No. It would be a change of gears, since I have been working
on other things, but creating a written plan for Arch 2.0 might
be a good idea. It would help make it easier to decide whether
it is worth working on.
I have some new ideas, too. Among them, first hints of how to
build-in distributed, decentralized revision control at the storage
level: make it part of what users see as the "file system". Also,
beginning to *seriously* think of ways to (a) integrate source code
revision control deeply into apps such as IDEs (e.g., "patches to
functions, not files") (b) handle other media types (e.g., a
word-processor document).
About the file system point, do you mean something like a commit would
be like a snapshot at the FS level ? a branch a snapshot copy in
another volume and such ? So that Arch 2.0/revc would be somewhere
some kind of reiser4+zfs generation 2 ? Or did I completely miss the
point ? :)
Within the tolerance of the loose way we are talking here, yes
that is right.
There's some "thesis" kind of work to be done, too. I mean
a "writing up" of things. Over the past couple of months I've
watched perhaps a dozen or so good programmers, on two mailing
lists, try to make complex decisions about revision control. In
both conversations, people wanted to summarize and compare various
systems. They were trying to construct "taxonomies" of features
of the design space, etc. And, while, yes... good programmers ...
that discussion was lame. There should (or should 'a been) a
carefully written Arch paper aimed at bringing some lucidity to
the current dialog.
You're right. revision control system is a so complex domain that a
couple years of dedicated work would be welcome. Unfortunately, I'm
afraid most (every?) programmers can't afford enough time purely on
research.
How about 2 months to write an Arch 2.0 proposal? That would be a
chance
to try to explain more clearly how I see things. Maybe that's just
interesting
and the end of it. Or maybe that's interesting and then it's more
obviously
worthwhile to put more effort into 2.0. Either way, it's a chance to
evaluate
what has been a fairly intense and under-reflected-upon history.
The "something else" projects that I'm working on aren't entirely
Arch-irrelevant either. Those are also "distributed, decentralized"
systems with persistent stores and collaborative work on documents,
etc. So, Arch stuff should come up in those projects too -- it's just
not the highest priority right now.
I've taken a quick look at flower, and I *think* I understand the link
with Arch. That project is pretty ambitious and sounds quite
appealing. but, in my humble opinion of revision control systems
newbie, is it a good idea to work on the "upper" level instead of the
base, the revision control system itself ? That said, we may just have
a different pov on dev: i tend to write down basic gears first, then
"high level" functions, you sound like working the other way :) And I
must admit I don't know which method is the best.
I won't do another step, or we'll fall into philosophy ;)
One aspect of Flower is that it contains something "very much like" a
traditional
file system. But, in this case, we're beginning to work out the
meta-data and the
semantics of modifying files so that the file-system-like-thing also
"puns" as
a "distributed-decentralized-revision-control-thing".
I stopped working on Arch 2.0 for the very simple and necessary
reason that I could not afford to continue it (and still can't).
It's not *good* that 1.x has fallen aside as it has but it could
turn out to be *convenient* if work on 2.0 were to happen, just
because the 2.0 project would retain all the wisdom of the 1.x
experience, but shed any pressing need for exact upwards compatibility.
(Can "less users" be good for a project? :-)
If someone wants to work on Arch 2.0, and is experienced enough
to collaborate with me, and has bandwidth to do the bulk of the
heavy lifting.... I'll help as I can.
I'd be interested in working on Arch 2.0, because revision control
systems are intellectually interesting to work on. But I'am a
*complete* beginner in it.
bw shouldn't be much of a problem (adsl 2+ at home 1.3MB/s download,
100KB/sec upload - no cap), and I rent a mutualised server (900MB disk
space, 600GB bw/month, http, ftp).
I don't know you well enough to guess whether we would or
would not work well together but, generically, I think it could
help if there was a "partner" to work with where we both have to
understand and agree on the plan (as a discipline of how to work
and also as a sanity check on the plan).
Heck, an optional Flower-based (basiscraft.com) "smart server"
for Arch 2.0 could be very interesting.
Agreed. I don't want to sound harsh, but, from a purely technical pov:
XML will be a problem one day of another, because of speed
Yum (the package manager), was using XML and switched to sqlite, and
is much snappier now.
I'm sure there are other examples. I don't know of any XML use in
heavy computation environment. But, well, I guess you have really good
reasons to have chosen that technology. (btw, I work as SA/dev/you
name it in a physics lab - satellite images processing and other
"light" tasks - and I swear no one ever proposed XML;))
There is a lot of crap XML technology and, "on average", popular SQL-ish
packages tend to be more mature and less crap than popular XML tech
but....
there is no intrinsic problem with XML and there are tools out there
that actually do not "suck".
But... the main problem is resources. I can't afford to work on it.
I don't like how public projects so often wind up wasting the time
of everyone involved (to some third party's benefit). I don't like
the way "inner circles" of bordering-on-success projects like Arch
turn into pitched-battle power plays and back stabbing. I see no
point to the paradigm of project mgt. Arch 1.x was born under.
I completely dislike too the way things went with tla/bazaar. I guess
such things unfortunately happen. Hopefully, most free projects evolve
nicely.
Yeah.
So, no, there are no active plans for furthering Arch 2.0 even
though, technically, it's an attractive idea. Any ideas about making
it practical for everyone are welcome.
We'd first need some docs with things to do, path to follow, technical
description of data formats etc. And, some devs much more experienced
in revision control systems than I :-).
Regards,
Laurent
So, that brings us to yr next message.
> What's the way to help you so you can try to work a little bit on revc/arch 2 ?
> I've checked gnuarch website but can't find paypal link or something.
> I hope my mail sent on the ml isn't too dumb, but it's not always easy
> to be clearly understood, as french is my main laguage and not english
> :)
My paypal address is address@hidden
If I knew a way to raise about $5K to deliver a "study" -- an informal
Arch 2.0 plan -- that could make some sense from my perspective.
The deliverable for that funding is a document (probably in the form
of web pages). The goal is to make something that sums up some key
elements of my perspective on revctl and that lays out an actionable
plan for doing it.
-t
|