Version control system better suted than SVN
Chanoch (Ken) Bloom
kbloom at gmail.com
Sun Apr 19 22:03:34 CEST 2009
On Sat, 2009-04-18 at 19:48 +0100, hessiess at 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
> 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
* 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
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the vcs-home