|Subject:||Re: [Gnu-arch-users] revc|
|Date:||Sun, 30 Mar 2008 20:27:13 -0700|
|User-agent:||Thunderbird 22.214.171.124 (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 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
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.
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
|[Prev in Thread]||Current Thread||[Next in Thread]|