"Greg Stein" <gstein_at_gmail.com> writes:
> > Maybe you could start by implementing merge-tracking that
> > actually works. And maybe these other projects will not stand
> > still, either.
>
> Oh, don't throw me into the merge tracking lump. I'm gonna work on
> frying some other fish, thankyouverymuch.
Urg, I reread that a couple times and still didn't see that it
doesn't come out right at all. I'm not trying to put blame on
anyone about the state of merge-tracking; as someone who never
lifted a finger to help with it, I have no right to cast blame.
I was reacting to what I read in your message, that svn is so
close to being competitive with DVCS. You need more in your
list, starting with merge tracking.
Hopefully that makes more sense.
> > more interested in seeing how individually compressed texts in a
> > content-addressable store performs.
>
> That would certainly be an interesting approach, and I think it works
> great for files up to a specific size. For large files, then I think
> you might start chewing through space "too quickly".
True, but who says you have to use the same storage strategy for
every file? Take a page from Perforce, which does not store all
file data in RCS. For +s files ("store only the head
revision"[1]), it just stores one file containing the compressed
contents. For some files, it stores a series of simple
compressed contents; maybe that's for all binary files, I'm not
sure. I saw it in a test depot, but don't know enough about
Perforce to say.
So, you could store some files as delta series. But I wonder if
"large files" are usually "binary files" which don't diff well at
all. Two versions of an rpm or of an iso of rpms don't really
look very much alike.
To put it another way: the pluggable backend is overrated; it's
possible to design a robust, flexible backend that performs well
for tiny 3-person organizations as well as giant organizations.
[1] I've heard it said that we can't do "store only head
revision" in Subversion, but it seems doable to me.
fs_file_contents would just return nothing. As for storage,
in the BDB backend you could replace the old contents with
the new. In FSFS, the old data would remain but would never
be served; we could have an optional garbage collector
script. Same for a content-addressable store.
--
Eric Gillespie <*> epg_at_pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 07:06:42 CEST