revc

Hi,
In case someone cares, I've been able to find somewhere the
last
revision of revc made by Thomas Lord. sha1sum and md5sum are
the same
as the ones given on the website.
You'll find the file here: http://dl.kodro
s.fr/revc.0.0x2.tar.gz
Regards,
Laurent.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-usersgnu.org

http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://sav
annah.gnu.org/projects/gnu-arch/

2008/3/26, Andy Tai <ataignu.org>:
>
> Thank you for locating the Arch 2.0 prototype.  It
should be of interest,
> historically at least.
You're welcome.
After a bit of reading about GNU/Arch, it seems clear that
this
wonderful piece of software is falling into oblivion :-(
Tom is interested by something else, some devs left for
bazaar, some
went to git etc etc, and even the FSF is advocating for
bazaar-ng.
I don't think that tla 1.x is going to see a lot more dev,
and revc
hasn't (yet?) seen someone continuing the path opened by
Tom.
Is there somewhere any official position on tla's future ?
Is there
someone interested in its (revc) revival ?
Regards,
Laurent


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-usersgnu.org

http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://sav
annah.gnu.org/projects/gnu-arch/

2008/3/28, Thomas Lord <lordemf.net>:
>
>  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


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-usersgnu.org

http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://sav
annah.gnu.org/projects/gnu-arch/

2008/3/31, Thomas Lord <lordemf.net>:
>
>  Hi.  This is a combined reply to both of your
messages.
Hi. Sorry for the delay but real life has ben awfully busy
last days.
>
>  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.
Losing such a knowledge would be a shame.
>
>  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 guess you're the one that has to decide whether Arch 2.0
is
necessary, or if bazaar-ng, git, svn (etc) are good enough.
Anyway,
I'm afraid developping "yet another" revision
control system wouldn't
attract enough interest. Darcs or monotone, for example, are
in the
field for quite some time and don't seem to get an
increasing
popularity.
>
>  Within the tolerance of the loose way we are talking
here, yes
>  that is right.
ok.
(quick thinking) I see 4 ways here:
- Really develop a kernel level FS tailored for revision
control
system. Cons: quite a lot of work, pretty annoying to
deploy,
portability problems. We may hit too VFS
"limitations" as we may need
VFS changes. -> hard (impossible ?) to be integrated in
mainline (just
talking about linux/bsd kernels here. Reiser4 is a good
example).
Impossible with MS/Windows and other proprietary problems.
Pros: would
be fast.
- Work on top of the FS, like some kind of a tar file. Cons:
slower
than a kernel level FS (but faster than FUSE I think).
Pros:
portability. Easy to distribute (http, ftp, ssh, rsync, you
name it).
We can implement our own checksumming, snapshoting methods
as needed.
- Use FUSE (FS in userspace) : still need to read through
the doc to
see if it provides snapshots and such. Anyway, ZFS on top of
FUSE
exists, so I suppose it would be powerful enough. Cons i'm
aware of:
quite slow. Unsure about availability on MS/Win (looks like
there's a
C# version). No openBSD port.
- Work with the FS, like tla, git etc. Pros: well known.
stable. Cons:
limited by FS features (snapshotting just a part of a FS
etc) -> need
to implement it ourselves. Like in the "tar file"
like way, but may be
more difficult due to number of files etc.
My prefered way would be the "tar file" like
approach. You ?
>
>  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.
If you feel two months is ok for you, then so be it 
>
>  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).
I'll wait for your plan, and we'll see if we're on the same
path. I'll
try to get some ideas/thoughts written down and get back to
you.
>
> 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.
I unfortunately don't know a way either.
Regards,
Laurent.
PS: no need to CC me as I'm suscribed to the ML.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-usersgnu.org

http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://sav
annah.gnu.org/projects/gnu-arch/

2008/4/11, Laurent Wandrebeck <l.wandrebeckgmail.com>:
Hi again,
>  (quick thinking) I see 4 ways here:
>  - Really develop a kernel level FS tailored for
revision control
>  system. Cons: quite a lot of work, pretty annoying to
deploy,
>  portability problems. We may hit too VFS
"limitations" as we may need
>  VFS changes. -> hard (impossible ?) to be
integrated in mainline (just
>  talking about linux/bsd kernels here. Reiser4 is a
good example).
>  Impossible with MS/Windows and other proprietary
problems. Pros: would
>  be fast.
>  - Work on top of the FS, like some kind of a tar file.
Cons: slower
>  than a kernel level FS (but faster than FUSE I think).
Pros:
>  portability. Easy to distribute (http, ftp, ssh,
rsync, you name it).
>  We can implement our own checksumming, snapshoting
methods as needed.
>  - Use FUSE (FS in userspace) : still need to read
through the doc to
>  see if it provides snapshots and such. Anyway, ZFS on
top of FUSE
>  exists, so I suppose it would be powerful enough. Cons
i'm aware of:
>  quite slow. Unsure about availability on MS/Win (looks
like there's a
>  C# version). No openBSD port.
>  - Work with the FS, like tla, git etc. Pros: well
known. stable. Cons:
>  limited by FS features (snapshotting just a part of a
FS etc) -> need
>  to implement it ourselves. Like in the "tar
file" like way, but may be
>  more difficult due to number of files etc.
>  My prefered way would be the "tar file" like
approach. You ?
A fifth way came to my mind. It'd need more thinking from a
technical
POV, but here it is anyway:
- Using a SQL backend. A powerful one. That means truly
ACID, or we
wouldn't really get any pros from using it. Pros: Once the
DB
designed, no need to take care of the storage technical
details.
Easily allows to insert, update, delete, diff etc file
contents.
Snapshots are easy. Cons: each user would have to have the
backend
running on its system. quite easy if we would use sqlite or
something,
a bit more work if we would use a real DBMS like postgreSQL.
A SQL
backend looks easy to use in a centralized revision control
system.
Doesn't look so in a distributed one.
Regards,
Laurent.


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-usersgnu.org

http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://sav
annah.gnu.org/projects/gnu-arch/