[Top][All Lists]

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

Re: [Gnu-arch-users] revc

From: Thomas Lord
Subject: Re: [Gnu-arch-users] revc
Date: Sun, 30 Mar 2008 20:27:13 -0700
User-agent: Thunderbird (X11/20060808)

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

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 ( "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


 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 :-).


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.


reply via email to

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