Re: [Gnu-arch-users] revc

[Laurent Wandrebeck]

2008/3/28, Thomas Lord <address@hidden>:
>
>  Hi!
Hello Thomas,
>
>  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 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 ?
>
>  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 ? :)
>
>  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.
>
>  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 ;)
>
>  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).
>
>  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;))
>
>  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