Re: [Gnu-arch-users] revc

[Laurent Wandrebeck]

2008/3/31, Thomas Lord <address@hidden>:
>
>  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.