Greg Hudson <ghudson@MIT.EDU> writes:
> I've thought about how to do a direct mapping to the filesystem, and I
> came up with a fairly simply idea: if REPOS is the path to the
> repository, then REPOS/1 is the first revision, REPOS/2 is the second
> revision, and so on. Inside a revision, you can have a relative symlink
> back to a previous revision for an unchanged file or directory. Files
> can contain raw contents or diffs against some other path. When you're
> doing a commit, you build up a new rev in REPOS/some-id-string, and when
> you're ready to finalize the commit you merge it with any commits which
> have been made in the meantime and then rename it to REPOS/3 or whatever
> the next number is.
>
> Needs some fleshing out (I haven't mentioned properties, and you need
> some concept of relatedness in order to produce efficient diffs for the
> client), but... I wish I had this idea way back before the team decided
> to use Berkeley DB and implemented it that way. :)
New fs implementations are welcome. :-)
(I'm being serious, not sarcastic. Of course, it's a lot of work to
get it right, esp w.r.t. locking and atomicity, that's why we don't
expect to see lots of patches for new filesystem backends. But
they're still welcome.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 2006