On Sat, 2009-04-18 at 19:48 +0100, hessi...@hessiess.com wrote: > I have recently started storing all of my data (not config files) in a > subversion repository. Previously I was using unison to synchronise my two > computers, but annoyingly it won't work over the collages proxy server due > to SSH being blocked. SVN however does work because it can be used over > HTTPS, with the added advantage of version control, reducing the chance of > loosing data and also the need to store files which `may be useful > sometime'. > > One problem I have had with SVN is it storing 2 copies of everything in > the working copy, which in the case of my home directory is much more > space than I actually have available on my laptop. So are there any > version control systems which, like SVN store all revision history server > side and work over HTTPS, but unlike SVN, only keep one copy of each file > in a working copy.
I think bzr may solve your disk space problem, though it reintroduces the protocol problem, since its http and https options are read only. (ftp operation might work for you though.) A full summary of your options: * CVS only checks out one copy of the files involved. These revision control systems have severe drawbacks for everyday use, though you might look at Joey Hess' article "At home in $CVS" (http://kitenet.net/~joey/cvshome/) to see that it can be done. All operations (including diff) have to go out to the network. The CVS directory in your working copy, though ugly, is very lightweight. (See http://www.linuxdevcenter.com/pub/a/linux/2002/01/03/cvs_intro.html) * Subversion keeps two copies as you have mentioned. * SVK keeps one copy in your working directory, but it also keeps a local repository somewhere which probably has the same drawbacks as your subversion issue (though the local repository could in principle be located on a different partition if that helps your problem.) * Git keeps a local repository with full history in your working directory. This means at least two copies of everything are stored. [The amount of history can be controlled by using the --depth option when you pull, but this can cause pushing and merges to fail. The git manpage warns of this, but in practice the warnings are a bit strict compared to the actual behavior, and you can always fetch the history further back if you have a problem, and then things should work. If you use the --depth option, the amount of history will stored locally will grow over time anyway. There is no provision for forgetting old history to save space, short of blowing away your local repository and cloning anew. The --depth option can't get you any smaller than two copies of everything.] * Monotone and Mercurial seem to work like git. They may not support limiting the amount of history you grab on an initial pull. * Darcs supports --lazy checkouts, which "get patch files only as needed". (They advertise this right on their home page, when tell you how to get their source code from their own darcs repository.) I think it might keep patches around as it decides it needs them, meaning that your locally stored history may grow backwards in time as well as forwards, as you do more stuff with your working directory. * Bzr supports history-less checkouts. See http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#getting-a-lightweight-checkout They also discuss other strategies for saving disk space when cloning repositories. -- Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory. Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/
Description: This is a digitally signed message part
_______________________________________________ vcs-home mailing list email@example.com http://lists.madduck.net/listinfo/vcs-home