[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] revc
From: |
Laurent Wandrebeck |
Subject: |
Re: [Gnu-arch-users] revc |
Date: |
Fri, 11 Apr 2008 15:38:40 +0200 |
2008/4/11, Laurent Wandrebeck <address@hidden>:
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.