[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn and "mostly-binary" repositories

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2001-10-01 14:25:33 CEST

> - Efficient file transfer protocols. Using rsync might be of
> interest.

I'm not sure how rsync would fit. We are definitely much more sparing
with bytes on the wire than CVS is, though; we always send diffs where
possible, never the complete text of files.

> - Efficient file comparison. When deciding wether a local file is in
> sync with the repository, use md5sum instead of fetching and
> diffing.

What we do at the moment is store a pristine copy of each working copy
file in the admin directory. This allows us to send diffs across the
wire for commits, and to determine whether a file has been modified by
looking at mod times and performing a local diff if they're different.
Unfortunately, it also comes at a 100% space penalty in the working
copy; a checkout of a 1GB source directory will come in at 2GB.

In theory, we will make it an option in some post-1.0 release to omit
the pristine copy in the working copy, and instead use hash checksums
of some kind to decide whether a local file is in sync with the
repository. And, of course, to do a commit the client would have to
send the new complete text rather than send a diff.

> - versions and branches as usual in CVS.

We don't do versions and branches "as usual in CVS." We provide
efficient copies of directories. That's it. If I want to make a
"release branch" of a directory in my repository, I just make a copy
of it with a different name; the copy takes almost no space, but
changes to the mainline won't affect the copy and vice versa. If I
want to make a "release tag" of a directory, I make a copy and set it
non-writeable.

I think this is kind of cool from a theoretical perspective, since it
removes the concept of "branches and tags" from a node, and eliminates
all the conceptual problems associated with them (e.g. what should
happen when you create a new file and want to add it to a branch). I
can only hope that CVS users don't experience too much culture shock.
So far indications are fairly positive.

> - file locking

I don't remember our plans here. I assume we eventually want
something like "cvs watch" and "cvs edit", which you should check out
in CVS if you're not aware of them.

---------------------------------------------------------------------
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:43 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.