On Sat, Mar 08, 2003 at 04:05:14PM -0800, Larry McVoy wrote:
> Zack Brown wrote:
> > Linus Torvalds wrote:
> > > Give it up. BitKeeper is simply superior to CVS/SVN, and will stay that
> > > way indefinitely since most people don't seem to even understand _why_
> > > it is superior.
> >
> > You make it sound like no one is even interested ;-). But it's not true! A
> > lot of people currently working on alternative version control systems would
> > like very much to know what it would take to satisfy the needs of kernel
> > development.
>
> [Long rant, summary: it's harder than you think, read on for the details]
[skipping long description]
OK, so here is my distillation of Larry's post.
Basic summary: a distributed, replicated, version controlled user level file
system with no limits on any of the file system events which may happened
in parallel. All changes must be put correctly back together, no matter how
much parallelism there has been.
* Merging.
* The graph structure.
* Distributed rename handling. Centralized systems like Subversion don't
have as many problems with this because you can only create one file in
one directory entry because there is only one directory entry available.
In distributed rename handling, there can be an infinite number of different
files which all want to be src/foo.c. There are also many rename corner-cases.
* Symbolic tags. This is adding a symbolic label on a revision. A distributed
system must handle the fact that the same symbol can be put on multiple
revisions. This is a variation of file renaming. One important thing to
consider is that time can go forward or backward.
* Security semantics. Where should they go? How can they be integrated
into the system? How are hostile users handled when there is no central
server to lock down?
* Time semantics. A distributed system cannot depend on reported time
being correct. It can go forward or backward at any rate.
I'd be willing to maintain this as the beginning of a feature list and
post it regularly to lkml if enough people feel it would be useful and not
annoying. The goal would be to identify the features/problems that would
need to be handled by a kernel-ready version control system.
Be well,
Zack
-- Zack Brown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:16 EST