|
»
»
»
revc
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
revc
by Laurent Wandrebeck-2
::
Rate this Message:
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.kodros.fr/revc.0.0x2.tar.gz Regards, Laurent. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Andy Tai
::
Rate this Message:
Thank you for locating the Arch 2.0 prototype. It should be of interest, historically at least. On Wed, Mar 26, 2008 at 2:48 AM, Laurent Wandrebeck <l.wandrebeck@...> wrote: Hi, Andy Tai, atai@... _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Laurent Wandrebeck-2
::
Rate this Message:
2008/3/26, Andy Tai <atai@...>:
> > 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-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Andy Tai
::
Rate this Message:
I cannot say anything about revc but it seems that someone with Tom's expertise would be needed to bring it up to maturity. If Tom is not interested in it we won't see it developed further.
Tla (GNU Arch 1) has architecture limitations so it won't see improvements necessarily to be competitive with newer SCMs like git or Hg or bzr. I should make a new release with some minor interface improvements but there is no major change. So yes, GNU Arch had its glorious days but it has passed its prime... but in the history of SCMs GNU Arch will always has its place; git, Hg, bzr, etc. all have been influenced by GNU Arch. Yes, bzr is now the GNU Bazaar. On Fri, Mar 28, 2008 at 6:31 AM, Laurent Wandrebeck <l.wandrebeck@...> wrote: 2008/3/26, Andy Tai <atai@...>: -- Andy Tai, atai@... _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Ludovic Courtès-3
::
Rate this Message:
Hi,
"Andy Tai" <atai@...> writes: > Yes, bzr is now the GNU Bazaar. Ironically enough... The announcement [0] claims that "Bazaar is already supported on savanah.gnu.org", although it's actually GNU Arch (or "baz") support that's available, which just happens to work as well with Bazaar AFAIK. Incidentally, many (most?) GNU projects that no longer use CVS use Git now, as can be seen on git.sv.gnu.org. Thanks, Ludovic. [0] https://launchpad.net/bzr/+announcement/276 _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Thomas Lord
::
Rate this Message:
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. I have a pretty decent (not perfected, just "actionable") idea of what Arch 2.0 should be and how revc fits in. 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). 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. 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 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. Heck, an optional Flower-based (basiscraft.com) "smart server" for Arch 2.0 could be very interesting. 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. 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. -t Laurent Wandrebeck wrote: 2008/3/26, Andy Tai atai@...: _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Laurent Wandrebeck-2
::
Rate this Message:
2008/3/28, Thomas Lord <lord@...>:
> > 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. 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. 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-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Thomas Lord
::
Rate this Message:
Hi. This is a combined reply to both of your messages.
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.
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.
Within the tolerance of the loose way we are talking here, yes that is right.
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.
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 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).
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".
Yeah.
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 lord@... 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 _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Laurent Wandrebeck-2
::
Rate this Message:
2008/3/31, Thomas Lord <lord@...>:
> > 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-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: revc
by Laurent Wandrebeck-2
::
Rate this Message:
2008/4/11, Laurent Wandrebeck <l.wandrebeck@...>:
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 ? 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-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
rev. ctl and file systems
by Thomas Lord
::
Rate this Message:
So, the general question is "should revision control be
built-in at the storage level; should it be part of the file system". Here is a more complete description of my current best guess as to a good answer. This answer is already present in the design (and partially, in the implementation) of Flower: http://basiscraft.com Flower contains patent pending technology, I am obligated to remind people, at this juncture. (The source code at the link uses a license that the FSF describes as a free software license and that the OSI has approved as an open source license. It also helps to protect the value of any patents I may receive). ------------------------------------------------------------- As I said, "yes," loosely speaking, I see the next logical step as being to build revision control deep into the storage level. First "why" and then "how": -------------------------------------------------------------- "Why" is more than just a matter of convenience. It's a matter of necessity. The reason is because of the rising importance of portable, personal computing and because of the rising importance of distributed collaboration. When we carry around computers, and especially when we sometimes "work off-line" but then "sync-up", in effect we are (by hand) simulating a distributed file system. When two of us do that at the same time, remote from one another but working on copies of the "same files" that later we want to sync up, we are (by hand) simulating a revision control operation. Even without "off-line" operation: if two of us edit the same documents stored on the web, at the same time (as in Wikis) then, again, we need revision control functionality. Because these kinds of activities are more and more the common case (at least for personal communication or collaborative content), we are reaching a situation in which we really "want" distributed, decentralized revision control for pretty much *all* of our data. There is a group of researchers who, for many years, have worked on what I would call "conventional" approaches to (perhaps global-scale) distributed file systems. An early cite might be, for example, the Andrew file system (aka AFS). An interesting observation is that as they have wrestled with the problem of scaling upwards to global scale, and coping with networks that sometimes "partition" during a netsplit or that simply can be very slow -- they too have (long since) discovered that distributed, decentralized revision control is the only way to go. So, the need for this at the storage level is indicated from top to bottom: from what users need all the way down to what implementations require in order to work at all. That's enough "why" for now. --------------------------------------------------------------- Let's talk "how". Laurent, your message set out to nicely explore a design space and try to map out the game tree there. That's a good approach. But.... let's take one step back here. Most of what you are talking about is ways to put revctl functionality into a unix-like file system. We could imagine some future "Linux ext5 file system" that has these new capabilities. I doubt that that is the right approach, though the reasons are a little unfamiliar to many: First, memory (RAM) is inexpensive. Second, network bandwidth is tending to go up but, network latency can only go so far. Let's look at latency. Rough distance from the San Francisco Bay Area, where I live, to Boston, where the GNU project lives, is 2,700 miles. Ignoring all medium and switching costs, the best possible latency between me and Boston exceeds 14 milliseconds. In reality, it will always be much worse than that. In contrast, the latency cost of a system call on a local PC is something we typically measure in microseconds. Why does latency matter to the design of a unix-like file system? Because the traditional unix API for files encourages random access, short reads and writes, etc. It is on the basis of those properties that, for example, MySQL or Berkeley DB can reasonably run *atop* a unix file system rather than having to go to a "raw disk". The unix API makes it possible and natural; the low (local) latency makes it practical (enough). But raise that latency by an order of magnitude and, suddenly, the API no longer makes practical sense. Why does memory matter? Because that gives us an alternative: we can do more work locally in RAM (even nvram or otherwise locally persistent store) and, instead of using a unix-like API, just try to read and write large chunks, infrequently. Another practical insight here is that Unix's meta-data standards and transactional capabilities are anemic for todays needs; it's indexing capabilities all but non-existent. So, when it comes to "how" my inclination is to re-think what we mean by "file". The W3C's emerging architecture gives us a very natural answer: a "file" is (roughly speaking) the kind of thing you GET in an HTTP reply or PUT in an HTTP request. Simplifying only a little, we can say that a "file" is, therefore: 1. An envelope, containing arbitrary XML meta-data. 2. A primary payload, containing arbitrary XML data. 3. One more (possibly multi-media) "attachments" -- additional MIME "parts". My concept of a multi-forked, multi-media file here is one that might remind you a bit of, for example, the original Macintosh file system. Given that insight, "how": Well, to make a long story short my thought (in Flower) is to leverage database technology like Berkeley DB / DBXML for storage, transactions, and indexing --- and then to build revision control into the API for accessing that new kind of store. That's one reason I hesitate before investing more in Arch 2.0: I wonder if we can't render traditional unix file systems "obsolete legacy" within 5-10 years. Make some sense? Thanks, -t _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
| Free Forum Powered by Nabble | Forum Help |